Kwikset HC 620 status problem - safety/security issue

Configuration Z-Wave
1

While I was away on vacation abroad recently, I operated on several of my locks remotely in HA - unlocking and locking several of them. Everything looked fine remotely in Home Assistant, with all door locks reporting being locked.

However, on May 4 at 9am PT, my pet sitter came in and found the door to the master bedroom balcony opened with the deadbolt sticking out. One of my 3 indoor cats had escaped. He completely freaked out. Fortunately, I knew how to get her back inside, and she came back indeed 8 hours later.

I don’t have an entry sensor on the door that lock is on, so I don’t know when the door actually opened. I only have information about the HC620 door lock in HA.

The log for that particular lock in Home assistant ZUI, Node 17, does not show any unlock or relock event for the relevant time period of the preceding day.

The logs for April 30 through May 4 are shared here :

https://drive.google.com/drive/folders/1bAexiiYJ8odpTlqyWe90jswHTZfMgt4n?usp=sharing

There is no instance of any action on Node 17 on May 1 or May 3. I don’t have a good handle on when the unlock and relock happened. My pet sitter came by every 12 hours, and says that he would likely have seen the door to the balcony with the deadbolt sticking out, as it is located in the master bedroom where the cats spend most of their time. This means the issue would have happened between May 3 at 9pm PT and May 4 at 9am PT. Problem is, there is absolutely nothing in the log for that node on May 3. In the May 4 log, the first mention of Node 017 is at 2025-05-04T16:06:39.324Z , which is 9:06am PT, the time the pet sitter came in. In other words, the log for these 2 days sheds no light whatsoever as to what happened to that node and door lock.

