I hear you! I have 9 locks in use and 2 in the junk box. Talk about an investment!
Version 8+ firmware has been shipping for at least 2 years. If you have locks with the 7x series, they probably sat on a shelf for a year ot two before you purchased them.
Want proof they are obsolete? Call Schlage and tell them that you're having issues connecting with Z-Wave.. The first or second they will ask is when the lock was purchased. Once you tell them that you have owned your locks for 2 years, they will be "unable to assist" any further.
I've been there.... And have $400 worth of Schlage product sitting in a junk box to prove it.
I feel your pain. I have 3 BE469 locks that worked without a hitch on Wink for years. When I migrated to HE I had lots of issues, from fast draining batteries, to the locks falling off the network completely. I tried all of the known fixes, and have 5 Aeotec z-wave repeaters throughout the house, with 1 next to each lock, 1 centrally located, and 1 next to my hub.
I was able to solve my problem with 1 additional $80 investment, and have had no issues since. I, similar to you, did not want to spend $600 on new locks for my home.
2 of my locks are in my house, and 1 is in my detached garage. The lock in my garage was the flakiest, and the lock at my back door would regularly have issues, too.
My solution
In my garage I put an old Netgear WiFi range extender, and got a 2nd Hubitat C5 (if you have an old WiFi router lying around, you might be able to put DD-WRT on it and turn it into an access point for this purpose)
I plugged the C5 into the range extender so it's on the same network as my main C5. I then paired it with the lock and the Aeotec repeater in the garage
I installed the Hub Link and Link To Hub apps so my main C5 hub in the house can communicate with the C5 in the garage.
After a few days of my mesh settling down, during with I had a fast drain of my back-door lock, I have since had zero issues. This was back in October. It's now the dead of winter in MN, and my batteries are fine, the locks always work, and the WAF is higher than ever.
I can only imagine that the true underlying issue is a combination of the Schlage firmware/devices causing issues with my mesh when there are a certain number of other devices and rules also active.
Getting a 2nd hub might not be the right choice for you, but it was for me. I wish I had done this back in May when I was pulling my hair out trying to resolve the issue. It would have saved me so much time, anger, and frustration.
I have read several posts where people are adding a second hub. Is this essentially acting as a repeater and all of your programming is still done on the primary hub? What's the process to configure this? Thanks
How does firmware ONLY affect being on the Hubitat platform. Why does the lock with the same firmware operate on other platforms without issue? Also why does that firmware NOT cause problems on Hubitat if you KEEP the hub within 5 feet of the lock?
My anecdotal evidence is contrary to yours.. I have 4 FE599's and 5 BE468/469 locks.. The only issue I have is one of the BE468 locks will go offline once in a while. I have to pull power to the lock to reset it, but it come back every time. That's certainly not a hub issue.
So who's anecdotal evidence is correct? Nobody can declare that. Not you, not me.
However I will close by saying that it's a well known fact of human nature that people complain more than they compliment. Therefore, it's not an unreasonable assertion to say that a vocal minority are having issues with these locks.
Basically, the two hubs can, and do, operate independently of each other, but you can link them together with 2 apps that are included with Hubitat.
Here's how I have them set up.
Hub 1 - let's say this is at 192.168.0.2
Hub 2 - let's say this is at 192.168.0.3
Hub 1, I have 95% of my rules and over 100 devices
Hub 2, I have 2 rules and 5 devices
The two hubs can talk to each other through 2 built-in apps "Hub Link" and "Link to Hub"
Hub Link goes on your 'main' hub.
Link to Hub goes on your "2nd Hub".
These two apps allow the easy creation of virtual devices on Hub 1 that mirror what is on Hub 2. You can choose which devices to mirror.
Example:
On my Hub 1, I have a rule to unlock all of my locks.
This rule unlocks 2 locks connected to Hub 1, and a virtual lock that is tied to Hub 2.
When the virtual lock on Hub 1 is unlocked, this triggers the real lock on hub 2 to unlock. When the real lock on hub 2 locks, the virtual lock on Hub 1 is also updated.
It's a pretty slick and easy interface, much more so than RM or anything else.
There is a user-created app called HubConnect that offers way more functionality, but for me the built in apps were all I needed.
I disregard the "mesh" theory all together. Zwave is designed to operate "end devices" Locks ARE end devices. The only time a "mesh issue" is relevant is if you have too many "end devices" with not many repeating devices spreading out the congested traffic.
This issue occurs with the lock being THE ONLY device on the hub, there is no congested traffic. If the lock is more than 5 feet away from the hub, you will not get consistent operation with the hubitat.
And Like what @craigspree posts as soon as you bring the lock within that 5 foot. ALL ISSUES go away.
If true, that would certainly indicate that the Hubitat requires at least one Beaming-capable repeating device in order to use locks.
Most battery powered Z-Wave that receive messages require a connection to a Beaming-capable device. Beaming is a store and forward mechanism where the repeating device holds a message for a period of time until the end device wakes up and checks for messages.
This is an easy theory to test since I have 2 development hubs with no Zigbee or ZWave devices attached. And a ton of locks.
I have done over 9 months of testing trying to solve this issue on Hubitat. I've completely started my zwave hub from scratch at least 3 times.
FYI: Your testing needs to be over about a 3 day span. There were MANY times I thought I had the issue figured out, only to have the device go unresponsive just a day or two later.
Have you tried pulling the batteries from the lock to power cycle? I have one of these that requires that to be done once in a while. The lock comes back to life every time. That’s absolutely not a hub issue.
I have literally tried everything (multiple times), in the 9 months.
(Recommended) Alkaline batteries instead of Lithiums thinking the "undesirable behavior" Schlage themselves state in their manual on Lithiums cause could be the issue. It wasn't. ALL issue went away the closer you "permanently" move the hub to the lock.
FYI My "mesh" is 2 repeaters (All Zwave Plus) to every 1 end device and I have at least 5 known "beaming" repeaters. And still had issues
To properly figure out this issue you must eliminate variables. And I did eliminate the mesh variable out of the diagnosis.
I also eliminated the "firmware" variable at least for anything 7.1 and newer as 2 of my locks are 7.1 and one is 8.0.
I previously had issues with one of the 7.1's and one 8.0 repeatedly as those two were the furthest distance away from the hub(and we're not talking a great distance, we're talking 25-40 feet). Now that I've added a hub next to each of them, the issues are gone.
Yeah that’s good advice. Never use lithium’s in locks. It completely screws up battery reporting amongst other things due to the “cliff effect“.
Stupid question. You don’t have any older cordless phones, baby monitors, non-BT headphones or older wireless speakers, do you? Are you using any power line Ethernet extenders? Some models use 900MHz to achieve greater distance at the expense of throughout.
A lot of early digital phones and baby monitors ran in the 900MHz band, some still do. Those devices and Z-Wave both operate in the same band and are subject to co-interference under part FCC 15 rules. (It says amongst other things that a device must not intentionally interfere but must accept interference from other devices). A Z-Wave lock operates at a much lower power level than some of those devices and can easily be overpowered.
Nope, only wireless (speakers) are sonos and this issue predated acquiring them, And my closest neighbor is a block away.
One of the things to keep in mind, like your question above. Is that would be very valid on a new to automation user in diagnosing an issue. But the overwhelming majority of those who are stating these issues on here are coming from other platforms where the device was already working on (in their current environment). Just a data point on variable elimination.
At the time I did my test, I was pulling my hair out. Eventually I got 5 Aeotec repeaters, and even tried adding my Wink v1 back to my network as a repeater, but nothing fully solved the problem. At the time, @mike.maxwell even created a new dedicated BE469 driver and made further revisions to it over time. Yet my issues persisted leading me to believe it was a combination of many factors, not just mesh, not just lock, not just HE software. Eventually I went the 2 hub route, which solved my issue.
Here is a (not to scale) illustration of my current setup with 2 hubs and 3 BE469s. My hubs are not within 5 feet of my locks. With this current setup everything is working without a hitch, and has been doing so since October. I have many other devices and repeaters, both z-wave and zigbee, throughout the house. This is just to illustrate distance between locks and hubs, as well as Aeotec repeaters.
Not saying everyone should or shouldn't do this, just sharing what worked for me and preserved my sanity as otherwise I am much happier with Hubitat than I ever was with Wink.
Thanks for sharing! This is interesting and I'm tempted to try a second hub. Just have to convince myself it's worth throwing more money at Hubitat first.
I also have very dense meshes.. So there's another datapoint that supports the weak mesh theory. 
