Far from me the idea that it'd have been intentional. For now mine drops out of connection and its not even 6 meters away and it is in direct sight of the hub...
I have a Zwave fan controller that is in touching distance from the HE hub. I have OZWCP set up to monitor my Zwave network and it is in fact 2 hops from the hub. You must look at connectivity from the device's antenna perspective. Radio waves travel in straight lines between antennas. What is really between those two antennas. How much lumber and plaster, plumbing or heating.
Sure, but this doesn't change the fact that HE is weaker than ST in terms of signal. Have a switch downstairs, never, ever, never a connection problem with ST and it simply can't stay connected to HE... I have sent emails to support but they say it's because of my cust code being, basically, shitty. So I deactivated all my cust apps. Same issues (anyway, don't see how this could affect connectivity. I get that it can render the hub unavailable, but I'm talking about issues that happen when the hub seems to work properly here).
This must be very specific to your setup.
I do not see this in my configuration.
Even temporarily put a Zwave Plus plug in device directly across from the lock. See if that improves things. Zwave devices do not "fall off" the network if you have a strong mesh. Having multiple paths between devices ensures that things work reliably.
Remember, the radios in locks spend most of their time sleeping. For a lock or unlock command, the hub issues the same command 3 or 4 times (don't remember which) but since the Zwave radio spends most of its time sleeping, it is possible the command is missed. With a beaming repeater across from the lock, when the lock awakes from sleep, it will ask "anything for me to do?". The beaming repeater has stored the original command from the hub and will forward the earlier command to the lock.
1 Like
did you check this app out?
I'll look into it. Thanks a lot. I'm also trying to have everything set with built-in apps so tech support can look at the issues I report without constantly stating it's my shitty config that is the cause of every bug (LoL just teasing them a little here [they tend to take the offense])
I've had no trouble with mine, that wasn't mechanical. I submitted an RMA, Quickset sent me a new one and all is good. It works the same on HE as it did with ST.
We don't actually know that.. it's just a consistent refrain when ST and HE are compared. Given that there is only one chip manufacturer and that now they "own" both Zigbee and ZWave, their future solutions may be more powerful. But everyone is using chips already manufactured, the Series 500 dominantly. Therefore the power output was hard coded years ago. The ONLY variability is the antenna. and ST and HE use PCB antennas. It's difficult to find a scenario where the various Hub manufacturers can gain an advantage strictly on signal strength.
Ok, so let's pretend that the signal generated within the ST plastic case and the HE plastic case are close enough to identical to allow us to look past the chip. Is there anything else in the environment that can adversely affect the signal? Well of course there is 
Kind of a given, actually. The Hubitat case is quite a bit smaller than ST and the antennas (in the C-5's) are glued to the top, inside surface. Are you deploying your Hubitat "face up" or "face down" for cooling? Face down would put the antenna's closest to whatever your mounting surface is... a wood shelf? Then it's going to attenuate a fraction more signal due to proximity. And so on.. thousands of minuscule elements in each of our environments that make the physical Hub placement better or worse.
Then comes the order of integration. When ST was deployed, did you Join a whole house full of devices in the same period as with Hubitat? The probability of the mesh formation being different is quite high, actually.
A Z-thing mesh tries to build the largest physical "bubble" possible. It wants your edge devices to be primary repeaters if at all possible. Which means the bulk of your devices are using a repeater that is further away from the hub.
ZWave has a 4 repeater limit and therefore the most distant/edge devices are more likely to be repeaters. So that lock?? There maybe a closer ZWave device that can repeat, but it might not be used as such. The mesh MAY hop right over the device you imagine is the repeater and use one further away. Most all modern devices support beaming and a Lock is the specific device beaming was invented for,
I'm in no way reducing the impact you are experiencing. It's also kind of a given that a device that was on ST worked well there... otherwise you'd have returned it.
But ST's mesh and Hubitat's mesh are likely to be different ESPECIALLY during migration.
As has been stated, locks sleep. They are battery devices and therefore must sleep and they sleep deeply and quickly. Meaning their awake time is smaller than say a battery door sensor. It's intentional, designed into Locks by the manufacturers. Beaming is the solution invented for Locks as I stated above. Lock manufacturers really don't want you to come home to a dead battery. They go the extra distance to make the batteries last. Which increases the potential for completely missing communications, especially without a nearby beaming device.
5 Likes
Thank you @csteele for this extensive and clarifying explanation. I heard about most of the facts you are referring to regarding how a mesh extends, evolves and adjusts itself, which makes my case worse, actually! 
This suggestion solved all of my problems.
I have three of these locks and they have been working fine for months. But now, one of them will not respond to commands (although I do get notifications when it is opened/closed). It looks like it lost the zwaveSecurePairingComplete=true setting, it is on the other two locks. Any way to regain this without removing and adding the lock? I have a whole bunch of rules that use it, and I really do not want to deal with resetting each one, if I can avoid it.
please post a screen shot of all the driver states, settings and data.
anything unusual in the past live logs?
you could try a restore from a previous backup, if that doesn't sort it, you'll have to remove and rejoin the lock.
You could add a virtual lock device as a place holder in all your rules before removing the actual device if you end up needing to re include the lock.
2 Likes
Truth is I am not sure when it stopped working. Have been distracted with other stuff, and with the house full of people all the time, I had not been paying much attention to the locks! So I am not sure how far back I would have to go. It sounds like excluding/including may be the best. It won't kill me to have to re-tweak all the things that use it. It's not like I have places to go! Adding a virtual lock would work nicely, I had not thought about it.
Thanks for the help.
1 Like
As Mike indicated, just make sure you remove the lock from any rules/apps before excluding it. Save yourself from trouble down the road. (temporarily replace it with a virtual lock as a placeholder).
1 Like
It was a hassle moving everything around, but exclude/include did fix the problem, and the lock is working correctly again.
1 Like
I've installed seven Kwikset z-wave locks now. Five 910's and two 914's. In every instance, I had difficulty getting the locks to work. Here is a recipe I've come up with that seems to work most of the time.
-
Perform a factory reset on the lock. Take the batteries out, hold down the program button and reinsert the batteries, keep the program button held down for approximately 30 seconds until the led flashes red. Release the button and wait until the led flashes green.
-
Calibrate the lock. With the lock in locked position, take out the batteries, push and hold the lock button, reinsert the batteries and continue holding the lock button until the deadbolt retracts halfway.
-
Manually set at least one lock code. Contrary to Kwikset's instructions, you must program at least one lock code in manually (you can delete it later). Press the program button, enter the code on the keypad, and press the lock button. If successful the keypad will flash.
-
Pair the lock to the hub. Put your hub in inclusion mode and press the "A" button on the lock.
-
Once paired, check for functionality. Chances are it will not be fully functional. But if it is, consider yourself fortunate.
-
If the lock is not fully functional, perform a z-wave network repair cycle. This usually takes 30 minutes to an hour on my network.
-
After the z-wave network repair is complete, exclude the lock from the network. Put the hub into exclude mode and press the "A" button on the lock. After the exclusion is successful, perform a second exclusion on the lock.
-
Perform a network inclusion on the lock. Hub in inclusion mode, then press "A" button.
-
Once the inclusion process is complete, check for functionality. Much more likely to be functional now. If not, repeat entire process.
2 Likes
