MQTT switch help

Turning DEBUG on like that did not work, but I just did DEBUG and it turned on for everything. Here is what it gave me :

17:00:59.508 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho70904578979633: received bytes count=1
17:00:59.508 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho70904578979633: received bytes count=27
17:00:59.509 [DEBUG] [mqttv3.internal.wire.MqttInputStream] - null: 501
17:00:59.509 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho70904578979633: received key=0 message=PUBLISH qos:0 retained:false dup:false topic:“VBMC/0100000B-01/state” payload:[hex:4f4e00 utf8:“ON” length:3]
17:00:59.509 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho70904578979633: new msg avail, notify workAvailable
17:00:59.509 [DEBUG] [client.mqttv3.internal.CommsReceiver] - paho70904578979633: network read message
17:00:59.510 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho70904578979633: call messageArrived key=0 topic=VBMC/0100000B-01/state
17:00:59.510 [WARN ] [b.core.events.EventPublisherDelegate] - given new state is NULL, couldn’t post update for 'TestSwitch’
17:00:59.511 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho70904578979633: notify spaceAvailable
17:00:59.511 [DEBUG] [client.mqttv3.internal.CommsCallback] - paho70904578979633: wait for workAvailable

Does that give you any clues?

Regards

Ben

Hi Watou,

Any thoughts on my situation?

Ben

Hi Ben,

If the MQTT item binding binds a Switch item to “<[broker:topic:state:default]”, then any message published to broker:topic must be a string ON or OFF, no spaces or padding. This ought to resolve to an OnOffType state which is then posted to the item (binding code). But it’s not working, or the strings aren’t exactly ON or OFF.

I don’t know how to interpret the Paho log message “paho70904578979633: call messageArrived key=0 topic=VBMC/0100000B-01/state”, but if “key” meant the message and it is “0”, then you would need to replace “default” in the item binding string with MAP(onoff.map), and the file transform/onoff.map would have to contain:

0=OFF
1=ON

so the binding would try to parse the ON or OFF that it needs. But like I said, “key=0” might not refer to the message itself.

If the above doesn’t help, please post your complete configuration (mqtt lines from openhab.cfg and your items file contents at least, and relavent log lines). Surround the snippets with new lines only containing three backtick marks (```), so it’s easier to spot whitespace padding.

Hi Watou

I would suggest the debug message of interest is this one :

17:00:59.509 [DEBUG] [o.client.mqttv3.internal.ClientState] - paho70904578979633: received key=0 message=PUBLISH qos:0 retained:false dup:false topic:“VBMC/0100000B-01/state” payload:[hex:4f4e00 utf8:“ON” length:3]

From that it would be the payload we are looking at which is 0x4F 0x4E 0x00, a Null terminated string “ON” So I think thats as it should be.

Here is the config I am using:

From mqtt.cfg in conf/services

‘’‘
mosquitto.url=tcp://10.20.31.186:1883
mosquitto.qos=1
’’’

From demo.items in conf/items

‘’‘
Switch TestSwitch {mqtt="<[mosquitto:VBMC/0100000B-01/state:state:default]"}
String TestString {mqtt="<[mosquitto:VBMC/0100000B-01/state:state:default]"}
’’’

Hi Ben,

Maybe the NUL termination of the string is unintentionally being considered? Could you use mosquitto_pub at a command line to try to publish just ON and OFF to the topic, and see if the Switch item updates?

mosquitto_pub -t VBMC/0100000B-01/state -m ON
mosquitto_pub -t VBMC/0100000B-01/state -m OFF

(you may need other flags, depending on your configuration)

If using mosquitto_pub causes the Switch item to update and there is no “given new state is NULL, couldn’t post update for ‘TestSwitch’” log message, then you can either change the code that publishes the ON or OFF to not include the NUL termination, or—and this may not work—you might be able to use a MAP file like:

ON\u0000=ON
OFF\u0000=OFF

(kind of a stab in the dark, but try mosquitto_pub anyway to see what happens)

Ok, I tried that, and with mosquitto_pub it works fine. So it looks like the extra NULL in the termination is causing the issue.

I shall modify my code to only send the ON or OFF and not the NULL termination from the hardwares firmware.

Thanks for the help!

Regards

Ben

1 Like

Thanks an easy and effective solution