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 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 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
  - 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: state
    entity_id: lock.kwikset_front_door
    state: locked
  - data:
      entity_id: lock.kwikset_front_door
    service: lock.unlock
  initial_state: on

- id: sync_front_door_locked
  - 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: state
    entity_id: lock.kwikset_front_door
    state: unlocked
  - 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.

@a3a - Thanks a ton for this workaround - I am going to take a stab at trying to figure out how to resolve directly in the component, but very grateful for a good interim solution.

Hey everyone, I did poking around and I think I figured out how to get my specific Kwikset Lock (916) working. You need to be comfortable with loading custom components in your HASS instance to do this. As @a3a mentioned, the ZWave Lock Component has some fixes for quirky locks. It seems all the Kwikset locks use the same WORKAROUND_DEVICE_STATE, and just needs the correct manufacturer_id and product_id to match your lock. My lock was not on the list to be matched, so didnt pick up the workaround behavior. The instructions below will help you find your IDs and modify the zwave file to catch your Kwikset lock.

  1. Open your HASS Logs
  2. Identify your Z-Wave IDs: Navigate to Configuration>Zwave>Select your lock node>Print Node
  3. Search the string in your logs for manufacturer_id and product_id and make note of it
  4. Modify your components/zwave/ file and add your lock IDs at around line 35.
  5. Restart HASS and test!

My locks so far as been VERY consistent. I will continue to test but if we get more people to test and provide their IDs we can do a pull request with HASS core.

I typed this up super quick, so hopefully this makes sense. Heres the lines I added to my Zwave file:

    (0x0090, 0x0001): WORKAROUND_DEVICE_STATE,

Good Luck!


Hello All,

I’ve had a Kwikset Obsidian for about a year now and it has always bothered me that after connecting it to Home assistant it would not show the “locked/unlocked” status in the Home Assistant UI.

Initially, I came here to the Home Assistant forums looking for a solution and found that the whole codes list approach which I didn’t like, so I came up with a templates approach using Automations. BUT BEFORE you use this, the solution that @blee posted is absolutely the best solution in my opinion, and I’ve since then removed my automations and used @blee’s approach, which I’ll show in detail how to do below.

Here is the automations solution using templates, it’s not perfect and sometimes if you lock/unlock the door to quickly it gets stuck in a loop, unlocking and locking the door until I reboot Home Assistant which is not acceptable to me for a long term solution. But, it’s cleaner then the codes so if anyone wants to use it, here it is.

And here is the config for unlocked.

Now using @blee’s solution here are my updated step-by-step instructions making this solution easy to follow and do yourself.

  1. Open your HASS Logs (You need a log viewer or file system access installed to do this) I would suggest the file system approach which is Samba since you’ll need it anyway for the later steps, you can install it from your Home Assistant Supervisor section.

  2. Identify your Z-Wave IDs: Navigate to Configuration>Zwave>Select your lock node>Print Node

  3. Connect via Samba and open your logs file.

  4. Search the string in your logs for manufacturer_id and product_id and write them down. The logs are long so expected a huge wall of text.

  5. Now to get a copy of the Zwave component you’ll need to download the source code for Home Assistant.

  6. Once you have it downloaded you need to extract the zwave component, which is a folder with files in it. Make a copy of this folder somewhere.

  7. Now you need to open and edit the file and add in the information you wrote down.

  8. Now you need to connect to the config directory using Samba access and create a folder called “custom_components”, you must spell it exactly correct. Then copy up the whole zwave folder which contains the modified file in it to this directory.


  10. Restart HASS, test it and you should be good to go.

Some drawbacks to consider, when the community updates the Zwave code in the future to be compatible with newer versions of Home Assistant, it might break since your custom component is essentially a forked version of the code. SOOOO you’ll need to from time-to-time repeat these steps to update your custom component unless someday your device makes it into the main source code. Also if you’re on a really old version of HA, you should look for an older version of the Zwave component to try and ensure compatibility. The best thing to do is just update HA to the latest version, then create the custom component.

Good luck and THANK YOU SO MUCH to @blee for finding this solution. SUPER AWESOME :+1: :+1: :+1: :pray: :pray: :pray:

How has it been working for you? Mine is great, and will be putting together a pull request to get this pulled into the project. We can probably include both of ours for the sake of simplicity!

Mine has been flawless, working nearly instantly updating the status. Awesome work on your find… my addition is actually in the photo in my post if you’re able to make a push and include these devices is standard builds.

Cheers and thanks again!

I submitted a PR here, with your lock as well :slight_smile:

And approved! That was quick - I suspect next build we’ll be able to remove that custom component!