recently updated to V3.41 (from an earlier version )
the behaviour of acknowledging grid failure alarm (maybe others? but not tested)
appears to have changed.
Previously, after acknowledging, (via cerbo touchscreen) the alarm sound would cease
AND notification would cancel.
Now the notification continues to “flash” and it shows “notifications 1”.
(local cerbo alarm sound does cease however)
As a result of this- the message cerbo sends via MQTT - which im using to monitor via other IP connected device,
continually gets an alarm.
that is the MQTT alarm message doesnt get cancelled when acknowledging via cerbo touchscreen
Was there an intentional change made to the alarm behaviour that is causing this?
and for (victron) reference,
a recent (last 6?) month Venus update to cerbo “broke” or changed” the behaviour,
it didn’t previously have the “ongoing”notification issue.
(unfortunately i skipped a couple of venus updates, and hence cant pinpoit exactly which release it changed)
seems that when acknowledging the notification on Cerbo, it cancels cerbo buzzer,
but keeps the notification active? (& external devices recieving MQTT msgs etc continually get an “alarm” notification)
For me it is expected behaviour that an Alarm state remains active as long as the alarm condition is still triggered.
You can dismiss the notification, but the alarm state is still present.
In the case where there is an event notification, rather than a state condition, then it can be dismissed completely for the GX UI, but it will still show on VRM UI until it is also dismissed there. The alarm notification acknowledgement status doesn’t sync across the two.
however for sure its behaviour definitely changed at some point…
In particular… it now continues to “resend” updated alarm in the MQTT messages,
so my external apps that use this, continue to retrigger indefinitely,
regardless of acknowledging them on cerbo.
another example i recently discovered.
battery went low on a ruuvi BT tag,
and i continually get alarm messages (via the mqtt interface) even after acknowledging on cerbo.
i likewise acknowledge the alarm on the other app/s, but it continually retriggers
ie as the updated mqtt msgs are recieved.
guystewart
(Guy Stewart (Victron Community Manager))
7
There was a fix for the low battery on the Ruuvi tags added in a recent version of Venus, now that requires a larger voltage drop before the alarm is resent.
What external apps are you using that are seeing issues?
It might be how they have been designed to handle these alarm messages, we have only accounted for the behaviour of our own equipment and software.
good news on the change in battery threshold for ruuvi ,
and very wierdly … about 30min ago i got a low battery alert from another of my ruuvi tags.
… this time im going to ignore and see how long it continues to work for …
The external app
Signalk (on RPi) that ingests msgs from Cerbo (venus) via MQTT msgs.
signalk generates alerts/warnings (“notifications”) based on “notifications”
it recieves from cerbo.
the change im reffering (on cerbo) is that even after acknowledging the notification on touc screen, it continues to generate ongoing periodic notifications in MQTT msgs
(previuosly this didnt appear to occur)
guystewart
(Guy Stewart (Victron Community Manager))
9
If the issue is narrowed to SignalK on a raspberry pi - I’m going to move this over to the modifications space.
ok,
however it started from a change to the venus behaviour … it does it for
any “notificatons” generated by cerbo….
after first alerting … and an acknowledgement by user - why continue to periodically send further notyifications ? (which it dodnt previusly do …)