[SOLVED] Help migrating MQTT 1.x binding to the new MQTT 2.x

Add-ons Bindings
60

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.

61

@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:
image

62

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.

63

Turns out I had a little time to look at the actual mqtt-tuya code and it really is just this code that is interpreting topics this way. It looks like it would be very easy to modify the code to have a single command topic and act instead on the message as it already does this for colors.

However, I found an even easier way to make this work for now. Following the code I noticed that the function interpreted not just command/on and command/off topic, but also command/toggle topic. While I guess this could possibly have some type of negative side effect if, for example, two things send an ON command without checking state, so an “ON” could potentially toggle the light off, but for my simple case, this is OK, and I have a strong habit of checking status before sending commands in my rules and logic anyway, so this seems good enough for me for now.

I’ll probably still take a look at updating mqtt-tuya to act on messages instead of just topics, but that probably won’t happen for a week or two.

I still have an issue with the embedded broker as it doesn’t seem to retain state during a restart even though I have a persistence file defined. Perhaps yet again this is something I just don’t understand yet, but I’ve just temporarily reverted to mosquitto for my broker while still using the 2.4 bindings.

64

Ive finally found some time to runup a test OH 2.4 instance to play around with the new MQTT binding.
Its not as scary as i initially thought and can see the benefits. @David_Graeff Great Job !

I am using hand crafted things and items files to do this.

Ive migrated over some of my Sonoff devices and some home grown stuff published out of Nodred without any problems, but have just looked at my Open Energy devices which use a regex transform.
Here is the v1 Items:

/* emonSh11 */
Number  emonsh11_ct1       "Power Circuit l [%d W]" (gEmon)  { mqtt="<[oemmqtt:emonhub/rx/11/values:state:REGEX((.*),.*,.*,.*,.*,.*)]" }
Number  emonsh11_ct2       "Power Circuit 2 [%d W]" (gEmon)  { mqtt="<[oemmqtt:emonhub/rx/11/values:state:REGEX(.*,(.*),.*,.*,.*,.*)]" }
Number  emonsh11_ct3       "Power Circuit 3 [%d W]" (gEmon)  { mqtt="<[oemmqtt:emonhub/rx/11/values:state:REGEX(.*,.*,(.*),.*,.*,.*)]" }
Number  emonsh11_ct4       "Power Circuit 4 [%d W]" (gEmon)  { mqtt="<[oemmqtt:emonhub/rx/11/values:state:REGEX(.*,.*,.*,(.*),.*,.*)]" }

A payload for emopnhub/rx/11/values may look like:

27,214,33,1340,236.9,-69

How would i go about using the REGEX transform to split this apart? or is there a better way?

Cheers,
Greg

65

Create a channel for each and add the transformation pattern:

REGEX:(.*),.*,.*,.*,.*,.* (For the first one)

If you are using text things you need to add the parameter transformationPattern="REGEX:(.*),.*,.*,.*,.*,.*"

If you are using the paperUI, you can add the transformation pattern by clicking SHOW MORE in the channel definition dialog

66

@vzorglub - Thanks for the super quick reply… ill give it a go!

edit Working a treat!

 Thing topic oem "OpenEnergyMonitor" @ "Power" {
    Channels:
        Type number : emonsh11_ct1      "Power Circuit 1 [%d W]" [ stateTopic="emonhub/rx/11/values", transformationPattern="REGEX:(.*),.*,.*,.*,.*,.*"]
        Type number : emonsh11_ct2      "Power Circuit 2 [%d W]" [ stateTopic="emonhub/rx/11/values", transformationPattern="REGEX:.*,(.*),.*,.*,.*,.*"]
        Type number : emonsh11_ct3      "Power Circuit 3 [%d W]" [ stateTopic="emonhub/rx/11/values", transformationPattern="REGEX:.*,.*,(.*),.*,.*,.*"]
        Type number : emonsh11_ct4      "Power Circuit 4 [%d W]" [ stateTopic="emonhub/rx/11/values", transformationPattern="REGEX:.*,.*,.*,(.*),.*,.*"]
        Type number : emonsh12_ct1      "Power Circuit 1 [%d W]" [ stateTopic="emonhub/rx/12/values", transformationPattern="REGEX:(.*),.*,.*,.*,.*,.*"]
        Type number : emonsh12_ct2      "Power Circuit 2 [%d W]" [ stateTopic="emonhub/rx/12/values", transformationPattern="REGEX:.*,(.*),.*,.*,.*,.*"]
        Type number : emonsh12_ct3      "Power Circuit 3 [%d W]" [ stateTopic="emonhub/rx/12/values", transformationPattern="REGEX:.*,.*,(.*),.*,.*,.*"]
        Type number : emonsh12_ct4      "Power Circuit 4 [%d W]" [ stateTopic="emonhub/rx/12/values", transformationPattern="REGEX:.*,.*,.*,(.*),.*,.*"]
               
    }
