All MQTT messages are published with {qos:1, retain:false}

[theagentk]

All MQTT messages are published with {qos:1, retain:false}

[tsightler]

Yes, this is just old code not yet removed, just non-functional leftovers, I don't really see it as an issue. Retain was supported previously mostly just because of topic configuration. Using retain causes too many support issues so I don't use it for any of my MQTT projects. Why would retaining an availability message be useful if it could possibly be out of date, it would continue to be as potentially inaccurate as any other state data. Feel free to describe the use case.

[mbronk]

Why would retaining an availability message be useful if it could possibly be out of date, it would continue to be as potentially inaccurate as any other state data. Feel free to describe the use case.

The way I think of it, the availability topic is different from all the others in the sense its value is computed (originates from tuya-mqtt script and not the device itself).
Meaning: contrary to other topic which can go out of date when the actuators/devices go offline, the status topic is valid as long as the script runs. Even more so, as a clean exit of tuya-mqtt also publishes an offline message (I am assuming it is through LWT, but did not check). In other words - the only case where /state topic (with retain:true) would produce an invalid value... seems to be on edge conditions, when the script exited abruptly (though even then - LWT should still have worked(?))...

Use case:
I have tuya-mqtt feeding data into OpenHab. The way I have my things structured, I am using the '/status' topic to indicate if things (lightbulbs in my case) are online or offline (so that if they're physically off... I am making the whole devices 'disabled/offline' and hiding certain control options etc.)

My startup sequence is: mosquitto --> tuya-mqtt --> (other helper frameworks) --> openhab (i.e. I deliberately start openhab last, as I want all execution engines like MQTT ready to go).
Now, if the state topic is not retained, when OpenHab connects... it doesn't get to see an 'online' message (which was published before it subscribed) and I have to manually power cycle the device for the system to resync.
(I guess I could send a get-state command or force-refresh in another way... though I thought a retained status message is the cleanest way of doing this).
Hope it makes sense. Let me know if I am missing anything...

[tsightler]

tuya-mqtt follows the same model I've used for ring-mqtt for years, i.e. no retained messages. I don't know how OpenHAB deals with online/offline notification because I use Home Assistant and, in Home Assistant, it updates homeassistant/status with Online/Offline state which is used as a trigger to let other MQTT integrations know that they should resend discovery and/or state updates. I used this method with ring-mqtt because attempting to use retained messages just led to so many people reporting issues of online status when things were offline or even no longer existing. In my experience most users just don't understand MQTT and how retain works and interacts with the HA platform. Heck, some users were using MQTT brokers with no persistent storage which caused different behaviors for different users, so I just gave up depending on retain for anything.

So I always recommended users configure birth/last will messages in Home Assistant since it supported them for years and it has since become the default. Just like ring-mqtt, tuya-mqtt listens for these birth/last will messages from Home Assistant, and automatically resends state 30 seconds later (giving the system time to stabilize). There does happen to be a bug in tuya-mqtt where it's not sending online status during this republish, but I'll get that fixed with 3.0.1.

I don't know if OpenHAB has such an option to set Birth/LWT, but, assuming so, or it at least has some way to send a message to a topic on startup, that would be my recommendation, i.e. send "online" message to homeassistent/status any time it starts/restarts so that tuya-mqtt will send an update.

[mbronk]

I agree additional complexity is best avoided. That said, to the best my best knowledge, OpenHab binding is not as smart to use birth/LTW (heck, I have the whole online/offline piece written in an overlay/custom scripting...). I sure could extend this further and add better openhab-side support... though I find it way simpler to change tuyua-mqtt :)

IMHO, the best of both worlds would be to add a configuration option to tuya-mqtt to allow the /status topic to use retained messaging (and 'off' might be a sensible default indeed).

[Flip76]

@mbronk I am also an OH-user and I was wondering if you don‘t use any OH persistance service like influx or mapdb?

[mbronk]

