We're really going with semantics here.
Does not mean "required"
"roughly" means + or -
600/4 = 125 feet (open air) PER HOP so dividing that amount by 3 = 41 is not irrational for going through a single wall. Absolutely not dividing it by 5 = 25 feet.
If you follow the "recommendations" 600 feet is physically impossible, both cannot be true.
Let's see.. You just dismissed the recommendations by the people who created Z-wave. Then tried to justify it on the basis of a simple (and laughably absurd) mathematical formula to try and prove that recommendation wrong?
Thanks for the best laugh I have had all day. 
Yes as logic doesn't work within that paragraph see the following edit to my previous post
There's a difference between marketing specs (328 feet) the real world. Physics get in the way of marketing, which is exactly what that paragraph says. For marketing purposes, one can reasonably and accuratly estimate of the signal strength received at a particular distance if you know the frequency, transmit power level (TPO), gain and pattern of the antenna. TPO and gain are calculated to derive a value known as ERP (effective radiated power).
Once you know the ERP and antenna pattern, one can calculate with reasonable accuracy, the expected signal strength at the receive antenna. This of course, is based on the highly controlled test environment of an anechoic chamber. And that is where the 100 meter maximum "open air" distance is derived from.
Environmental factors like temperature, humidity play a role in signal attenuation, as do people (we absorb RF quite well), pets, walls, furniture, windows, stucco, electrical wiring, even lead-based paint! Basically anything that isn't air can and does attenuate RF...
There is no way to calculate a one-size-fits-all value to conform to the real-world, hence why the recommend 30 feet or less.
Whether you want to continue to counterpoint based on anecdotes and false-logic is meaningless as you "cannot change the laws of physics".
I was actually being extremely generous with the mathematical formula as per their paragraph "open air" distance is 328 feet not the 125 I was using.
Which is why (according to math) one standard wall losing 80% of it's RF efficiency (because of these "environmental factors" is more than a lenient of calculation based on real life device reception (not even mentioning devices on higher frequency bands, that by design cannot travel as far, but achieve far greater than 25 feet *cough Zigbee *cough) In fact by using their "open air" calculation of 328 feet (your test environment noted) 25 feet is in fact losing 92% of it's RF efficiency.
It's not anecdotes, the paragraph you posted "by the creators" contradict within their on paragraph the ranges it itself is capable of.
Leniency is anecdotal and irrelevant. You need to stop coming back to what you believe a common sense performance metric should be. It doesn’t work like that in the real world.
Yep. Entirely possible. It all depends on the material the RF is passing through.
There are hugely complex formulas for calculating path loss, environmental losses, absorption rates of objects, interference, reflections, etc. They are all way above my pay grade.
It cannot be boiled down to a simple and contrived formula that somehow tries to support a derived argument that 92% is too much signal loss for one wall.
It simply doesn’t work that way.
It actually does when you see other hubs do it. Other devices do it All day everyday.
But the dead horse is beaten
Again, toss aside facts and physics in favor of more over-generalized anecdotes. That seems to be your motive here in most of your posts. (See what I just did?)
I’m just trying to help and explain things with an open-minded and scientific explanation for other factors. It’s to HELP you.
There are a lot of people using these locks without issues so it’s disingenuous to assume it HAS to be the hub and CANNOT be anything else.
At this point I might as well be taking to a dead horse.
With my situation, the only thing that has consistently cleared up unresponsive locks is to reboot the hub. Immediately after reboot, locks will be responsive but the Fe599 in a detached garage will go AWOL after a few locks/unlocks. When multiple locks start hanging, time to reboot the hub.
I am leaning towards @craigspree 's solution since nothing else I've tried has made a difference.
It’s not only the Schlage. I’ve been fighting with these Yale zwave locks for a while.
It’s not my mesh. I have zwave covering the whole house with the inovelli switches. I also have an extra repeater just in case.
They just seem to stop responding for a few hours at a time and eventually kick back in.
I’m trying to find the zigbee module for the yrd256 in Canada but I can’t seem to find it at a reasonable price. It will cost me $200 for two from the states.
If you go this path, be sure to give it about 4-5 days for your mesh to settle after setup. When I first did this, my lock at my side/back door had fresh batteries die twice over two days, and I got discouraged. But, then the current batteries have been in since October and I’ve had no issues!
That would be me. My Schlage 469 locks are older, from mid-2017 and they are fine on Hubitat as they were on Wink. I am not sure what lock firmware I have, but I cannot possibly have the latest few revisions due to the age of them.
One minor issue I have is fairly short battery life, but I am using NiMh rechargeables instead of the recommended (non-rechargeable) alkalines. I get probably 6-8 weeks on the rechargeables, but that is acceptable to me. I don't remember how often I replaced batteries on Wink, so I have no frame of reference there. The only MAJOR issue with Hubitat is activating all 3 locks simultaneously, it seems to jam the network. So I just don't do that anymore.
My hub is in the basement probably 50 feet or more from the 3 doors on the main floor, so not particularly close. I do have Z-wave switches near all the locks (and a few other places in the house) as well as Iris outlets throughout the house.
The weird thing is everyone says you have to be a couple feet away to pair, I actually paired the locks in place without the Iris repeaters, I added those months later. The locks paired on the first try no problem. The locks were the last things I paired after all other Z-wave devices (powered or otherwise) with the exception of the Iris outlets noted above.
That's typical for Z-Wave... The hub sends a command and waits for a response. Locks are a bit slow to wake up and and respond.. The Schlage FE599 handle locks are the quickest and usually respond in the UI within 1-2 seconds. I can issue commands to the entire group of 4 and they'll all respond very quickly. The BE468/469 are terrible and a poorly designed product. On their best day the 4 I have in service right now take at least 5-7 seconds longer.
It sounds like you dealt with it in a similar way. I have done two things.. For things like presence changes, I use RM to issue the lock commands for the FE599s with a 3 second delay between each one. The BE468/9 locks are on a different hub, but for those I use a 10 second delay between each command. That seems to wok very well for me. Having two hubs helps adds parallellism given the number of locks controlled.
I had these issues on SmartThings too, except worse. ST sends a Z-Wave command and waits until it's ACK'd.. If the ACK doesn't come in within a period of time, the hub power cycles the Z-Wave chip. Meanwhile, no other Z-Wave commands are happening. I could never use locks in Routines. I always had to use my own app to delay and manage the locks.
One final thought, in the case of presence, I delay all non-lock related Z-Wave actions by a full 90 seconds to ensure that all of the locks have had a chance to respond. Since it's more important to lock the doors than turn off the lights so those commands always go first.
Something a HAM would say 
I never had issues with ST and now Ring with the locks. I could not get them to pair with HE.
The way I got around the issues I was having with my Schlage locks and HE was to move the locks to Ring and then use the Unofficial Ring Integration app to control them. I have had zero issues since doing that. If you are in the market for an alarm and have the stomach to use Ring this may be something to try. The cost of the basic Ring setup and a new Schlage lock are comparable. You won't need a Ring subscription to use this setup. If Ring ever makes changes that render the Unofficial Ring Integration inoperable I guess I'll be SOL.
I'm not here to debate whether HE or Schlage is the issue. I'm just offering an option that worked in my environment.
Yup, I have Kwikset, but after hearing from people with problems with Yale and Schlage too, and we all had the same experience, even across both ST and Hubitat, I came to the conclusion that the z-wave spec for locks is just a faulty spec at its core.
I also had the problem like @neonturbo where it would lock up if I tried to do more than one lock at a time. I had this problem on both ST and HE. I ended up making my Lockdown app for Hubitat, which would space out the lock commands, ask for refreshes too, and have error correction and retries.
But still, I've ended up converting most of my z-wave Kwiksets to zigbee by switching out the chip. After conversion, I have zero problems with the converted locks. So I believe the z-wave spec is deficient for locks, and the zigbee one does it better.
Just to share my experience, I have just 1 Schlage BE469NX lock myself (FW 7.1) that is now 4 years old on my front door. I found it works way better on Hubitat than it ever did on Smartthings when I moved over to Hubitat almost 2 years ago. I can't tell you how many times I had to reboot my Smartthings Hub and reset the lock with Smartthings even though I had no problems with any other Z-Wave device. This is even when my Hubitat hub was in the same location as my Smartthings Hub I noticed a huge difference since switching to Hubitat nearly 2 years ago.
I was having battery a little bit of drain issues with my lock though I noticed and looking at suggestions I found by others on this site I added 2 more Z-Wave Extenders and now it's been 6 months since then since I replaced my batteries. I also think since moving to a 3 Hub setup last year has helped a ton as well using HubConnect, that allowed me to split up the devices on 2 hubs (3rd hub is coordinator with HubConnect) although I kept all my Z-Wave on 1 hub still since I have way less Z-Wave than Zigbee devices.
Anyone having issues in my opinion is mesh or device related with the lock; look in the ST forums and you'll see a ton of posts of ppl having issues with the Schlage locks too so this isn't just an issue with Hubitat. I can't speak of Wink since I never owned a Wink hub, maybe Wink has a much strong Z-Wave radio or something that is causing the differences there vs Hubitat. I'm hoping Hubitat looks into the 700 series Z-Wave chip on the next hub they release, I'll probably get one if it does 
Schlage locks I hate to say are just crappy Z-Wave locks, your better off getting Zigbee locks if you ever get a new lock. Schlage isn't much help either when I have called them since they can't update the firmware and won't help you when you have an older firmware. That's when I called them multiple times in the past when having issues with Smartthings.
We have removed Schlage locks from our list of compatible devices. We don't have a good solution for these locks, and we don't want anyone to be misled about them working well.
Excellent start. Word of caution though some will still link the compatibility with their being native drivers for it.
And for some people they work. We won't remove the drivers, but are going to be forthright in saying that these locks don't work for everyone, for reasons that are not known.
Download the Hubitat app
