TL;DR: What’s the status of MQTT and retain, particularly in the case of publishMQTT? I see lots of old messages, but no apparent resolutions.
Here’s the deal. I have a Z-wave controller that OH4 owns. That is, the controller knows how to transmit and receive, but has no intelligence. OH4 tells the controller what to transmit, and listens to it for status updates from Z-wave devices.
OH4 publishes the status of the Z-wave devices to my Mosquitto MQTT broker, so other systems in my network can access that information when they need to know. OH4 does this via a rule that calls publishMQTT, and this works well. Or would, except that without the MQTT retain flag, the status data disappears after a while. So some external system X wondering about the state of light switch Y can’t reliably find out its condition.
The MQTT RFC has a retain flag because some messages are transient, while others need to stick around until revised. And whether something should be retained is often determined on a message by message basis, not on a connection-to-the-broker basis. In most use cases, status information (e.g. “light switch Y is on”) is considered permanent data - it stays around until it’s updated. Command instructions are typically transient.
So, I need to mark my status updates as to be retained, while commands I send elsewhere are transient. People have been asking about this for several years. Are we there yet? If not, is this an active issue? I think a simple way to go would be to allow an optional third parameter on the call to publishMQTT to set the retain flag. It’s fine to have an option in channels and such if we want, but sometimes that won’t be selective enough. My rule doesn’t have a channel, nor need one, so channel-level options aren’t useful.
If this isn’t being worked on anywhere, can I open a bug report on MQTT data being lost for lack of a retain flag? If no one else wants to work on this, I probably can, but I don’t even know what language I’d be programming in, and I probably don’t know it anyway (not that that’s ever stopped me before), so an experienced OH developer would be better.
