What's the deal with the Schlage BE468/469 locks and when will the issue be fixed? The issue is definitely on the Hubitat side since everyone is reporting that they never had issues with the same locks with ST or Wink (including myself with a Wink 2 for over 2 years). There are numerous posts dating back to earlier this year and there seems to be no suggested fix or workaround.
The locks are unreliable which is a pretty big deal considering the cost and importance of a lock to anyone's smart home. I have tried factory resetting the locks a number of times, adding repeaters and testing different locations, Z-Wave repairs, hub reboots, hub shutdown and unplug overnight and nothing seems to make a difference. PLEASE HELP!
I empathize with your frustrations with Schlage z-wave locks. I went through something similar when I first moved to Hubitat, and started the thread indicating that the addition of an Aeotec Range Extender right next to the HE and additional Range Extenders elsewhere in the house (although not necessarily near a lock) resolved the issue for me. That was back in May.
My locks dropped off once in August; that may have been a generalized issue with an "overwhelmed" z-wave queue because the lock that I didn't reset came back on its own a few hours later. And the lock that I did reset/exclude wouldn't pair back to HE at the time, but paired a few hours later. There have been no incidents in the 2.5 months since then.
I've had both my locks on Wink since August 2014; they would occasionally stop responding to Wink as well. Especially right after I changed batteries.
My experience may change yet, but at this time, the behavior or my Schlage locks is no different than when they were on Wink. I suspect some of the instabilities are lock firmware related. My locks are on an ancient firmware.
What issues are you talking about? I switched 2 schlage locks from winks to hubitat and i haven't any issues. I'm using hubitat since 4 months now. I'm interesting to understand to check if i have the same.
The ongoing issues I'm having are instability issues where I press lock and sometimes it's instant and sometimes it takes minutes or just never locks/unlocks at all. If it was a slight delay I would be fine with that but when I'm relying on it to lock the doors and it never happens that is pretty frustrating and really defeats the purpose of smart locks.
I added a zwave plus repeater to my mesh. A cheap enerwave power plug with metering and that solved my issues. They say that you should put a repeater that supports beaming within 10 feet of the hub. I'm sure that there's a reason you want it close to the hub and not the lock, but I have no idea why. Mine is on the other side of the wall from my lock and has improved battery consumption and reliability. I've had that for 2 years now. Just recently I had issues, but I had moved that repeater over 10 feet to the other plug and didn't perform a repair.
The Zwave radios in locks, being battery powered, spend most of their time sleeping. When a lock/unlock command is sent from the hub, there is a good chance that the Zwave radio in the lock will be sleeping and miss the command. The hub does send the command multiple times but it then goes about its work and forgets about the lock. Locks require a beaming repeater to help locking reliability. A beaming repeater, any line powered Zwave Plus device, captures things like lock messages and holds them. When the Zwave radio in a lock wakes up, the beaming repeater forwards the locking command. Add Zwave Plus devices, some near the Hub and others near locks.
Wink and Schlage likely spent lots of time and money overcoming these issues and making them work even without repeaters, but at the expense of a light responsive Zwave mesh.
The explanation is that a Z-Wave device is able to route messages via up to four repeating nodes. So by design, a "slave" is making every attempt to communicate with as few repeaters as possible.
That was my very first (of 3) platforms and the Schlage locks were my very first devices on that platform. Although there was a delay because of the cloud operation, they never once failed entirely to fulfill the command issued to them, as they routinely do here (even "now" with beaming repeaters).
