I am trying to setup a connection between OH3 and my local mqtt broker (mosquitto). In general, I have the bridge configured (and “Online”) and a Generic MQTT thing, on which I defined one channel and linked that to an item.
Now, if I use a Switch item and a channel type switch, I can bidirectionally send signals, i.e. if I send the corresponding command on the mqtt bus, I get the switch item updated, and if I change the status of the switch item, OH3 publishes the correct mqtt message.
When I, however, use a contact item and a corresponding contact channel on the MQTT thing, this only works in one direction, namely updates on the bus are reflected inside of OH3 (the contact item gets updated). But any update to the contact item does not publish a message on the bus.
Both configurations are 100% identical. It is just once a switch item and switch type channel and the other time it is a contact item and a contact type channel.
My use case, btw, is to send updates on specific contact items (presence detectors) onto the mqtt bus (so, exactly the case I described that is not working).
I could do a workaround by using a contact item (which is actually a given as the presence detectors are contact items) and then use a rule to change an intermediate switch that is connected to a switch type mqtt channel. This would work, but seems overly complex, especially as it is unclear to me, why the contact type only works one way.
The physical contact sensor can’t receive any commands, so it makes sense that the Item doesn’t send any.
You can use your proxy Item workaround, or just use a Switch Item instead of the Contact Item in the first place. Or use an MQTT action within a rule which publishes messages to your broker of the Contact Item changes.
You can’t send commands to an openHAB Contact type Item,by design,it represents a passive sensor.
If you have some binary gubbins that you can send commands/instructions to, you would represent that with an oipenHAB Switch type Item.
You can do that, with careful configuring. State updates are not commands. Let’s clarify, is that really want you want to do, broadcast state changes of some openHAB Item?
Ok, so that means there is no chance to “forward” a status update of a contact item? As that is (more or less) what I want to do here: transfer the contact status to the mqtt bus.
Yes, exactly. There are two KNX presence detectors that I have where I want some application to do something, when there is presence detected. Of course, I could use different means to inform the application that presence has been detected. But, frankly, I think this is exactly one of the use cases of mqtt.
Anyway, if that is not possible, I can indeed build some workaround. Either with a rule, e.g. updating an internal switch item that is connected with the mqtt bus, or using an mqtt action as @hafniumzinc has suggested. I was just wondering, why this wasn’t working as I expected.
Well, they are indeed one way devices, so closer to contacts than to switches. So, I have all of them configured as contacts. Therefore they deliver OPEN and CLOSED.
Do you suggest, I should have them rather configured as (ro) switches in OH3?
You’ll have to, but it’s not a workaround it is just using the available tools.
Obviously you cannot just pipe a KNX message to MQTT with a jumper wire, it needs to pass through an Item in openHAB.
Your choice of Contact type Item restricts what you can do, because it cannot accept commands - most bindings require commands to send external messages.
MQTT is one of those bindings.
To get MQTT to publish a message, you must either use a proxy Item that is capable of handling commands, or you must build a message direct in a rule and use MQTT Action.
Sounds like an interesting idea. I’ll give it a try.
One “proxy” item is already in OH3 as I, of course, want to see the state of the presence detectors. If I see that correctly, I would just need to add the follow profile to the mqtt channel, right?
Applying a follow profile to a Contact type Item is going to result in non-existent “commands” OPEN and CLOSED arriving at the MQTT channel. But because a lot of this stuff gets handled internally as strings, it might just work.
