I recently installed a smart code 916 dead bolt, and included it in my system. It’s added properly(or so it seems) as a secure node and I am unable to lock and unlock with home assistant, which is great. However I am seeing that when the lock is locked or unlocked manually the status does not update in the “lock” that was created in the front end. The status does however update in the attributes section of the states tool ie: locked manully, unlocked manually or by key, etc. What is the solution to make the lock on the front end update when these events happen? Also, how can I pull the attributes from my lock to send messages regarding events that are happening? I’m versed in notifications, but have so far been unable to pull the attributes out in anyway. I’ve searched around quite a bit regarding this issue, and it seems to be scattered and there is no solid solution. I’ve attached a quick screenshot of the states page showing some of the attributes for reference. Thanks in advance for anyone who is able to help!
Adding screen of the lock that was created and not updating. As you can see the status shows it was “locked manually” yet the option to unlock hasn’t changed on the UI. It still gives the option to lock.
I’ve been trying to figure this one out myself. It happened with my SmartCode 916 (zwave) & with upgraded SmartCode 916 (zwave plus). I see you have the Zwave Plus model. This model definitely updates state/alarms quickly, except for the lock component primary input toggle sometimes works, often is stuck in stale state.
I have been experiencing this as of late also. These locks used to update very quickly, now they are extremely slow. Might be worth a github issue?
For me, the sensor states reflect accurate values. It’s only the lock component that is not updated. In other words, I’m unsure it is a zwave (lower level) issue.
I think I saw a bug issue in GitHub a while back.
I have the Kwikset 888 which has the same behavior (HA 0.90.2).
I see that there have been a few patches / workarounds in the source to help track states better but our locks don’t seem to have been fixed. I unfortunately don’t have the time or energy to work on the zwave.py source code, but I was able to come up with a quick and dirty automation to synchronize the lock state into home-assistant so that when the lock is manually opened or closed its status will be updated in HA.
What I’m doing is a hack but it seems to work ok. The basic idea is to capture the alarm type associated with manual lock and unlock and then activate the service that will set the lock state to the same state as was just performed. Luckily I found a website with details of the
Alarm Type statuses. Check http://s7d5.scene7.com/is/content/BDHHI/ApplicationNote-UsingASCII-Z-Wave-Locks for details.
The state table is:
Alarm Type Alarm Level Notification Event 021 001 Lock Secured using Keyed cylinder or inside thumb-turn 022 001 Lock Un-Secured using Keyed cylinder or inside thumb-turn 027 001 Lock Auto Secured – Successful (Fully extended) 017 001 Lock Secured at Keypad – Bolt Jammed (Not fully extended) 018 000 or User-ID#* Lock Secured at Keypad – Successful (Fully extended) 026 001 Lock Auto Secured – Bolt Jammed (Not fully extended) 019 User-ID#* Lock Un-Secured by User (User-ID) at Keypad 023 001 Lock Secured by Controller – Bolt Jammed (Not fully extended) 024 001 Lock Secured by Controller – Successful (Fully extended) 025 001 Lock Un-Secured by Controller – Successful (Fully retracted) 112 User-ID#* New User Code (User-ID#) added to the lock 032 001 All User Codes deleted from lock 161 001 Failed User Code attempt at Keypad 162 User-ID#* Attempted access by user (User-ID#) outside of scheduled 167 001 Low battery level 168 001 Critical battery level 169 001 Battery level too low to operate lock
So I set up an automation that triggers on Alarm Type 19, 22, and
25 and then sends an unlock command to the already unlocked lock, synchronizing the physical state as well as the lock entity state. Similarly when Alarm Type 18, 21, 24 or 27 is set then the lock is locked. Since in both cases the lock is already in the targeted state, nothing physical happens on the lock, but the state in HA dashboard is correctly updated.
- id: sync_front_door_unlocked trigger: - entity_id: sensor.kwikset_front_door_alarm_type platform: state to: '19' - entity_id: sensor.kwikset_front_door_alarm_type platform: state to: '22' condition: - condition: state entity_id: lock.kwikset_front_door state: locked action: - data: entity_id: lock.kwikset_front_door service: lock.unlock initial_state: on - id: sync_front_door_locked trigger: - entity_id: sensor.kwikset_front_door_alarm_type platform: state to: '18' - entity_id: sensor.kwikset_front_door_alarm_type platform: state to: '21' - entity_id: sensor.kwikset_front_door_alarm_type platform: state to: '27' condition: - condition: state entity_id: lock.kwikset_front_door state: unlocked action: - data: entity_id: lock.kwikset_front_door service: lock.lock initial_state: on
Probably don’t need to trigger on states 24 or 25 since those seem to reflect the status correctly , but I don’t think it hurts anything since I am guarding against loops in the condition state check.
Hope this helps until someone has time to implement a real fix in the base component.
Update: as is perhaps not surprising, my workaround has a problem if you quickly unlock and re-lock the lock inside HA’s event loop time, then the lock can lock/unlock erroneously. Not sure I can completely avoid this problem in general but am thinking of introducing a very short delay and then double-checking that the Alarm Type and Lock status are still “out of sync” before executing the service.
Update2: Removing the stanzas for state # 24 and 25 did help with the looping, so I recommend that – and the lock status seems pretty solid for me at this point.
This is great! A work around is better than nothing, thank you for sharing!
Removing the stanzas for state # 24 and 25 did help with the looping, so I recommend that (I’ll edit my previous post accordingly.)
States 24 and 25 reflect unlocked/locked by RF, which I use all the time from other automations. It’s 23 that randomly fired on my kwikset 916 (non zwave plus). The zwave plus model reports alarm levels perfectly however.
Man, i’ve been fighting this lock for MONTHS! It i can’t find a pattern to this thing getting out of sync. I’ve reset it, reinstalled it, replaced the Z-wave card twice (it was originally a BLE lock). It would work fine for an hour and then get out of sync. Sometimes, opening it manually causes no problem, but other times throws it completely off. I have URC remotes with Z-Wave on the way. Unless a miracle happens and the lock starts working, I am ditching it.
Do you have the zwave or zwave-plus model? For me the original had the same issue, the zwave plus model does not…(for me.)
Only issue I have is that on restart of HA, it triggers an unlock ~ lock event (doesn’t physically happen, just reports this). Otherwise the workaround works great.
Apparently the fix didn’t get merged? The PR seemed to go stale.
I confess I dropped this – the workaround has made me lazy
There is a section in the component where there are a list of known “quirky” locks that have a workaround built-into the component. There are already a longish list of Kwikset models in that component but mine isn’t one of them. I haven’t tried to figure out the intricacies of determining the specific internal model # needed to register my lock in the list of “quirks” that are already there.