Migrating MQTT1 items to MQTT2.4 items

Tags: #<Tag:0x00007f4335b983e8>

Hello Rich,

could you please tell if it still possible in MQTT2 to define things, channels and items over the files.
I can not find any information till now about it. I have found в little about things definition, but now complete, but about channels and items nothing.
Couild you make soime example or guide?

Thanks a lot!

It’s possible. The ability and syntax is a core feature of OH and not implemented by individual bindings. There are examples all over the forum.

But I personally recommend using PaperUI to create at least your initial Things and then if you have a lot of copy/paste/edit, use the REST API. People are always getting the syntax wrong and very rarely do users reasons for insisting on using .things files have merit in my opinion. When you use the UI the syntax is guaranteed to be right and it’s clear and intuitive what options there are and how to use them.

I do not define anything in .things files and I recommend against their use so I won’t be the one to create a guide or tutorial.

2 Likes

Thanks!
I have installed mqtt2 yesterday. It worked till restart.
Now i get

2019-11-23 13:58:44.656 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.mqtt.handler.BrokerHandler@9d4645': null

java.lang.NullPointerException: null

	at org.eclipse.paho.client.mqttv3.internal.MqttPersistentData.<init>(MqttPersistentData.java:63) ~[?:?]

	at org.eclipse.paho.client.mqttv3.persist.MqttDefaultFilePersistence.get(MqttDefaultFilePersistence.java:219) ~[?:?]

	at org.eclipse.paho.client.mqttv3.internal.ClientState.restoreState(ClientState.java:342) ~[?:?]

	at org.eclipse.paho.client.mqttv3.internal.ClientState.<init>(ClientState.java:172) ~[?:?]

	at org.eclipse.paho.client.mqttv3.internal.ClientComms.<init>(ClientComms.java:108) ~[?:?]

	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:470) ~[?:?]

	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:320) ~[?:?]

	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:315) ~[?:?]

	at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.createClient(MqttBrokerConnection.java:752) ~[?:?]

	at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.start(MqttBrokerConnection.java:706) ~[?:?]

	at org.openhab.binding.mqtt.handler.AbstractBrokerHandler.initialize(AbstractBrokerHandler.java:108) ~[?:?]

	at org.openhab.binding.mqtt.handler.BrokerHandler.initialize(BrokerHandler.java:232) ~[?:?]

	at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) ~[?:?]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.M4]

	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [133:org.openhab.core:2.5.0.M4]

	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

2019-11-23 13:58:44.708 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'mqtt:broker:max': null

java.lang.NullPointerException: null

	at org.eclipse.paho.client.mqttv3.internal.MqttPersistentData.<init>(MqttPersistentData.java:63) ~[?:?]

	at org.eclipse.paho.client.mqttv3.persist.MqttDefaultFilePersistence.get(MqttDefaultFilePersistence.java:219) ~[?:?]

	at org.eclipse.paho.client.mqttv3.internal.ClientState.restoreState(ClientState.java:342) ~[?:?]

	at org.eclipse.paho.client.mqttv3.internal.ClientState.<init>(ClientState.java:172) ~[?:?]

	at org.eclipse.paho.client.mqttv3.internal.ClientComms.<init>(ClientComms.java:108) ~[?:?]

	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:470) ~[?:?]

	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:320) ~[?:?]

	at org.eclipse.paho.client.mqttv3.MqttAsyncClient.<init>(MqttAsyncClient.java:315) ~[?:?]

	at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.createClient(MqttBrokerConnection.java:752) ~[?:?]

	at org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.start(MqttBrokerConnection.java:706) ~[?:?]

	at org.openhab.binding.mqtt.handler.AbstractBrokerHandler.initialize(AbstractBrokerHandler.java:108) ~[?:?]

	at org.openhab.binding.mqtt.handler.BrokerHandler.initialize(BrokerHandler.java:232) ~[?:?]

	at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) ~[?:?]

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]

	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.M4]

	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:52) [133:org.openhab.core:2.5.0.M4]

	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

And seems not to work at all. All things are offline.
Pi4 and OH 2.5M4

I have googled a little, and seen the same problem in 2018, it was written, that they must be fixed, but how can it be, till now not fixed or have i made smth wrong?

Thanks a lot!

Use 2.5 M5. That version dropped the Paho library for the HiveMQ library because Paho isn’t being speed very well.

It is still possible. I use thing and item files for all my devices. It’s easier if you own multiple instances of the same devices.

1 Like

Thanks Rich,
I have just installed 2.5M5 form M4.
After installation and restart i got messages that persistant service with ID Influx not found (maybe other i have not mentioned)
And after reboot dashboard and logs and all uis never came back. OH died :crazy_face:

After 2 reboots it is again here with me :rofl:

Rich, I read that you if you wish to use the Alexa skill you’ll need to tag items or things which is not available in paper ui. I presume you not using the Alexa skill.

Items need to be tagged. Rich mentions that at least things should be configured in PaperUI since otherwise it is likely that you get the syntax wrong an this always is a pain to find and support

You need to tag or add metadata to Items. Not Things.

