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.