Bug - Philips Hue Dimmer Switch v2, when double press is enabled, single press is recognized as double

[rubin110]

Blueprint name

philips_929002398602

Home Assistant Core Version

2022.10.2

Home Assistant Installation Type

Home Assistant Supervised

Description

My apology if I miss a requirement entering this bug, it's my first time here.

After enabling double press for a button on my dimmer switch, single button presses are no longer recognized by the automation. They are printed out in the helper as a double press.

I've gone through and adjusted the delay. Once it's under about 100ms I can get single button presses again but it's impossible to recognize a double press event.

Disabling double press on a button (there seems to be a bug with the blueprint UI some resets to values don't save, so I've just been editing the yaml) brings back single presses.

I've looked through the code when the double press condition happens but haven't spotted anything weird. Looking at the events from the action entity all I see is a single press and then a release, however there seems to be some kind of clear state happening after the press and then also the release. I don't know if that's expected. Please see screenshot.

Automation YAML config

alias: Rubin Switch
description: ""
use_blueprint:
  path: EPMatt/philips_929002398602.yaml
  input:
    controller_entity: sensor.rubin_switch_action
    helper_last_controller_event: input_text.rubin_switch
    integration: Zigbee2MQTT
    button_off_double_press: true
    action_button_off_double:
      - service: scene.turn_on
        target:
          entity_id: scene.rubin_s_lights_red
        metadata: {}

To Reproduce

Repro steps:

1. Pair a Philips Dimmer Switch v2 to a Zigbee2MQTT instance
2. Create the needed helper and light hook.
3. Create a new automation with the philips_929002398602 blueprint
4. Define the switch action entity and helper
5. Enable double press for the down button
6. Save the automation
7. View the helper entity's value
8. Single press the down button
9. Observe

Expected behavior

Expected result:
A single press event is recorded
{"a": "off_press_release", "t": 1665447076.87523}

Actual Behaviour

Actual results:
a double press event is recorded
{"a": "double_press", "t": 1665447722.531603}

Additional Details

• I'd like to help developing a fix for this issue.

Screenshots

Additional context

Logs from Zigbee2MQTT:

Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin Switch', payload '{"action":"off_press","battery":92,"linkquality":120,"update":{"state":"idle"},"update_available":false}'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin Switch', payload '{"action":"","battery":92,"linkquality":120,"update":{"state":"idle"},"update_available":false}'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin Switch/action', payload 'off_press'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin Switch', payload '{"action":"off_press_release","battery":92,"linkquality":120,"update":{"state":"idle"},"update_available":false}'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin Switch', payload '{"action":"","battery":92,"linkquality":120,"update":{"state":"idle"},"update_available":false}'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin Switch/action', payload 'off_press_release'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin 1', payload '{"brightness":48,"color":{"h":3,"hue":3,"s":100,"saturation":100,"x":0.677,"y":0.319},"color_mode":"xy","color_temp":232,"linkquality":171,"state":"ON","update":{"state":"idle"},"update_available":false}'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin 2', payload '{"brightness":48,"color":{"h":357,"hue":357,"s":100,"saturation":100,"x":0.667,"y":0.284},"color_mode":"xy","color_temp":153,"linkquality":120,"state":"ON","update":{"state":"idle"},"update_available":false}'
Info 2022-10-10 19:29:23MQTT publish: topic 'zigbee2mqtt/Rubin 3', payload '{"brightness":48,"color":{"h":358,"hue":358,"s":100,"saturation":100,"x":0.683,"y":0.291},"color_mode":"xy","color_temp":154,"linkquality":76,"state":"ON","update":{"state":"idle"},"update_available":false}'

[rubin110]

Note that long presses are still recognized just fine.

[deathbybandaid]

I'm experiencing the same thing with v1 switches using ZHA.

Single Presses are being registered as double presses, and long presses work just fine.

[inertia666]

I've tried both ZHA and Zigbee2MQTT with this blueprint and it's the same problem. Seems to be related the helper.

Another part of the issue is that even after deleting the double click event and unexposing the double click behaviour the single click no longer works properly.

[inertia666]

https://github.com/EPMatt/awesome-ha-blueprints/blob/902b87a8d59ae59cf5151fda271ffd21b61a2c4c/blueprints/controllers/philips_929002398602/philips_929002398602.yaml

This commit seems to fix the issues with the double click but then a single click with a light hook no longer seems to work.

