Zwave lock problems all of a sudden

Hey everyone,

I have two routines that lock my two zwave locks if the door they are installed on is closed and the lock has been unlocked for more than 15 minutes. The routines have been working fine for many months, if not years. Sometime recently I began to notice that locks that should have been locked were not. I’ve narrowed the problem down to the lock locked/unlocked status not updating properly when the lock is manually locked or unlocked, either in the app or on the IDE. The status does seem to get updated sometimes, but only sporadically. Maybe once or twice every 10 times. I can stand there at the lock with the app open on my phone, manually lock or unlock it and nothing happens. No history entry, nothing.

So far I’ve tried deleting/excluding both locks and re-adding them, repairing the zwave network, relocating the (v2) hub so that it’s much closer to both locks, even resetting both locks to factory defaults and starting over. Nothing has improved the situation in any significant way.

I’ve opened a ticket with support, but haven’t progressed past the initial “please try the following obvious things to see if it helps” stage (all of which I had already done, and more).

The odd thing is that it’s happened to both locks at the same time. If it were only one of them I’d figure maybe it simply broke, but that doesn’t seem likely given that they are both having the same problem.

They’re Kwikset zwave locks. One is a 910, the other a 914.

I’d be grateful for any ideas.


Checkout my post from last week with a similar issue. You apparently need a repeater

Both locks function properly when the lock or unlock command comes from the app. It’s only when they are locked or unlocked manually. If it were a signal issue I’d expect the lock/unlock commands from the app to fail periodically. That’s not the case. Also, moving the hub to within a few feet of the locks didn’t help either. So I really don’t think a repeater would help.

It sounds like the issue is communicating status back to the hub, not from the hub to the lock. This was my issue as well. The status wasn’t being correctly sent back to the hub. Since the locks are battery powered, they have one shot at sending in their status. If that is missed, it will be out of sync. A repeater will make sure it gets to the hub. A dedicated repeater on a nearby plug, or an in-wall switch should do it. A smart plug near the lock fixed my issues until I install a light switch next to it.

Here is the full writeup that was given to me with an explaination

I forgot to mention, I did change the batteries in both locks a couple of days ago. Both are at 100%. I’m willing to try the repeater. What smart plug did you use?

Aeotec smart plug, but I think any zwave smart plug will work. They pretty much all have repeaters. Once you have it, you can either exclude the lock, include the smart plug, and include the lock. Or just wait for the mesh to repair itself. Check the routing in the IDE to make sure it is going through the repeater. Mine took about a day to figure itself out.

mmmk, will give the minoston mini a try, thx for the tip

I do wonder though, why would this have broken down all of a sudden? It’s been working fine forever and I’ve made no changes to my local environment that would have affected zwave. I did switch to a wifi 6 router, but zwave and wifi don’t conflict to my knowedge.

1 Like

So I got two Ministon mini plugs. I excluded all zwave devices from my hub. Then I added the two plugs, one by one. That worked fine and in the IDE both devices have a route directly to the hub. Then I added both locks back, which also went fine. Finally I started a zwave repair, which finished almost immediately. Both locks have a route direct to the hub and do not appear to be using the plugs as intermediary nodes. Both plugs still have issues reporting their locked/unlocked status when I manually lock or unlock them. They can both be locked or unlocked via the app with no issue. So, what now?

How close are the meanest in plugs to the two locks? To be chosen as the beaming repeater, they need to be within about 10 feet.

One is about 11 feet. The other 14. There is no closer outlet for the lock that has the plug 11 feet away. There is a closer one for the other. I will move it. Do I have to repair again after moving it?

Edit: It turns out there is a plug closer than 11 feet. I moved the plug there. Now the route from that plug to the hug goes through the other plug (that is now about 8 feet from its closest lock). THe route from each lock to the hub, however, still isn’t using either of the plugs. I dunno. Maybe it has to sit for a while.

Yes, Do the repair so hopefully the lock will find it.

The distance thing is part of the Z wave specification’s security protocols. The venting repeater has to be within “whisper distance.“

Did the repair. The lock didn’t find it. Very odd. It’s 3 or 4 feet away from it, and has a route to the other plug, which is way closer to the hub. I’m beginning to understand why zwave never really took off in the mass market. Sheesh.

Remember that the report that smartthings gives us is not a true zwave routing report. It’s just one specific route recorded in the cloud at one point in time. It doesn’t tell you the most common route, or the route it will take next time. And it’s not real time.

