The Homie convention outlines that you can use non-retained messages to process momentary items (doorbell presses, etc).
It appears, based on my understanding of the documentation that those are handled as channel triggers:
System trigger channels are supported using non-retained properties, with enum datatype and with the following formats:
Format: "PRESSED,RELEASED" -> system.rawbutton
If something is a channel trigger, is that by definition a 1-way item? For example, in a rule can I fire a channel trigger so that the binding can process it and send it back out?
In my particular use case the momentary button should be bi-directional.
openHAB defines triggers channels as unidirectional and stateless events, so no, they can’t be bi-directional. In fact, triggers channels should be seen as “remote control” elements and you should link them to the real item device (zigbee, zwave, mqtt,… “switch” type item). This channel type was introduced to avoid (or reduce) the creation of proxy items, because if you think about it carefully, a momentary button doesn’t have any state, you just press and release it, but you can’t query its state. May I ask you what are you trying to achieve?
Thanks for the response @riturrioz -
This relates to the Homie Convention implemented in the MQTT binding. I have a non-retained item which can be used for momentary buttons. Most of the details are in the post about my Polyglot binding.
Essentially, I have a PlayPause button which is bidirectional. I want Openhab to know when the remote side sends PlayPause (this is captured in the trigger) - but I also want to send PlayPause to the remote device from OpenHab.
Ok, I understand what the problem is, although I think that we can address it easily. First, a couple of questions:
Is the PlayPause button a physical button? Where is it placed? And does it toggle the real PlayPause state of the Nuvo audio system?
If the button is a physical one, is placed in an audio receiver and toggles the music state, I think that you should not model it as a non-retained property. Your PlayPause button has a state, so that should be the info sent to openHAB thought MQTT. Create a settable and retained Homie property, make (in your Kotlin script) the button toggle the PlayPause state locally (but inform about the change updating the property value) and like the property (channel) to an openHAB player item.
But the PlayPause state of your music system is decoupled from the press of that button or are they related? If pressing the button doesn’t change anything in your music system, then yes, you should model it as a non-retained topic and use the generated trigger channel in your openHAB installation (you can link the button to your audio system or to anything else). But if the button actually toggles your music, then I wouldn’t expose it to the outside world (model the button behavior in the kotlin script, internally) , because it’s usage is already coupled to something. Just expose the PlayPause state of the music system, but not the button.
