ZWave WallMote distinguish between KeyPressed and KeyHeldDown

Hi,

I have a few ZWave Aeotec WallMote devices that are ZWave remotes with 4 touch sensitive pads, when directly grouped with ZWave devices these have tap, swipe and long hold options which work well.
When using with ZWaveJS i have 4 trigger options, [blank], KeyPressed, KeyHeldDown, KeyReleased. Ideally i would like to have different functions when the key is pressed vs key held down. e.g. Key Pressed toggles the bedroom light and Key Held Down triggers a night time routine. The problem is KeyHeldDown also triggers the KeyPressed event.

I have a similar thing working for a ceiling fan but i cheated and made KeyHeldDown turn the fan on and off and then KeyPressed toggles the speed (only if the fan is on).

Any ideas how i distinguish between a KeyPressed and KeyHeldDown to make sure that KeyPressed isn’t triggered all the time?

This is a cut down version of my automation thus far for button #1:

alias: '[Bedroom remote 2] Light control'
description: ''
trigger:
  - platform: device
    device_id: ###
    domain: zwave_js
    type: event.value_notification.central_scene
    property: scene
    property_key: '001'
    endpoint: 0
    command_class: 91
    subtype: Endpoint 0 Scene 001
    id: switch_1_press
  - platform: device
    device_id: ####
    domain: zwave_js
    type: event.value_notification.central_scene
    property: scene
    property_key: '001'
    endpoint: 0
    command_class: 91
    subtype: Endpoint 0 Scene 001
    value: 2
    id: switch_1_long
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id: switch_1_press
        sequence:
          - service: light.toggle
            data: {}
            target:
              entity_id: light.bedroom_main_light
      - conditions:
          - condition: trigger
            id: switch_1_long
        sequence:
          - service: script.bedroom_lights_off
            data: {}
    default: []
mode: single

Looking at a trace shows that the button_1_long doesn’t get triggered because the automation is running for button_1_press already. If i change to queue or parallel the automation gets run once for each case.

Has anyone come across this or worked out a workaround where the Held option can be triggered without the Press?

Thanks,
Richard

Hi Richard,

I have the same issue.

When holding the key, in my setup I can see in the Trigger Debug Trace that the press part of the Trigger is not triggered by KeyPress but by KeyReleased (value: 1).

this:
  entity_id: automation.nanomote_quad_scene_4_press
  state: 'on'
  attributes:
    last_triggered: '2022-02-24T07:53:23.462956+00:00'
    mode: single
    current: 0
    id: '1645434922089'
    friendly_name: Nanomote Quad - Scene 4 Pressed
  last_changed: '2022-02-24T06:51:24.264458+00:00'
  last_updated: '2022-02-24T07:53:23.471713+00:00'
  context:
    id: 3537c7641e0057582e592aeceac345e6
    parent_id: 99cff1dc0e194ce9c12a01074e7bf509
    user_id: null
trigger:
  id: '0'
  idx: '0'
  platform: device
  event:
    event_type: zwave_js_value_notification
    data:
      domain: zwave_js
      node_id: 108
      home_id: 4183812632
      endpoint: 0
      device_id: 4f8637681dd6854437bdb7f0da02521f
      command_class: 91
      command_class_name: Central Scene
      label: Scene 004
      property: scene
      property_name: scene
      property_key: '004'
      property_key_name: '004'
      value: KeyReleased
      value_raw: 1
    origin: LOCAL
    time_fired: '2022-02-24T07:53:25.337576+00:00'
    context:
      id: 7af6929afd0d59bb1fe92b681366fb5b
      parent_id: null
      user_id: null
  description: event 'zwave_js_value_notification'

Looking in the UI, the value:0 part is not there, but looking at the automations.yaml, it seems OK:

- id: '1645434922089'
  alias: Nanomote Quad - Scene 4 Pressed
  description: ''
  trigger:
  - platform: device
    device_id: 4f8637681dd6854437bdb7f0da02521f
    domain: zwave_js
    type: event.value_notification.central_scene
    property: scene
    property_key: '004'
    endpoint: 0
    command_class: 91
    subtype: Endpoint 0 Scene 004
    value: 0
  condition: []
  action:
  - service: input_select.select_option
    data:
      option: 100 °C
    target:
      entity_id: input_select.waterkoker
  mode: single

I this the same with your setup?

Don’t know how to fix this though. Perhaps we can have a condition based on the event data where we can check the value or raw_value of trigger.event.data?

Regards,
Floris Jan

Hi Floris Jan,

I actually worked around this by using the KeyReleased too. It seems that short press (KeyPressed) is not triggered when held now. I don’t know if something changed in a version of ZWaveJS2MQTT or HA but my automation for short and long press seems to work using KeyPressed and KeyReleased respectively.

KeyHeldDown didn’t seem to work for me how ever i tried, i suspect there could have been an issue with the automation already running though causing issues.

Thanks,
Richard

Hi Richard,

Good to hear you worked it out. I did some testing, and I think the KeyPressed is working though, but it is the UI that is messing things up.

When first setting a Trigger to the value KeyPressed, the trigger is saved correctly to trigger on value: 0. When you close and re-open the automation, the drop-down value field is empty in the UI. If you click save then, the value: 0 condition in the automation.yaml disappears. Now the trigger that would have only fired on KeyPressed, fires on all values, including KeyHeldDown and KeyReleased, so that would explain the behaviour you and I saw.

I was looking how to report this issue, and found two issues already:

I guess we’ll have to wait until those are resolved. Until then I have be careful to (re)select the correct value everytime you use the Central Scene with KeyPressed.

Cheers,
Floris Jan

That explains a lot. I setup the automation again when changing to KeyReleased and set the values to KeyPressed.
I’ll make sure to set the values if/when I change the automation again.

I did notice the automation showed blank values but didn’t think much of it, when this was broken I must have saved the blank values.

Will keep an eye on the defects.

Thanks,
Richard