Zwave, being a very low powered radio does not travel well through walls and is susceptible to interference etc. You can't tell radio waves where to go and which devices to route through. Since this is a DIY platform, it is your job to figure out the best placement and quality of repeating capable devices should they be needed.
2 Likes
wall(s) The (s) isn't required the problem lock was within 30 feet within ONE wall "WITH TWO BEAMING REPEATERS". Zwave is a low frequency radio capable of 328 feet in open air. One wall does not reduce that to less than 30 feet, Nor does multiple walls with all other devices on my network.
Then you have proven your views as correct. Good luck.
A FLiRS device (locks) wakes more often than other battery devices BUT it wakes for a shorter period. The intent is to extend battery life. The result of the shorter wake period is it will often miss the fact that the Hub has something to say. Between one and four times a second (manufacturers choice) a FLiRS device will partially wake.. only enough to listen for one message.. the special beaming message. That message originates on the Hub but is stored at the last router on the path to the FLiRS device. It will either hear it from the Hub directly, or indirectly via last router. It then fully wakes and carries on a completely normal conversation with the Hub.
FLiRS + Beaming means 1 second (max) response, unlike other battery devices. This was added to the ZWave protocol in 2013.. probably hitting real world devices in 2014/2015.
A beaming repeater is not needed if the Hub is the "last always on" device, in other words there's a direct route from Hub to Lock. 
However, since 2013, hubs have been tasked with a few more things to do. They can miss the partial wake. A Beaming Repeater doesn't miss. It has had nothing new to do since 2013. 
5 Likes
This. This. This. Sorry, I should have mentioned this. I have found an oddity with the Schlage locks. They work fine for me with rechargeable batteries, but they only seem to pair correctly with a fresh set of non-rechargeable batteries. I keep forgetting this because I only have to repair them when switching hubs, but I ran into this with the new ZP lock too so it hasn't changed with the new versions.
1 Like
This means there's something in your household which isn't a good repeater which got inserted into the path. See if you can get HE support to give you the Z-wave path or use a Z-wave sniffer and it should be apparent. Or simply try turning off devices one at a time until the lock works perfectly.
FYI radio waves are weird. I've seen Z-wave devices using a repeater that's 10 feet from the hub, when the device and hub were 3 feet away from each other with only air between them.
2 Likes
Do you know factually (via zwave path details from the hub) which repeaters were used? You refer to "all the other devices on my network" -- it's very likely there are other nodes in the path.
1 Like
It actually doesn't as I can move the hub itself leaving everything else it their exact location and the problem is eliminated.
I've completely removed all devices and reset the zwave radio at least a half dozen times during the months of testing for this......trust me I've tried every single scenario possible and the only solution was the location of the hub itself for the locks issue.
I have end devices that are 150 feet away from the hub outside, on a metal mailbox that has never missed a single communication. Mesh or zwave "distance" isn't an issue.
You've seen this because that is the design of zwave to "expand" the mesh. If it routed everything from 3 feet away first with only being allowed a 4 hop maximum, you wouldn't be able to achieve much distance overall if everything went through the closest devices.
Just FWIW the Hubitat does only local processing where ST did less. It's entirely possible this discrepancy in behavior exists due to that, for the reasons that @jeubanks mentioned:
A beaming repeater is not needed if the Hub is the "last always on" device, in other words there's a direct route from Hub to Lock.
However, since 2013, hubs have been tasked with a few more things to do. They can miss the partial wake. A Beaming Repeater doesn't miss. It has had nothing new to do since 2013.
2 Likes
I'm not following your logic here. "If I move my hub close enough to the lock that the path shortens, the problem is resolved ..." is proof to you that something was not in the path previously that didn't work?
I believe it provides the opposite--this is clear proof there was a bad relay used in the path previously.
That said, you seem not to be interested in learning from what others are sharing so I'm going to stop trying to help. @jeubanks in particular seems to have a deep grasp of what's going on in Z-Wave. Should you decide that solving the problem is more useful than arguing, I suggest you go back and read his detailed posts.
2 Likes
Agreed. That said, it would really help if Hubitat provided the paths used to the devices for debugging purposes @mike.maxwell
2 Likes
The reason you're not following is because nowhere in your initial statement regarding "something in your household which isn't a good repeater" say anything about the "path"
Those are two completely different statements.
Wrong, what there is clear proof is that to solve the issue you cannot rely on ANY path except for direct communication, and that is only achieved with the hub being in an extremely short distance from the device.
Adding a repeater to your network is designed to IMPROVE your communication not weaken it.
I'm not the one "not to be" interested I appear to be one of the few who have spent months diagnosing this, yet you are trying to provide help when you haven't done any background on this? To be not interested would be your response which requires repeating for the 15th time, this issue is shown by having this device being the ONLY device on the hub, everyone keeps trying to involve "the mesh" into this NON MESH issue. The issue is easily reproduced with no other devices on the controller.
1 Like
I'm curious-- how do we interpret the firmware version printed on the device? The only one I have disassembled right now is a new ZP lock and the printed firmware version is 0.10.8 ...
@bobbyD is this a version 10 lock or a version 8 lock? Is this one you all said you wanted as minimum version? Since I bought this off the shelf I doubt it's a pre-release version 0 lock...
I don't believe that is revealed by the ZWave controller.. based on the fact that neither OZWCP nor ZenTools display it. Both will display a X-Y map of what can communicate, but don't reveal which path has been selected. In other words, from the Map, you could see that the Hub has direct connectivity to devices #8 and #14 (among others) and that the Lock is device #34 which can also communicate with devices #8 and #14 (among others.) But nothing tells you which one was picked.
1 Like
I have a non Plus BE469 and the label shows 6.8. I think Nexia was the only platform that could update the firmware, but when it proved unreliable, Schlage discontinued it way back in 2013. After that, I think Schlage simply replaced peoples locks.
1 Like
I don't believe that is revealed by the ZWave controller.. based on the fact that neither OZWCP nor ZenTools display it.
When I've borrowed Zwave cards to sniff the network the paths were easy to see. If you read the Home Assistant forums there's advice on how to do this. I've also had other hubs display the paths in debug mode.
As HE's market is those who don't want to become experts with their own scanning tools, they could be helpful by providing the path information.
Both will display a X-Y map of what can communicate, but don't reveal which path has been selected. In other words, from the Map, you could see that the Hub has direct connectivity to devices #8 and #14 (among others) and that the Lock is device #34 which can also communicate with devices #8 and #14 (among others.) But nothing tells you which one was picked.
That's because they are observing the packets without decoding them. The path is contained inside the packet contents from what I understand. @jeubanks said the same thing, and he appears to be one of those with good tools 
I collect the hop counts and neighbor tables using OZWCP as the best I can achieve. I can know which devices can talk to which and how many hops between hub and device. I could make guesses but that's it.
Update on my last comment:
My zwave environment changed as I'm moving out soon (building a home). Here's the latest:
-
Removed 2 Leviton Decora DZS15 which were 2 feet by the door
-
Removed all Leviton Decora DZR15 in-wall plugs (2 on same level, 2 in basement where HE is located, and 2 from the upstairs bedrooms.
-
The ONLY Zwave products now remaining: Aeotec Range Extender 6 (1 by the door and 1 by the HE).
RESULT:
I'm now getting all events in the logs, and my automations (turn on lights when code is entered) are working.
Again the changes above are what I've made, in addition to 2 HE platform updates.
What conclusions (if any) can be drawn from my recent changes?
@zarthan @endorphin_junkie @IpostThings
Should I get rid of these gen1 products or sell them to upgrade to Zwave Plus?
Wait and see if your results are the same a few days from now.
After adding my (5) Aeotec Range Extender 6's my problems (I thought) went away for a few days only to return to the exact same way it was prior to adding them.
Roger. It's been about a day and a half. Forgot to mention after removing those pieces that I ran another Zwave repair