If i set up a double click on the "on" button this will trigger but I cannot turn on the light. The dim buttons work and the off button works but not the single click on to turn on the light.

[kenny-f]

I'm also seeing this issue.
I had to disable double press to get single press working again

[cptkng]

I'm experiencing the same thing with v1 switches using ZHA.

Same issue here

[AllardKatan]

The Hue dimmers have native double press support. If you double press them, they don't send two single press commands, but one double press command. This is not reflected in the blueprint. On top of this, the blueprint listens to both press and release of the button (there is a separate issue, # 457, related to that) . So when you press and release once, you trigger the automation twice, which makes it think there is a double press, not a single. The solution would be to 1) only listen to 'release' commands for the short press. 2) adding a piece of code specifically for the Hue dimmers that bypasses the whole double press partof the code and instead listens for the native double press command. Nr 2) would be a significant change to the blueprint and a step away from the generality, but for these devices it is necessary.

In fact, the Hue dimmers sends separate commands for single, double, triple, quadruple and quintuple clicks of each of the four buttons, in addition to long presses. You could program 24 different actions on a single remote! If you use the Hue app and bridge you will actually be able to program up to five scenes on multiple presses of the 'on' button of a V1 remote, but not the other ones.

[Morriz]

@AllardKatan unfortunately the zigbee implementation of the v2 also suffers the same problem. It does send on_double_press natively (even all the way up to on_quintuple_press), but it is just a clunky derivative sent after on_press and on_short_release, in effect triggering the automation 3 times in a row ;(

IMO there is no shortcut to solve this and the delay logic has to be reworked.

[Morriz]

I reviewed this blueprint and it works as intended for all the capabilities provided by the v2: https://community.home-assistant.io/t/zha-philips-hue-v2-smart-dimmer-switch-and-remote-rwl022/353143

So I recommend to switch over as it has none of the custom logic.

[Morriz]

One thing I noticed is that *_release should never be assigned anything as those ALWAYS get triggered at then end of any press. I will recommend the creator to just document that and warn users about it.

[rubin110]

Sorry for not bouncing back to this bug, life got in the way.

https://github.com/EPMatt/awesome-ha-blueprints/blob/902b87a8d59ae59cf5151fda271ffd21b61a2c4c/blueprints/controllers/philips_929002398602/philips_929002398602.yaml

This commit seems to fix the issues with the double click but then a single click with a light hook no longer seems to work.

If i set up a double click on the "on" button this will trigger but I cannot turn on the light. The dim buttons work and the off button works but not the single click on to turn on the light.

So this doesn't seem to work for me with Zigbee2MQTT. After writing over the blueprint with the new one, do I need to delete and rebuild the automation? I've got a dozen of them.

[AllardKatan]

@AllardKatan unfortunately the zigbee implementation of the v2 also suffers the same problem. It does send on_double_press natively (even all the way up to on_quintuple_press), but it is just a clunky derivative sent after on_press and on_short_release, in effect triggering the automation 3 times in a row ;(

IMO there is no shortcut to solve this and the delay logic has to be reworked.

It looks like the behavior of the switches changed since I placed my last comment, maybe some automatic update? Indeed now it sends a press and release event for every click in a multiclick action, before finally sending the multiclick event. I updated my own code but hadn't thought of revisiting this thread. I am using a self-made blueprint now, which works despite the multiple extra commands of press/release being sent. I assume it is because it sets the automation mode to 'restart', the multiple triggers don't cause any problems. It simply triggers again before taking any action. Perhaps building in a delay would make that more robust, but my old Pi3 isn't quick enough to cause trouble :)

[Morriz]

Please read my comments above as there is no need to have userland code to detect these events, as those are sent natively

[rubin110]

So I've finally had some time to sit back down with this issue. At this point for me once I enable double press, single presses stop working. If I set the double press delay to something like 20 ms and hold down the button for that long, it'll activate the short press action. What clues should I be looking for in order to debug this? Thanks!

[Morriz]

Haha. It feels as if I don't exist and my remarks are not read at all. Anybody care to respond? Because I feel I am missing something and am willing to learn ;)

[rubin110]

@Morriz The Blueprint you linked to seems to only be for ZHA. I'm on Zigbee2MQTT.

[tarocco]

Noticing this issue as well. I've resorted to using separate automations to handle double presses as a workaround. Automations use the device's native double press.

In this blueprint, does this happen because the automation is counting the press and release as a double? Because the switch has its own logic for double/triple/quadruple presses, I think supporting those would be a better option.