[Bug] Philips Dimmer Switch not Performing Actions

[jtrahan]

I have 4 Philips Dimmer Switches and for quite some time they have been working fine. However I recently updated zigbee2mqtt and also z2m and now it's not performing the associated actions. I put homebridge into debug mode to capture the logs and here is what i'm seeing.

I've tried removing the cached accessories, reinstalling the plugin, restarting homebridge and homepod, etc. It doesn't matter what I do the actions are no longer working.

LOGS

[3/25/2022, 9:56:07 AM] [zigbee2mqtt] Connected to MQTT server [3/25/2022, 9:56:07 AM] [zigbee2mqtt] Using Zigbee2MQTT v1.24.0 (identified via zigbee2mqtt/bridge/info)

[3/25/2022, 9:56:14 AM] [zigbee2mqtt] Mapping of property 'action' of device 'Dimmer Switch - Kitchen': Button 1 (down):

• SINGLE: down_press
• LONG : down_hold Button 2 (off):
• SINGLE: off_press
• LONG : off_hold Button 3 (on):
• SINGLE: on_press
• LONG : on_hold Button 4 (up):
• SINGLE: up_press
• LONG : up_hold

[3/25/2022, 9:59:36 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Living Room: {"action":"on-press","battery":100,"brightness":129,"counter":1,"duration":0,"linkquality":255,"update":{"state":"idle"},"update_available":false} [3/25/2022, 10:00:08 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Living Room: {"action":"up-press","battery":100,"brightness":193,"counter":1,"duration":0,"linkquality":255,"update":{"state":"idle"},"update_available":false} [3/25/2022, 10:00:26 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Living Room: {"action":"down-press","battery":100,"brightness":129,"counter":1,"duration":0,"linkquality":255,"update":{"state":"idle"},"update_available":false} [3/25/2022, 10:00:37 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Living Room: {"action":"off-press","battery":100,"brightness":129,"counter":1,"duration":0,"linkquality":255,"update":{"state":"idle"},"update_available":false}

[itavero]

Next time, please provide all the information requested in the Bug Report issue template.

This sounds similar to #382. Have you tried changing the legacy option (or something similar) in Zigbee2MQTT for this device?

If that does not help, then please provide the information requested in the issue template.

[jtrahan]

Ahh yeah they changed how it's handled. They actually say to set legacy to false per the information below. Thanks for the tip and I'll close this issue

https://www.zigbee2mqtt.io/devices/324131092621.html

[jtrahan]

As an additional note here is an example of the payloads if it's legacy or not legacy in case you need to make changes to handle either situation. just guessing without looking at the code but it appears that z2m may be looking for the "_release" events.

Legacy = true Note 1 Event [3/25/2022, 9:59:36 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Living Room: {"action":"on-press","battery":100,"brightness":129,"counter":1,"duration":0,"linkquality":255,"update":{"state":"idle"},"update_available":false}

Legacy = false Note 2 Events [3/25/2022, 10:29:58 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Kitchen: {"action":"on_press","battery":98,"brightness":191,"counter":1,"linkquality":255,"update":{"state":"idle"},"update_available":false} [3/25/2022, 10:29:58 AM] [zigbee2mqtt] Handled device update for Dimmer Switch - Kitchen: {"action":"on_press_release","battery":98,"brightness":191,"counter":1,"linkquality":255,"update":{"state":"idle"},"update_available":false}

An Additional Event for Long Press when legacy is off Handled device update for Dimmer Switch - Kitchen: {"action":"off_hold","action_duration":2.395,"battery":98,"brightness":191,"counter":1,"linkquality":255,"update":{"state":"idle"},"update_available":false}

[jtrahan]

Actually it appears the behavior is different when legacy is false. If I do a long press the short press event is triggered before the long press event actually occurs. so maybe it's not looking at the _release events after all. But this I would consider a bug because the _release event doesn't get triggered if there is an _hold event

[itavero]

For this device the plugin looks at the following values (take from the log you shared), which it got from the Exposes information:

Mapping of property 'action' of device 'Dimmer Switch - Kitchen':
Button 1 (down):
- SINGLE: down_press
- LONG : down_hold
Button 2 (off):
- SINGLE: off_press
- LONG : off_hold
Button 3 (on):
- SINGLE: on_press
- LONG : on_hold
Button 4 (up):
- SINGLE: up_press
- LONG : up_hold

[jtrahan]

That is what it's picking up. However when legacy is false it appears the order of events are

xxx_press = initial event when press, should be no action taken xxx_press_release = button let go, this is when the single press event should fire. it does not get triggered when it's a long press xxx_hold = long press

[itavero]

The remote controls I've tried from other manufacturers do not work like that. I'm afraid there's no straightforward way to change this, without introducing some additional configuration (which is what I'd like to avoid in this on in general).

Personally I also have a Hue Dimmer Switch, but I have it paired directly to a group of Zigbee lights via Zigbee2MQTT, so I've never noticed this different behavior.

[jtrahan]

It's probably from whatever recent change was made that broke my switches in the first place. But the order of events happens on all 4 of my switches when I set them to legacy false in zigbee2mqtt. If I have time I may pull the code and see if I can help you figure out something so we wouldn't have to make configuration changes.

[jtrahan]

OK I figured why when it's in legacy mode it's not working anymore. z2m is expecting xxx_press and xxx_hold. However looking at the payload it's sending xxx-press and xxx-hold. When legacy is false then zigbee2mqtt is sending xxx_press and xxx_hold

z2M Button 3 (on):

• SINGLE: on_press
• LONG : on_hold

This is what I'm seeing from zigbee2mqtt. {"action":"on-press","battery":100,"brightness":223,"counter":1,"duration":0,"linkquality":255,"update":{"state":"idle"},"update_available":false}

[itavero]

I'm not sure if I've already raised an issue for it on the Zigbee2MQTT repository, but the exposes information that it provides does not take that legacy configuration into account.

[jtrahan]

That definitely what it looks like. When I removed the dimmer and rejoined it back to the network even though it defaults to legacy it's definitely setting the exposes incorrectly. Here is a log entry if you're going to report it to the Zigbee2MQTT team.

Zigbee2MQTT:info 2022-03-28 11:50:40: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"definition":{"description":"Hue dimmer switch","exposes":[{"access":1,"description":"Remaining battery in %","name":"battery","property":"battery","type":"numeric","unit":"%","value_max":100,"value_min":0},{"access":1,"description":"Triggered action (e.g. a button click)","name":"action","property":"action","type":"enum","values":["on_press","on_hold","on_hold_release","up_press","up_hold","up_hold_release","down_press","down_hold","down_hold_release","off_press","off_hold","off_hold_release"]},{"access":1,"name":"action_duration","property":"action_duration","type":"numeric","unit":"second"},{"access":1,"description":"Link quality (signal strength)","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"324131092621","options":[{"access":2,"description":"Set to false to disable the legacy integration (highly recommended), will change structure of the published payload (default true).","name":"legacy","property":"legacy","type":"binary","value_off":false,"value_on":true}],"supports_ota":true,"vendor":"Philips"},"friendly_name":"0x0017880104f36e54","ieee_address":"0x0017880104f36e54","status":"successful","supported":true},"type":"device_interview"}'

However as a future item I think some development work will be needed if someone does turn off the legacy flag since it does unexpected behaviors for the long press events due to it adding the _release events

[jtrahan]

Just an FYI, I rolled Zigbee2MQTT back to 1.22.2 and now the exposes events match up. This gets me back to expected behavior for now.

[stale[bot]]

It appears that this issue did not have an update in quite some time. Please check if you can provide any additional information to help resolve this issue. If there isn't any activity in the next two weeks, this issue will be closed automatically. Thank you for your contributions!