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:
That was still based on the old way. In the new karaf builds it is different.
to get the io transport, type the following in the OH command line feature:install openhab-transport-mqtt
Is this still valid, since I can install mqtt binding 1.9.0 with Paper UI in OH2 ?
Does it make sense to combine mqtt1.9.0 with org.openhab.binding.mqttitude-1.8.3.jar or is this obsolete in OH2?
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.
Thanks for your response.
I am not sure if I got your point completely.
I installed Mqtt binding 1.9.0 (by Paper UI as you suggested). Together with mqttitude 1.8.3 (manually put into addons) it works like a charm.
(Only task is to work with owntracks)
So, what about Mqtt.io mentioned above?
Is this for sending out mqtt messages to other devices or processes?
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
userdata/cache/org.eclipse.osgi/7/data/config/org/openhab/mqtt-eventbus.config etc.
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).
I setup a new OH2 server today. I did the Paper UI bundle install. I updated the mqtt.cfg.
The log looks like its working but it does not show in inbox.
any ideas
openHAB 1.x bindings like the MQTT binding (note the 1.9 in the version) do not have things or channels; they bind directly to items that you define in .items files. See the wiki for how to do that.
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.
Any Ideas>
Please format your logs, items or whatever info as “preformatted text” with the </> button. It’s a lot better to read, especially if the text gets longer.
Is that the complete log output? Then you may have a config problem in your mqtt.cfg, because this line normally shows the name of the broker like:
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
<[broker:topic:type:transform]
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.