Fix Livolo state handling

[ashway83]

The toZigbee livolo_socket_switch_on_off convertSet converter was returning state_<endpoint> which results in new state errorneous values where endpoint suffix is appended twice, e.g.
{"linkquality":94,"state_left":"OFF","state_right":"OFF","state_right_right":"OFF","state_left_left":"OFF"}

This trivial fix resolves the issue.

It should also address Koenkk/zigbee2mqtt#13531

I've built Docker images for convenient and quick testing:
https://hub.docker.com/r/ashway83/zigbee2mqtt/tags

[Koenkk]

Thanks!

[sanychonline]

This update cause switch status change - it was switched, but apple home app flaps status back to off (switch stays on).
Please post status ON twice (like version 1.24),, and OFF also twice. This completely resolves issue.

[ashway83]

This update cause switch status change - it was switched, but apple home app flaps status back to off (switch stays on).
Please post status ON twice (like version 1.24),, and OFF also twice. This completely resolves issue.

@sanychonline, this update doesn't affect the logic of sending status updates. It only fixes state properties, e.g. instead of

{"linkquality":94,"state_left":"OFF","state_right":"OFF","state_right_right":"OFF","state_left_left":"OFF"}

the correct state message is generated.

{"linkquality":94,"state_left":"OFF","state_right":"OFF"}

Do you use MQTT-Thing Homebridge plug-in? I also noticed the behavior you mentioned with MQTT-Thing. I'll investigate that further.

[sanychonline]

I use "homebridge-z2m": "^1.9.0" as a communication between homebridge and zigbee2mqtt

[ashway83]

@sanychonline I see, anyways the number of consequent duplicated updates shouldn't cause status changes on the Homebridge side. I suggest you to update your original issue Koenkk/zigbee2mqtt#13531 and provide logs.

[ashway83]

@sanychonline I can confirm the behavior you described with homebridge-z2m 1.9.0. I can also confirm that Zigbee2MQTT reports status updates correctly. It looks like the issue is on the homebridge/plugin side. I'll try to troubleshoot that.

For example, initial state_left is ON, on iOS device I switched left endpoint to OFF, lights went off, the corresponding accessorry on iOS device went off, and then on again.

2022-08-24 20:21:39 Received MQTT message on 'zigbee2mqtt/0x00124b001802eebd/set' with data '{"state_left":"OFF"}'
Debug 2022-08-24 20:21:39 Publishing 'set' 'state' to 'sw-living-room-2'
Debug 2022-08-24 20:21:40 Received Zigbee message from 'sw-living-room-2', type 'raw', cluster 'genPowerCfg', data '{"data":[124,210,21,216,0,189,238,2,24,0,75,18,0,34,0,1],"type":"Buffer"}' from endpoint 6 with groupID 0
Info 2022-08-24 20:21:40 MQTT publish: topic 'zigbee2mqtt/sw-living-room-2', payload '{"linkquality":94,"state_left":"ON","state_right":"OFF"}'
Info 2022-08-24 20:21:40 MQTT publish: topic 'zigbee2mqtt/sw-living-room-2', payload '{"linkquality":94,"state_left":"OFF","state_right":"OFF"}'
Debug 2022-08-24 20:21:40 Received Zigbee message from 'sw-living-room-2', type 'raw', cluster 'genPowerCfg', data '{"data":[124,210,21,216,0,189,238,2,24,0,75,18,0,34,0,0],"type":"Buffer"}' from endpoint 6 with groupID 0
Info 2022-08-24 20:21:40 MQTT publish: topic 'zigbee2mqtt/sw-living-room-2', payload '{"linkquality":91,"state_left":"OFF","state_right":"OFF"}'

My debugging command line MQTT client received the following:

{"linkquality":94,"state_left":"ON","state_right":"OFF"}
{"linkquality":94,"state_left":"OFF","state_right":"OFF"}
{"linkquality":91,"state_left":"OFF","state_right":"OFF"}

It looks like frequently repeated OFF state updates are triggering some debouncing logic on the homebridge side. Or possibly the state values are ignored and status update events act as a toggle instead of explicit on/off commands.

For now, as a workaround, you can enable debounce for Livolo switches, e.g.

  '0x00124b001802aebd':
    friendly_name: sw-living-room-2
    debounce: 1

[sanychonline]

@ashway83 Yeah. It works. The status flaps one time, but then goes back to actual. So the behavior on home app looks like:
Press switch "on"
Status set to "on"
Status goes back to "off"
Then it updates to actual "on"

The same scenario when we want to switch it off. Status flaps, but it works.

Config part for device:

devices:
'0x00124b0018021438':
friendly_name: LivingRoomLED
debounce: 1

Zigbee2mqtt log part:
Zigbee2MQTT:info 2022-08-26 09:54:30: MQTT publish: topic 'zigbee2mqtt/LivingRoomLED', payload '{"linkquality":28,"state_left":"OFF","state_lef
t_left":"ON","state_right":"OFF"}'
Zigbee2MQTT:info 2022-08-26 09:54:31: MQTT publish: topic 'zigbee2mqtt/LivingRoomLED', payload '{"linkquality":36,"state_left":"ON","state_left
_left":"ON","state_right":"OFF"}'
Zigbee2MQTT:info 2022-08-26 09:54:35: MQTT publish: topic 'zigbee2mqtt/LivingRoomLED', payload '{"linkquality":36,"state_left":"ON","state_left
_left":"OFF","state_right":"OFF"}'
Zigbee2MQTT:info 2022-08-26 09:54:36: MQTT publish: topic 'zigbee2mqtt/LivingRoomLED', payload '{"linkquality":31,"state_left":"OFF","state_lef
t_left":"OFF","state_right":"OFF"}'

homebridge log:
[8/26/2022, 12:54:30 PM] [zigbee2mqtt] Publish to 'zigbee2mqtt/0x00124b0018021438/set': '{"state_left":"ON"}'
[8/26/2022, 12:54:34 PM] [zigbee2mqtt] Publish to 'zigbee2mqtt/0x00124b0018021438/set': '{"state_left":"OFF"}'

[sanychonline]

Anyway, I wonder: zigbee2mqtt version 1.24.0 has no such issues and does not require any special config update, so as per my understanding something changed right in 1.25.0 and later builds.

[ashway83]

While investigating this issue, I've found a bug on the Homebridge side - in HAP-NodeJS homebridge/HAP-NodeJS#964

@sanychonline It looks like the version of zigbee-herdsman-converters which is used in zigbee2mqtt 1.24.0 was sending an extra state update and that served as a workaround.