Thanks for the advice. However I have already added two Aeotec 6 repeaters between the hub and the lock. Hub and lock are only 30 feet apart.
And youāve done a Zwave repair ?
Thereās also an Iris Zwave repeater driver that @srwhite created that works well and provides data on the repeaters state. You could try that driver to ensure the repeaters are being utilized.
1 Like
Thank you. Can you explain why you are setting time twice on Rule 1?
NM, I got it. You have to set it to current then set the offset to +2! Thanks again!
1 Like
I am experiencing the exact same thing! Have installed repeaters, locks may be 30' away...have done numerous repairs...the lockdown program has improved actual functionality but don't think its done anything for battery life.(Need more time for proof)
As I said before, I switched over from Smart things....the same devices in the same locations....I never had one lock issue with smart things but they are not functional with Hubitat.
I use both Yale and Shlage...you can say its the locks but why did they work with smart things? is the radio power that much stronger?
I am convinced there is some kind of bug/issue because - in my case, this is not a commerical, functional device for handling locks.
Dave
1 Like
I've given up on Hubitat with Smart Locks. I've tried everything to make them reliable with Hubitat. All my locks work fine with control4 and Smartthings. From drop off's to battery drain 100% to 0 in a day can get expensive. Just not worth connecting or trying new Locks with Hubitat IMO.
1 Like
I too couldn't keep my Schlage locks reliable on Hubitat after moving from SmartThings. I tried the repeater route and every other ideas posted, nothing worked. I kept my SmartThings active because I was using the SmartThings Home Connect mesh WiFi for internet. I moved the locks back to SmartThings and connected everything using the Hubconnect app. The locks are as reliable as they were before and controllable via Hubitat. Kind of a hodge podge but it works well.
As far as my locks are concerned, the apps and drivers available with SmartThings expose many of the capabilities that weren't available within Hubitat. I also use the SmartThings system to record house telemetery such as power and water usage uploaded to Google sheets for graphing into my SharpTools dashboards.
1 Like
Ever since I put my hub in the same room as the locks they have been very reliable. Iāve left the hub there and everything has been working fine.
Still canāt figure out why they donāt like routing through the other devices. But Iām going to leave the hub in that room for now and be thankful that everything is working.
After no luck installing repeaters, doing multiple rebuilds...I moved my hub - It was located in a built in wall shelf in the middle of my house next to my TV with other equipment including my router, and smartthings hub. My smartthings hub operated fine from this location...but It is in same a wall and close to a nonvented gas fireplace which has a metal shroud around it...bottom line - since i moved it my locks are relialble but I need to use Joel Wetzel's lockdown program. If I just ask Rule machine to lock all four locks - it will not get them all? Do they need to be separate commands with time in between?
It seems as is the Hubitat is much more senstive to interference from other devices and/or walls...
Dave
When I had z-wave locks, I would delay lock/unlock commands by 5 additional seconds for each lock. So if the first lock was locked at 0 seconds, the second was locked at 5 seconds, and the third at 10 seconds.
1 Like
thanks...I will try that.
1 Like
This makes sense. I rewrote my lock drivers to auto retry the lock command after 10s.
When I send lock commands to both at the same time I notice one will go right away and the second will get the command on the next retry by the driver.
1 Like
Iād recommend lockdown. I never open all the locks at once, but do lock them all. Lockdown has built in retries.
1 Like
Built in retries and also built in delays between each lock attempt. It really helps with z-wave mesh congestion.
2 Likes
Not a mesh congestion issue.
Iām not sure which issue you are referring to, but I am absolutely referring to a mesh congestion issue. In a system with multiple otherwise perfectly working z-wave locks, trying to lock multiple at the same time can cause mesh congestion, resulting in all other z-wave commands (lights, etc) to be delayed. I wrote Lockdown to spread out the beaming load.
1 Like
I'm not saying there isn't a problem of which you solved with this app. I am saying this is not a "Z-Wave Mesh Congestion Issue". Using a broad term as such is misleading to those new to z-wave.
Ok. You disagree with my description, but havenāt provided an alternative. How would you describe it?
I disagree with the conclusion of it being a "z-wave congestion" problem. I know from my own experience of installing small and large z-wave installs that the protocol is more robust than most give it credit.
Often times these problems are mesh related of not having enough beaming capable repeaters (non plus devices) and the non-plus devices compound the issues with non-optimal routes. There's also the problem of overruns that can happen when there's a lot of traffic and no repeaters and the hub is having to answer all of the secure messages from all devices (locks included).
However that isn't a congestion problem of the network. It can be a overrun of the controller message queues (which takes a lot of messages) or it could be a mishandling of message queue within the software stack. There's simply too many variables to give out a conclusive "z-wave congestion" as a definitive.
We're going to have to agree to disagree on our terminology then, because when I read your description, it sounds exactly like "congestion" to me. Exactly like road congestion. Too many cars. Not enough roads.
1 Like
Fair enough. Only we're discussing a couple locks not 20-30-40 so the idea of 3-5 locks causing congestion is more a queue failure than too many devices/messages.
1 Like
