I’ve noticed something - and I’m not sure if it is a bug or feature. But it has caused me some confusion until I figured out what was going on. So, I’m posting here to hopefully get some more context around why this behaves the way it does. If this does turn out to be a bug - I will happily file an issue on GitHub.
Some background: I have a zwave lock, a Schlage Connect, that is paired with my SmartThings hub. The lock is then pulled into Home Assistant via the SmartThings integration. I’ve recently taken up the task of migrating my last remaining WebCore piston over to Home Assistant automations. A lot of the logic in this automation is based on which code is entered into the keypad on the lock - and this is where I came upon the issue.
The issue: Depending on how the lock is either locked or unlocked, Home Assistant displays different state attributes. This caused me to hunt around for quite some time to figure out how to build an automation triggered off the code entered on the keypad. Eventually, I got lucky and happened to look at the lock in the Developer Tools after someone had just used a code to unlock the door - and it was then that I was able to spot the code_id attribute.
Is it expected behavior that attributes would change based on different events happening to a device?
After doing some testing, these are some of the different attributes that are present based on various scenarios:
Unlocked via keypad:
lock_state: unlocked
code_id: 4
method: keypad
friendly_name: Front Door Lock
Unlocked manually (z-wave or physically):
lock_state: unlocked
friendly_name: Front Door Lock
Locked manually (z-wave or physically):
lock_state: locked
friendly_name: Front Door Lock
1 post - 1 participant