[C-8 Pro/2.4.1.xxx] Kwikset z-wave deadbolt randomly unlocked by itself, potentially after switching to use Z-Wave JS

Hi, I have a Kwikset Home Connect 620 deadbolt, which is a Z-Wave Plus device. It’s been running fine for 2-3 months with 2.4.0.151 version. Last week I upgraded the hub’s platform to version 2.4.1.xxx and also switched to use Z-Wave JS (from the Z-Wave Details page). Since then, I’ve experienced the deadbolt randomly unlocked by itself, about 1-2 times per day.

I’ve tried to do Z-Wave Repair (by pressing the button in the Z-Wave Details page) and rebooted the hub several times, but they didn’t fix the problem. I also replaced the deadbolt batteries (still at 71% battery level) with brand new batteries (100% battery level after replacement), but it didn’t solve the problem as well.

So, 3 days ago, I switched back to use the Legacy Z-Wave. Since then, I haven’t seen the random unlocking problem anymore.

Has anybody switched to use Z-Wave JS and seen similar problem with their z-wave deadbolt? Did I miss anything in my migration to Z-Wave JS? (I only pressed the “Switch to ZWaveJS” button from the Z-Wave Details page).

Thanks.

Please post the event log for this device. It will be useful to see if these random events are in the log. And if they're there, the log will also indicate their origin/trigger.

I have 5 of the same lock (Kwikset Home Connect 620). I have been running ZWaveJS since it was in beta. Never seen this happen.

I think the last time it unlocked by itself was 4/6 morning, before I switched back to Legacy Z-Wave. Here are the event logs.

Here are the logs from the Logs tab for 4/6.

I just switched back to Z-Wave JS, to see whether I can capture more/better logs when the problem repeats. After that I also shutdown the hub, unplug the power cable for several minutes and plug the power cable back.

I notice that my Kwikset deadbolt doesn’t have a “Repair” button. The Repair button was there when I used the Legacy Z-Wave (see my original post). Is this normal?

Here is my current deadbolt’s log setting. Do I need to enable Debug logging?

I have setup notifications to tell me when the deadbolt is unlocked/locked/stay unlocked.

Anything else that I need to do so I can capture more data for troubleshooting the root cause of the random unlocking?

Thanks.

That's normal for battery powered devices...same w/my Schlage lock, my iBlinds, and a few battery-powered Z-Wave sensors that I have on ZWJS...they all just have the Refresh button (same w/LR devices, both mains powered and battery, as LR doesn't have any mesh connection to repair):


Turn off Alexa hunches (if it is turned on). You need to do this in the Alexa app, and not Hubitat.

What would be really helpful is capturing one of the "random" unlock events - in the Lock's event log.

I just removed the deadbolt from the Alexa skills. Thx

1 Like

I'm not an Alexa user, but I think you should also turn off Hunches directly on Alexa as well, unless you like having Hunches on.

I think you can just say something like "Alexa, turn off hunches."

2 Likes

I just told Alexa to disable hunches. They are now Off.

2 Likes

So now hopefully you can get the event that @aaiyar mentioned above so your issues can be figured out.

Hi, The issue happened again yesterday around 5:15pm, with a twist. I was able to reproduce it. I also did some experiments and I believe I have narrowed down where the problem is. See below for details.

What Happened:
Yesterday around 5:15pm, I took my dog out for a walk, through the front door. I locked the front door deadbolt by pressing the Kwikset 1-touch locking button (see picture below). I double checked that the door was really locked by trying to open it. About 2 minutes later, I got an alert/notification on my phone that “the front door deadbolt has been left unlocked”. (I have a notification setup that would notify me every 2 minutes if the deadbolt stayed “unlocked”). After letting my dog finished his walk, I went back home to check the front door. The front door deadbolt was still physically locked, but the alerts on my phone kept triggering and the deadbolt status on hubitat dashboard showed “unlocked” despite the door was physically “locked”

Here is the deadbolt’s events log – it doesn’t show much, if anything.

Here is the deadbolt's logs (from the Logs tab).

Here are the Notifications log on my phone and the deadbolt status on the Hubitat dashboard.

Looking back now, I realized that all the alerts that I got in the past week happened when I was away from the house. When I got the alerts that “the deadbolt has been left unlocked”, I would just lock it remotely from my hubitat dashboard on my phone. I never checked the door as sometimes I was already miles away from my house. I only discovered it yesterday that the door was actually still locked, but hubitat was mis-reporting it as unlocked.

I did some experiments on different ways to lock the deadbolt and summarized them below.

Here are my observations/notes from the above experiments.

  • With the Legacy Z-Wave, locking/unlocking the deadbolt would change the status in hubitat almost instantaneously. With Z-Wave JS, most of the time, it would take a few seconds for the status to change in hubitat. So in this case, Legacy Z-Wave seems to be faster than Z-Wave JS.
  • The behaviors of Legacy Z-Wave and Z-Wave JS, for Kwikset deadbolt locking, are the same, except for one scenario. When locking the deadbolt by pressing the 1-touch locking button on the lock, the behavior of Z-Wave JS was different from the behavior of Legacy Z-Wave. Hubitat status for Z-Wave JS was incorrect and mismatched with the reality.
  • I only focused on the locking behaviors of my Kwikset deadbolt and didn’t test any other behaviors/scenarios. So there may be other behavior differences between Legacy Z-Wave and Z-Wave JS that we don’t know yet, which I hope the Hubitat developers could do more comprehensive testing.

Here are the event logs for Legacy Z-Wave vs Z-Wave JS, for locking the deadbolt using 1-touch locking button. (I disabled my notification alert so it doesn’t clutter the logs). Note that Hubitat with Z-Wave JS didn’t recognize locking by pressing the Kwikset 1-touch locking button.

