Migrating MQTT1 items to MQTT2.4 items

Tags: #<Tag:0x00007f7455666f40>

Hi there, i am trying to Setup my new Installation with mqtt2.4, till now i just used the old one with textual config and worked fine. I used map Transformation to transform 1 to on and 0 to off on the Incoming value and now i dont know how to do this in paper ui. is it even possible?

Always get the following error:
Command '0' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.0

Thanks in andvantage

Hi!

Do I need to install the “MQTT Embedded Broker” via Misc in Paper UI or is it enough to install only the mqtt binding posted in first thread?

The MQTT binding is NOT a MQTT Broker!
For the use of MQTT Messages you need a MQTT Broker, the “MQTT Embedded Broker” is one (but not the only one).

1 Like

I could setup by copying data from my old MQTT items for my sonoff TH03 sensor SI7021 for temperature but unfortunatelly not for humidity - Any Idea what i do miss, I tried the channel setting for text, number and percentage - all seems not working for humidity.
For the temperature is use “number”.

This is the non-working channel setting for the humidity
image

and this is the working setting for the temperature

This are my items:
Number TH03TEMP {channel=“mqtt:topic:TH03TEMP:TH03TEMP”}
Number TH03HUM {channel=“mqtt:topic:TH03HUM:TH03HUM”}

and this is my sitemap for the both entries:
Text item=TH03Temp label=“TH03Temp [%.1f °C]” icon=“temperature”
Text item=TH03Hum label=“TH03Hum [%.1f %% ]” icon=“humidity”

I would use a Number channel for humidity as the values sent from Tasmota are 0-100
Did you verify by using an MQTT monitor that the humidity data is being sent?

Sorry, I don’t know how to use a mqtt monitor.
I just did copy the values from my old mqtt items and there humidity was working.
Same I did for the temperature and here it is working. Therefore I am a bit lost.
Yes, number I also tried first because number is working for temperature as well.

If both sensors are at the same sonoff device, the thing-name should be the same.
Sou are using the channel “mqtt:topic:TH03TEMP:TH03TEMP” for the temperature, that would suggest a thing-name of TH03TEMP, according the used stateTopic I would think the name is “TH03”. But since you do get temperature readings lets assume your channel is correct. The humidity sensor should be using the same thing-name.

I was creating 3 things for the TH03 and the sensor S7021 attached, one for the switch, one for the temperature and one for humidity. For each I was adding one channel.
Currently the switch and temperature are working.
You suggest to use the thing for temperature, and add a second channel for the humidity to that temperature thing, right?

I suggest one thing for the THING. The sonoff is one thing. One physical thing. One piece of hardware.
Then add 3 channels. The switch, the temperature and the humidity to that one thing.

This will help you manage your things. One piece of kit = One thing.

1 Like

As @vzorglub already suggested ONE DEVICE=ONE THING!

Great, Thanks -> Yes, this was it! Solved!!

works now, for others maybe interesting when using a TH03 with a SI7021 sensor

Items:
Switch TH03 {channel=“mqtt:topic:5f4a663f:TH03”}
Number TH03TEMP {channel=“mqtt:topic:5f4a663f:TH03Temp”}
Number TH03HUM {channel=“mqtt:topic:5f4a663f:TH03Hum”}

Sitemap for the sensors:
Text item=TH03TEMP label=“TH03Temp [%.1f °C]” icon=“temperature”
Text item=TH03HUM label=“TH03Hum [%.1f %% ]” icon=“humidity”

and this is the example for the humidity channel:
image

1 Like

Hi guys,

i have read all this thread and i can not really understand which advantage has all this to mqtt1 if everything already configured in items and works?
Only UI with which i can easily add new devices or i can get some other plus points from it?

Because eventually v1 binding support will go the way of the dodo. So getting used to a v2 binding now, whilst the two can still work together, is best practice.

Vincent, am supporter of configuring things and items throught files and not UI. If something happend, i put the files to their places and everything works again in minutes. But with GUI as somthning happens you will have lot of problems.
I have really NO one problem from the time i installed mqtt1! It looks like that it is the stabiliest part of my intallation:slightly_smiling_face:
So why migrate to mqtt2? :smiley:

Because one day you will HAVE to and will will curse that day for not having prepared for it

1 Like

That is the problem ((( that we have to leave the real stable things.

MQTTv2 is stable
A lot, and I mean a lot of work and testing went into it.
MQTTv2 actually has more options than MQTTv1 like nested transformations, payload validation etc…

1 Like

MQTT2 supports:

  • automatic discovery of Things that follow the Homie or Home Assistant standard
  • chained transformations (e.g. perform a JSONPATH followed by a REGEX without needing Rules)
  • use of the retained flag in a more MQTT standard and expected way
  • is receiving updates and will continue to receive updates going forward, development has completely stopped with MQTT 1 and the MQTT 1 Action
  • MQTT 1 will no longer be supported at some point, perhaps as soon as OH 3 sometime next year
  • supports Profiles
  • will eventually support Units of Measure
  • works better with REST API creates/managed Items (you cannot manage OH 1 binding Items any way except through .items files
  • you are guaranteed to get the syntax right every time and you don’t have to look anything up when creating the Thing.
  • The UIs as you see them in PaperUI is not how the UIs will exist in OH 3. They are undergoing a complete rewrite and from what I’ve see so far it’s going the be really good.
  • Already the number of people who can provide support on the MQTT 1 binding on this forum has grown small.
  • Simple transforms like mapping 1 to ON and 0 to OFF can be done right on the Thing without the need to create and use a transform.

I’m sure there are more but those are off the top of my head.

No, and in fact when you manage your stuff through the UI/REST API you are in an even better situation that with .items files.

  • If you are creating backups, you are already (or should already) be backing up the “mysterious” database where stuff created through the UI/REST API because you had better be backing up /var/lib/openhab2 too. If you are using òpenhab-cli backup` you are also backing up that folder as well.

  • The JSONDB (that “mysterious” database) is automatically backed up for you on every change and periodically. So if something goes wrong, you have an automatically created backup you can restore from. Unless you create a backup every time you save a .items file you can’t have that with text configs.

  • The JSONDB is not really that mysterious. It’s a text file, JSON formatted, and it has one entry for each element and it is pretty easy to read and, if necessary, edit by hand.

To reiterate Vincent’s posts, it’s a lot better and easier to migrate when you want to rather than when you have to. And there are benefits as mentioned above.

If you are of the "don’t touch it you’'ll break it"sort, than you won’t be making any updates or upgrades to your system anyway, so why ask the question in the first place? You’ll be staying on OH 2.3 or what every older version of OH you are currently running and just let it run. But if you need or want to update OH to get bug fixes or new features as OH continues to evolve, at some point you will not be able to continue to run the MQTT 1 binding any more.

In my experience, at least for the parts of the binding I’ve used, the MQTT 2 binding is now every bit as stable as the MQTT 1 binding. Only it works a lot more like it should now in how it treats the retained flag. And I have a lot more capability than I ever had in the MQTT 1 binding.

2 Likes

Rich, perfect explanation! Thanks a lot.
After that i will think about it carefully.

Thanks Vincent.
Will learn more about mqtt2.