Schlage BE469NX connectivity issues / unreliable


#42

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.


#43

It sounds like waynespringer79 tried it and it didn't help so it may not be worth the trouble.


#44

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.


#45

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.


#46

It worked on my be369 after nothing else would.


#47

Fresh batteries in the lock?


#48

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...


#49

Yep. Brand new. Tried both regular alkaline and the fancy lithium energizers. No difference.


#50

I am detecting that the lock is failing 2 ways

  1. 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

  2. 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. :slight_smile:

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.


#51

UPDATE: No resolution for me yet, but I've been trying lots of things this weekend...

  1. Moved the hub to each lock
  2. Manually reset each lock, then excluded each lock, then reset the lock again, then included each lock
  3. 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%):

  1. Do not do anything with any Z-Wave device for 5 minutes
  2. Unlock ONE lock directly via the "Devices" page - any of the 3 locks selected will unlock within 1-3 seconds which is acceptable.
  3. 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
  4. 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.
  5. 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.


Difficulty Pairing Schlage BE469 Lock