MQTT difference between OH2.5 and OH3.1

Did the use of MQTT change between OH25 and OH31.

I’m migrating a working config from OH25 to OH31.

My item file with the switch definition looks as follows

Switch NB_S1_O1_lichtWC “WC” (gLichtBeneden, gLichtMQTT) { channel=“nikobus:switch-module:mypclink:S1:output-1”, channel=“mqtt:topic:synology:lights:wc” }

My MQTT things file is as follows

Bridge mqtt:broker:synology "Synology MQTT Broker" @ "Synology NAS" [ host="", port=1883]
    Thing  topic lights "MQTT commandos lichten" {
         Type switch : wc "WC" [ stateTopic="openhab/light/NB_S1_O1_lichtWC/switch", postCommand=true]

Under OH2.5 an MQTT message with topic “openhab/light/NB_S1_O1_lichtWC” was sent every time the state of the configured switch changes. Now under OH31 this is no longer the case.

The switch does respond to incoming topics under “openhab/light/NB_S1_O1_lichtWC/switch”

I have tried configuring a commandTopic but this will only send out an MQTT message when the switch receives a command not when the state is changed without command (by the Nikobus binding for example).

What I try to achieve is have a configuration that sends out an MQTT message with the state every time the state changes and listen to a (possibly different) topic and trigger a command when message received.

Why is my config no longer sending out MQTT messages when the state changes. What has changed between OH25 and 31 that makes my config files obsolete ?

However that happened, it was not by the configuration you have shown us.

That’s right, that is how it is supposed to work.

If you want to transmit MQTT on Item state change, there are two possibilities;
Use a rule to listen for state update or change, use MQTT Action to send.
As you want to ‘follow’ an incoming channel, use the follow profile. This does a kind of conversion from state update to a command.

In neither case do you want postCommand=true on your MQTT channel, which converts incoming MQTT messages to openHAB Item commands.

Thanks @rossko57

Agree doesn’t make sense but looked at all rules and can’t figure out why it behaves like that in OH25.

That being said your suggestion about the follow profile was great as I now manage to achieve desired behaviour without needing rules.

I now have the following item line

Switch NB_S1_O1_lichtWC "WC" <light> (gLichtBeneden, gLichtMQTT, gLichtAllOff) { channel="nikobus:switch-module:mypclink:S1:output-1", channel="mqtt:topic:synology:lights:wc" [profile="follow"] }

And this MQTT channel line in same as above MQTT thing setup

Type switch : wc "WC" [ stateTopic="openhab/light/NB_S1_O1_lichtWC/switch", commandTopic="openhab/light/NB_S1_O1_lichtWC",postCommand=true]

only minor remark is it now sends out 2 MQTT messages on the command topic when a command is received (guess one due to the command and one due to the state change turned into a command). I can live with that and every change is sent out as I was aiming for.

I did say that you do not want postCommand=true
This converts incoming MQTT messages on stateTopic (like say a response to a previous command) into an openHAB command to the Item, instead of the usual state update.
And then, because you have a commandTopic set, that Item command also gets posted out to MQTT.
The loop is of your own making.


yes I know but that’s exactly the behaviour my current 2,5 setup is having and the behaviour I want for this use case. And because the command is sent out on a seperate different topic that is on the other side capuring status without sending a command again I’m not having loop.

So tested it and it works freat. I didn’t know about the follow profile so learned something great :slightly_smiling_face: