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 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 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…
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.
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.