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?
Thanks!
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
Save
Yes I know and sorry for that, but as I stated earlier in the first post I couldn’t find it Now in the final version of 2.4 clicking on the binding takes to the docs
Thanks for (indirectly) pointing me there I will try to add my MQTT items to that one.
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.
“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
You have picked the wrong Thing to add channels too 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.
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?
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.
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/192.168.75.118/state
and Command: /lightbulb/12204702807d3a49b2ae/dd28170cbf5dcd08/192.168.75.118/command/off and -on.
Now in the final version of 2.4 clicking on the binding takes to the docs 
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.