Closed btrudgill closed 4 months ago
You provided no logs, or any way to reproduce, yet somehow expect this issue to be resolved?
Realistically, I don't think it is possible that ring-mqtt is directly the cause of this. The function for arming/disarming is only called from the processCommand() function, and only if a message is received on the specific alarm/command topic. That is the only code path which can call disable, so the only way for the disarm function to be called is if ring-mqtt received a command telling it to do so.
I'd suggest looking closely at any other automations that might be incidentally triggered as part of a restart, that is by far the most likely path. Or perhaps any MQTT messages being sent with retain, as that could also potentially cause the behavior I guess.
Unless you can provide a method to reproduce reliably, or at least provide some logs of the event, there is nothing I can do about it.
Describe the Bug
Last night at 1am my unraid server is set to backup all containers (weekly), shutting down the ring-mqtt container, backing up, and restarting perfectly coincides with when my alarm was disarmed (we were alseep). On testing, issue seems to only be reproducable sometimes.
Steps to Reproduce
Arm ring alarm, then restart container and see alarm become disarmed.
Expected Behavior
Ring alarm should maintain state when the ring-mqtt container starts/restarts.
Log Output
Screenshots
No response
Config File
Install Type
Docker
Version
latest
Operating System
Unraid
Architecture
x86_64
Machine Details
Custom built Unraid server