[Solved] Attempt to migrate from MQTT1 to v2

Version: 2.5.6 (Build)

I thought I start migrating from mqtt1 to the v2 binding.
Found a tutorial from BK Hobby, which had v1 and v2 installed at the same time.
I installed v2 and all hell broke loose. Error messages galore.
Read on the forum that both versions won’t work together.
So I uninstalled mqtt(v2).

How did people migrate from mqtt1 to v2?
All my controllers talk MQTT.

Can I write all .things files for the controllers first, then uninstall mqtt1, install v2 and hold my breath all is working?

A different post suggested to create the broker thing and generic mqtt things via PaperUI… to then state elsewhere they use config files.

Any hints appreciated.

AFAIK this stopped being possible since 2.4.

For my MQTT1 to MQTT2 migration I actually set up a separate openHAB instance on my PC, just for trying and testing the new MQTT2 things and items definitions, while my usual system was still chugging along on the Raspberry Pi.

1 Like

Yes… this seems like the way to go…
A test set-up. Great.

If you like, post an extract from your MQTT1 setup, perhaps for a single device, and some information about the broker you’re using (hopefully Mosquitto?) and we can help translate to MQTT2.

I tried to do a step by step to integrate a simple Sonoff Basic flashed with Tasmota - the principles are all the same though: Control Tasmota flashed devices via MQTT

Another source for getting started with MQTT 2.x is MQTT 2.5 Event Bus. The first part is generic MQTT stuff which might prove useful.

I and others recommend managing all Things through PaperUI. You can’t generate syntax errors and all the options are presented there in the form including what they mean and sometimes examples of what to put in the fields. At a minimum I recommend at least creating the first one that way and then looking at the JSON and examples on the forum to convert it to a .things file. If you have a lot of similar MQTT Things to create and want to use PaperUI/Karaf Console/REST API to manage them I recommend:

  • Creating the first one through PaperUI
  • Query for that newly created one in the REST API
  • Copy the JSON to a text editor
  • Modify the JSON with the values for another Thing
  • Submit the modified JSON to the REST API

NOTE: In OH 3 the UI handles this much better. You can copy and paste everything right there in the MainUI.


I think if you install mqttv2 first then mqttv1 they will co-exist. I do this while I migrate some things over. There’s something nice an simple and satifying with the mqttv1 items format.


I couldn’t agree more!
{mqtt:<blah,>blah} made far more sense to me than linking thing and item with a somewhat cryptic config.
But then, I do not get THINGS.

I used PaperUI to create the broker thing and one generic thing.
Now I am trying to delete them and can’t get rid of it.
I restarted OH, then these two tings come back as uninitialised, and when hitting the bin, they sit on removing forever.

In my books this is not how the system should behave, and why I am so cautious about using the UI.

[edit/update] There is a force remove option in PaperUI, which got rid of both.

Isn’t this the conundrum? I need to be on a v2 binding before I migrate to OH3. Hence, the v3 UI is of no use, if mqtt1 does not run on it… I need the conversion on OH2 first, then move to OH3?!

I will try:

This should allow for a one by one (mqtt-item-rule) transition.
Otherwise I will go with a test system, and replicate your (Rich’s) set-up (which I really like), with Docker on a rPi4, also installing grafana; something I wanted to do for a long time… as it provides nice graphs for HABpanel.

Yes, just tried it… and it works. Thanks.

OK, if I take this advise… (as I wouldn’t know how to submit the JSON to REST), and add the generic mqtt things… how do I have to define them?
There is no auto-config, because these are some Arduinos.
… and what do I put into the item.

As an example, here are a few items sending / receiving mqtt commands:

String ZevaUNO_MAC			"MAC address [%s]"						<network>		(gZevaStatus)		{mqtt="<[mymosquitto:ArgyleCourt/Shed/Tower/Zeva16/MAC:state:default]"}
String ZevaUNO_Message		"SysMsg: [%s]"							<settings>		(gZevaStatus)		{mqtt="<[mymosquitto:ArgyleCourt/Shed/Tower/Zeva16/Notification:state:default]", expire="12m,Zeva Controller broken"}
String ZevaCellSetRaw		"Cell sets raw [%s]"									(gZevaStatus)		{mqtt="<[mymosquitto:ArgyleCourt/Shed/Tower/Zeva16/Voltages:state:default]"}

Number   Irrigation1_1_ValveVolume          "Stn 1.1: Outer East Volume [%d l]"             <sprinkler>     (gIrri1All, gPumpStation1_ZoneVolumes_Chart, gPersist_rrd4j)    {mqtt="<[mymosquitto:ArgyleCourt/Property/PumpStation1/Volume1:state:default]"}

