openHAB 1.7.0 and MQTT: another question related to running the runtime on Linux

Setup, Configuration and Use Items & Sitemaps
, ,
1

In a previous message topic, I had a question about synchronising two web UI’s, running on two different Windows machines (in my case, a WinXP and a Win8.1 machine), both talking to one and the same Mosquitto broker running on a Raspberry Pi.

This question is about openHAB runtime running on a Linux distro, Debian Jessie, which runs in VirtualBox on the same Win8.1 machine mentioned in that previous message topic.

The Linux distro has exactly the same demo.sitemaps file content as the ones running on my WinXP and Win8.1 machines and almost the same demo.items file content, apart from the mqtt broker name and clientId, which is different. But that shouldn’t matter, isn’t it?

Also the openhab.cfg file is, apart from the broker name and clientId, exactly the same as the ones running on my Windows machines.

Finally, the transform file “1on0off.map” is a 1-to-1 copy of the ones running on my Windows machines.

The IP address of the Linux distro running in VirtualBox is 192.168.123.128, so in the same address range as both my Windows machines and my Raspberry Pi, running the Mosquitto broker.

My problem is now: when I modifiy something in the web UI on the Linux distro, I don’t see any reaction in the Mosquitto broker logs on the Raspberry Pi. Also, the mosquitto_sub - running on the Raspberry Pi - that listens on the topics submitted through the web UI on the Linux distro doesn’t see any changes passing by.

The other way around is also true: when I modify something through mosquitto_pub on the Raspberry Pi, the openHAB runtime on my Linux distro doesn’t receive anything.

However, when starting the openHAB runtime on my Linux distro, I do see the connection request on the Mosquitto broker logs on the Raspberry Pi. So, both machines do see each other!

I’m puzzled about this: is this explainable? It looks like the Linux distro doesn’t send and/or receive any updates to/from the Mosquitto MQTT broker running on the Raspberry Pi.

Coincidence or not: at the office, I have exactly the same problem with the same setup. The only difference is that the openHAB runtime is running on a “real” Linux machine (also Debian Jessie), not a virtual one running in Windows VirtualBox.

2

As I understand, all of your machines use the same mosquitto instance on an RPi.

  1. To see everything received by your broker including the topic: mosquitto_sub -h -t /# -v
  2. You should see an reaction when you use mosquitto_pub on your Linux VM: mosquito_pub -h -t /aTestTopic -m testmessage

If not - your networking setup has issues. Check if you can reach the mosquitto brokers port (testable by telnet 1883) - if it says “connection refused” something is wrong.

As you dont see the connection request in your openhab log: Are you sure you copied the MQTT addon jar to the addon folder ? I’m asking because it happened to that I simply forgit this … :wink:

Cheers - Robert

3

Hi Robert,

Indeed, all my machines are talking to one and the same Mosquitto instance, running on my Raspberry Pi.

Next, your 2nd point was a good testing point: sending a mosquitto_pub message from my virtual Linux machine to the Mosquitto MQTT broker on the Raspberry Pi, while I also deployed your “general topic sniffer” method on the Raspberry Pi by running the command “mosquitto_sub -d -i subscriber -t /#” in a separate terminal .

When I run the command “mosquitto_pub -d -h 192.168.123.155 -i myvirtuallinuxmachine -t /randomTopic -m randomMessage” from the virtual Linux machine, I do see the message in both the mosquitto log as well as the mosquitto_sub log on my Raspberry Pi. So, both machines really do “see” each other.

I’m also sure the MQTT addon is loaded when running openHAB runtime on my virtual Linux machine, since I see the following message when starting the openHAB runtime:

geertvc@debianJessie:~/mystuff/openhab/runtime$ ./start.sh
Launching the openHAB runtime…
osgi> 2015-09-14 15:20:06.167 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.0).
2015-09-14 15:20:06.808 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2015-09-14 15:20:06.856 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.
2015-09-14 15:20:06.858 [INFO ] [.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2015-09-14 15:20:06.858 [INFO ] [o.i.t.m.i.MqttBrokerConnection] - Starting MQTT broker connection 'geertvc_debian’
2015-09-14 15:20:08.087 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest

and when I touch the items on the web UI on my virtual Linux machine, I do see the reaction on the openHAB runtime log:

2015-09-14 15:22:08.214 [INFO ] [runtime.busevents ] - mqttsw1 received command ON
2015-09-14 15:22:09.278 [INFO ] [runtime.busevents ] - mqttsw1 received command OFF
2015-09-14 15:22:10.505 [INFO ] [runtime.busevents ] - mqttsw2 received command ON
2015-09-14 15:22:11.453 [INFO ] [runtime.busevents ] - mqttsw2 received command OFF
2015-09-14 15:22:11.469 [INFO ] [runtime.busevents ] - mqttsw2 received command ON

But still, receiving MQTT messages from external (e.g. mosquitto_sub from the Raspberry Pi) or sending messages to the broker from within the web UI on the virtual Linux machine doesn’t seem to work.

I have the impression openHAB does something weird on my virtual Linux machine (and as I mentioned before, on a “real” Linux machine I have exactly the same behaviour).

4

Hi Geert,

Ok - fine, basic setup seems to work.
Now try to define a minimalistic MQTT transport configuration in your openhab.cfg. The only needed entry is in your case

mqtt.geertvc_winxp.url=tcp://:1883

I choose “geertvc_winxp” as broker identifier because of your item binding configuration in your previous topic. This broker identifier is used in openHAB to discriminate different MQTT brokers if more than one is used.
I’m not sure but I think in my beginnings I had difficulties like you when specifying an own mqtt client id in mqtt.geertvc_winxp.clientID.

I can assure you openHAB does absolutely nothing “weird” under Linux - I’m running openHAB on a BananaPi and it works like charm :wink:

5

Hi Robert,

I found my problem and I think you were absolutely right from the very beginning by asking if I was sure if the MQTT jar file was added to the addons folder.
I said I was absolutely sure that was the case, since I saw the following message when starting up the openHAB runtime:

2015-09-14 15:20:06.858 [INFO ] [.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2015-09-14 15:20:06.858 [INFO ] [o.i.t.m.i.MqttBrokerConnection] - Starting MQTT broker connection 'geertvc_debian’

However, I’ve experienced that this doesn’t prove at all that the MQTT jar file is in the addons folder! Why? Well, I must admit now that the MQTT jar file was NOT in my addons folder. I was fooled by the openHAB runtime log content…

So I thought, to double check it, I will deliberately remove the MQTT jar file again from the addons folder and restart my openHAB runtime. What did I see? To my surprise, exactly the same MQTT message as given above! And of course, the MQTT mechanism was again not working any more…

Then I went one step further and I commented out the two MQTT items in my openhab.cfg file (broker and clientId). Then I started the openHAB runtime again and guess what? Not any mentioning of MQTT whatsoever any more…

So, apparently, mentioning the MQTT broker and clientId in the openhab.cfg file without having the MQTT jar file installed into the addons directory is already enough to get the feedback during the startup of openHAB runtime, that the MQTT service is initialised and the MQTT broker is started.

I don’t know what your opinion is about this, but that is totally misleading information to me…

And that has put me completely on the wrong path… To me, this feedback should not be shown on the openHAB runtime log output, if the MQTT jar file is not in place…

Just to crosscheck: would you be willing to do the same experiment and confirm if you have the same behaviour? I thing this might be useful input for the guys developing openHAB…

Thanks anyway for your useful contribution to my problem!

6

Hi Geert,

I can confirm your findings that the mqtt config lines in openhab.cfg will trigger the log entries in question.
I had a look at the code and the situation is as follows:

The MQTT I/O component handling the connection to the broker is packed in the bundle org.openhab.io.transport.mqtt. This bundle is part of the openhab runtime. So when you configure your openhab.cfg to have an mqtt..url line, openhab in fact starts a valid connection to the MQTT broker. You can prove this by starting your openhab instance and after that restart the MQTT broker. You will see log enties in openhab on loosing an restoring connection.

The MQTT binding in bundle org.openhab.binding.mqtt is responsible for reading an working with the openhab item configurations from configuration/items/…

So the behaviour of openhab is correctly.

I think the point which was misleading you is that openhab does not complain on an item binding configuration which is not “understood” because of a missing addon. Maybe a info or warning should be logged in such cases.

7

Got it. Thanks for the analysis!

8

Follow up:
I filed an issue on that problem but it will not be solved in openHAB 1.x.