1 Like
67

Hey @Genix thanks for the example!!!

I got completely lost today when updating to openhab 2.4 and finding out that the MQTT binding has completely changed. I have sooo many items defined here via MQTT, don´t know how I can manage to transfer all of them to the new binding architecture, I am really unhappy at the moment… :frowning:

Couldn´t you have invented a migration assistent to automatically transfer all old defined items into the new structure?!

I really don´t know where to begin, atm I am running in the old legacy mode, otherwise nothing would work here… :disappointed_relieved:

68

That’s alright to run mqtt1, no worries. There are still a few bindings that need to be converted before the OH1 support will be disabled.

69

Not likely. The new MQTT binding is almost completely different. There really isn’t all that much that can be automated. It uses a fundamentally different structure with a completely different set of concepts. Even if it were possible, you would end up with a suboptimal migration.

I don’t know how long you have used OH, but this is true of all the 1.x versus 2.x bindings. The architecture is just too different.

You don’t have to transfer them all right now or even in the near future. You can keep the old 1.x version and the new 2.x version and migrate little by little as time allows.

I myself am only about 60% through the migration.

70

Hey thanks for brightening my mood :wink: I will use try to migrate them one by one as time permits then.

One thing (haha joke) that I do have problems with is the combination of paper ui and textbased configuration. Is there a strong reason why things and channels defined in the paper ui are not reflected in the text files as well? I do have some problems to understand the thing, channel, item logic atm… but maybe that’s too off topic and I should open a new thread… :confused:

71

No. Text files as they exist in their current form are legacy from OH1. There are long and heated discussions about their future. Just have a look in the developer section.

1 Like
72

Silly question from a beginner:

I am currently running mqtt binding 1.13 with mosquitto and would like to migrate my sonoff device handling to mqtt 2.4 standards (binding and imbedded broker).

Before migrating from mqtt 1.x to 2.4 - do I have to uninstall mosquitto (sudo apt-get --purge remove mosquitto)?

73

Keep the mosquitto running and use that. If you use the embedded broker, you’ll need to change the Sonoff config.
Also, the embedded broker goes down when you restart openHAB.

1 Like
74

@vzorglub Thanks, I know that I have to convert all my sonoff things from my text files to paper ui when migrating to the embedded broker.
I still want to do this, as I am only using openhab as a “user” of mosquitto and I really would like to have a “plain” installation with the embedded broker.
As far as I understand, the embedded broker does the same for “openhab connetced” devices (sonoff, miflora) as mosquitto does and is intergrated well in OH 2.4.
In order not to have two brokers running at the same time, do I have to uninstall mosquitto? Or is the embedded broker soemhow using mosquitto?

75

Since you insist to use ths embedded broker, the answer “a sort of yes”. If I’m not mistaken the mosquitto broker is running as a service which can be stopped and disabled ( the last is needed in order to not restart on the next boot). Having done that, mosquitto is still installed but not running. You can deinstall using your posted command as well.

76

Keep to use mosquitto. It is the more mature broker and uses less system resources. The embedded broker is for people who are doing home automation for the first time and want a ready-to-use system within a few clicks.

Cheers

1 Like
77

Thanks, I will follow your advice!

1 Like
78

If you have a broker running already, why re-invent the wheel.
Also, this way you avoid putting all your eggs in the same basket. If you have processes that rely on MQTT apart from openHAB. (I have) then it makes sense to ave a separate broker.
Mine is running on a Pi zero. That’s all that pi is doing and has been up for more than a year without hick ups.

79

Do you have a wild guess how long the 1.x legacy bindings will still be working?