MQTT connection lost

[Dim (Angelos)]

@narf27

the number changes, here’s the log after said changes and reboot:

this points to the direction that this is an auto-generated clientId (using the processId and the hostname)
I am not sure if it’s coming from the openHAB2 mqtt binding connection… maybe it is (looks like it)
Something seems to be sending an empty clientId on a second connection…

I found the following info:

client_id is the unique client id string used when connecting to the broker. If client_id is zero length or None, then the behaviour is defined by which protocol version is in use. If using MQTT v3.1.1, then a zero length client id will be sent to the broker and the broker will generate a random for the client.

@narf27

it’s the vertical bar…

Yes…
It should be ( | ) due to CVE-2017-7650. Since Mosquitto 1.4.12, clients are not allowed to have a ‘#’, ‘+’, or ‘/’ in their username or client id.

Info:
i) Redirecting...
ii) regression because of CVE-2017-7650: clientid with / character · Issue #462 · eclipse/mosquitto · GitHub
iii) mosquitto/client/client_shared.c at master · eclipse/mosquitto · GitHub

[narf27 (Peter)]

@Dim

try the following:
0) switch to root (sudo su)

1. stop the OH2 service (systemctl stop openhab2)
2. move the mqtt.config file to another destination: mv /var/lib/openhab2/config/org/openhab/mqtt.config /root/)
3. make sure that /etc/openhab2/services/mqtt.cfg is correctly configured
4. start the OH2 service (systemctl start openhab2)
5. check logs (openhab & mosquitto)

cat /var/log/openhab2/openhab.log | grep mqtt

2017-07-22 12:32:45.726 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2017-07-22 12:32:45.732 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mqttson'

...
1500717721: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1500719450: Client openHAB2 disconnected.
1500719522: Saving in-memory database to /var/lib/mosquitto/mosquitto.db.
1500719565: New connection from 127.0.0.1 on port 1883.

[paulo9999 (Paulo Wang)]

hello all,

I made the changes of duplicated clientid, etc…

checked the netstat and now I have only one connection:

tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:1883 127.0.0.1:38744 ESTABLISHED
tcp 0 0 10.0.0.101:1883 10.0.0.104:13727 ESTABLISHED
tcp6 0 0 127.0.0.1:38744 127.0.0.1:1883 ESTABLISHED

the mqtt.config (after the change):

raspberrypi.clientId=“openHAB2”
raspberrypi.pwd=“password”
raspberrypi.url=“tcp://127.0.0.1:1883”
raspberrypi.user=“openhabian”
service.pid=“org.openhab.mqtt”

the Mosquitto,log

1500718948: mosquitto version 1.4.14 (build date Mon, 10 Jul 2017 23:48:43 +010$
1500718948: Config loaded from /etc/mosquitto/mosquitto.conf.
1500718948: Opening ipv4 listen socket on port 1883.
1500718956: New connection from 10.0.0.104 on port 1883.
1500718956: New client connected from 10.0.0.104 as DVES_A7F83D (c1, k15, u’ope$
1500719029: New connection from 127.0.0.1 on port 1883.
1500719029: New client connected from 127.0.0.1 as openHAB2 (c1, k60, u’openhab$
1500719556: New connection from 10.0.0.100 on port 1883.

(the last connection is from MQTT fx)

After that I tried to publish the command at MQTT.fx but no response:

2017-07-22 07:33:33,040 INFO — MqttFX ClientModel : attempt to add PublishTopic
2017-07-22 07:33:33,041 INFO — MqttFX ClientModel : sucessfully published message to topic cmnd/sonoff-abajur/POWER off (QoS 1, Retained false)

[Dim (Angelos)]

@narf27

1500719565: New connection from 127.0.0.1 on port 1883.

so… did the mosqsub|1730-openHABian dissapear?

[Dim (Angelos)]

@paulo9999

After that I tried to publish the command at MQTT.fx but no response:

no response from what? (OH2 or the Sonoff?)

post your item config to check it

[narf27 (Peter)]

yes! (for now?)

EDIT: NO!

1500719565: New connection from 127.0.0.1 on port 1883.
1500719565: New client connected from 127.0.0.1 as openHAB2 (c1, k60).
1500720088: New connection from 127.0.0.1 on port 1883.
1500720088: New client connected from 127.0.0.1 as mosqsub|7105-openHABian (c1, k60).
1500720244: New connection from 192.168.178.160 on port 1883.

still no communication with openHAB2 ?

[12:34:38] openhabian@openHABianPi:~$ mosquitto_sub -v -t 'tele/#' -t 'stat/#'
tele/sonoff/LWT Online
stat/sonoff/RESULT {"POWER":"OFF"}
stat/sonoff/POWER OFF
tele/sonoff/STATE {"Time":"2017-07-22T11:43:00", "Uptime":3, "Vcc":3.204, "POWER":"OFF", "Wifi":{"AP":1, "SSID":"NETGEAR47", "RSSI":32, "APMac":"80:2A:A8:4A:C7:AC"}}

thoughts: if the TOPIC is “sonoff1”, my item should be:

Switch Sonoff_TH16A "Sonoff Test" <light>
    { mqtt=">[broker:cmnd/sonoff1/POWER:command:*:default],
            <[broker:stat/sonoff1/POWER:state:default]" }

right?

'til now i have used the client id of the sonoff device…

changing (correcting) the item doesn’t help, still no signs in openhab.log…

[paulo9999 (Paulo Wang)]

[quote=“Dim, post:28, topic:31993”]
no response from what? (OH2 or the Sonoff?)
[/quote] no response from Sonoff. I don’t know how to see if could be any chance on OH2. But the log is below:

2017-07-22 07:23:49.078 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2017-07-22 07:23:49.083 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection ‘raspberrypi’
2017-07-22 07:23:49.619 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2017-07-22 07:23:49.921 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-07-22 07:23:50.023 [WARN ] [mqtt.internal.MqttPersistenceService] - mqtt-persistence:topic
2017-07-22 07:23:50.026 [WARN ] [mqtt.internal.MqttPersistenceService] - mqtt-persistence:message

the sonoff.item:

Switch Abajur_light “Abajur” (LR, gLight)
{ mqtt=“>[raspberrypi:cmnd/sonoff-abajur/POWER:command:ON:on], >[raspberrypi:cmnd/sonoff-abajur/POWER:command:OFF:off],
<[raspberrypi:stat/sonoff-abajur/POWER:state:default]” }

[paulo9999 (Paulo Wang)]

When I tried to move the switch at OH2, I got the following message:

2017-07-22 07:56:06.192 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Text
2017-07-22 07:56:06.207 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item ‘Abajur’ for widget org.eclipse.smarthome.model.sitemap.Switch
2017-07-22 07:56:06.211 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item ‘Abajur’ for widget org.eclipse.smarthome.model.sitemap.Switch
2017-07-22 07:56:06.215 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Switch
2017-07-22 07:56:06.244 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value ‘93.25861’ of item LivingRoom_Light_RSSI with format ‘%d %%’: java.util.IllegalFormatConversionException: d != java.math.BigDecimal

[Dim (Angelos)]

@narf27

EDIT: NO!

anything useful with lsof -i :1883 ?
or ps -efwww |grep 7105 (that seems to be the process id)

@narf27

thoughts: if the TOPIC is “sonoff1”, my item should be:

Switch Sonoff_TH16A “Sonoff Test” <light>
{ mqtt=“>[broker:cmnd/sonoff1/POWER:command:*:default],
<[broker:stat/sonoff1/POWER:state:default]” }

checking your item now…
for starters, change broker to mqttson
edit: check examples from here:

ITEAD Sonoff switches and sockets - cheap ESP8266 Wifi+MQTT hardware

ITEAD Smart Home Products https://www.itead.cc/wiki/Sonoff_Smart_Home_Solution [image][image][image] These very cheap modules come with their special smartphone app but are all actually based on the famous ESP8266. It didn’t take long till the tinkerer community got a hold of that and started hacking. After opening up the cases, all you need to do is solder a few header pins and connect your FTDI breakout programmer. Alternative firmwares are ready to provide nice MQTT based Wifi SmartHome end…

it should be something like:

Switch Sonoff_TH16A "Sonoff Test" <light> { mqtt=">[mqttson:cmnd/sonoff/power:command:*:default], <[mqttson:stat/sonoff1/power:state:default]" }

[ThomDietrich]

Hello, jumping in here because of the mentioning before.

@Dim

i think that you shouldn’t be subscribing and publishing to the same topic… maybe you will create a loop like this.

Pay attention to the first topic level: cmnd vs. stat - that’s something I personally don’t like about the Tasmota default settings. This order can btw be changed in settings.
The config is in sync with what I’ve given as a template here.

Sooo from what I’ve read we are looking at two problems here. Why is there an additional connection with the clientID mosqsub|1234-openHABian and why is your openHAB not able to receive states and send commands.

1. The additional connection is not present on my system
2. @narf27 looking at this posting your setup is simply wrong. The topic name of your module is “sonoff”, you are subscribing to “sonoff1”. Change the topic of your module before adding it to openHAB! Also just as @Dim said, you need to use the right broker name. Please check your setup against this article: GitHub - arendst/Tasmota: Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at

[Dim (Angelos)]

@ThomDietrich

Why is there an additional connection with the clientID mosqsub|1234-openHABian

this is driving me crazy

anyway this thread is a mess with 2 different setups that we are trying to debug

edit: You are right… I didn’t see the first topic level

[ThomDietrich]

Example setup Click to see fill image

–> Added to the Tasmota wiki

And the corresponding items configuration:

Switch BK_Balkonmagic "Balkonmagic" <stars> (BK,gLight)                           {mqtt=">[broker:tasmota/sonoff-A00EEA/cmnd/POWER:command:*:default], <[broker:tasmota/sonoff-A00EEA/stat/POWER:state:default]"}
Number BK_Balkonmagic_RSSI "Balkonmagic RSSI [%d %%]" (gRSSI)                     {mqtt="<[broker:tasmota/sonoff-A00EEA/tele/STATE:state:JSONPATH($.Wifi.RSSI)]"}
Switch BK_Balkonmagic_Unreach "Balkonmagic unreachable" <siren> (gUnreach)        {mqtt="<[broker:tasmota/sonoff-A00EEA/tele/LWT:state:MAP(unreach.map)]"}

[paulo9999 (Paulo Wang)]

@ThomDietrich , mine is quite the same. How is your Topic/ Full topic configuration??

[ThomDietrich]

Click the image

[paulo9999 (Paulo Wang)]

@ThomDietrich thank you! Mine configuration is the same!!!

[Dim (Angelos)]

@paulo9999

2017-07-22 07:56:06.207 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item ‘Abajur’ for widget org.eclipse.smarthome.model.sitemap.Switch

@paulo9999 : you have some errors in your sitemap file

your item is defined as Abajur_light but your sitemap is complaining about an item named Abajur

post your items and sitemap contents to be checked

[paulo9999 (Paulo Wang)]

@Dim:

@Dim

s Abajur_light but your sitemap is complaining about an item named Abajur

post your items and sitemap contents to be

thank you, sorry for this slight mistake, I’ve corrected it, now sitemap is ok but unfortunately things still isn’t working…

Paulo

[Dim (Angelos)]

is anything useful in the logs?
read again the examples that Thom posted, You will get it working (it seems that your broker connection is fine)

[narf27 (Peter)]

@Dim

anything useful with lsof -i :1883 ?
or ps -efwww |grep 7105 (that seems to be the process id)

[19:34:12] openhabian@openHABianPi:~$ lsof -i :1883
COMMAND    PID       USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mosquitto 7105 openhabian    5u  IPv4  21570      0t0  TCP localhost:40962->localhost:1883 (ESTABLISHED)

ANYWAY… these are my settings now:
sonoff device TH16:

Client Id = OH2MQTT
Topic = sonoff1
Full Topic = tasmota/%topic%/%prefix%/

items (according to @ThomDietrich) :

Switch Sonoff_TH16A "Balkonmagic" <stars>                            {mqtt=">[broker:tasmota/sonoff1/cmnd/POWER:command:*:default], <[broker:tasmota/sonoff1/stat/POWER:state:default]"}
Number Sonoff_TH16A_RSSI "Balkonmagic RSSI [%d %%]"                  {mqtt="<[broker:tasmota/sonoff1/tele/STATE:state:JSONPATH($.Wifi.RSSI)]"}
Switch Sonoff_TH16A_Unreach "Balkonmagic unreachable" <siren>        {mqtt="<[broker:tasmota/sonoff1/tele/LWT:state:MAP(unreach.map)]"}

mqtt.cfg:

[19:59:02] openhabian@openHABianPi:~$ cat /var/lib/openhab2/config/org/openhab/mqtt.config
mqttson.clientId="openHAB2"
mqttson.url="tcp://127.0.0.1:1883"
service.pid="org.openhab.mqtt"

[ThomDietrich]

So… does it work?

I feel like both of you should take a step back. For example in your posting the Client Id = OH2MQTT - Do you know what this means? Your setting doesn’t make much sense, you should just leave it with the default setting. Next your Topic setting. Why sonoff1? Give it a meaningful name, something you can work with (e.g. “sonoff-coridorlight”, not too long, no underscore).

Your config looks okay. You can again leave the client Id setting commented to have a random one generated. I take it your broker doesn’t provide authentication? If you’ve installed via openHABian setting up a password was offered.

After you’ve set up everything do a test. You could for example restart openHAB, then wait a few minutes and check the log for mqtt related messages. It should look similar to this one:

[21:22:34] openhabian@openHABianPiW66a:~$ grep "mqtt" /var/log/openhab2/*
/var/log/openhab2/openhab.log:2017-07-22 16:52:19.891 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
/var/log/openhab2/openhab.log:2017-07-22 16:52:19.893 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'broker'
/var/log/openhab2/openhab.log:2017-07-22 17:13:40.344 [INFO ] [penhab.io.transport.mqtt.MqttService] - Stopping broker connection 'broker'
/var/log/openhab2/openhab.log:2017-07-22 17:15:24.084 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
/var/log/openhab2/openhab.log:2017-07-22 17:15:24.089 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'broker'