Switch   PumpStation1_SoilPermittivity      "Stn 1 soil permittivity"                                       (gIrri1All)                         {mqtt=">[mymosquitto:ArgyleCourt/Property/PumpStation1/Command:command:ON:soilOn],>[mymosquitto:ArgyleCourt/Property/PumpStation1/Command:command:OFF:soilOff]"}

You gace me examples for rules the other day:

        // MQTT 2.x version
        val mqttActions = getActions("mqtt","mqtt:broker:mymosquitto") // use Thing ID for broker Thing
        mqttActions.publishMQTT(topicRoot + "Flow"   + valveNumber, valveFlow.toString)
        mqttActions.publishMQTT(TopicRoot + "Volume" + valveNumber, valveVolume.toString)

… as for “use Thing ID for broker Thing” I have (re)named to mymosquitto. :slight_smile:

[edit] I have started another thread: [Solved] Things: doing my head in :(

… and things (pun intended) have become much clearer by the minute. :slight_smile:

I wasn’t suggesting you use the OH 3 binding. I was just mentioning that the limitations of PaperUI have been addressed so that future readers of this thread don’t think that such problems were ignored and never addressed.

There is an interactive REST API Docs addon in the UI’s category. It’s all documented there and you can un the queries and submit the edited JSON from there.

There are examples and details in the MQTT 2.5 event bus tutorial I posted above. Look at the openHAB Binding Installation and Base Configuration section to set up the broker Thing.

Look at the Rules section right after that to see how to use the publishMQTT Action.

To create the Generic MQTT Thing, follow the same instructions as for the MQTT Broker Thing only choose Generic MQTT Thing from the list. Then go to that newly created Thing and click the blue + button to create a Channel. The Channel is where you will define the topics to subscribe/publish to and transformations and such.

You just put channel="full:ID:of:mqtt:channel. It’s further documented at https://www.openhab.org/docs/configuration/items.html#_2-x-binding-configuration.

1 Like

Correct, and I never assumed|said you did :slight_smile:
I meant OHv3 UI capability is no good if I need to have my bindings fixed before movinhg to OH3.

I learned a lot yesterday, when my OH production system failed after an update of OH. All hell broke loose… and some clear thinking pointed to my recent attempt to migrate to mqttv2 and installing the v2 binding, which I promptly removed, because it does not play with v1 installed.
I reckon a reboot after that would have let ended up with the same result, as my rPi/OH update a few days later.

So, by trying to get on top of it and bring OH back to talk to mosquitto, I removed the mqttv1 action and binding; and while at it, tried what another forum member suggested – install the mqtt v2 binding and then the v1 binding and action. And the minute I did this, OH was talking to mosquitto again.

So out of this turmoil came the benefit of being able to transition one Arduino controller thing at a time, at my convenience. (Thanks @psyciknz.) The latter is what made all the grief about the incident go away, as I have some 15 controllers with up to 12 channels… add the rule modifications required on top of that, and I am talking about many days I’ll need for the changes to take place.

I’m interested in this - why would you need to modify rules? Presumably your rules reference your Items? And your Items can stay the same, just remove mqtt="blah blah blah" and replace with channel="blih blih blih", right?

It’s possible that I’m missing something!

Note the reference to MQTT Actions, a rule feature.

I thought v1 / v2 actions could not coexist at all - this may need the big bang approach.

:slight_smile: No I am missing something…
I looked at this THING business most likely a year ago. Read the docs. I didn’t get the concept at the time. And didn’t bother to change… as my set-up was and is working fine.

With this OH update and the following issue of OH not talking to mosquitto, panic and a steep learning curve set it.

Now that I have actually created a few things, and was pointed to the docs, which I didn’t read recently, and which have been updated containing for more info now than a year ago, I now get the THING thing.

I have not looked at what is modifications are required for rules, where I publish directly to controller. My assumption is, if I change to channels, my publish command must be different to what I have now.
Rich has provided me with an example what a rule needs to look like with mqtt v1 and v2.
It is one thing seeing it, and another to write your own. :slight_smile:

This is the propagated truth. However, when it was pointed out to me that installing v2 and then v1 would work, and my system did not work after an update of OH; I removed the mqtt v1 action and binding; installed the v2 and then v1.
No errors occurred, the v1 connected straight to mosquitto, all was working again.

Yes, being time poor, as in when you work, migrating the amount of controllers I have to things, updating rules, etc. takes significant time (and maybe I am not the fastest).

Having this migration path now, where I can change one controller at the time, even “half” the ‘channels’ of a thing; yes, I have now a half migrated controller; e.g. I thing’ed the easy bits (string, switch, number; and not participating in rules), and will do the ones needing transformation or rule updates tonight or tomorrow.