Both of my Schlage Zwave locks have worked well for quite some time.
However, they have now both stopped responding to lock / unlock commands. I have no idea why and would like to see if anyone here has any ideas about this.
My Zwave mesh is super strong and stable, with no zombies, only one or two switches out of 56 showing any route changes, and overall really fast operation.
Hub is a C8.
The locks report their status instantly when you manually turn the lock knob. They clearly are on the Zwave network.
However, both of these no longer lock or unlock with commands from Hubitat. The logs say they got the message, but that doesn't change the status on the dashboard icon nor on the device tab, and it shouldn't, because the locks don't lock-or-unlock.
The locks work fine with their local keypad control. They have fresh batteries.
Since they do 'talk' TO the Hubitat and all else in my system works fine AND they have numerous neighbors in the Zwave table, I presume the radio communications aspect is not the problem.
I further presume that since both locks used to work (at least, on the previous C7 hub; don't recall if I tested them after I made the upgrade) and now they don't, the Hubitat is the common denominator.
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.
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%
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.
