I have not tried the hack driver. Coming from the wink world instead of the ST world, I’m not as familiar with drivers. I have a few user drivers and apps installed, but am not yet comfortable building/hacking one in my own especially for a door lock.
It sounds like waynespringer79 tried it and it didn't help so it may not be worth the trouble.
Wish we could get a clear answer about rboy's stuff. Thread I found said HE staff never responded, but HE just told me rboy wasn't interested. =/
Guess I just hope a native driver helps.
Sorry need to correct myself. Not using reliable locks but using his other tool called lockdown. I never tried the ST “hacked” drivers. Did you try the full reset on the locks vs just exclude and include? Also please open a ticket with support as they can see stuff we can’t. @bobbyD did a great job of pointing out noisy devices (HEMv2) - also working fine on ST - were spewing data and causing mesh issues. Firmware updates for HEM’s plus addition of a 3210-L seem to have resolved my issues. Run lockdown at night and when away and I unlock a door whenever someone arrives, so, I’d think I would know if something was failing. Good luck and come back and post if you do get it resolved. Don’t buy new locks just yet.
2 Likes
It worked on my be369 after nothing else would.
Fresh batteries in the lock?
support weren't useful in my case. I got it working before they responded 2 days later, and they didn't really offer any input about my issues (having to use ST to do the exclude). They did say rboy wasn't interested and that they really wish he was...
Yep. Brand new. Tried both regular alkaline and the fancy lithium energizers. No difference.
I am detecting that the lock is failing 2 ways
-
I have a rule set up if the lock is ‘unlocked’ for longer than 15 minutes. I am getting a false positive at lest once a day. I always verify the lock is locked. I then open the device in Hubitat and it says it’s unlocked. So the rule is not the problem
-
at least once a day when I try to unlock via the dashboard, or even direct front the device interface, the lock won’t respond for 15-30 minutes and I’ll have to manually lock or unlock. Sometimes it responds with a 2-3 second delay. So frustrating.
I did uncover a separate totally reproducible bug for the Hub that is entirely unrelated to the locks that I’ll create a new thread for later tonight. So all this trying stuff is good for at least something. 
Also, yes I did fully reset the lock. I just excluded and included it again to see if that will help. @bobbyD is talking with me via private message as well.
UPDATE: No resolution for me yet, but I've been trying lots of things this weekend...
- Moved the hub to each lock
- Manually reset each lock, then excluded each lock, then reset the lock again, then included each lock
- The locks will respond pretty fast when initially after inclusion, but after a few locks/unlocks things start to get bad again where the lock wont respond for 30 seconds to a few minutes before locking/unlocking.
I now have the hub back in its original location, and performed a Z-Wave network refresh. I have tried a bunch of steps to get the issue potentially reproducible, and here is what I have found.
Reproduction steps (frequently, but not 100%):
- Do not do anything with any Z-Wave device for 5 minutes
- Unlock ONE lock directly via the "Devices" page - any of the 3 locks selected will unlock within 1-3 seconds which is acceptable.
- For the next 1-5 minutes are where it becomes difficult to do one or more of the following:
a) Lock the lock that was unlocked, via the Devices page, or any dashboard
b) Unlock any other lock, via the devices page, or any dashboard - During this time, sometimes the locks respond quickly, but more often the locks do not respond at all to one or frequent lock/unlock/refresh queries via the devices page or dashboard.
- After waiting for 5 minutes or so with no Z-Wave activity, the next time a lock/unlock command is sent to a single lock it will respond within 1-3 seconds as expected. However, if any further lock commands are sent to any locks then the process repeats from step 2 above. Again - this is not true 100% of the time, sometimes the locks simply wont respond to lock/unlock commands even if it's only to 1 lock at a time and nothing else has happened on my z-wave network within a 5 minute time-frame before the lock/unlock attempt.
Impact: I have a few rules setup which trigger 2 or 3 locks simultaneously. Such as when I am leaving home in the morning. I run a triggered rule which should unlock my side (house) door and my garage door. At night I have a rule that triggers all 3 locks to lock themselves. Whenever I use these rules, I experience the issues starting at step 2 above, which appears to be a correlation.
Note : I have been watching my logs, and have not seen anything strange such as excessive lock/unlock commands or anything that I can visually identify such as commands flooding the network. It is possible that the locks/hub/mesh/repeaters are flooding my network with commands during lock/unlock events but none of that is showing up in the logs I have visibility into.
1 Like
This is what I see. It acts like the zwave network is just saturated for some amount of time after a lock/unlock.
Super frustrating. Really hope we get some update to zwave lock driver with next update... this is untenable.
I pulled all 3 of my locks off the doors yesterday (needed to have them rekeyed anyways) but for 6 hours I left them within 2 feet of the hub.....all 3 worked flawlessly every command every time. As soon I put them back in their use locations, communications are sporadic at best even using reliable locks app. and my mesh is fine as I have devices 100ft further away from these locks working everytime with no delays in commands as well as plug in repeaters within 5 feet of each lock.
I "think" the locks just appear to drop communication with the hub at random from my experience....hopefully the lock that @mike.maxwell is looking at from a user can determine a cause/fix for this.
On a side note observation, when all 3 locks where next to the hub, I did notice interruptions when trying the "get codes" command if the logs became chatty from other devices as it would stop the get codes command, at which I had to re-initiate the get codes command to get it to complete it's scan of the codes, this happened a couple of times. Also noticed that when communication gets interrupted that "usually" unplugging the lock from it's batteries for 5 seconds and plugging them back in brings it back to communicating.
I quite honestly believe that a vast majority ofthese Schlage BE469 locks have shipped with either faulty Z-wave modules/radios, bad firmware, or a combination of both. Yes, I know some people have no issues.
My 469 lock refused to work properly with SmartThings or Hubitat, even though it paired to each hub without issue. It would work one day then fail to update lock/unlock status the next. None of my lock based rules ever worked consistently. I swapped out the Schlage for a Kwikset zigbee lock and zero issues on HE since.
All 3 of mine work almost perfectly on Vera and Smartthings, I wouldn't agree that it would be a faulty zwave module/radio (in the devices), if this were the case the device would act the same on all 3 platforms, but I can literally "pair in place" these locks on the other platforms and they rarely have any communication issues, its the only device I have issues with on this platform.
1 Like
I'm just speculating. I personally believe that the generic lock driver in HE compounds the issue. Like I said, my Schlage lock paired with both ST and HE without issue. Heck, now that I think of it, it even paired properly with my old Vera Plus hub. However, it never worked properly with any of these hubs.
I know cost is an issue for most, but considering a switch to a zigbee lock will alleviate much of the frustration. I believe Schlage makes a 469 style zigbee lock now.
It could be that I simply had a dud, but at this point I'm happier with my zigbee lock and not looking back. Perhaps I'll reach out to Schlage one day, but I'm in no rush.
To me this isn't a consideration, as that would be throwing $600 down the drain.
3 Likes
Luckily on the kwikset you can replace just the comm module, and not the whole lock. 
So converting from zwave to zigbee on my 3 locks wasn't that painful.
In all prior houses I used standard/non-plus zwave schlage locks, and they worked well for me. But that was not on Hubitat, either.
Ya I read what you wrote on this and emailed Schlage to see if this was an option. Got the following response:
Hello,
Thank you for contacting Schlage Support. The Zigbee boards are not available for purchase as well as the product were not made to be easily switched. You will need to purchase the Zigbee lock is you would no longer like to use your Z-wave version. Thank you!
Thank you for choosing SCHLAGE
Have a safe day!
Yeah, that stinks.
It is too bad, too... I had very good luck with my zwave Schalge locks in past houses (on smartthings, vera, and homeseer). I had OK luck with zwave kwikset on Hubitat, but bad enough I couldn't live with it after multiple missed locking events.
I only switched to Kwikset in this house because I like their user re-keying ability. So I could have the same keys w/o paying a locksmith.
If I flat out couldn't get the locks to work reliably in Hubitat, I would probably pickup a cheap or used SmartThings hub, put the locks on there, and then bring them over to Hubitat via HubConnect. But I'm weird and have almost zero patience for things that only work intermittently.
We think alike, as this was my thought as well, but my "Smartthings Experience" was using a stick attached to Nvidia Shield, at which I believe I read HubConnect only works with an actual Smartthings "Hub" so that killed that idea as I'm not buying one especially to have the locks on cloud based, if it would work (with what I already have) I would take the chance even though I wouldn't like it.
So I have high hopes in Mike solving this problem......he seems pretty smart 
1 Like
