It is absolutely not recommended also not tested to have the same state and command topic. It might be that your openHAB goes into an endless loop of publishing ↔ receiving. I have seen several people with a sonoff so far and no one had this setup. Are you sure the state and command topics are the same? (I doubt the sonoff firmware developer was so insane).
Cheers, David
Thanks! I was wrong! I have a seperate topic 
Not sure if this helps but I have topics using mosquito like this
{mqtt=">[broker:Sonoff1/cmnd/POWER:command:*:default],<[broker:Sonoff1/stat/POWER:state:default]"}
I tested that and it works. The same topic can update the item and a sendCommand will publish on that topic. I have not tested tested the autoupdate feature.
Will do tomorrow.
The new MQTT binding can coexist with the old MQTT openHAB 1.x binding (but I really do not recommend this setup).
How do i do that
my old configuration dose not work
for me it worked without a problem. You have to have MQTT1 and MQTT bindings installed simultaneously to use both of them. MQTT1 is a legacy binding, you also have to check that.
How do i bind MQTT1 i can’t see it in the add-on binding list
Paper UI → Configuration → System → Add-on Management → Include Legacy 1.x Bindings → Save
I have successfully migrated from 1.x to 2.4 mqtt binding, even it was typo in documentations:
1.x:
mqtt.conf:
mqtt:broker.url=tcp://XXX:1883
mqtt:broker.clientId=openhab
mqtt:broker.retain=true
items:
Number GF_LivingRoom_Temperature "Temperature [%.1f °C]" <temperature> (GF_LivingRoom, gTemperature) {mqtt="<[broker:house/temp/0e82240a0000:state:default]"}
2.4:
things:
Bridge mqtt:broker:myUnsecureBroker [ host=“XXX”,secure=false ]
{
Thing topic mything {
Channels:
Type number : GF_LivingRoom_Temperature “LivingRoom temperature” [ stateTopic=“house/temp/0e82240a0000” ]
}
}
items:
Number GF_LivingRoom_Temperature "Temperature [%.1f °C]" <temperature> (GF_LivingRoom, gTemperature) {channel="mqtt:topic:myUnsecureBroker:mything:GF_LivingRoom_Temperature"}
Hope it helps as a reference.
Is there some alternative to use MQTT Actions with the new MQTT binding?
Or how can I publish MQTT messages easily? Like building the topic from rule and publishing some message on these topics?
Have you considered to read the documentation and the blog about the new MQTT binding?
I haven’t found any specific info regarding the Action (why it is not supported, why it is not a good thing to use).
What I have found out, that you can create Group and send a command to that group (so the topics will be published with the command).
See there for the action: https://www.openhab.org/addons/bindings/mqtt.generic/#rule-actions
I need clarification on this statement. Because my switch defined two different topics for on/off (like the first post) I created two channels and linked them to the same item. However, as you note, this sends the command to both MQTT topics, which immediately issues both an ON and OFF to the switch, final state is just random based on which command came last by a few milliseconds.
I feel like I must be missing something simple, but I just can’t find a way to reliable toggle this switch with the 2.4 bindings. I ended up resorting to a rule that sends the appropriate MQTT message based on command received, but this feels wrong. A hint as to what I’m missing would be very appreciated.
The new binding can’t do that and creating two channels with only duplicate the ON/OFF sent to 2 different topics.
Your approach with the rule is the correct one
That depends on the firmware. I understood this:
/CMD/off
/Cmd/on
Topics and now both receive either ON or OFF.
But a /CMD/off should not react to an ON command, should it. Or is the payload irrelevant? Then the Mqtt binding can’t really help. Because that topic layout is sooo unusual and non-mqtt like and should be fixed asap.
You mean this for Tasmota? Yes the layout of MQTT topics is really crap… would be great if it could be changed… (however I didn’t really found the greatest way of MQTT topics… Some of them uses like this: device/command is the state and device/command/0 is the command…)
However for me it is working flawlessly since upgrade…
Indeed the message payload is irrelevant, simply publishing any message, including null, to the specific topic causes the action to occur. I can literally send “OFF” to /CMD/on and the switch still turns on. The rule seems to work just fine, but with many devices I could end up with a lot of rules and I don’t see that as any improvement over just using the legacy 1.X MQTT binding, which works just fine without any rules.
I’m using the tuya-mqtt binding from TheAgentK (GitHub - TheAgentK/tuya-mqtt: Nodejs-Script to combine tuyaapi and openhab via mqtt ) so my next thought is to modify this code to apply some type of transformation to the topic based on the message. In theory it feels like it should be easy make it simply pass through the topic if it’s /CMD/on or /CMD/off, but if it’s just /CMD it could look at the message and, if ON/OFF, append on/off to the topic. That being said, I’m still a NodeJS neophyte and I haven’t even looked at the code yet, so it might be more difficult than it seems on the surface, and, unfortunately, I probably won’t have time to look at it in depth for a week or two.
@tsightler
You could also have a look at node-red
Subcribe to the topic from openHAB in a node and pass it on to two outbound mqtt node each with a different topic depending on the payload
Or with a function node your can use some Javascript to separate the payload.
It would look something like this:
That’s a really good idea. I was already looking at node-red this past week for other use cases, but leveraging it to overcome this limitation seems like a good idea. I’ll have to take a deeper look. When I first thought about your diagram it seems like I’d need to have one of these for every switch I wanted to control, however, maybe that wouldn’t really be required as I could pass the required options in the message and parse that with a function. That would make adding new devices a breeze.