What happens is that I get this error right after starting OpenHab.
org.eclipse.paho.client.mqttv3.MqttException: Connection lost
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:138) ~[na:na]
at java.lang.Thread.run(Thread.java:744) ~[na:1.8.0]
Caused by: java.io.EOFException: null
at java.io.DataInputStream.readByte(DataInputStream.java:267) ~[na:1.8.0]
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:56) ~[na:na]
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:100) ~[na:na]
... 1 common frames omitted
Is it possible that there is a problem with the whitespace in the password field?
If I use another Java based tool, for example MQTT.fx, it runs with the exact same specified fields without any errors.
So my questions are:
Can I use whitespaces like shown in the configuration?
If not, how can I escape them?
Is this indeed an error and should I open an issue on github?
Should not be a problem, as spaces are allows in Java properties files (whitespace is only discarded right after the separator character, which is not the case here). However, you do need to follow these formatting rules:
Do you know for certain that Azure is an MQTT-3.1.1 conforming broker? If it is, it would be a recent development. I know that the MQTT broker that Amazon AWS IoT offers, for example, is not.
You may also be experiencing SSL handshake issues, like not sharing a common certificate authority. I suggest googling compatibility questions between Eclipse Paho and Microsoft Azure IoT MQTT.
I’m sure that Azure is using MQTT-3.1.1 as every documentation states this and the working connection via MQTT.fx is configured via MQTT-3.1.1 as well.
I can get the exact same error in MQTT.fx (which uses Eclipse Paho as well) when I disable the needed SSL security. So I guess your hint to SSL handshake issues was correct.
In MQTT.fx I can connect when choosing “CA signed server certificate” and one of the following protocols: SSLv3, TLSv1, TLSv1.1, TLSv1.2. Sadly MQTT.fx is closed source so I couldn’t find any information on how this was done in code.
If the issue is with SSL negotiation, you would need to know what your local Java installation doesn’t know (like a CA cert in common), and then update your configuration. I don’t know if instructions like these are applicable, because it depends on what your further research finds.
Hi Matija,
sadly I didn’t find a solution by now.
I made my own workaround by using a self implemented MQTT broker which later forwarded the message to IoTHub. I simply ran this broker on the same device that OpenHab was running on.
I know this is an old thread. I have the beginnings of an Azure Iota Hub binding. it does auto discovery and can send and listen to device events. I will submit the code once its all cleaned up but if anyone wants to help. The devices in azure come up as things…