Aquara opple switch sends "release" before the button is released

[andrasbiro]

What happened?

While investigating why I cannot use my opple switch for dimming, I found that it sends button_x_release exactly 5s after button_x_hold, even if I keep pressing the button.

Exact device is WXCJKG13LM

The same works with home assistant ZHA, and I suspect it worked at some point, as there are hass blueprints for it, e.g. https://community.home-assistant.io/t/zigbee2mqtt-aqara-opple-switch-3-bands/256212 Note that the last commenter here seems to have the same issue as I have.

What did you expect to happen?

button_x_release should be only sent when the button is released

How to reproduce it (minimal and precise)

See above

Zigbee2MQTT version

1.28.2

Adapter firmware version

20210120

Adapter

zzh!

Debug log

info 2022-11-28 00:53:20: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c75b377', payload '{"action":"button_5_hold","battery":100,"linkquality":84,"operation_mode":null,"power_outage_count":262,"voltage":3014}' info 2022-11-28 00:53:20: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c75b377', payload '{"action":"","battery":100,"linkquality":84,"operation_mode":null,"power_outage_count":262,"voltage":3014}' info 2022-11-28 00:53:20: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c75b377/action', payload 'button_5_hold' info 2022-11-28 00:53:20: MQTT publish: topic 'zigbee2mqtt/reading-livingroom', payload '{"brightness":201,"color_mode":"color_temp","color_temp":454,"linkquality":120,"power_on_behavior":null,"state":"ON","update":{"state":"available"},"update_available":true}' info 2022-11-28 00:53:25: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c75b377', payload '{"action":"button_5_release","battery":100,"linkquality":84,"operation_mode":null,"power_outage_count":262,"voltage":3014}' info 2022-11-28 00:53:25: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c75b377', payload '{"action":"","battery":100,"linkquality":84,"operation_mode":null,"power_outage_count":262,"voltage":3014}' info 2022-11-28 00:53:25: MQTT publish: topic 'zigbee2mqtt/0x04cf8cdf3c75b377/action', payload 'button_5_release'

[danieledwardgeorgehitchcock]

It looks like this is coming from the device itself and is therefore not a Z2M issue

[andrasbiro]

I would assume too, but hass zha somehow worked (but the switch didn't reconnect to hass zha after hass restart, so I come back to z2m). I will try to set up a sniffer and take a look (I have some silabs devkits)

[andrasbiro]

All right, I've set up a sniffer. Before going into details, I'm sorry if I misidentify something - I don't know much about zigbee, however, I am quite familiar with 802.15.4 So here's what I see (I was filtering on 15.4 src address):

"momentary" press

When I press the button short, the device sends out a ZCL ReportAttribute message, with attribute ID 0x55, and 0x0001 as an int16 attribute. (I suppose the button ID is always in the application support field, as I see the source endpoint changing based on the button for all of these ZCL msgs). I suppose this is a well known fact, since it's working nicely, but it's good to have it here for the sake of comparison.

"mid-long" press

And by "mid-long" I mean about 1s long

1. The device sends out a ZCL ReportAttribute message, with attribute ID 0x55, and 0x0000 as an int16 attribute
2. This is followed shortly by the same message with 0x00FF attribute.

It seems that this is what is supported by zigbee2mqtt, as I also see my automation triggered by it

"long" press

I just keep pressing, but the log suggest that the threshold is 2s.

1. The same first message goes out (0x55/0x0000)
2. followed by a 15.4 data request 2 seconds later. I think that "signals" the long press started
3. When I finally release the button, another data request is sent

And this is what is not supprted at the moment, or rather, handled incorrectly as a "mid-long" press. I cannot find the message for the 5s delay I've seen in the zigbee2mqtt log, so I suspect there is a timeout, which triggers that message, assuming the 0x00FF message got lost.

Let me know if you need more info. Though it might take me a while to set up the sniffer again, if you need info from my captured log, I can look into that.

[andrasbiro]

I checked with ZHA, and with that, the long press also sends the 0x00FF attribute, instad of the second data request. Maybe it is configuring the device differently?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[new-kirte]

I have the same issue. I had automati9ns that worked perfectly for more than 12 months and stopped working now

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days