Mike's the best.
If @mike.maxwell has a fault it is that he only has 24 hours in his day and can't investigate everything we want him to. 
3 Likes
I have had issues with these same locks since i have had the hub. I have tried all the tips from the 50+ threads i have seen about this set of locks. In fact, perhaps its a skewed observation, but if someone counted the most topics per device, these schlage locks continue to have threads about them without a "lightbulb" comment that fixes the issue. I keep hoping that the hubitat team prioritizes a specific driver for the lock.
1 Like
Yes. 100%. All 3 of my locks worked flawlessly for years with my Wink v1. I love pretty much everything else about HE - it's a 100000x improvement from Wink... with the exception of my locks.
1 Like
My FE599 and BE469 worked flawlessly with Wink v1 from 2014-2016, and Wink v2 from 2016 to when I switched to HE. Cannot get them to be controlled stably. Support told me today that the generic zwave lock code itself is fine, but the issue lies with devices used to repeat zwave commands from/to the locks. And that zwave+ repeaters work much better.
So I've ordered a bunch of Aeotec range extender 6 - will know in 2 weeks if things improve.
1 Like
I have 14 zwave+ repeaters on my network (no non zwave plus repeaters), and each lock (besides the closest one to the hub about 5 foot from hub with one wall in between, which has the least amount of problems) 1 other has 2 repeaters within 5 foot line of sight from the lock, with a 3rd about 15 foot away through a wall, and the 2nd lock has 3 repeaters between 5-10 foot away line of sight from the lock, and I still have the issues. Total distance from my farthest lock and my hub is outside about 35 total feet.
Keep us posted if yours improve with using the range extenders
1 Like
Definitely will. There is one interesting thing in what Hubitat Support emailed me:
The bold emphasis is mine. So I'm planning to put at least one of the zwave+ repeaters really close to the Hubitat.
4 (1 of them is literally powering my hub) of my 14 are within 5-10 feet of my hub as well...my house isn't super big so 14 in my floor plan should be adequate.
Hopefully one day there will be a resolution to this.
1 Like
I would certainly think so. My house is small too. I'm going to put one repeater immediately next to the HE.
1 Like
Support told me the same thing... but I struggle to believe that given all other evidence.
I shared a video I made with support 2 weeks or so ago where I illustrated the following:
- The locks tend to work when used one at a time direct from the Device page.
- The locks tend to 'freeze' the z-wave network for 3-5 minutes when a rule is used to operate two locks simultaneously.
I was told that the video would be shared with Hubitat devs to help identify the issue, but Youtube stats tell me that the video hasn't been viewed by anyone other than me. I'm sure they were busy with the sale over Easter, and getting the 2.9 release out. I know what it's like to not have enough resources to make everyone happy, so I'm not significantly upset by the lack of followup just yet. Support has otherwise been great.
Here were the results of a series of tests I ran and shared with support. This has me convinced that the issue appears to be in the software on HE side, and not due to any repeaters (I have many z-wave + repeaters, and again, never had the issue with Wink (just like you) or a significant popcorn effect longer than a few seconds).
Conclusion : When the following is true, my z-wave network freezes for 3-5 minutes:
- MORE than 1 BE469 z-wave lock receives an UNLOCK command simultaneously
Symptoms :
- The z-wave network will freeze for 3-5 minutes.
- Any z-wave command that is attempted from the hub during the freeze is stored and eventually triggered when the freeze ends.
- During the freeze no z-wave devices will respond to any z-wave commands.
- During the freeze no z-wave commands will appear in the Hubitat logs.
- During the freeze, zigbee devices are not impacted and can be used normally.
- After the freeze, all z-wave commands that were sent during the freeze will fire simultaneously and also display in the log.
TESTS to determine impact from Rule Machine on issue (2.5 and issue persists in 3.0) . Again - no issues encountered when ANY locks were individually locked/unlocked directly via the device page:
-
ONE LOCK - side door
Trigger: Cloud End Point
Select Actions: Unlock: Garage Lock
SUCCESS - ran several times. No issue. Lock always unlocked. Could always be re-locked in a few seconds. Ruled out issues with repeaters, z-wave mesh. Ruled out issue with Rule Machine if only a single lock and no other devices were triggered. -
ONE LOCK - garage
Trigger: Cloud End Point
Select Actions: Unlock: Side Door Lock
SUCCESS - ran several times. No issue. Lock always unlocked. Could always be relocked in a few seconds. Ruled out issues with repeaters, z-wave mesh. Ruled out issue with Rule Machine if only a single lock and no other devices were triggered. -
TWO LOCKS SIMULTANEOUSLY
Trigger: Cloud End Point
Select Actions: Unlock: Garage Door Lock, AND Side Door Lock
FAILURE - Every time the Garage door unlocked, and then the z-wave network froze for 3-5 minutes. Any command sent to any z-wave device during the 'freeze' time was queued and instantly ran as soon as the freeze ended. -
ONE LOCK, 2 Z-WAVE LIGHTS SIMULTANEOUSLY
Trigger: Cloud End Point
Select Actions: Unlock: Side Door Lock, Turn On 2 Z-Wave Lights in Garage
FAILURE - ran several times. First time no issue. Second time z-wave network froze for 3-5 minutes. Any command sent to any z-wave device during the 'freeze' time was queued and instantly ran as soon as the freeze ended. -
1st LOCK UNLOCK, delay 10 seconds, 2nd LOCK UNLOCK - two triggers
First Trigger: Cloud End Point
Select Actions: Unlock: Side Door Lock
Second Trigger: Other trigger fires: if Trigger above is run, delay 10 seconds, Unlock: Garage Door Lock
SUCCESS : ran several times. First time no issue. Second time there was a 5-10 second delay before first triggered lock unlocked. Locks could be individually locked via Hubitat without issue or delay immediately following this test. -
1 LOCK, delay, 2nd LOCK AND 2 Z-WAVE LIGHTS SIMULTANEOUSLY - two triggers
First Trigger: Cloud End Point:
Select Actions: Unlock: Side Door Lock
Second Trigger: Other trigger fires: Unlock Garage Door, turn on 2 Z-Wave lights in Garage
FAILURE : ran several times. First time both locks unlocked and lights turned on, but the z-wave network immediately froze for 3-5 minutes. -
1 LOCK, delay, 2nd LOCK, delay, 2 z-wave lights on - three triggers
First Trigger: Cloud End Point
Select Actions: Unlock: Side Door Lock
Second Trigger: Other trigger fires: if Trigger above is run, delay 10 seconds, Unlock: Garage Door Lock
Third Trigger: IF Garage Door Lock unlocks, delay 1 second, turn on 2 z-wave lights
MIXED SUCCESS : ran several times. First time no issue . Second time there was a 5-10 second delay before first triggered lock unlocked. Locks could be individually locked via Hubitat without issue or delay. Third time, the second trigger never fired according to the logs , but I was able to unlock/lock both doors via the device page lock/unlock buttons with no z-wave freeze issues. Fourth time ran without issue.
After each z-wave network freeze was cleared and z-wave network was working again , each z-wave lock was re-tested by clicking on "Lock" and "Unlock" on the device settings page for that lock. Each time ALL of the locks responded normally when used individually and directly from their device page.
I share all of our hopes that there is one day a resolution to this.
2 Likes
Very good process of elimination testing there, I hope they do take note.
I also believe it is somewhere software related, as before I learned of the "pairing next to the lock" process when I first joined (as this wasn't needed on previous 2 platforms), my pairing these caused my zwave radio to completely freeze and go innactive to the point that all the devices I previously paired disappeared from the zwave settings list, at which reboots did not fix, after contacting support a "hub shutdown" and power cycle was recommended and brought the radio and devices back to actually working again.
3 Likes
Hi all - this topic was actually briefly mentioned during Hubitat Live a few days ago - and the founders acknowledged they are aware of the issue. https://youtu.be/FPa05oM_V54?t=2177
@mike.maxwell As you work on debugging the issue, hopefully my reproduction steps above are helpful. If you want to see the video I made for @bobbyD further illustrating the issue and how to reproduce it, let me know.
2 Likes
Did anyone lose the ability to see their locks after upgrade to 2.1.0.123? My locks haven’t updated since 5/31 when I upgraded. @bobbyD any suggestions?
There’s a known issue with the driver for Schlage locks that is expected to be resolved in the next major update: Adding user lock code failed on schlage lock - #22 by craigspree
Adding a few (4) Aeotec repeaters has helped my locks stay connected more regularly but they still fall off the network and stop reporting every few days. There are a few posts recently with people having success with these repeaters and the Schlage locks.
When my locks fall off the network and stop updating, I find that if I unplug and replug the batteries in the lock it tends to get it to start reporting it’s status again for at least a few days.
1 Like
Thank you, Craig. Looking forward to an updated driver. BTW, rebooting my hub seemed to bring things back. It should also be noted that my Kwikset Convert, as well as other Zwave devices, were not communicating until a reboot.
1 Like
I cannot believe how unstable the integration is with these locks. Hard to believe it's an issue with the locks. I am on my third lock ad it still stops working out of the blue. So frustrating. I am going to fire up my old smartthings hub and see if it does the same thing with that.
I feel you frustration. The HE hub doesn’t seem to have as strong of a z-wave radio as my Wink did. Adding 4 of the Aeotec repeaters from this thread did the trick for me. The key is to have one repeater close to your hub and then the other repeaters close to each lock. Yes it sucks but it sucks less than replacing each lock. 
Adding Aeotec Range Extenders has made my BE469 and FE599 locks reliable
1 Like
Good to hear. I just bought 2 of the Aeotec repeaters in an attempt to resolve this. They get here tomorrow. If it works...can't believe I had to shell out over $60 to solve this when my hub is in direct view of the lock and 15 feet away.
fwiw, I'm seriously considering replacing my Schlage's with Yale's... my Yale that's in my shed works 1000x better than my Schlage's. =/
Like @craigspree, I moved here from Wink. I am simply amazed at the difference the z-wave range extenders have made to my z-wave locks in particular. My locks (BE469 & FE599) are less than 20 feet removed from my hub. They were difficult to control and would frequently drop off. Adding the first extender about 10-12 inches away from the Hubitat made a huge difference.
Adding additional extenders has made my entire z-wave network rock-solid. Nothing has dropped off. My locks are extremely responsive - I have lock-code based automations that never worked before.
The first month after moving to HE was horrible for anything that depended on automating the locks. I added the range extenders early in May, and I haven't had a single issue since.
I hope your experience is the same. I do recommend that you "repair the z-wave network" after adding them.
4 Likes
I got one of two repeaters and set it up. I put it in the outlet right next to the hub. The other repeater gets here tomorrow and i am going to put it in the hallway outside the office where the hub is. I have two locks, and the one that was not working still wasn't working. I replaced the batteries and it started working right away. I got this lock brand new only about 3 weeks ago. Could the batteries truly be dead already? If so, is that a result of the weak zwave mesh that the repeaters will hopefully solve? I need to rely on these locks and can't have the batteries dying within weeks. Is there a best practice I should be following for settings on the locks or something?