My theory is that what triggered the lock to unlock and relock is an attempt to rebuild the entire Z-Wave network’s routes, which was done on May 2 at `2025-05-02T08:50:20.568Z, or May 2 at 1:50am PT . Obviously, initiating a rebuild is not the greatest idea one is not onsite, but I still never expected that it might lead to a door unlock. I have not tried to rebuild the network again now that I am onsite. I did try to rebuild the route for just the one lock that had the problem, but that did not cause it to unlock or relock.

I am not sure if it is a bug in the firmware or a bug in HA, but at this point, I can no longer trust this smart lock, or any of the 12 others HC620 that I recently installed. The lock that experienced the issue is the newest model with the LR firmware revision 7.23.4 .

Now that I’m back home, I’m trying to determine the root cause. Everything seems to be behaving correctly for the lock in question - Node 17. It answers to lock and unlock commands, and reports its status correctly. In other words, I can’t reproduce the problem that led to this yet. I have yet to try to rebuild the whole network. I will do so, but only while physically present and monitoring my cats, so they don’t get out again if the door unlocks and opens.

I have got another HC620 lock which behaves incorrectly, also, but in a different way. It answers to lock and unlock commands properly. However, its lock/unlock status never updates in ZUI, no matter what I do. This is node 194.

I see that both locks are experiencing some timeouts - ZW0201 shows up in the log files for nodes 17 and 194. I am not sure if that accounts for the status not updating on 194. Since it answers correctly to lock/unlock, it is really strange that status won’t update.

It is very possible that there is a signal issue, as it is a large home with thick building materials. Node 17 is 2 floors up and far away from the controller. Node 194 is on the same floor as the controller, but in the back of the garage.
However, since a lock is a security device, I would expect any problem with the signal to be relayed to the user, so that appropriate action can be taken, including physically checking the lock/door state.

Some sort of HA notification would seem appropriate in this case, if ZUI has evidence that the lock may be malfunctioning due to signal issues - for example, by never updating its lock status after a lock/unlock command, or experiencing many frequent timeouts. This is not happening right now. I think it should be automatic for this class of device due to the severe consequences when the status information is lost or commands don’t get through, as I experienced. Many alarm systems will warn in some way if there are communication with security devices, for example, and I’m hoping for similar behavior here.

Is there a way to set up such a notification manually for communication problems ? If so, I would like to do it for all my locks.

If it turns out to be a firmware bug with the lock, though, as I still suspect it is, the fix would have to come from Kwikset. And they are not even setup to distribute them at this point. If the firmware is at issue, pending a fix, the only safe thing for me to do would be to remove all my HC620 from my Z-Wave network, and operate them only as dumb locks, using the physical keypad or physical key (smartkey).

If it’s strictly communication issues, I would hope that some improvements in HA might help detect them in time to prevent a repeat of the event. I am considering relocating my Z-Wave stick to a Raspberry Pi in another location to better reach distant devices such as these locks. The physical PC that my HAOS VM runs on is in an edge location, and that is where the Z-Wave stick currently is. I will not physically move this machine for many reasons. But I could add a Raspberry Pi running ZUI, and the “Home assistant remote” add-on, if that will improve Z-Wave signal. But it’s a much less manageable solution to use two HA instances - you now have multiple backups to coordinate, and cannot restore your system in a single step anymore. Also, the Pi in the new location would have to run on Wifi, which adds its own set of wireless signal problems, that may compound with Z-Wave’s. Nevertheless, I may give it a shot.

2

I have several of the HC620’s in play but none of them have LR firmware. Most recent one was acquired just 5 weeks ago and it’s on 7.21.0 so I don’t know where you got one with that firmware so I can’t talk about if it’s a problem with the firmware or something else.

I would, however, strongly recommend putting an entry sensor on that door so you have better visibility into the status of it being open and not having it lock if it’s open. I only let my Kwikset 912s autolock since those are lever locks and not deadbolts so the door can properly close even if the lock has relocked.

On the topic of the ZWave controller, you could look into getting a dedicated network based controller. Most of them are ethernet, but you might find one that also supports being connected to a wireless network for the controller access. ZUI supports that and it would let you get something more central to the rest of the property.

3

The one with LR firmware was a warranty replacement direct from Kwikset.
I have another warranty replacement still boxed that is likely LR firmware too.
The issues with the 2 locks that failed were a dead speaker, DOA when new,
and the deadbolt auto mechanism that went bad a few weeks after installation, that couldn’t be fixed by reset.

Thanks. I added entry sensors to all my doors with my Simplisafe alarm now. Unfortunately, I could not get the Simplisafe integration to work, so those sensors are currently unavailable in Home assistant. I need to buy 13 more separate entry sensors as a result. I wish the Kwikset lock could be used as an entry sensor itself. A magnet could be integrated with the deadbolt. Of course, if the locks fails to communicate, it’s all for nothing.

Anyway, I’m not sure which entry sensors to buy that would be reliable and affordable enough. I have a few Yolink entry sensors, which I use for appliance doors such as fridge and freezer. I wouldn’t use them for critical applications like doors, because their hub is still cloud-only. I can’t have the door stay open if the ISP is down. I have been waiting for years for Yolink to add local functionality to their hub, to no avail. After years of promises, I no longer believe they will ever release that feature. I will probably sell the couple remaining door sensors I still have boxed. I have a few boxed motion sensors that I may still install.

Given the Z-wave signal problems, perhaps Z-Wave door sensors are not the top choice. But what options does that leave ? Bluetooth door sensors ? I would need a bunch of Wifi/Bluetooth proxies to make it work given the property size. Maybe not one per door, but probably for every other door. My current HAOS VM runs on a Windows host, and the desktop motherboard lacks bluetooth. I have not gotten a separate Bluetooth stick to play ball with VMWare, so there is no bluetooth support at all currently, even for the front door which is well within range of the host.

Thanks. I did not know there were dedicated Z-wave based network controllers. There is unfortunately no Ethernet wiring available in the locations that would be best suited to improve the Z-Wave signal. A quick search found this : Z-NET Z-Wave Network Controller Interface – HomeSeer . It says it supports Home Assistant with Z-Wave JS. Not sure if that means that Z-Wave JS UI is supported as well. How does one set up the remote stick in that case ? Also, can I have multiple sticks if one turns out to be insufficient for full property coverage ? I am thinking to keep the local stick, and add one remote stick. Obviously, they would be two separate Z-Wave networks, but that is OK, since I’m not using any direct associations.

The Z-NET G8 is a lot more costly than a roll-my-own solution with the Remote add-on, and a Raspberry PI 3B+, since I already have a spare board, spare microSD card, spare power supply, and spare Z-Wave stick, to set it all up. On the other hand, it also adds Zigbee, and might be more reliable as well, as it’s already been built, and may be supported directly in ZUI. I have run into reliably problems with The PI 3B+ Wifi interface and my Unifi access points. I currently use two Wifi connected Pi 3B+ connected via RS485 to my Carrier zoned HVAC as smart thermostat interfaces. Unfortunately, they occasionally lose the Wifi signal when the APs reboot, or configuration changes are made to the AP, and require power-cycling to bring them back online. It’s so pervasive that I have had to install smartplugs and an automation that pings them to cycle them if they go offline. Nevertheless, given that my marginal hardware cost is zero, I will probably still persist and try to build my own anyway. You have me intrigued about how to integrate the remote stick in ZUI. I would certainly like to do that, rather than install a complete HAOS instance on the Pi 3B+, and use the HAOS remote proxy add-on.

4

I tried to rebuild the whole network, but it did not trigger anything physical with any of the locks. No lock or unlock operation. However, two of the locks are now dead nodes, with seemingly no way to ping them or rebuild the routes manually. One is only about 25ft from the controller and really shouldn’t be misbehaving. It worked fine before the network rebuild, also.

5

When you buy a network based Z-Wave controller you are buying a computer that has software installed on it that allows you to access your Z-Wave controller over the network. The software is called ser2net and it’s free. If you already have the hardware lying around it’s cheaper to diy.

If you are looking for cheap Z-Wave door sensors I recommend you buy the alloy branded ones off eBay. They are 700 series, have temp and humidity sensors, have a USB port and can act as a repeater when powered via the USB, run off cr123 batteries, and are cheap. If you wanted 13 of them it would cost you $97 after tax. The only thing I don’t like about them is that they are huge compared to other door sensors I have. I bought one and it’s been reliable.

1 Like
6

Thank you ! That is really cheap indeed. Do you know if there is any model that supports SmartStart that’s not cost prohibitive ? Something in the $10-$12 range with SmartStart would be better. If not, I will order the Alloy.

The Zooz ZSE41 has SmartStart, but it’s not a viable option for me at $25 a piece.

7

And thanks for the tip about ser2net.

8

The alloy does supports smart start as it’s a 700 series device.

1 Like
9

Great ! Sorry to ask again - do you have any idea of the max distance between the sensor and the magnet ? My Yolink door sensors don’t work because of the crown molding. The Simplisafe SS3 entry sensors I installed yesterday allow up to 2 inches, and do work with all my doors. But no HA integration :frowning:

10

The manual says 2 cm. If you want better range you can always buy larger magnets.

11

Thanks ! Is the manual available online ? I couldn’t find it. Actually, how did you become aware of the existence of Alloy and this sensor ? I can’t find much in a search engine, only a link to smartrent.com . And the sensors aren’t listed for sale, nor were there manuals.

I didn’t realize buying larger magnets was an option. That sounds great ! Are you aware of a source for something that is known to work ? Seems like these N52 have relevant dimensions, but no one seems to have tried them with sensors according to reviews. They are black or silver and not white, also.

12

Here is the manual https://fccid.io/Z52NAS-DS07Z1U/Users-Manual/15-NAS-DS07Z1U-UserMan-4745664. Some Z-Wave products are rebranded. So someone else makes the device and a company puts their logo on it and sales it. This is why it’s sometimes difficult to find information about a product. The easiest way to find documentation is visit the FCC listing which is what I linked to you.

I think I found out about alloy by doing an eBay search. I have a couple of resources I use for looking up Z-Wave products. I search eBay, I search Google news, I check the Z-Wave product pages, and the FCC listing.

As far as magnets go I don’t have any recommendations.

13

I’m not using Z-Wave entry sensors anywhere. I’ve got Zigbee in use there. My favorite sensor is a little on the pricey side: Aeotec SmartThings Multipurpose Sensor the cheaper entry sensors that I have in use are the Aqara Mini Contact Sensor. Again you would run into the centralized controller issue, but there’s also network controllers for that as well.

I don’t know what the wiring in your property looks like, but if you’ve got coax running all over the place (which is very common in the US where I am) then you could pick up some MoCA adapters to get get an ethernet port somewhere close to what you want. I use these in a few of my properties to build out ethernet to locations where I need since I’ve got coax into every room. Just be aware, that you should probably also get a MoCA filter to put on the cable company feed into the property so you don’t leek your MoCA network out to the rest of your neighborhood!

14

Thank you again ! That is helpful. I still have many reliability problems with Z-Wave that I would like to solve before I add any more devices, including these entry sensors. The seller doesn’t accept returns also, so I probably wouldn’t be ordering 13 at the same time in case they are unsatisfactory in my application, in terms of both Z-Wave and magnet range.

I will be setting the roll-my-own remote hub on Pi3 to see if things improve with Z-Wave range. Some of the issues may not be directly related to range, though. For example, on Wednesday I created a macro to turn the 3 Z-wave light switches on or off in my master bedroom using an IR remote control, with an ESPHome IR/Wifi receiver receiver processing the input. It works intermittently. The first time, there is some delay of 1 to 5 seconds for the switches to turn on/off. When flipping them on/off a few times from the IR remote, everything works fine, with <1s delay. But after I do this too many times in sequence, the Z-wave bus seems to jam, and no command is processed again for the next minute or so.

I have the exact same jamming issue in my Home theater with the same 3 ZEN76 switches, same IR remote, same IR receiver. The home theater room is much closer to the controller. But things still jam the same when testing and sending several commands in quick sequence. Not sure if it’s a problem with the ZST39 controller, Z-Wave JS, or the ZEN76, or a general unfixable problem with the way Z-Wave works and the slow bus limitation.

15

Thanks. The first one is not viable due to cost. The second one is more reasonable, but still too high. The 0.86in gap is also not enough, so it would need magnets too, assuming the coil is strong enough to detect it. I would also need a minimum of 4 network Zigbee controllers to adequately cover my property. For Wifi, I currently use 9 APs.

Unfortunately, there is nothing usable for network wiring. There is coax in a couple rooms, but I have no idea whether they are connected to each other, or to anything on the outside. I haven’t bothered testing them. There is a large number of rooms, and even if these are all usable, they wouldn’t be enough. The only wiring that’s consistently everywhere is power outlets. I used to have X10, which uses PLC, and it was too unreliable, so I got rid of it and replaced it with Zigbee. I tried powerline Ethernet before, for a printer that performed very poorly with Wifi - connecting to distant APs, taking 30 minutes for an A3+ color photo print. Sometimes the PLC would lose the connection, too. I have 70 micro-inverters that use PLC. PLC is just not an option.
Because of the lack of wiring, 7 out of my 9 Wifi access points are meshed. 2 of them double-meshed. It would be extremely costly to add wiring, and very unsightly, as contractors have told me it wouldn’t be possible to run them in the walls without basically tearing down the house. Conduits outside would be the main solution to reach all the rooms that have exterior walls. Several rooms don’t meet that requirement, in particular the central location where I want to put the Z-Wave controller, so raceways on ceiling or walls running from the outside to these inside rooms. We are talking thousands of dollars to add wiring, possibly getting into 5 figures, and when it’s all said and done, it will look very ugly with all the visible outside conduits and indoor raceways. I did not do it for the last 15 years for cosmetic reasons, even though I could afford to. Now I’m no longer working, and won’t do it for cost reasons also.

16

Did you ever measure th e zwave traffic level and try to reduce it?

17

No. Is there any guidance I can read about on how to do that ?

18

Bump. My 72-node Z-Wave network has gone to hell. Clearly I had not been paying enough attention as I was away from home for a while out of the country.

All the nodes did work at some point in the past to some degree. But not all 100% simultaneously.

I did another network rebuild earlier this week, and reviewed the state of the nodes today in ZUI. The network rebuild is still in progress after several days, at 68 out of 72 nodes. There are 9 nodes showing with problems on the ZUI control panel screen.

a. 1 node is marked as dead, a battery operated an HC620 lock for my front door, located just 6 ft from the Z-wave controller, though separated by one wall. It was last seen by ZUI May 19. The batteries were last reported at 62%, and the physical keypad still functions. It is also marked as having failed node rebuild in ZUI. I cannot ping this node. I tried an individual node rebuild, but so far it hasn’t worked.

Edit: Finally, I opened the cover and pulled the battery tab, then re-inserted it. The lock then showed up alive in ZUI. I can now lock and unlock it from ZUI.
I then attempted another rebuild route to try to clear the error state in ZUI. It worked.

Needless to say, this workaround is impossible to do remotely. The only thing that fixed this lock was physical intervention. Nothing that I found in ZUI could fix it . I believe this is not a range issue due to proximity to the controller, and it is a bug with the lock. The firmware on this particular unit is 7.21.0 . At least I did not have to exclude the lock to fix it. Doing so would have wiped all the lock settings, including up to 250 user access codes, though I’m only using one code at this time. I’m not sure if there is any way to backup the lock device settings and restore them. If I used 250 codes times my 13 locks, that would be a lot of manual backup/restore upon include/exclude.

b. 4 nodes are marked as asleep, and having failed node rebuild. They are all Zooz ZEN34. But all 4 were last seen by ZUI earlier today. I pressed one of them, and it still functioned - HA ran the corresponding light automation.

c. 1 node is marked green, but also having failed rebuild routes. It is a Zooz ZEN76 wired switch. This controls an outdoor light circuit. I tried multiple times to flip the switch state through ZUI. Both times, ZUI said the value updated. But the terrace light never turned on. I walked to the switch and pressed it, and the light turned on. When I walked back to my desktop, the switch state had updated from red to green in ZUI.

d. three nodes have a spinning arrow, and are still trying to rebuild several days after the network rebuild process was started.

Two are battery-operated Zooz ZSE11 with the batteries removed. They were last seen by ZUI on March 16 . I had forgotten to exclude them from the network.

The third device with spinning arrow is a ZEN34 that physically died, so I cannot reinsert the battery to exclude it. It must be forcibly removed through ZUI.

“Removed all failed nodes” was run several times since March 16, and failed to remove all 3 missing nodes from the network. I was just able to manually remove them one at a time.

These are just the failure indications I could observe from the ZUI control panel.

After I removed the 3 missing battery operated nodes from mentioned in bullet point d above, I was able to manually rebuild the route for the ZEN76 from bullet point c successfully. I was able to flip the switch from ZUI on my desktop, and verified that the light turned on. I then used HA on my phone to flip it off, and the light turned off. I then waited a few seconds and flipped it again from HA to turn it back on. Nothing happened this time. Several minute later, the light is still off. It is correctly reported as being off, though. A subsequent attempt to flip it on worked. About 10 on/off at about 1 second intervals worked as expected. A few more rapid flips through HA caused the switch to jam. Error ZW1405 was reported in the HA GUI. After that, the switch became unusable, not responding to any command through HA anymore, even after a few minutes. I waited a few more minutes, and was able to control it again. But it was very slow and erratic. The first flip on turned on the relay and updated status immediately. The next flip off turned off the relay, but did not update status for about another 20 seconds later.

This ZEN76 is a wired switch about 45ft away from the controller, with 2 walls and cabinets in between. There is one ZAC38 plug-in range extender near that path that might in in theory help, though not in direct line of sight. There are 2 also other ZEN76 near this failing one. All 3 ZEN76 in that corner are experiencing similarly erratic behavior in terms of response to remote control and status update.

There are unfortunately other problems with many other devices not responding, jamming, not reporting, misreporting, or reporting late, that can’t be diagnosed solely from the ZUI device screen. 72 (now 69, after removing 3 battery devices) is a long list of nodes to test for misbehavior. Z-Wave is supposed to be self-healing, but clearly is not in my house. And the network route rebuild has only made things worse.

I would be willing to give a go at manually trying to find out misbehaving devices and excluding them from the network if I can identify them. But that may mean that there are no longer enough repeaters to reach some areas. And already even with every powered node currently active, it doesn’t seem to work from just 2 rooms away.

Another option might be to try static routes, since the automatic rebuild option failed. I don’t know how practical that is to achieve manually.

The sledgehammer option would be to exclude every node and rebuild from scratch. It would take a lot of time to exclude 68 devices to bring the node count down to just 1 (controller) as I believe this would require 68 physical interactions. I could re-enable 63 of them through SmartStart in the desired order, if I knew what that order should even be. 34 of them are wired devices and should re-include without physical intervention after the SmartStart entry is turned on. 29 are battery-powered and will require physical intervention to include despite SmartStart. Without having an idea of the root cause of the problem or how to fix it, this approach is probably not going to be successful or a good use of time. It will also break all device-based automations in HA. Only the entity-based automations would continue to work if a node gets reassigned. This adds another massive layer of pain for this method.

19

Start with these links. I have 70 node networks that have been 100% reliable for several years.