Mqtt-binding - different retain bit

mqtt-binding
Tags: #<Tag:0x00007f18277b13a8>

(Dimitar Dragoev) #1

Hi,
I need to set different retain bit based on item when OH2 publish a message.

For example if I turn off Item_1
Switch Item_1 {mqtt=">[broker:/def/relay1:command:OFF:1]"} - to have Retained but
For example if I turn off Item_2
Switch Item_2 {mqtt=">[broker:/def/relay2:command:OFF:1]"} - not to have retain bit

Now as I can see this is set globally when configure the broker
broker.retain=true

BR


(Rich Koshak) #2

File a feature request Issue on the openhab1-addons repo. Though given that most of the effort is focused on the MQTT 2 binding you should look in the openhab2-addons repo for the WIP issue on MQTT 2 and chime in there as well.


(Nadir Syed) #3

I also wish to have a way of selecting when to retain or not retain messages.


(Magcode) #4

+1

would also appreciate this feature


(Rich Koshak) #5

On a different thread it occurred to me that you can set the retain bit in the broker config in mqtt.cfg. So if you need some Items to have the retain bit enabled, just define two brokers, one with the retain bit and one without. Then:

Switch Item_1 {mqtt=">[retain-broker:/def/relay1:command:OFF:1]"}
Switch Item_2 {mqtt=">[broker:/def/relay2:command:OFF:1]"}

The same would go for QOS settings.


(Magcode) #6

OH! That is brilliant!
Problem solved. Thanks @rlkoshak


(Dimitar Dragoev) #7

Thanks @rlkoshak for the hint !


(Michael Ingraham) #8

@rlkoshak,

Do you use this kind of setup for things like light switches etc.? THat is, for things that you want to have the switch in a powered off state when it boots up, you configure those items in the non-retained broker. But for items that you want to have come back on restart to the state they were in previously you use the broker with the retain flag on? Or is there a different/better method for configuring “PowerOnState” Off and “PowerOnState” Retain setups in an openHAB environment?

Thanks.

Mike


(Rich Koshak) #9

I do not. All of my main lighting is zwave. I have some sonoffs that control some things but they are basically always on and on power loss they come back on when power is restored so I don’t have to mess with retain bits or anything like that. My other MQTT actuators are momentary actuators like my garage door openers where I absolutely do not want to use the retain bit.

Whether or not this is appropriate for you is really only an question you can answer. When you send a message with the retain bit, that message will stay on that topic until another message with a retain bit gets published to that topic. This means any time the device loses its connection from the broker will get the retained message when it reconnects whether or not it has already processed that message. That may be perfectly acceptable in your case or it may be a disaster.

The tl;dr is you need to look at exactly the behavior you want and choose an approach that works for that behavior. There will not be a single solution that works in all cases.

Other common approaches is to use settings on the device to remember their prior state, System started Rules, and System started Rules with restoreOnStartup.


(Michael Ingraham) #10

Thanks @rlkoshak. Understood. You’re right, innocuous items such as lights are really not the point of concern. It’s those things such as a garage door opener or what have you where coming back online in a “safe” state is critical. I just wasn’t sure how best to configure for states to be retained or not - i.e., a best practice approach. I obviously have not yet put my head around retention (client, broker), persistence, etc. I need a “flow chart for dummies” :wink:

TTFN

Mike


(Rich Koshak) #11

And this is why I always say that home automation is hard. openHAB does a whole lot to make integrating all of these devices and sensors together and making it easy enough. But when it comes down to the minute details like these, there is nothing that openHAB can do to make it easier. You will have to work it out for yourself to determine what the correct approach is for your specific use cases. We can’t give a generic rule of thumb to guide you.

Good luck!