Multiple Schlage ZWave locks stopped responding but they appear in the logs

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.

This issue just happened to me with the same lock. Battery pack checked out at 5.96v. A good old fashioned power off / on for both devices resolved my issue. Have been using Reliable locks for years and the issue only started happening after removing the battery/lock to paint the front door. All is well again, Hubitat is great!