Now I tried this with a OH2 snapshot from this week. I tried installing via Paper UI, manually downloading mqtt transport/binding 1.9 snapshots and also with the 1.8.1 addons. At best with 1.9 I get this in the log:
Generally, 1.8 binding JARs are likely to have problems running under OH2. Small changes were needed to most 1.8 bindings so they would run correctly under OH2 (and continue running under 1.8). You should be able to get the MQTTitude (OwnTracks) binding from here to manually add to the addons folder, if it doesn’t install from Paper UI. The 1.9.0-SNAPSHOT MQTT binding that installs from OH2 is the one you want.
Hi @NCO, I don’t understand if you are reporting a problem, providing more information about an existing problem, just searching more general information, or ?
If the 1.8.3 mqttitude binding is working for you, that’s great. The 1.9.0-SNAPSHOT version ought to work as well. The org.openhab.io.transport.mqtt is installed with the binding, action, or persistence service, so you should not have to manually handle that JAR if you have any of those other components installed. That service encapsulates the lower-level pieces of the MQTT stack and so it’s needed by the higher-level binding, action, persistence, OwnTracks services.
I had a real strange bug with the MQTT binding yesterday.
I accidentally set a different broker (=“cubie”) in mqtt-eventbus.conf. One config line (.qos) in mqtt.conf was also using this different broker.
The correct broker was “local”. “cubie” was NOT configured, except “cubie.qos = 1”, so there was NO VALID address for “cubie”. “local” was configured correctly.
This lead to many, many connections errors (connection lost, unable to connect, retry, …), and some messages (from some items configured for the MQTT Binding AND for event bus) where successfully send to the broker and its subcribers.
After I corrected the configuration in mqtt.cfg and mqtt-eventbus.cfg, the behaviour was still the same.
I emptied mqtt-eventbus.cfg -> still the same (including some messages from the eventbus!)!
I restarted Openhab2 --> still the same!
After this, I grepped for the name of the wrong broker (“cubie”) and found a copy of the old config files in
I deleted them and restarted OH2. Finally everything was running as expected (items for mqtt-binding worked fine).
What has happend here? Why are local text config files copied to a local cache?
And why they are not changed if you change the original? (I saw in the log that the change was recognized by OH2!).
I believe there is an issue in OH2 with service configurations holding old values. In OH1, there was a startup value called osgi.clean=true that cleared out all old config data at startup, but there is no equivalent in OH2. I think stale config values might be accumulating until some manual action clears them out. I’ve seen reports regarding a number of 1.x addons that appear to be having this issue. I reported a concern about this some time last year (IIRC).
Thanks for your help. that make much more sense.
I took my OH1 items and the Basic UI displays them. but the external broker does not receive commands and the OH2 does not see the states. No errors.
To check if you have subscribed to the correct topic in your items file, I would take a MQTT client (f.e. mosquitto_sub or mqtt.fx on Windows) and subscribe to the /# wildcard topic, it will show you the complete path the messages are coming in …
You “in” binding config strings are not going to perform the way you want. The format should be
There is an optional :regex possible on the “in” binding config strings, but that doesn’t apply to your use case. Your item should probably be defined like this, so that when a 0 is published to the topic control/SW010101/SW1/state, it turns the switch state to OFF, and 1 to ON.
Also, if you get this message, and yet your mqtt.cfg does not currently mention the broker named mosquitto, then you have to solve the gotcha which currently exists in OH2 but was much rarer under OH1.