Heya AK,
I'm hoping this is a plugin issue rather than a Remootio quirk....everytime the Remootio device loses wifi connectivity, the values of both the main and the .output devices get changed to -1. That in itself isn't a problem but when the remootio comes back online, both those values change again...the main device changes to the appropriate value for either open or closed, based on the current status of the gate, and the .output status changes back to 0, for ok. This change from -1 to the real current status of the main device causes on-open or on-close events to be triggered erroneously.
Wifi comes back online...
Wifi goes offline...
You can replicate this simply by putting an on-open and on-close speak event on your remootio device and then rebooting your router. As it loses and regains connectivity you'll hear your speak events triggered. Would it be possible to *not* have the main device values changed based on wifi connectivity? If the .output device value changes based on connectivity but the main device does not, it then gives the user the option to both monitor wifi connectivity and gate status change without having to worry about erroneous reports on the gate status due to changes in wifi connectivity.
As it is now, one cannot reliably trigger events based on gate status because a wifi connection change will trigger gate-open and gate-close events erroneously. For me, I have whole-house speak events on gate-open and on gate-close and this issue causes random gate announcements near dusk and dawn when the rapid temperature change effects wifi connectivity to a remootio that is at the edge of my wifi coverage.
I'm hoping this is a plugin issue rather than a Remootio quirk....everytime the Remootio device loses wifi connectivity, the values of both the main and the .output devices get changed to -1. That in itself isn't a problem but when the remootio comes back online, both those values change again...the main device changes to the appropriate value for either open or closed, based on the current status of the gate, and the .output status changes back to 0, for ok. This change from -1 to the real current status of the main device causes on-open or on-close events to be triggered erroneously.
Wifi comes back online...
Nov-07 15:28:15 | AK Remootio | [2626]: Device: Gate 207 Set to 6 |
Nov-07 15:28:14 | AK Remootio | [2627]: Device: Gate 207.Output Set to 0 |
Nov-07 15:28:14 | AK Remootio Warning | [2626]: WebSocket Connected |
Nov-07 15:28:13 | AK Remootio ERROR | [2626]: Sending {"type":"PING"} - but websocket is 'Closed', trying to open |
Nov-07 15:27:58 | AK Remootio | [2626]: Device: Gate 207 Set to -1 |
Nov-07 15:27:58 | AK Remootio | [2627]: Device: Gate 207.Output Set to -1 |
Nov-07 15:27:58 | AK Remootio Warning | [2626]: WebSocket Closed code: 1006, reason 'An exception has occurred while receiving.' |
As it is now, one cannot reliably trigger events based on gate status because a wifi connection change will trigger gate-open and gate-close events erroneously. For me, I have whole-house speak events on gate-open and on gate-close and this issue causes random gate announcements near dusk and dawn when the rapid temperature change effects wifi connectivity to a remootio that is at the edge of my wifi coverage.
Comment