I have 2 910s in my personal setup, they have never dropped off the network in the two years they have been in production on Hubitat.
One of them was recently moved to a different hub, still solid.
Hmmm, you must never have submitted any tickets over there...
And how many st engineers regularly participate in their forum?
Agree with Mike. 3 ZW 910's here. Rock solid. Never misses a beat. A pain to pair, but that is a different story.
@mike.maxwell, thank you for your answer. It is indeed always appreciated to have your team answer so promptly. It is true that HE's reactivity is nothing to be compared to ST's. I was just teasing a little...
However, you stated earlier in this thread, I think, that you have the zigbee versions. just know that the Z-wave version are a nightmare to use wit HE. I think there are enough posts in this thread mentioning the issue. I have had this lock for years with ST and it never failed, although ST itself failed at many other levels.
Now, there are things for which it is hard to grasp what you policy is about. You probably have one the most stable products on the market and it seems you are expanding pretty fast.
However, here are a couple examples of what I think is still posing an issue:
a) HE still won't allow to set up / support thermostats over voice control devices such as Echo.
b) Old Aeon Labs power meter switches (DSC06106-ZWUS) are not really supported; They will "work" with zooz or aeon/Aeotec power switch V.6 drivers, but very unrealiably: power reports will return, at times, values such as 155478.04 watts... Also, their z-wave range and other protocols such as "wake up" will fail at times, rendering those devices unresponsive.
c) Many switches will make alexa return the "device is not responding" phrase while they did respond effectively to the a cmd, pointing an issue at the driver level. All this, even after temporarily disabling all customized apps...
Be sure I am saying this in all friendship here. the matter of the fact is that it feels as though it is not being taken care of despite the fact, that Thermostats and Alexa, for example are an issue for which has been reported almost 2 years ago...
best,
Mine are zwave, that would have been lame to tell you that mine were fine if they were using a different protocol no?
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.
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.
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.
Download the Hubitat app
