Zwave_js_value_notification automation: time_fired > last_triggered?

Configuration Z-Wave
1

I’ve implemented some clever logic to distinguish local on/off, single, and double taps on non-central-scene devices. It all works reasonably well, but I’d like to reduce some of the timing constraints. Basically, if too much is happening in a small interval, the sequence becomes ambiguous and I have to ignore the tap.

Because the same automation handles many devices (parallel mode), there’s the possibility of reentry. I currently use the last_triggered attribute for my timestamp. This is always available, but I assume it’s shared? Some zwave_js triggers also include time_fired which I assume is specific to the trigger condition. That would be ideal. I could then switch to queued mode which would avoid the possibility of the same device retriggering before the previous run has completed.

What I find confusing is that time_fired can be much later than last_triggered. How is that possible? I need to go back and compare with the Z-Wave logs. My fear is that last_triggered is actually updated after the automation runs. That would introduce variable lag based on the script complexity. In that case, it would probably be more accurate to use utcnow() for my timestamp.

this:
  entity_id: automation.switch_tap
  state: 'on'
  attributes:
    id: switch_tap
    last_triggered: '2024-01-23T17:40:02.876854+00:00'
    mode: parallel
    current: 0
    max: 9
    icon: mdi:button-pointer
    friendly_name: 'Switch: Tap'
  last_changed: '2024-01-23T09:21:38.886367+00:00'
  last_updated: '2024-01-23T17:40:02.897994+00:00'
  context:
    id: 01HMVPGQ5WE5NZJ4GVWAVGVGEE
    parent_id: 01HMVPGQ5WG9CS5PY9F4X843HQ
    user_id: null
trigger:
  id: bath2_vanity_md033g
  idx: '1'
  alias: bath2_vent_s060u
  platform: device
  event:
    event_type: zwave_js_value_notification
    data:
      domain: zwave_js
      node_id: 60
      home_id: 3515281067
      endpoint: 0
      device_id: 011e25071915f203ffff339390368e65
      command_class: 32
      command_class_name: Basic
      label: Event value
      property: event
      property_name: event
      property_key: null
      property_key_name: null
      value: 0
      value_raw: 0
    origin: LOCAL
    time_fired: '2024-01-23T17:40:04.451161+00:00'
    context:
      id: 01HMVPGRQ3J0N3PQXZBXRQ4DBC
      parent_id: null
      user_id: null
  description: event 'zwave_js_value_notification'

So, I logged all 3 times:

last_triggered 2024-01-23 19:17:05.815033+00:00
time_fired     2024-01-23 19:17:08.860201+00:00
utcnow         2024-01-23 19:17:08.862945+00:00

last_triggered is obviously not what I thought.

More digging. The value of last_triggered depends on how you access it. If you use

this.attributes.last_triggered

you’ll get the previous time. If you use

states.automation.< entity_id >.attributes.last_triggered

you’ll get the current time. I do remember ditching the this. variant at some point. Probably because it was undefined on startup.

All is good. My script was working as expected. This is what happens when you try to “clean up” code. :slight_smile: