Automation triggers with wrong value passed from z-wave

I’ve read this and is there no option for “=” or “At” (never sure if docs are up to date)?

Problem: My Yale locks user automation will 9 x out of 10 grab the correct user. I have just confirmed the Z-wave Lock is sending the correct user ID, which seems to be numeric, but the automation seemed to have been passed the wrong user number.

So 1 x out of 10 the automation gets the user wrong.

So I’m thinking the problem may be with my conditions. The current (possibly flaky) conditions are:

This one is used as a condition to the trigger and always seems to be correct.

condition: state
entity_id: sensor.front_door_lock_alarmtype
state: 19
attribute: value

and this one below is used in a Choose action, which is not 100% correct:

condition: state
entity_id: sensor.front_door_lock_user
state: 1
attribute: value

Z-Wave Log.

Trace:

What do you think?

  1. Should this work?
  2. Is there a way to evaluate the condition to an exact number in the GUI using Numeric State?
  3. Is there a deeper issue here?

No idea’s on what could be going on here?

Continues to happen. At this point this has to be a core Home Assistant issue? You can clearly see Alarm Level 3 (this is the user ID) is correctly seen in both z-wave-js and zwave2mqtt, yet the automation saw user 2 (the previous ID)

z-wave-js logs

zwave2mqqt logs

Automation trace

What is sensor.front_door_lock_user?

Why don’t you just use the the Notification event?

  1. That is the z-wave user entity for the lock

  1. I’ve never used Events (I’m new to Home Assistant). Is the trigger (data) path from zwave-js into HA different when using Events?

I don’t believe the integration creates any kind of lock “user entity”. Did you rename it from the “alarm_value” entity?

Your driver logs show clearly that the V1 alarm messages (alarm_type and alarm_value) are being mapped to a Notification. The alarm values are the old implementation, and for some locks the driver supports mapping those values to the modern Notifications. A driver Notification results in an event in HA, as shown in the linked documentation. You can trigger your automation on the notification, instead of whatever that sensor is. That might result in a more accurate automation.

You can listen for zwave_js_notification in the Events DevTools tool to see what the results are (will look the same as the driver logs, basically).

I probably did rename it for ease of use.

I still don’t understand how the passed data is some how incorrect on HA side. When is does fail (the current setup will work for weeks and then bamm, wrong user.) it’s always the previous alarmLevel (user) X => X that somehow makes its way into my automation. Timming issue?

Ok, so I’ll look into triggering from an event.

Thanks for your help.

Using Events worked. I’ve not had any further issues.

Thanks