After crash "1" instead of "ON"

Either I am blind or insane.

Everything went fine except for Sunday when OH 2.4.1-0 froze and I had to restart the PI.

The USB stick with Zigbee2MQTT was no longer active and so all Zigbee sensors were gone.
At first I thought that the stick was defective, but after rebooting everything was fine again. I thought.
A Mueller bulb did not work anymore. During research I found the following.

.things

Type switch : mueller_0x00158d00031dc5fe_light      "Keller 2"           [stateTopic="z2mqtt/0x00158d00031dc5fe",transformationPattern="JSONPATH:$.state", commandTopic="z2mqtt/0x00158d00031dc5fe/set", formatBeforePublish="{\"state\":\"%s\"}"]

.items

Switch  KG_Flur_Licht_1dc5fe_Switch          "Flur KG"         <switch>    (gKeller,gHaus_Lichter,gKG)               { channel="mqtt:topic:MyMosquitto:lichter:mueller_0x00158d00031dc5fe_light"}

In a rule, a motion detector is queried and then a command is triggered.

KG_Flur_Licht_1dc5fe_Switch.sendCommand(ON)

But the following is sent to the MQTT server:

Nov 17 01:39:18 openHABianPi npm[550]: Zigbee2MQTT:error 2020-11-17 01:39:18: Publish 'set' 'state' to '0x00158d00031dc5fe' failed: 'Error: State value of message: '{"state":"1"}' invalid, must be 'ON', 'OFF' or 'TOGGLE''
Nov 17 01:39:18 openHABianPi npm[550]: Zigbee2MQTT:info  2020-11-17 01:39:18: MQTT publish: topic 'z2mqtt/bridge/log', payload '{"message":"Publish 'set' 'state' to '0x00158d00031dc5fe' failed: 'Error: State value of message: '{\"state\":\"1\"}' invalid, must be 'ON', 'OFF' or 'TOGGLE''","meta":{"friendly_name":"0x00158d00031dc5fe"},"type":"zigbee_publish_error"}'

Why does OH turn the “ON” into a “1”? Where can I search for the error?

The code has not been changed.

1 Like

In the nearly 1 1/2 years since OH 2.4 came out a ton of stuff has been fixed, updated, and changed in the MQTT binding. I do not think there will be anyone here left on the forum with the knowledge and recent experience necessary to recommend anything more than updating to OH 2.5.10 or the OH 3 milestone release and if the problem persists put the binding into debug logging and post the logs.

The fact that the RPi froze and you had to restart probably means that you had to pull the power from the machine. If it was writing to the SD card when you pulled the power than it’s likely that some files on your machine were corrupted. This can result is strange behavior from the subtle (like this) to the catastrophic. It’s always a good procedure to restore from a known good backup when ever you pull the power from any machine that relies on any flash based storage.

1 Like

You were right. But since this was the only irregularity, I did not suspect it. Whatever happened, I will not be able to comprehend it anymore.

But I took the opportunity to update from 2.4.1 to 2.5.x.

Now I still have to fix the problems with add-ons that obviously don’t start anymore, like

openhab-misc-unifi
openhab-misc-netatmo
openhab-misc-ecotouch1

Strange things happen.

After two days working perfectly, same problem get back in place

Sending command (ON)

Type switch : mueller_0xxxxx_light      "Keller 2"           [stateTopic="z2mqtt/0xxxxx",transformationPattern="JSONPATH:$.state", commandTopic="z2mqtt/0x0xxxx/set", formatBeforePublish="{\"state\":\"%s\"}"]


KG_Flur_Licht_1dc5fe_Switch.sendCommand(ON)

is sent as “1

Publish 'set' 'state' to '0xxxx' failed: 'Error: State value of message: '{"state":"1"}' invalid, must be 'ON', 'OFF' or 'TOGGLE''

Where is the instance that could cause this?

I can now exclude an error on the SD-Card, because after the update to 2.5.x everything worked.

:roll_eyes:

Whilst I can’t answer the ‘why did it work before, but it’s not working now question’, to fix this issue I would recommend:

  • Setup zigbee2mqtt so that it publishes attributes separately as a plain string, rather than JSON. See this post for more info.. This means you won’t have to use funky transformationPattern or formatBeforePublish parameters in your Thing Channel.
  • Add on="ON", off="OFF" to the end of your Thing Channel configuration, to force openHAB to publish either ON or OFF.