Items are much easier to create by hand and present far fewer syntax problems. So I, and the official docs say to use .items files for Items and not to use .things files for Things.

I do not use Alexa but I do use GA which does require tags, soon to require metadata. And because of that and other reasons I follow the official advice in the docs and define my Items in .items files. But all my Things are defined through PaperUI or the REST API and I’ve never had a syntax error or had to research what fields are available or what needs to go into them.

I installed the addon using a file “addons.cfg”. What do I have to change in this file to migrate?

addons.cfg:

package = minimal
# Access Remote Add-on Repository
remote = true
# Include legacy 1.x bindings
legacy = true

action = mqtt
binding = http1,mqtt1,network,astro,network
ui = classic,basic,paper,habpanel,habmin
transformation = map,regex,xslt,exec,javascript,scale,xpath,jsonpath

Didn’t read your question properly. So i edited all of it:; Did you install te MQTTv2 binding? It should be done via UI and not addons.cfg

Using the addons.cfg you “installed” the old mqtt (Version 1) binding and its related mqtt action.

I think that using the user interface - is the wrong way to go and poor engineering. Any configuration should be done by importing the “configuration directory” without any additional actions. I think this is what the developers created the “addons.cfg” file for.
For example: 3 weeks ago my SD card died (luckily I’m synchronizing the configuration via Syncthing). To restore OpenHab, I simply put my current configuration in the new OpenHab directory. He set up all the addons himself and everything worked as if nothing had happened.

1 Like

I found the answer:

binding = mqtt,mqtt1,http1,network,astro,network

(mqtt1 - OpenHab1, mqtt - OpenHab2)

addons.cfg is legacy. The “configuration directory” that gets imported is located in /var/lib/openhab2. When running openhab-cli backup/restore it includes that folder. Whether or not it’s bad engineering is a matter of opinion (often driven by an ignorance of all the requirements driving the development) but you are free to volunteer your time and join the development team and show them all how they are doing it wrong.

2 Likes

addons.cfg is mentioned in the documentation as a valid way to configure.
I cannot find confirmation of this statement (that this file is “legacy”) in changelog and documentation. Can you give me a link?

1:
With this information we can now edit the addons.cfg file in the $OPENHAB_CONF/services folder on the machine you are running openHAB on.

2:
openHAB settings as defined in services/addons.cfg and services/runtime.cfg will override any settings made in PaperUI’s Configuration/System pane.

I am guided by official documentation. That’s what it says:
Site configuration: /etc/openhab2
Userdata like rrd4j databases: /var/lib/openhab2

My opinion: the existence of two equivalent folder with configurations, one of which is not mentioned in the documentation (everywhere it is specified that it is “userdata” but not a configuration) and which contains a configuration in an undocumented format - is bad engineering and bad architecture pattern.

I also find it bad engineering to require manual input with a GUI without the ability to automate the process (via file or API).

For now - that they are doing the right thing - I can fully configure the program using only /etc/openhab2. I understand the engineering reasons for the second directory and I do not judge them. We (programmers) do it all the time))).

Unfortunately, I will not be able to join the development - my specialization is C++, Python and industrial programming on IEC-61131. The threshold to enter such a large project is quite high - you cannot just say “you can join”.
But as you can see, I have already noted some problematic points in the documentation. Maybe it makes sense to discuss them and make PR?

Frankly the docs have not managed to keep up with the development in a number of areas, this being one of them. But referring to it as legacy does not mean it’s not supported nor does it make it invalid to use it. But it is a method of configuring openHAB that is left over from openHAB 1.x and IMHO the way it is loaded and processes is not ideal.

There is only one configuration folder. The stuff in /etc/openhab2/services gets copied to /var/lib/openhab2. In the case of addons.cfg, the actual file used by openHAB is in /etc/openhab2/config/org/openhab/addons.config. The file format is the same as the format used by /etc/openhab2/services/addons.cfg, minus the comments.

There is nothing that you can do through any UI that cannot also be done through configuration files, the Karaf Console, or the REST API. Almost everything can be done through the REST API and Karaf Console. For now, there are three things that cannot be managed through those two:

  • configuration of persistence
  • configuration of sitemaps
  • configuration and use of OH 1.x bindings.

In fact, everything that the UIs do is through the REST API. So you can’t do those three things through the UIs either. In OH 3 that list drops to one (right now), configuration of persistence.

The main supported way to configure OH is through the REST API. A UI exists for users to use but you can automate the interactions with the REST API to your heart’s content. There are several such scripts and programs on the forum that do so (e.g. moving data from one persistence database to a different one). Using text based configs in the /etc/openhab2 folder remains supported and probably will continue to be supported, but it is legacy support.

And yet you persist in calling their efforts “bad engineering”.

About the only issue I see that you’ve identified thus far is that the documentation is behind in some areas. We are fully aware of this and are waiting for OH 3 to get closer to done before a full rewrite of the docs where this particular issue is high on the list to be corrected. That being said, the threshold to help with the documentation is actually very very low. You don’t even need to leave the browser to create and submit a PR. See How to file an Issue.