@Flip76 - I am actually using persistence and restoreOnStartup strategy, though `/status' is not something I want persisted openhab-side. I claim it makes more sense for such status to be closer to the actual device (in this instance: MQTT/Tuya)
As an example, if the broker fails to start, I do not want to get an 'online' message from previous session, rather see the failure and be able to react to it.

[Flip76]

Maybe I didn‘t understand your needs completely... If you start OH you will get a retained status from MQTT but this might be an old message (let‘s say tuya-mqtt didn‘t start for some reason). This would mess up your UI right?

I am using a system startup rule where I set the status to NULL, displaying a message „Startup in progress“. If tuya-mqtt is online, I will get a status update within the next 30 seconds... Also the MQTT binding supports LWT...

[mbronk]

Maybe I didn‘t understand your needs completely... If you start OH you will get a retained status from MQTT but this might be an old message (let‘s say tuya-mqtt didn‘t start for some reason). This would mess up your UI right?

Yes, it would mess up my UI, if it happened as you describe... From how I am thinking about it though - this condition should never occur. See, I don't believe that under properly implemented retention mqtt-tuya's-side, it will be possible to get a false-positive ('online' message when tuya-mqtt is offline).
I guess I might have missed a condition so am hoping you can help explain what I am missing. Here's a couple of scenarios I can think of:

1. Device: goes offline, mqtt-tuya: online, MQTT broker: online, OpenHab: online
   Behavior: mqtt-tuya publishes offline to /status topic, OpenHab reacts to that and marks device as offline

2. Device: online, mqtt-tuya: goes offline, MQTT broker: online, OpenHab: online
   Behavior: MQTT broker upon mqtt-tuya's disconnect executes LWT and sets /status as offline (OK)

3. Device: online, mqtt-tuya: fails to start, MQTT broker: online, OpenHab: online
   Behavior: No message on /status topic -> OpenHab assumes the device as offline (OK)
   Note if OH was using a cached state from persistence... it would have reported 'online' which is untrue

4. Device: online, mqtt-tuya: online, MQTT broker: dies/gets offline, OpenHab: online
   Behavior: subscriber (openhab) is unable to connect to MQTT, so the device is reported as offline (OK, because if broker is down... the device can't be managed, really)

I am using a system startup rule where I set the status to NULL, displaying a message „Startup in progress“. If tuya-mqtt is online, I will get a status update within the next 30 seconds...

Actually, I am starting with the same assumption (I send UNDEF to the managed things), but this is mostly a byproduct of OpenHab not receiving 'online' message from MQTT as it starts 2nd.
I could indeed poll for the state/force-refresh - I just find it less elegant than having the status message retained :)

Also the MQTT binding supports LWT...

Thanks, didn't know that. Could you point me at an example?
I still don't believe OH-side LWT is going to help in my case, though I would definitely want to educate myself how to configure it :)

[tsightler]

I understand all of the scenarios you describe, but the part that I'm missing is this behavior:

OpenHAB has state and is shutdown for 5 minutes while tuya-mqtt continues running and states changed. You start OpenHAB and it sees device as "online" but, in that case, how does OpenHAB know that it's current state is in sync with tuya-mqtt? Many state changes could have easily happened while OpenHAB was down, so you're going to need to trigger tuya-mqtt to send updated state data no matter what to ensure that OpenHAB state is in sync with tuya-mqtt state, regardless of whether status for a device is reported as online/offline.

If the status state is published with retain then OpenHAB would see the device as online, but could easily have old state data. I don't understand what good this is.

Also, to be clear, this state is reporting the state of the connection of tuya-mqtt to the device, it has nothing to do with tuya-mqtt connection to the MQTT broker.

[mbronk]

OpenHAB has state and is shutdown for 5 minutes while tuya-mqtt continues running and states changed. You start OpenHAB and it sees device as "online" but, in that case, how does OpenHAB know that it's current state is in sync with tuya-mqtt?

As mentioned before - I actually do not want/need OpenHAB to retain state. All I care about is a reliable online/offline message (regardless of startup order). Fact is - in my case I simply don't care about stale 'runtime' values at all - all I am after is a yes/no whether the device can be controlled this very minute.
In fact, the online->offline transition of the device invalidates the OH state state in my config (I explicitly clear it)... though for me having an up to date state of everything upon OH restart is a secondary objective at best.

so you're going to need to trigger tuya-mqtt to send updated state data no matter what

It is was the full device state I was after, then yes - I guess I would need to trigger a retrieval.

If the status state is published with retain then OpenHAB would see the device as online, but could easily have old state data. I don't understand what good this is.

You're assuming certain implementation of the client (here: OpenHab).
Actually, I don't believe it helps the discussion to narrow it down to OpenHab implementation and possible configuration workarounds (which I agree - can be applied, though then again - it is by far easier for me to fork tuya-mqtt and change 3 lines of code than do a client-side w/a).
If we talk pure state of the broker, however... to a new subscriber it would be reflecting reality (i.e. device being online, state: unknown).

[tsightler]

I'm going to close this. I appreciate your feedback but if you don't care about the device state before you start trying to control it then that sounds like a unique situation for you and you're free to modify the code for this case and maintain that yourself.

[mbronk]

@tsightler - It is your call, I understand. Need to note though that while we have been discussing my use case (where I do not care about later device items' state), my unique use case is not at all what drives the '/state' approach (I consider it universally better than current impl).

Since the change got rejected, I am happy to maintain my own fork for now. If you decide to change your mind later on - here's a relevant PR: #53 (I will close it, though if you would like to resurrect any part of it - feel free)

As an illustration, here's how it works:

mbronk@mbhab:/opt/tuya_mqtt$ sudo systemctl stop mosquitto; sudo rm /var/lib/mosquitto/mosquitto.db || true; sudo systemctl start mosquitto;
mbronk@mbhab:/opt/tuya_mqtt$ mosquitto_sub -t 'tuya/t2_candle_5w_rgb_cw/status' -v &
[1] 29079
mbronk@mbhab:/opt/tuya_mqtt$ DEBUG=tuya-mqtt:info node tuya-mqtt.js &
[2] 29213
mbronk@mbhab:/opt/tuya_mqtt$   tuya-mqtt:info Connection established to MQTT server +0ms
tuya/t2_candle_5w_rgb_cw/status online

mbronk@mbhab:/opt/tuya_mqtt$ kill %1
[1]-  Done                    mosquitto_sub -t 'tuya/t2_candle_5w_rgb_cw/status' -v
mbronk@mbhab:/opt/tuya_mqtt$ mosquitto_sub -t 'tuya/t2_candle_5w_rgb_cw/status' -v &
[3] 29877
mbronk@mbhab:/opt/tuya_mqtt$ tuya/t2_candle_5w_rgb_cw/status online

mbronk@mbhab:/opt/tuya_mqtt$ kill %2
  tuya-mqtt:info Exit code: SIGTERM +46s
mbronk@mbhab:/opt/tuya_mqtt$ tuya/t2_candle_5w_rgb_cw/status offline
  tuya-mqtt:info Exit code: 0 +1s
tuya/t2_candle_5w_rgb_cw/status offline

[2]-  Done                    DEBUG=tuya-mqtt:info node tuya-mqtt.js
mbronk@mbhab:/opt/tuya_mqtt$ DEBUG=tuya-mqtt:info node tuya-mqtt.js &
[4] 30640
mbronk@mbhab:/opt/tuya_mqtt$   tuya-mqtt:info Connection established to MQTT server +0ms
tuya/t2_candle_5w_rgb_cw/status online

mbronk@mbhab:/opt/tuya_mqtt$ kill -9 %4
mbronk@mbhab:/opt/tuya_mqtt$ tuya/t2_candle_5w_rgb_cw/status offline

[4]+  Killed                  DEBUG=tuya-mqtt:info node tuya-mqtt.js
mbronk@mbhab:/opt/tuya_mqtt$

[tsightler]

Thanks for the PR, I will certainly keep it in mind. I should note that, in theory, I agree with some of your points, but that theory was smashed into pieces by practice when I implemented a similar concept in ring-mqtt previously and I have no interest in revisiting it for now.