I am having intermittent locking/unlocking and reporting issues with my Schlage BE468/469 locks. Sometimes the locks respond immediately, sometimes they are delayed and other times they don't respond at all.
I have them all right next to a GE Z-Wave Plus Enlighten dimmers which act as repeaters so it shouldn't be a signal issue. I have tried factory resetting the locks, repairing and performing Z-wave repairs on the HE hub to no avail. I never had issues with these locks with my 2+ years of using a Wink 2 hub. Any suggestions would be greatly appreciated.
Use the search on the forum. There are MANY posts and many bandaids some are using to make these locks less troublesome on Hubitat. These have been a long standing problem device on the platform (for some people)
My BE468 was 20 feet from the hub with clear line-of-sight. I did try adding a couple of Aeotec repeaters and things got better-ish, but still not exactly right. In addition to some unpredictable behavior, I was seeing rapid battery depletion (typical 3 - 5 weeks life with regular alkaline cells).
I eventually gave up and bought a BE468GBAK, which is the ZigBee version of the same lock. It does have some quirks with Hubitat, but it has been reporting lock/unlock and firing off my associated notifications and rules without a single failure for the past 6 weeks. I don't have an especially weak Z-Wave or strong ZigBee mesh either. I was apprehensive about spending another $125+ (I bought the ZigBee unit "used - like new" from Amazon) to replace a device I already had, but I've been so much happier after making the swap, I feel now that it was money well spent...
I moved the Z-Wave unit to our back door where it seems to work a little better, but mainly I don't care because I am only using it for notifications and not for any automation.
I have two of these locks. One is about10 feet from the HE, the other is maybe 50 feet and both of them are very reliable with usually sub second response.
I came from SmartThings and had so many problems with the locks. Once I took that z-wave network down (about 20 devices) and set it back up with Hubitat, the locks have been gold.
I definitely believe it. When mine worked/works, it works very well. I often wonder if I don't have some other rogue device (either included in my z-wave mesh, or perhaps operating on an adjacent frequency) that causes the lock to be become unreliable. In the end, I didn't have the time or energy to chase it down, so I cut bait...
I'm hoping someone has a fix or workaround since I have three of these locks and another similar Z-Wave Schlage lock that I don't really want to replace due to costs. It's pretty frustrating that these worked so well with the Wink 2 hub for so long and I left Wink due to the ongoing issues only to experience new issues with Hubitat. I'd be willing to buy more repeaters if that was a promising fix but the fact that these are all next to a Z-wave Plus repeating light switch makes that seem unlikely.
Can someone help me make sense of this since I'm not hearing back from Hubitat support when I asked for clarification. This was the response I received from support in regards to the locks:
Thank you for taking the time to reach out to us. Unfortunately, based on your description and our preliminary research, your problem may be related to your device being too far away from the hub or a lack of beaming repeaters in your system. The lock doesn't repeat through the closest mains powered device, but rather through the furthest repeater that is closest to the hub. If the repeater that the lock is using to communicate with the hub doesn't transmit the messages to the hub, it results in the experience you are highlighting.
It appears with "this issue" support has deemed it a customer issue even with the repeated customers all the time reporting the same problem all with different environments, and ones like myself continue having the issues WITH the current recommendations they propose and all users claiming the device worked just fine on previous platforms WITHOUT the requested repeating/beaming devices.
Personally I believe they know with the current hardware with of the current hub they can't fix this problem, and thereby having the user spend hundreds of dollars on devices to "bandaid" a solution together is their only suggestion.
Unfortunately, it's the luck of the draw. The Zigbee version of these locks don't appear to have any issue on this platform.
I have 2 old Zwave versions on my orignal C3 hub (with the Zwave/Zigbee USB stick) and after adding addition Zwave plus switches they worked fine.
But I recently decided to change my Hubitat setup to a multi hub system using Hubconnect. This included using my old SmartThings hub. The SmartThings hub does not have anything on it yet it is just connected.
I was having a very difficult time getting my Schlage locks to join to the new C5 hub that I was putting all Zwave devices on.
Then I decided to try and just power off the SamrtThings hub in case it was interfering.
Then the Schlage lock paired, it took and couple of attempts to complete the pairing and I had to exclude and include again. But it works
I also noticed on this lock and a few switches that once the device pairs and you can save a name to it. If they did not respond to commands. Just do a Zwave repair and everything will start working.
The point being it may be a device causing interference. Might even be another Zwave device.
In the past I had a faulty Zwave switch that would cause the locks to get kicked off the network whenever I manually pushed the switch.
I will still probably upgrade my locks to the Zigbee version as most of my arrival sensors are Zigbee and would like to keep them all on the Zigbee hub.
I agree with everything you said, but want to make sure people considering the ZigBee lock know that it does have at least one quirk/oddity.
When the device reports locks/unlocks it sends double reports. One comes without information about who/how it was actuated and a second report contains that information. This doesn't bother me at all, but I have seen some people here complain that it can interfere with automations they are trying to create that depend on knowing which user code was used to open/close (eg. using that code entry to interface with HSM?).
At least it reliably reports EVERY TIME and doesn't get hung/disconnected and grind it's own batteries to dust...
