Missing "device LWT"
bartsnijder opened this issue · comments
The LWT that was implemented now indicates the online status of the mqtt client (as expected)
What I miss is something I call a device LWT; a retained message that indicates the power status of the device. With alternative versions of hcpy this was linked to the connection status of the device. (see also https://github.com/bruestel/hcpy.git).
During restarts of domotica SW / mqtt broker / device, the last status of the device is always known and can be used in domotica rules.
To give a specific example. I have a rule that sends a message to users currently at home if the washer is finished. If multiple users were send such message, a message indicating that the washer was emptied is also send. The "door open" status is primarily used for this rule. However, if somebody powers off the device before opening the door (default usecase of the wife), I miss the "door open" message and I would like to respond to a power off message (in the form of device LWT that is send when there is no route to host)
When your washer is powered off does it become unavailable? My dishwasher stays online even when the power button is turned off. None of my devices truly turn themselves off completely.
We can probably send a per device LWT offline state, but it would be to a different topic to the main homeconnect/LWT, but should be able to do one to homeconnect/{device}/LWT fairly easily on a websocket error being received from the device.
The approach taken in @bruestel's is to have a per device MQTT connection. I'd not looked at that code but it seems to be something I've been moving more towards (pure MQTT bridge) as some of the processing in the current one seems unnecessary and meant messages didn't get passed along.
Just double checked and my washer indeed fully switches off its wifi after device-power-off and neither does seem to have a setting to keep it on.
Did it reconnect easily when powered on?
Mine doesn't seem to recover well from network failure, not sure the current website library has good timeout/keep alive support so may be worth looking at a different one, but then the sslpsk support may be harder to redo
Since the (re)connect to the device is in a try/except, I've always assumed that disconnects or issues with re-connecting would end up in hcpy printing route-error messages. I do not recall having seen those at unexpected times.
Before the existence of this repository, I have been debugging random failures (after days of proper operation) with hcpy (bruestel and osresearch versions), where the script seemed stalled and no feedback was given anymore. In the absence of any shell feedback, I was assuming/investigating possible kills of the thread.
Somewhere, I stopped spending time into this, until this repository was created.
Not sure if this issue is related? At (re)connect issues, did you still get route-error messages??