Hue bugfix bridge offline every driver restart #922
Conversation
Whenever a driver is restart, a bridge will temporarily be marked offline while the event source connection is created. This seems to be affecting the online/offline state of children incorrectly post 0.49.x FW.
|
Channel deleted. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 70b7a0e |
… a bridge event source?
|
I'm not 100% confident that these fixes are the correct fixes for the symptoms we're seeing but I'm fine with pushing them forward to get the release moving, if we decide that's best. Firstly, the zigbee connectivity status isn't guaranteed to come in over a refresh. The only way this would be "fixing" things is by emitting events for lights that are connected to the bridge and so forcing an online event in that way, and the Hue bridge will gladly give you the last known state for a freshly disconnected device to get emitted. So it could be a false positive. The "correct" fix here would be to poll the Zigbee service for the Device directly but we don't currently store that association. Secondly, I have doubts about this statement:
Server-Sent Event connections are set up in such a way that if a client disconnects then reconnects, it notifies the server of the last event ID that it received, and the stream will "catch up" the client on anything it missed in the interrim: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/main/drivers/SmartThings/philips-hue/src/lunchbox/sse/eventsource.lua#L280 Granted there is an edge case somewhere in there where this statement would hold true if there was 0 activity on the SSE stream in between the disconnect and the reconnect, and this wouldn't hold for the case where the Hue Bridge itself loses power and so that state is no longer in the web server's memory. But this should be something exceedingly rare in a live system with just a hub or driver restart. |
…nect to a bridge event source?
Thanks for the clarification on how the bridge actually reports this. After discussing offline we should make a change that will poll the zigbee connectivity service for each device when the bridge is initialized (avoiding an http request flood). However, we should leave the refresh call in place because it seems that the attribute events emitted to ST cause the child devices to come online. |
Whenever a driver is restarted, a bridge will temporarily be marked offline while the event source connection is created. This seems to be affecting the online/offline state of children incorrectly post 0.49.x FW.