So in conclusion, the problem is not with the lock physically unlocked the deadbolt, but with Hubitat mis-reported the status of the lock for certain scenario.

@aaiyar Since you have the same Kwikset Home Connect 620 deadbolt, is it possible for you to test your lock’s 1-touch locking button for Legacy Z-Wave vs Z-Wave JS, to see if you observe the same?

Thanks.

3 Likes

I can reproduce this behavior.

@bcopeland, here’s a TLDR summary:

  1. Under ZWaveJS, lock events initiated by pressing the physical lock button on Kwikset Home Connect 620 locks are not recognized by the hub.
  2. Lock events initiated using the key, or thumb turn, are recognized just fine. Lock events initiated digitally are also recognized just fine.

This issue doesn’t happen under z/ip gateway.

The driver is the built-in Generic Z-Wave Lock driver

2 Likes

Super sleuthing, really well done.

1 Like

Here is what is shown in the zwave messages when a Kwikset 620 is locked with the 1 touch lock button @bcopeland . No event is created on the device.

2025-04-10 07:49:00.986 PMDRIVER all queues idle
2025-04-10 07:49:00.984 PMDRIVER « [RES] [SendDataBridge] - was sent: true
2025-04-10 07:49:00.982 PMSERIAL « 0x010401a90152 (6 bytes)
2025-04-10 07:49:00.978 PMSERIAL « [ACK] (0x06)
2025-04-10 07:49:00.975 PMDRIVER » [Node 197] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x24 - │ callback id: 0 - └─[Security2CCMessageEncapsulation] - │ sequence number: 224 - │ security class: S2_AccessControl - └─[SupervisionCCReport] - session id: 53 - more updates follow: false - status: Success - duration: 0s
2025-04-10 07:49:00.972 PMSERIAL » 0x011f00a9000100c5119f03e0002f32d64730b3428f2f914b1e09240000000000e (33 bytes) - 4
2025-04-10 07:49:00.969 PMDRIVER one or more queues busy
2025-04-10 07:49:00.964 PMCNTRLR [Node 197] [Notification] - type: Access Control - event: Keypad lock operation
2025-04-10 07:49:00.960 PMDRIVER « [Node 197] [REQ] [BridgeApplicationCommand] - │ RSSI: -79 dBm - └─[Security2CCMessageEncapsulation] - │ sequence number: 157 - │ security class: S2_AccessControl - └─[SupervisionCCGet] - │ session id: 53 - │ request updates: false - └─[NotificationCCReport] - V1 alarm type: 18 - V1 alarm level: 0 - notification type: Access Control - notification status: 255 - notification event: Keypad lock operation
2025-04-10 07:49:00.957 PMCNTRLR [Node 197] [~] [Notification] alarmLevel: 1 => 0 [Endpoint 0]
2025-04-10 07:49:00.955 PMCNTRLR [Node 197] [~] [Notification] alarmType: 19 => 18 [Endpoint 0]
2025-04-10 07:49:00.953 PMSERIAL » [ACK] (0x06)
2025-04-10 07:49:00.949 PMSERIAL « 0x012700a800000100c5199f039d00db88a028402476bd244a3d8ad06bc32218723 (41 bytes) - 9a6b000b1007f7faf
4 Likes

Thanks @JasonJoel - that should greatly help @bcopeland.

1 Like

Something similar is happening with the Schlage locks. In my case, it is the physical knob event for lock that is missing.

1 Like

I used the physical knob to unlock the door, took the dogs out, then locked the door, again with the knob. A few minutes later, I hit Refresh in the device settings page, and It found the door locked event, but totally misses the physical part of the lock event.

This is with a Schlage lock, (and Schlage driver) so I am making a (maybe incorrect?) assumption this is broken at the basic Z-wave JS level rather than driver level. @bcopeland

1 Like

On the Kwikset manual lock/unlock events done with the inside turn show up as expected. It is the keypad initiated lock events that don't.

Could be the same thing with the Shlage, but it sounds different the way you describe it.

1 Like

I don't believe it has to do with ZWaveJS

I too have been recently experiencing odd behavior with my z-wave deadbolt lock after updating to 2.4.1.xxx and have not switched to ZWaveJS. I believe it's happened twice where the deadbolt just randomly unlocks. I was busy during both occurrences so I never looked into it further and can't recall the date/time to review the logs. I want to say the first occurrence was around April-3 and the second a few days ago, say April-8.

Most recently, today April 12, 2025 with the latest update (2.4.1.157), The lock will report being unlocked when it's confirmed physically locked. This reporting happens on the web admin home screen, and in the dashboard for both the web admin and the phone app. It's unclear at this time if it happens randomly (i.e. without manual or command action) or a missed report after an action occurred.

For what it's worth, I'm attaching the logs of a test run (door unlock via keypad and subsequent manual lock). I did observe something a little odd while monitoring the dashboard on the phone app. After manually locking the door, the app in-kind showed the door locked, briefly switched to unlocked and quickly back to locked again. The logs below don't seem to reflect this strange occurrence I saw in the app. A second test did not duplicate this.

Plus, perhaps a separate issue, but I also noticed the logs reported "locked via command" twice after it was already manually locked and the related rule command's required expression was false. Not sure if that's normal but doesn't seem right.

Now that I know this is a thing, I will try to monitor the lock to see if it continues to randomly unlock, and get confirmation if discrepancy between physical/reporting occurs randomly or a result of an action.

C-8 Pro w/2.4.1.157
Kwikset SmartCode 916 500 Series w/Built-in "Generic Z-Wave Lock" driver

With Z-Wave JS, have you tried enabling command retry logic?