Mqtt 2.4 with switch, commandTopic and stateTopic

Hi folks,

I am starting to migrate from mqtt 1.x to mqtt2.4 and cannot get the stateTopic working for a switch.
What I am hoping is that the commandTopic sends the command but the switch state only changes once the stateTopic confirms the response. That seems logical to me.

I have
things:

Bridge mqtt:broker:mosquittoX "Mosquitto MQTT Broker" @ "MQTT" [ host="mqtt.home", secure=false, port=1883, clientID="OH2"]
{ 
    // Main Light
    Thing mqtt:topic:TestMQ "Main Light" @ "MQTT"  {
      Channels:
          Type switch : DDD "Power Switch" [ 
            commandTopic="home/lights/kitchen/SON-LIGHT-KITCHEN-CHAN/relay/0/set",
            stateTopic="home/lights/kitchen/SON-LIGHT-KITCHEN-CHAN/relay/0",
            on="ON",
            off="OFF"
            //transformationPattern="MAP:binary.map"
          ]
    }
}

Items:

Switch testSW "Main Light Switch" { channel="mqtt:topic:TestMQ:DDD" }

Now this works ok but if I change the sonoff (Espurna firmware) then I see the following in the logs:

09:59:17.207 [WARN ] [generic.internal.generic.ChannelState] - Command '0' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.0

So the message is coming back from the sonoff/mqtt but the channel does not know how to convert it (zero) to ON/OFF.
I tried using the map (binary.map which is 0=OFF,1=ON) but that does not seem to work.

Am I misunderstanding it?
Should it be a different channel altogether?

TIA

C

I have no idea how to do this in .things files. But there is a way to define 0=OFF and 1=ON when you define the Thing through PaperUI.

Also, don’t forget to set autoupdate to false on the Item. This will prevent the item from chasing state an a command until the device reports that it changed state.

I doubt that this definition is correct. Should be more like this:

Bridge mqtt:broker:mosquittoX "Mosquitto MQTT Broker" @ "MQTT" [ 
    host="mqtt.home", 
    secure=false, 
    port=1883, 
    clientID="OH2"]
{ 
    // Main Light
    Thing topic TestMQ "Main Light" @ "MQTT"  {
      Channels:
          Type switch : DDD "Power Switch" [ 
            commandTopic="home/lights/kitchen/SON-LIGHT-KITCHEN-CHAN/relay/0/set",
            stateTopic="home/lights/kitchen/SON-LIGHT-KITCHEN-CHAN/relay/0",
            on="1",
            off="0"
          ]
    }
}

So no colon and no mqtt for the topic, as the Thing is a child of the bridge.

Thanks. I’ve not looked at the UI version yet but wonder if I already have the on/off set as you’re showing it in the UI. I’ll take a look tonight and see.

I need to relook at how the Sonoff/Espurna work again.

Not sure I understand why that is different? All the examples I’ve seen show it with the colon.
Seeing as my version works, I’m confused why you suggest it’s wrong?

I’ll also try this this evening and let you know.

C

There are two options to configure a mqtt Thing, as a child of a bridge, or independently as a completely separate thing. The latter will need colons and the addon name (in addition to a link to the bridge),where the former won’t.

Well, this is now all working. I tried it through the GUI first and noticed that everything I was doing was around 15-20 seconds behind in log:tail. The light was also not responding as it should.

I restarted the OH service (running on RPi 3B+) and now it all works as it should. Final solution is:

Bridge mqtt:broker:mosquittoX "Mosquitto MQTT Broker" @ "MQTT" [ host="mqtt.home", secure=false, port=1883, clientID="OH2"]
{ 
    Main Light
    Thing mqtt:topic:TestMQ "Main Light" @ "MQTT"  {
      Channels:
          Type switch : DDD "Power Switch" [ 
            commandTopic="home/lights/kitchen/SON-LIGHT-KITCHEN-CHAN/relay/0/set",
            stateTopic="home/lights/kitchen/SON-LIGHT-KITCHEN-CHAN/relay/0",
//            on="ON",
//            off="OFF",
//If you're using the transformation you don't need this.
            transformationPattern="MAP:binary.map"
          ]

    }
}
    

I’ll stick to the files option for now until 3 comes along with the new UI :slight_smile:

Thanks for the help!

For all who experience such a bugs:
If you change transformationPattern and/or on, off parameters you need to reboot Openhab to properly reload the file. There are many bugs that exist for years regarding “unpopular” text file configuration.