Attributes change depending on state

Configuration
1

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
2

It certainly works that way on media player entities. You don’t, for example, get a entity_picture unless something is being played. So yes, attributes can be dynamic.

3

Likewise for lights you don’t get a color if the light is off.

1 Like
4

Absolutely normal… And how else would Schlage have told you that in your first case, not only did the user unlock the lock, but they also did it manually, using a code - number 4. (Presence / Absence of the method attribute denotes manual v code, value=Keypad denotes method of code entry (some locks support alternative methods such as RFID, BT, etc.)

Also, the Keymaster custom integration handles these locks rather well once you get past the first code load (sometimes it gets stuck on adding the code). Since you’re former SmartThings - it’s like RBoy. But not paid code. :slight_smile: And they’ve solved this problem.

Even if you don’t use it, might be worth checking out how they do their automations for unlock by code.