Thanks.
I actually had done that already, but, for grins, I tried again and it did the same thing.
The locks work fine -locally- and they report their status when manually unlocked / locked.
They also report their battery state.
However, they do not respond to the unlock or lock command from Hubitat.
For the record, these are Schlage model BE469 locks. Both are relatively new, as in less than 2 years.
Does hitting configure help at all?
Sadly I tried that as well, and, nothing.
Only thing I have not done is uninstall and re-install these locks. I actually don't want to do that since frankly it was kind of a pain to set them up in the first place. What's to say they do the same thing, again, anyway?
It is odd because both these identical locks used to work well, and, I don't change much on my system, which works really well otherwise.
One option is to just not use the remote lock / unlock function from Hubitat. Sort of defeats a large part of the purpose of the system. Expensive remote control locks that Hubitat cannot control, and I have read other threads describing this problem so I am not alone.
But if it doesn't work, it doesn't work. At least I can see if the lock is locked or not. In addition, others can read this thread to learn of the challenge, and set expectations accordingly.
You could try the Reliable Locks app either as a permanent solution or for troubleshooting. I had a similar problem with my Schlage lock and since using Reliable Locks it has been solid.
Okay. I will have to remind myself how to find and install non-included apps.
I did a little of that when I first got started with Hubitat, to fine tune what I needed. I use Hue and Lutron plus the 'direct' Hubitat controls.
Since I switched from Wink to Hubitat, the system has worked SO well that I only upgraded to the C8 hub to improve the Zwave performance, and added the cloud service.
That's why I am looking at these locks, they are the only fly in the ointment.
Look at the section in this post about Hubitat Package Manager. It will make things easier. I also know you say you don't have any ghost nodes but could you post your z-wave details page? The issue you're having sounds more mesh related.
Here are some other details I probably should have shared:
...both door locks are connected directly to the C8 hub (no relay paths via other devices)
...
and there are no listed Zwave devices (out of the 54 or so) that are not 'current' and
...
my SiLabs Zwave 'stick' diagnostics agree with Hubitat after I did remove two zombies around April 2023
...
and other devices in the network show typical response times of 1-2 milliseconds, and
...
both locks DO report their status changes instantly, and
...
I can see on my spectrum analyzer the RF packet exchange at 908.42 MHz
Given these ... I do not understand the reason I should consider the Zwave mesh to be a factor in the communications failure. Could you clarify what mesh communication mechanism would cause the anomaly where the locks can 'speak' via Zwave regarding status but not receive commands, so I could diagnose that?
Instead, I would be more apt to consider the secure mode attributes causing the logical path to not 'complete' and my next step would probably be to fully exclude the locks (resetting them to factory defaults), and rejoin the Zwave system with security mode disabled if that is an option.
Thanks for the suggestion about 'Reliable Locks' ... the install was easy. I wasn't able to get anything to operate differently using this app.
I can't say unless I see your z-wave details page in it's entirety. It's a diagnostic process and easier to start there.
No... You z-wave details page. it will have columns and rows... Each column is a device then the rows have specific info...looks like this. Post all of it.
"use windows Snip Just do multiple pages in one message"
I considered doing that.
Adjusting the text size so that say, roughly ten rows fit into each snip still takes a bit of effort given the more-than-sixty devices in the list (all of which are current), and I will have to schedule a time to tackle this.
All batteries are fresh, individually tested, and the locks both report battery status as 100%
use windows Snip Just do multiple pages in one message 
Did you try the easiest first step, and replace the batteries?
Might not be your problem, but I've seen multiple times where locks would report status fine but not actuate the motor due to low batteries.
Edit: I see you said that they have fresh batteries. So maybe that isn't it in your case. I would still try to swap them anyway.
I didn't even think of that, especially if using lithium batteries...
Might not be their problem, but it came to mind because I have personally seen this multiple times. Granted that was on kwikset locks not schlage.
sorry for the screen grab overlap on 2B
What do you think is the next diagnostic step, given this information?
I looked over the extensive history regarding these locks and the support for them on Hubitat, with some concern that the feature in question (basic control over the lock / unlock function) is actually supported at all. Looking forward to hearing a possible breakthrough.
Basic lock/unlock is certainly supported. That said the only thing I noticed is on the kitchen lock you have some high rerouting which indicates a beaming repeater may be in order. (did you have lag on it before?)
Also what driver are you using for the lock? Generic z-wave plus lock should work fine on the kitchen, but use the be469 driver for the front door. . After making any driver changes click configure.
Baring any of that, excluding and reincluding the lock may be in order (which I know is a pain because you have to pair the lock with 3 feet of the hub due to the whisper mode key exchange). That I think will ultimately cure it. It is weird that both the locks tanked at the same time.
Thanks very much for taking the time to look at the table data I added. I realize that after a long time trying to help others as you clearly have done, it had become challenging to ask for information that they might not otherwise know how to provide, so, it's best to just collect the whole data set.
I felt pretty sure that the RF part of the Zwave setup here was operating well enough. Glad you concur.
Watching the 'live log' of these two locks, there is no perceptible lag in the locks reporting to Hubitat of their manual status change. Flip the knob; get the status change readout immediately. To assure myself of this, I created a quick automation rule that turns on and off a Zigbee test light to 'match' the lock status, and that always works perfectly. Hence, my assertion that the 908.42 MHz RF path from the hub to the lock is not a major factor in this anomaly.
The relatively large number of 'reroutes' shown on the one lock you observed does not appear to be a valid number (test gear to see this) and may actually be telltale about the underlying driver problem. Hubitat might be recording route changes that have not occurred according to the RF capture of AFSK data at 908.42 MHz.
You have provided additional data points that point to the same conclusion I and others have made, which is related to the 'driver' for the lock in question. You've even suggested that I use different drivers for the two locks I have, likely a good idea.
I have in fact already tried some combinations of different drivers independent of this thread, without much luck. I will try additional combinations.
If any of these driver combinations can be made to work, I will post the results here.
I further appreciate that you noted my comment that these locks did lock / unlock via command on Wink and further that they worked for some time after I converted to Hubitat. Further investigation of past threads on this topic show that others have experienced similar issues of the Schlage Zwave lock remote control suddenly becoming partially inoperative, at some various points in the past. These data points appear to indicate that the anomalies being reported are related to the commands being sent by Hubitat and that the Hubitat environment had been changed at some point that caused these anomalies. This assertion has been anecdotally recorded by others, elsewhere. I hope that Hubitat staff is reading this thread and elects to contact suitable engineering resources at Allegion to find out the root cause of the problem and then create a robust way of working around any incompatibilities.
This is unlikely as they removed the schlage locks from the official compatibility list due to schlage's firmware being so wonky. The rule of thumb is anything 7.10 and above is fine, below a crapshoot. Now as to the different driver I mentioned was because One lock was z-wave plus (shown by the s2 encryption) and the other was at s0 (indicating an older lock that could or could not be plus). The be 469 driver works for both but it was just a thought to try. I think in the end, the re pairing of the locks is in order. if/when you do, create a virtual lock, then use device swap to swap it in to your rules. Then do a clean exclude of both devices. Shut down the hub via the settings menu, unplug for a few minutes and power back up. This will ensure a clean radio. Then factory reset the locks., That will ensure everything is clean on them.... Then re pair. If you get a failed pairing, STOP! Check for ghosts and remove if there.
Download the Hubitat app
