[SOLVED] Help migrating MQTT 1.x binding to the new MQTT 2.x

Hi Everyone!

I have seen on the community that the old MQTT will be not supported from 2.4, we will need to use the new binding.
I have tried migrating my setup to that binding but I’m stuck. Firstly, once I saw a binding description link here (github) but I couldn’t find it now.
Secondly, I have set my broker in the binding (hope it is OK, I have left the port empty, because I’m running it on 1883, but I don’t have any username/password for the mosquitto broker and I deleted the initial admin/pass from the config, but it stays there…)

Also I don’t know, what is the Channel Id when adding a new channel to a generic MQTT Thing (it can be anything?).
Also, how can I use MAP transform in the new binding? For example I have contact sensors which reports on/off and I map it to OPEN/CLOSED. How should I do this? Select contact sensor from the list and how to add the map?

After adding an item (with a channel id 1) to a Generic MQTT Thing, the Thing went offline (No MQTT Client). What should I do?

I have been playing with this a bit recently

Start from scratch.
Deleted all your MQTT2 things.
Uninstall the binding
Stop OH
clear the cache
Start OH

Install the Binding
Things - Add thing - MQTT binding - Add Manually - MQTT broker
Change the id if you want so that it’s easy to read
Put the IP address of your broker

Let me know when done

1 Like

Thanks I’ll try that! I will have some time to play with this on the next week! I’ll let you know!

It seems that after upgrading to final 2.4 (or deleting cache) the MQTT2 things are online…

Can you give me some hint how can I use this binding? How can I apply transforms (like add a map file), etc…

as @vzorglub always says: “#$@&%*!”, which translates to: READ THE DOCS.

Yes I know and sorry for that, but as I stated earlier in the first post I couldn’t find it :frowning: Now in the final version of 2.4 clicking on the binding takes to the docs :slight_smile:

Thanks for (indirectly) pointing me there :slight_smile: I will try to add my MQTT items to that one.

Hello community,

I am also stuck in the process migrating from a Mosquitto/MQTT 1.x-Binding to the new 2.4 MQTT.

What I did so far:

  • Installed the Embedded MQTT-Broker
  • Installed the MQTT-Thing

They are both configured and running. But now I don’t know how to “translate” the old MQTT-Actions to items
and channels, I checked the documentation

which shows the “old way” in the beginning, but then does not describe how to spilt the old item in things and channels, instead it discusses auto-discovery.

So for example, I have this “old” MQTT-Item:

Switch tuya_OG_Schlafzimmer1   <light> (group_OG_Schlafzimmer_Licht)  {mqtt="<[broker:tuya/lightbulb/12204702807d3a49b2ae/dd28170cbf5dcd08/*], >[broker:tuya/lightbulb/12204702807d3a49b2ae/dd28170cbf5dcd08/], >[broker:tuya/lightbulb/12204702807d3a49b2ae/dd28170cbf5dcd08/]"}

“broker” was the name of the old Mosquitto-Broker. The embedded broker is now called “embedded-mqtt-broker”. “tuya” is the topic. How does this “translate” to the new MQTT thing and the channels?

What part of the “old” mqtt-command goes to ChannelID, what part to MQTT-Topic (tuya?), and what is the Payload? And will I need three channels for State/ON/OFF? And if I have two lightbulbs, do I need two things with three channels each, or one thing with 6 channels?

Sorry for the questions, but I am really confused now :wink:

You have picked the wrong Thing to add channels too :slight_smile: The new MQTT binding is actually two folded. You add a broker first. You can add Trigger channels to this broker (as documented). And then, as seen in the blog post, you add a Generic Mqtt Thing on which you can add different types of channels.

Everything is also possible via text files if wanted.

Every channel on openHAB has a unique ID. This has nothing to do with MQTT actually and it is a bit sad, that Paper UI is highlighting this field and not prefiling it with a randomly generated id like it does on auto-discovery etc.

So if I got it right, everything is done in the thing. The things topic would be tuya. State Topic would be


and command? How would I translate these?



This is unfortunately a little tricky. The new binding allows one state and one command topic (and sane developers publish a state to the same topic and not to different ones, I guess).
You need a bit of a workaround and define two channels with a different command topic each. The trick is to link both channels to the same item.

Yes this is how usually developers do (I can’t say that this is right or not), my all MQTT Thing is do this, it has one topic where the device subscribes for the commands and also pushes its current state…

So I add two channels to one MQTT Item in the Thing. And add this one topic to each of these channels command topic? Leave state empty? How it will know it’s state?

You add two channels to your MQTT Generic Thing. (No items involved yet)


Both have the same state. I guess it also works if one has an empty state.

Channels don’t have a state. The item has. And you only have one item.

Sorry for the confusion! I wanted to write Thing not Item!

Yes, only one item is linked to the two channels… but if both channels only have command topic (or both have state topic as well) how the item will ‘know’ which channel should it send the command and from which channel will it get it’s current state?

It doesn’t. It sends the command to both mqtt topics. But that doesn’t hurt, does it.

Regarding the state: Both channels will update the item if you set a state topic on both channels. That is not hurting either but also not necessary. One channel should have the state set.

Thanks :slight_smile: and this is not possible if I set the state and command topic to the same topic? That way I will not need two channels

And this is why we need transformations outbound…

Ehm… the issue is two different command topics for a switches on and off position. An outbound transformation would not have helped here in this case.

Yes this is not the same, but I have switches which receives on/off and also only changes state if on/off published to the topic (not ON/OFF). And plus it publishes/subcribes to the same topic.

Can I achieve this with this binding? Now I simply have a MAP file which transforms on to ON of to OFF and vice versa and the command and state also mapped by this transformation file. Is this possible?

Switch channels allow you to define custom on/offs. Look up the documentation. No need for a transformation.

In your above post you said:

State: /lightbulb/12204702807d3a49b2ae/dd28170cbf5dcd08/
and Command: /lightbulb/12204702807d3a49b2ae/dd28170cbf5dcd08/ and -on.

That’s not the same topic for me?

Thanks! I might have read the whole docs again, because I have seen that it has been extended since I last saw it.

Yes these are different topics but I only have one topic like:


and now I use it like this:


So now it seems that most of my transforms can be done by channel configuration. So in general there is no map transform available?