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.