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