Issue of the topic: all ZB status of devices can be set from OH but not get
Thing and item configuration related to the issue
UID: mqtt:topic:MQTTBroker:DStu01
label: Luce studio
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mosquitto
location: Luce studio
channels:
- id: chLucestudio
channelTypeUID: mqtt:switch
label: Luce studio
description: Luce studio
configuration:
commandTopic: zigbee2mqtt/DStu01/set
postCommand: true
retained: false
qos: 0
stateTopic: zigbee2mqtt/DStu01/state
After a new installation I got a strange behavior from OH4. It seems that all ZB status of devices can be set from OH but not get.
To make an example, I have a light switch (see above) where I can set its ON/OFF status from OH4 but OH4 seems unable to get it from mosquitto (with the exception of events coming from non-zigbee devices).
Already checked that the status changes (in both directions) are correctly reflected on MQTT.
Already enabled DEBUG level on OH logs (only for openhab.event.ItemStateChangedEvent, openhab.event.ItemStateEvent, openhab.event.ItemStateUpdatedEvent)
Will be appreciated any idea to point me in the right direction.
There is a whole big mix of moving parts here that I’m really just guessing at. We will need a whole lot more information.
But first of all, always post code, configs, and logs using code fences.
```
code goes here
```
Particularly with YAML the white space is meaningful. Without code spaces we lose the white space.
So you have zigbee2mqtt which means from OH’s perspective this is an MQTT config, not a Zigbee config. OH essentially knows nothing of Zigbee.
By this you mean that when you send a command to the Item linked to this Channel you see the ON/OFF command message on the zigbee2mqtt/DStu01/set topic and when you change the switch outside of OH you see the ON/OFF message published to the zigbee2mqtt/DStu01/state topic.
Have you verified that the messages are correct? By correct I mean that the content and the formatting of the message are correct. In the command direction the message is as zigbee2mqtt expects and in the update direction the message is exacltly one of ON or OFF (no JSON, no extra formatting, etc.)?
You’ll only see those log statements when the MQTT Channel is already configured correctly. All evidence so far indicates it is not configured correctly. Do you see errors in openhab.log?
[quote=“rlkoshak, post:2, topic:157176, full:true”]
There is a whole big mix of moving parts here that I’m really just guessing at. We will need a whole lot more information.
You’re right, my post can be confused.
Here my configuration.yaml of z2m
[quote=“iceland12, post:1, topic:157176”]
So you have zigbee2mqtt which means from OH’s perspective this is an MQTT config, not a Zigbee config. OH essentially knows nothing of Zigbee.
Completely right!
By this you mean that when you send a command to the Item linked to this Channel you see the ON/OFF command message on the zigbee2mqtt/DStu01/set topic and when you change the switch outside of OH you see the ON/OFF message published to the zigbee2mqtt/DStu01/state topic.
Yes, both commands (sent from OH to the device and command sent outside OH) have reflected the change on z2m log and on the device. The first change OH item status, the second one leave it untouched.
Then in the previous installation you either had the on and off property of the Channel configured or you had a transformation. It has always been the case that a Switch only understands ON and OFF as an update or a command. Case matters so you can’t even send “on” or “off”. If anything other that ON or OFF is published to the topic, the message must be transformed.
This has not changed since MQTT was first implemented way back in OH 1.
I’m quite sure that in the previous installation I never used transformation for switch type.
So, considering my payload is {“linkquality”:148,“state”:“ON”} it’s not enough to have the customized ON/OFF values (in capital letters) on the channel config ?
Tested but nothing changed. Below the code of thing/item
UID: mqtt:topic:MQTTBroker:DStu01
label: Luce studio
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mosquitto
location: Luce studio
channels:
- id: chLucestudio
channelTypeUID: mqtt:switch
label: Luce studio
description: Luce studio
configuration:
commandTopic: zigbee2mqtt/DStu01/set
postCommand: true
retained: false
qos: 0
transformationPattern: JSONPATH:$.state
I’m surprised that in the OH log I found only messages of OH → MQTT status changes but nothing related to MQTT–>OH changes.
Below an extract of OH log:
2024-07-14 14:27:23.824 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Luce_studio_Luce_studio' predicted to become ON
2024-07-14 14:27:23.825 [INFO ] [openhab.event.ItemStateEvent ] - Item 'Luce_studio_Luce_studio' shall update to ON
2024-07-14 14:27:23.827 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Luce_studio_Luce_studio' updated to ON
2024-07-14 14:27:23.828 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Luce_studio_Luce_studio' changed from OFF to ON
I believe there is a way to configure zigbee2mqtt to not publish JSON and instead break the messages up into separate topics. Perhaps that’s what you did before.
But it’s never been the case where you can send JSON to a switch Item as an update or a command without transformation.
That’s events.log. you won’t see anything there unless it works, which it isn’t right now, and you’ll never see errors in that log. What do you see in openHAB.log?
In order to use json you have to have transformations installed and configured also
Have a look here
pay attention to line 17 on
# Optional: disables the legacy api (default: shown below)
legacy_api: true
# Optional: MQTT output type: json, attribute or attribute_and_json (default: shown below)
# Examples when 'state' of a device is published
# json: topic: 'zigbee2mqtt/my_bulb' payload '{"state": "ON"}'
# attribute: topic 'zigbee2mqtt/my_bulb/state' payload 'ON"
# attribute_and_json: both json and attribute (see above)
output: 'json'
If you recently updated you zigbee2mqtt then you now get json by default
your config shows you have legacy turned off.
@Larsen and @rlkoshak both you have completely found the solution! I completely forgotten the existance of this parameter.
Thanks a lot for your precious help!
