How to replicate multi stateTopic old mqtt 1 binding wiith MAP

[rlkoshak (Rich Koshak)]

@ttirv

Replicating these bindings in the new mqtt 2 binding seems impossible because only one statetopic and transform can be defined per channel.

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.

@ttirv

Moreover, you can’t even place # at the front of the statetopic only as last character.

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.

@hafniumzinc

I see now that your MQTT1 only triggered this when RESULT and STATE is ON. Not quite sure how to do that in MQTT2…

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.

@ttirv

Detecting these can not be done with regular expressions in the stateTopic as the format will change severely between these topics.

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

@ttirv

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

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.