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.
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.
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.
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.
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
Ok first, I did read the faq but perhaps I didn’t fully absorb it. I’ll read it again. Second, trying the new hub was only a quick and dirty check to see if maybe somehow my v2 hub had gone bad. I literally just set up the new hub and only added one device, one of the locks. Since it behaved pretty much the same as it did when connected to the v2 hub, I concluded that the hub isn’t the issue. Sorry about forgetting that the distance didn’t matter and making the silly comment about it also not working when I moved it closer. I plead a case of age-related CRS (can’t remember s**t).
Thank you for your patience with me. You’ve exhibited nothing but grace and kindness. I am humbled by that, especially considering your difficult circumstances.
Anyway I am in the process of one last re-do. I’ve excluded both locks and both plugs from the hub and am adding them back one by one, the plugs first and then the locks.
Funny. Actually I did have a look at the Schlage offerings this morning should worse come to worse. Since I have you here, can you tell me the Schlage equivalent of the Kwikset 912 and 914? Also, can you re-key the Schlage locks the way you can with Kwikset?
Did you search your mesh for any ghost devices or unresponsive devices?
I don’t know what that means or how to go about it if I did. Thanks for chiming in. I was a user of your RBoy apps back in the day. Great stuff.
The two locks (and now the two plugs) are literally my only zwave devices, if that helps.
Oh, one perhaps silly question, would your answer about wifi change if the new wifi router had integrated Zigbee? It’s an eero pro 6 mesh and has Zigbee built in, although I am not using it.
I’ve never seen any zwave-related error messages in the logs but will read through that wiki. My hub is on firmware 000.040.00006, so perhaps it has been taking care of it. I don’t know why I would have any unknown devices though, as I said, the two locks (and now plugs) are the only zwave devices that have ever been connected to it.
Fingers crossed that at least the lock which is quite close to one of the plugs will show improvement.
As far as the frustration, I think we all feel that at some point with smartthings. The app is very pleasant looking when seen on a 20 foot screen at a tech show. But it lacks a lot of informational features that you would expect for a modern zwave controller. Smartthings (even before the Samsung acquisition) made the decision that ordinary consumers wouldn’t be interested in all that tech stuff, Which would be fine if everything worked all the time, but it doesn’t.
This is what a standard Zwave routing table looks like:
Wherever there’s a blue square, that means that those two nodes have a direct route to each other. Where there’s a red square, they don’t. The white square is just the intersection of a node with itself, so not applicable.
I don’t know why smartthings doesn’t give us one, but they just don’t. They’ve had a design philosophy from the very beginning that people would be confused if there were features available for zwave devices that were not available for Zigbee devices. So they just hide everything.
Which again, would be fine if everything worked all the time, but since it doesn’t, I’d rather have the information.
There’s also the whole issue of the cloud layer which smart things ads and which can obscure information unintentionally.
When you press unlock in the app, that action first takes place in the cloud.
If there’s some kind of breakdown in your local Network, the cloud status may be different from the reality on the ground. What the app is really showing you is “stuff that the cloud thinks has happened.” Whether it actually happened or not. That’s why the app by itself can be really frustrating as a troubleshooting tool.
Here’s one example which probably isn’t happening at your house because the locks did used to work, but I just use it as an example.
Human bodies can block radio signals. It’s pretty common that you would stand in one place to manually unlock the door but might be standing in a different place when using the app. So it’s not impossible that signal is being blocked in one of those two situations and not the other.
Anyway, none of those details really matter for your particular situation, but I just wanted to emphasize that we would all feel a lot less frustrated if we had normal Z wave diagnostic tools. As it is, we just have to do the best we can.
So I followed the instructions for How To Identify All Ghost Devices. I ran the zwave repair. Contrary to the wiki, which said the repair should take 5 to 30 minutes, it completed in 6 seconds and there were no errors or anything at all. As I said my zwave configuration is very small. Only the two plugs are connected at the moment. I haven’t yet added the two locks back. But even when all four devices are connected, a repair completes almost instantly and I’ve never seen any errors. Does any of that make sense?