Closed doodieb15 closed 4 years ago
@ebaauw Could this also be useful for https://github.com/ebaauw/homebridge-hue or is the plugin notified early enough of a disconnect?
I use the ws
package to handle the web socket. According to the documentation, it supports ping/pong, but I never used this (at least consciously).
I haven't seen any issues with homebridge-hue nor with dc_eventlog
. Both reconnect automatically, when the web socket is closed. I haven't seen any delays between deCONZ stopping and the web socket reported as closed. I tend to run deCONZ and homebridge on the same Raspberry Pi, using the loopback interface. I suppose that's the most reliable channel you can get.
Occasionally, I run homebridge on a different machine (mostly when testing changes to my plugins), but haven't seen anything funny either. I haven't done any extensive testing, like pulling network cables or rebooting the network switch or router.
homebridge-otgw also uses the web sockets exposed by the OpenTherm Monitor. I haven't seen anything funny there either. But the again, I run homebridge on the same Pi as the OpenTherm monitor.
As long as the channel is reliable,everything is fine. I am running the websocket through an unreliable VPN channel and sometimes the client gets disconnected.Without the ping pong feature the client has no possibility to find out and reconnect if needed.
I've seen the same issue. After a random time the websocket connection seems to be still alive, but there comes no data. There is no message for close or error, so it is not possible to detect this situation.
It seems this issue is resolved. If it is not, please re-open!
RFC 6455 describes a mechanism to check whether a connection is still alive (ping/pong). The QT Websocket class also includes this mechanism. However, it is not implemented in the deconz REST/API, which is unfortunate. Please include this feature in the deconz REST/API, it would help to make a robust websocket connection through unreliable channels. Thanks