How to replicate multi stateTopic old mqtt 1 binding wiith MAP

  • Platform information:
    • Hardware: 4690k, 32GB
    • OS: Debian Buster (docker)
    • Java Runtime Environment: (docker latest)
    • openHAB version: docker latest
  • Issue of the topic: Multi stateTopic mqqt 1 bindings can not be represented with mqqt 2 :frowning:

I would like to replicate the following items:

Switch S20_1 "Coffee S20-1 Powerplug" (LR,gLight) 
   { mqtt=">[broker:cmnd/sonoff-S20-1/POWER:command:*:default],
             <[broker:stat/sonoff-S20-1/POWER:state:default],
             <[broker:stat/sonoff-S20-1/RESULT:state:JSONPATH($.POWER)],
             <[broker:tele/sonoff-S20-1/STATE:state:JSONPATH($.POWER)]
             "}
Switch S20_1_Reachable "S20-1 reachable" <contact> (gReachable)
   { mqtt="<[broker:tele/sonoff-S20-1/LWT:state:MAP(reachable.map)],
           <[broker:stat/sonoff-S20-1/RESULT:state:ON],
           <[broker:stat/sonoff-S20-1/POWER:state:ON],
           <[broker:tele/sonoff-S20-1/STATE:state:ON]
           " }

Sitemap:

    Switch item=S20_1 labelcolor=[S20_1_Reachable == "ON" = "green",S20_1_Reachable == "OFF" = "red"]

Replicating these bindings in the new mqtt 2 binding seems impossible because only one statetopic and transform can be defined per channel. Moreover, you can’t even place # at the front of the statetopic only as last character.

This is what I have so far:

Bridge mqtt:broker:openhabian [host="localhost", secure=false, clientID="OpenHAB2"]
{
    Thing topic dartboardswitch "dartboard switch" {
    Channels:
            Type switch : switch "switch" ["stateTopic="stat/dartboardswitch/POWER", commandTopic="cmnd/dartboardswitch/POWER"]

This is extremely limited as it will not detect state changes made through manual user interaction, firmware updates, powerloss. Detecting these can not be done with regular expressions in the stateTopic as the format will change severely between these topics.

I do not understand why the old bindings were deprecated as the same to have more features.

You can, however, attach multiple channels to a single item, which I think is what you ultimately want. Just separate them by a comma…

1 Like

Wouldn’t that result in them all having a different name? I am pretty sure the example below is invalid.

Channels:
            Type switch : switch "switch" [stateTopic="stat/dartboardswitch/POWER", commandTopic="cmnd/dartboardswitch/POWER"]
            Type switch : switch "switch" [stateTopic="tele/dartboardswitch/LWT",]
    }

:face_with_raised_eyebrow:
I am using this exact setup for my tasmotized sonoff-RF, switching it by RF is shown immediately.

You can’t have two channels with the same name, but once that’s fixed you can attach each one to the same item.

Once I’m back at a PC I can show some examples!

1 Like

@ttirv OK, so, to strictly do what you’re asking you can do something like:

Things

         Channels:
			Type switch : switch "Power Switch" [ 
				commandTopic="cmnd/sonoff-S20-1/POWER",
				stateTopic="stat/sonoff-S20-1/RESULT",
				transformationPattern="JSONPATH:$.POWER",
				on="ON",
				off="OFF"
			]

			Type switch : state "Power Switch 2" [ 
				stateTopic="tele/sonoff-S20-1/STATE",
				transformationPattern="JSONPATH:$.POWER",
				on="ON",
				off="OFF"
			]
         
			Type switch : reachable "Reachable" [
				stateTopic = "tele/sonoff-S20-1/LWT",
				on="Online",
				off="Offline"
			]

Items

Switch S20_1 "Coffee S20-1 Powerplug" (LR,gLight)  {channel="mqtt:topic:sonoff-S20-1:switch", channel="mqtt:topic:sonoff-S20-1:state"}
Switch S20_1_Reachable "S20-1 reachable" <contact> (gReachable)  {channel="mqtt:topic:sonoff-S20-1:switch", channel="mqtt:topic:sonoff-S20-1:state", channel="mqtt:topic:sonoff-S20-1:reachable" }

You don’t need to really use the stat/sonoff-S20-1/POWER topic because Tasmota always returns a stat/sonoff-S20-1/RESULT for any action, whether that action is caused by openHAB, or a remote, or something else.

Additionally, I don’t think using tele/sonoff-S20-1/STATE gets you anything here, other than perhaps the state of the switch if openHAB has just started (though it won’t update until the STATE topic is sent, which is periodically if left at Tasmota default).

And lastly, won’t S20_1_Reachable go OFF due to the RESULT and STATE channels, even though it is still strictly reachable? I see now that your MQTT1 only triggered this when RESULT and STATE is ON. Not quite sure how to do that in MQTT2…

1 Like

If these are running Tasmota, you can enable Home Assistant mode on Tasmota and the MQTT binding will automatically discover and create the Things for you.

When manually converting from MQTT 1.x bindings like this, you would, as has been suggested already, create a separate Channel for each config defined on an Item and link each of those Channels to the one Item. This would be the simplest one-to-one translation between the bindings.

That’s a limitation of the MQTT standard and has nothing to do with the bidning. From some IBM docs as an example:

A ‘#’ character represents a complete sub-tree of the hierarchy and thus must be the last character in a subscription topic string, such as SENSOR/#. This will match any topic starting with SENSOR/, such as SENSOR/1/TEMP and SENSOR/2/HUMIDITY.

What you would want to use is (from the same docs):

A ‘+’ character represents a single level of the hierarchy and is used between delimiters. For example, SENSOR/+/TEMP will match SENSOR/1/TEMP and SENSOR/2/TEMP.

Create a Channel with a REGEX transformation REGEX:(ON). If the REGEX doesn’t match it will fail silently. For more see MQTT 2.5 M1+ How to implement the equivalent to MQTT1 REGEX filters.

It is possible to craft a REGEX that matches more than one pattern. But in this case defining a separate Channel makes more sense.

The 2.5 MQTT binding is capable of doing everything that the 1.x binding could do (except for the event bus for which there is a reusable Rule library published) and far far more including:

  • support for Units of Measurment
  • automatic discovery of Things that follow the Home Assistant or Homie standards
  • chaining of transformations
  • can be created and managed through the REST API
  • built in support for simple conversions (e.g. recognizing on as ON), slightly more complex conversions (e.g. convert ON to {"device": "1234", "cmd": "power_on" } using an approach just like you would use in defining an Item label, and complex conversions (e.g. automatically convert a range of 0-255 to 0-100 and back for Dimmers, automatically convert RGB to HSB and back for Color Items)

There are more, those are just off the top of my head.