Kwikset smartcode 916 status and updates

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.

automations.yml

- 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.

2 Likes

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.