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.
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.
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.