Zwave is fine, and it did become very popular particularly for professional installers. ADT’s home automation offering, Xfinity security’s home automation offering, Vivint, all have many more customers than smartthings hub customers, and all are based on Z wave.

SmartThings is a multi protocol platform and has laid its own application layer over the top, which can be frustrating sometimes. It gives you more options and more flexibility, but sometimes it feels like some of the base functionality has been hidden away. For example, I don’t know why they don’t give us a full zwave routing table. Most Z wave hubs do. :thinking:

FAQ: Is there a way to see the Zwave mesh network map?

Anyway, it can take up to 24 hours before you really see a difference in routing, so the best thing is to be patient and see if you get improvements in status reporting tomorrow.

Submitted with respect.

Ok will chill for a day or two and see what develops.

1 Like

A wee update. After letting things settle overnight I decided to check to see if anything had improved. Yes, I know it maybe hasn’t been long enough, but nothing had really changed by this morning. Manual lock status changes are still only rarely being picked up by SmartThings but changes via the app are still working fine.

I happened to have a new-in-box Aeotec SmartHome hub sitting around from when I had to migrate my Summer home from a v1 hub last year. I ordered the Aeotec to replace it but ended up never using it because I found a v2 hub on ebay and given that my primary home already had a v2 hub, I decided to replace the v1 with another v2 just so both homes would be using the same type of hub.

Anyway I decided to hook up the Aeotec hub this morning and add one of the locks to it to see if it would work any better. I powered off the v2 hub and placed the Aeotec in the same location. Again, manual lock status changes were only rarely picked up and app-initiated changes worked fine. Since the Aeotec hub is wifi-connected I can put it anywhere, so I moved it to less than 5 feet away from the lock hoping it would fare better. It did not. At first it seemed to be picking up the manual changes better, but that was short-lived and I was back to the same-old same-old.

I was prepared to move everything to the Aeotec hub if it worked, but in the end it was no better so I dismantled all the changes and put everything back the way it was and will wait longer. I have to confess, though, that I think something has changed in the local wireless environment that has basically destroyed any ability for these locks to work properly with SmartThings and that there’s nothing I can do about it. The maddening thing is that this was all working flawlessly for years and I don’t think I changed anything that would have caused it. I did replace my wifi mesh network with the wifi6 version, but that’s really the only significant change and wifi shouldn’t impact zwave, right?

Correct that the WiFi shouldn’t affect Zwave.

I’m sure you’re feeling very frustrated right now, but I’m also feeling frustrated because it is physically quite challenging for me to write posts (I’m quadriparetic) and the whole reason I write FAQs is so
I don’t have to keep writing the same replies over and over. The questions are good, but the answers are the same, so my personal goal is to limit the number of times a technical fact has to be repeated.

The title of the FAQ @blueyetisoftware first suggested you read 3 days ago is:

“ FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?”

Take a second and read that title again.

Telling us you tried putting the lock really close to the new hub is missing the point.

All of the suggestions you have received since that link was first posted were based on the idea that you want the lock to be using an “answering service” repeater rather than thinking about the distance from the hub to the lock.

So it’s clear that my communications are not helping you understand the technical issues so you can troubleshoot effectively. I’m sure that’s my fault, but I honestly just don’t have the energy to try to communicate this a whole different way.

So I will leave it up to other people to help you with this.

One last thought: when you added everything back to the original hub, did you add the minoston plugs to the hub BEFORE you added the locks?

If not, you will need to run a zwave repair again and that will restart the mesh update clock again so now you will need to wait until 24 hours after that repair before doing new diagnostics.

I’m going to give you one more FAQ in case it’s helpful. Note that it suggests that you “build the backbone“ of your network first by adding all the mains power devices (such as the ministon smart plugs) before adding any of the battery powered devices (such as the locks). Doing it that way increases your network efficiency and reduces the number of zwave repairs you have to run. So it can save you a lot of time in the long run.

1 Like

I’m going to tag @rboy , Who is an expert on locks of all kinds, in case there’s something specific about the kwikset model that might be contributing to this problem. :thinking:

Why do you think it would fare better after reading the links posted by @JDRoberts and others above? Beaming devices (locks) have less to do with distance than with quality buffering devices (the hub isn’t a quality buffer and loses packets)

Did you search your mesh for any ghost devices or unresponsive devices?

Since I work for Schlage I blame your Kwikset locks :slight_smile: