Page 1 of 1
3202 Alarms broken
Posted: Sun 21 Aug 2022 5:11 pm
by bduren
Hello
Not able to start after update.
I have done mono CreateMissing.exe
Repaired 3 errors.
After that try to start.
First time CMX complained regarding Wind
Second start CMX complained regarding rain.
Second MXdiags attached.
mxdiags.zip
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 5:55 pm
by mcrossley
Please disable your rain alarm in Cumulus.ini and try restarting.
Code: Select all
[Alarms]
HighRainTodayAlarmSet=0
HighRainRateAlarmSet=0
IsRainingAlarmSet=0
And I'll take a look later at what is going on.
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 6:46 pm
by bduren
Hello
Did that to no avail, sorry.
Reverting to 3196 and working good
Attach the latest MXdiags file.
Thanks for taking a look at the issue.
mxdiags (2).zip
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 6:58 pm
by mcrossley
OK, so the Wind alarms have the same issue. It looks like the Alarms are not being created for your station type for some reason. I'll take a look at the code tomorrow, looks like I missed something for a particular set of stations that includes the WMR-928 (they do not all initialise in the same way).
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 7:47 pm
by sfws
I use the old Fine Offset station type, and in new release have already checked some Alarms are working for me. My MX runs normally on a RPi without me checking what is happening.
I think the behaviour for the "data spike" functionality might have changed when the new code for determining when to skip reading data was introduced in release 3.19.0. It appears a reading was made of all zeroes, when MX was synchronising, that triggered the "data spike" alarm, and that alarm never cleared until I stopped MX and restarted with new release, while all other alarms I had enabled with similar settings had worked as normal (trigger and clearing).
I did not have time to investigate before I installed the new release today, Since I have archived all the files from my MXDiags, with some spare time it would be possible to search for when that particular alarm was triggered and when not cleared.
I have not being able to test the "data spike" functionality yet on new release, as there has been no trigger of it yet.
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 7:55 pm
by mcrossley
Thanks, the alarms got another internal work-over in v3.20.0, functionality that was spread around is now encapsulated in the alarm class. That meant the initialisation of them had to change, it looks like I didn't catch all initialisation routes. No time tonight, but I'll take a look tomorrow.
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 8:11 pm
by rogerthn
To start with I did have
2022-08-21 16:45:52.525 - WH40 sensor id = 55050 signal = 0 battery = 1.60V (OK) dummy value?
in 3202
After some time
2022-08-21 22:00:03.349 - WH40 sensor id = 55050 signal = 0 battery = 0.31V (Low)
2022-08-21 22:00:03.351 Alarm (Battery Low): Sending email
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 8:13 pm
by mcrossley
rogerthn wrote: ↑Sun 21 Aug 2022 8:11 pm
To start with I did have
2022-08-21 16:45:52.525 - WH40 sensor id = 55050 signal = 0 battery = 1.60V (OK) dummy value?
in 3202
After some time
2022-08-21 22:00:03.349 - WH40 sensor id = 55050 signal = 0 battery = 0.31V (Low)
2022-08-21 22:00:03.351 Alarm (Battery Low): Sending email
Sorry, not sure what you are saying?
The alarm looks like it is working OK.
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 8:21 pm
by rogerthn
WH40 battery level is a dummy value?
Enclosing diag from first run of 3202
20220821-164545.zip
Edit: Maybe not a dummy.
I'll replace batteries tomorrow
Good Night
Re: 3202 Alarms broken
Posted: Sun 21 Aug 2022 9:01 pm
by mcrossley
The problem is there are different versions of the WH40, newer versions report the battery voltage. Older ones do not, but report a dummy value of 1.6 V. So if the value is reported as 1.6V there is no way of knowing if it is a dummy value, or a real value that just happens to match the dummy value!
Re: 3202 Alarms broken
Posted: Mon 22 Aug 2022 1:13 pm
by mcrossley
@bduren, if you still have one, could you post the ServiceConsoleLog.txt file please?
Re: 3202 Alarms broken
Posted: Mon 22 Aug 2022 3:14 pm
by rogerthn
mcrossley wrote: ↑Sun 21 Aug 2022 9:01 pm
The problem is there are different versions of the WH40, newer versions report the battery voltage. Older ones do not, but report a dummy value of 1.6 V. So if the value is reported as 1.6V there is no way of knowing if it is a dummy value, or a real value that just happens to match the dummy value!
I was "lucky" that there was 0.31 for some time!
2022-08-21 21:52:25.659 - WH40 sensor id = 55050 signal = 0 battery = 0.31V (Low)
2022-08-21 22:00:03.349 - WH40 sensor id = 55050 signal = 0 battery = 0.31V (Low)
2022-08-21 22:20:03.694 - WH40 sensor id = 55050 signal = 0 battery = 0.31V (Low)
2022-08-21 22:40:01.149 - WH40 sensor id = 55050 signal = 1 battery = 1.60V (OK) dummy value?
2022-08-21 23:00:00.492 - WH40 sensor id = 55050 signal = 0 battery = 1.60V (OK) dummy value?
2022-08-21 23:20:00.594 - WH40 sensor id = 55050 signal = 0 battery = 1.60V (OK) dummy value?
I do have a reminder, Replace battery on the 5th of November but thanks to the mail I now have signal = 4 again on the WH40
Code: Select all
2022-08-22 16:40:03.132 - WH40 sensor id = 55050 signal = 0 battery = 1.60V (OK) dummy value?
2022-08-22 17:00:00.662 - WH40 sensor id = 55050 signal = 4 battery = 1.60V (OK) dummy value?
Sorry for the noise
Re: 3202 Alarms broken
Posted: Mon 22 Aug 2022 3:59 pm
by bduren
Hello
Here it is, the ServiceConsoleLog corresponding to the mxdiag I send earlier
ServiceConsoleLog.txt
Re: 3202 Alarms broken
Posted: Mon 22 Aug 2022 4:10 pm
by mcrossley
OK, thanks, I think I have found the problem.