Hi, I have 4 of these and they worked without issue on ST. I just moved them over to Hubitat and I'm having issues with them receiving lock/unlock commands. They work sometimes, but other times I have to hit lock or unlock multiple times for them to be successful. The only time an event registers in the logs is when it's successful.
Lock Firmware: 7.1
HE Firmware: 2.0.5.114
Factory Reset Tried on BE469: Yes
SmartThings: Worked without issue.
Congestion?: ST hub is unplugged disconnected:
Range?: Device is literally 5 feet from HE hub.
Z-Wave Repair? Yes, I've run it several times (but as I've read on forums, battery devices don't always get updates right away)
Secure Pairing? Currently enabled for Locks & Garage Doors - have not tried turning off and re-pairing.
Generally this is a range issue, make sure you have a beaming capable repeater near the lock, then do a zwave repair afterwards.
The lock paired securely, no need to join it again.
Yes, in that wall switch is an Aeon micro switch, beside another door is a Monoprice dual relay. On the outside wall by another door is a GE/Jasco direct-wire 14285 (just using a generic Z-Wave driver; not sure if it will repeat if it’s not using a proper driver??), by another door are 2 HEMv2 devices.
I’m going to leave them for 24 hours and hope things resolve once everything is repaired. I’ll report back, but if you have any suggestions, I’m up for trying.
It's still acting up this morning; that door lock in the pic didn't get a lock command when I pressed it in the GUI from the driver page. Any ideas on ways to debug and get the issue resolved? Seriously had 0 issues on ST with these devices in over 2 years.
My only idea for a temporary solution is to create a virtual driver for each lock and have a loop to wait and check if the real device state actually changed, if not, send the event again. Can drivers access other devices, if so, do you have an example for this so I can work on creating something? I thought about going the Smart App route, but I don't believe the App would see the "lock" press events if they aren't showing up in the event logs. If you think the Smart App would see the lock event, then I'll head down that route as a temporary workaround. EDIT: Created a quick Smart App and it didn't see the event when I tried to lock/unlock and it didn't register. So not sure a Smart App will work.
That seems like a real pain!!!! I can only commiserate not help unfortunately.
I've had very similar issues with both my old ZW yale and ZW+ Yale locks. Tried relocating the hub which sort of worked but had spotty issues like yours, adding repeaters which did not - ended up switching to a zigbee module and everything is now okay. My old lock worked really well under ST too. Was using RBoys excellent manager app.
Range seems like a non-issue to me. My HE hub is in the same exact place as my ST hub once sat - which is right beside the lock in question. The devices that are in my HE z-wave mesh were the same that were in ST - everything has been converted over. Guess I'll move these back to ST unless there are other options to get HE to work reliably, that don't involve replacing the locks.
It just seems like there are a lot of issues with Z-Wave locks for some reason. I wonder if it's the secure Z-Wave connection misbehaving?
One thing HE seems to NOT like is a bunch of secured connections. Found that out early on when I inadvertently paired a bunch of door sensors "secured" (by double tapping instead of single tapping to get into pairing mode) and performance started to falter a bit.
Of course on the flip side I guess there are a lot of people whose ZW locks ARE working..
The BE469's in general are just temperamental. I'd rather install fiberglass insulation all day long, without using gloves.
The Z-Wave fixes in 2.0.4 pretty much cleared up the issues I was having with those locks.
That said.. I've also noticed that my locks will randomly disconnect anytime that Hubitat trie to fetch lock codes. I believe the commands are happening so quickly that the Z-Wave stack in the lock is crashing.
My fix has been to pull the batteries when the locks fail, which is not often as I do not change codes frequently. Try a battery pull next time the lock drops off.
They aren’t dropping off, they always register manual lock/unlock events. They just don’t seem to get every lock/unlock command. If I resend a few times it will eventually respond.
Speaking of the Stack crashing, I wonder if we took all the code management stuff out of the driver if that would help. I just want lock/unlock and it to be reliable. Maybe have 2 different versions of the driver?
fetching the codes sends a ton of commands, it runs when the lock initially joins to import any resident codes, there should be no need to manually run it after that.
From the initial code import forward any codes added from the lock, or the driver are sent the other way.
Removing the code management components isn't going to make lock/unlock commands more reliable...
Hey Mike, I had this lock with 7.1 firmware and it was a mess, many commands/reports lost, I had 3 repeaters about 3ft away, I had a rule to refresh the lock with a minute of delay when the door closed, that fixed many of the lost commands/reports, then by recommendation of @srwhite I replaced it with the same lock but with 8.0 firmware, I paused the refresh rule, I got my z wave tool and it has 26 routes, it worked fine for a few days then is doing the same as the 7.1, I had to turn on the refresh rule. I don't know but I think something still needed on the driver, I never had problems with ST with the 7.1 lock, and lately I don't even mention this worked better in ST because I'm very happy with everything else of HE, it's a great hub. Just a side note, I used rboy driver. Thanks.
Thanks. I suppose I could do trigger rules for any lock or unlock action and delay a minute and if state is still not what it should be, then try again. Guess it's two rules per lock. I assume delay will re-evaluate state before executing so I'm not sending lock commands if it's already locked? Sigh.
Well, if you create a rule instead a trigger then you can add more logic, but for this trigger every time the door is closed it will refresh the lock no matter the state. You can add a refresh when opening the door. When I said open or closed I mean a contact sensor on the same door as the lock.
Got another failure today. It’s not often but it happens. Is there anything one can do other than apply workarounds like rechecking if locks are unlocked and relocking? Confirmation that you’re aware and working on it, if not should I open a support ticket? Be glad to assist if I can.
Same issue happening to me, exactly as described above. FW 7.1 that worked flawlessly for years with Wink. Now with HE the lock works sometimes - meaning I can trigger it with a rule, or directly from the dashboard, to luck and unlock. But on my way out today I manually locked the lock and it never updated the hub. I got my alert notifications via rules telling me the lock was unlocked but it was physically locked. I tried sending a few lock commands via my dashboard throughout the day but it still reports as unlocked.
This has happened every other day with this lock for the past few days since I migrated. Has anyone solved this yet? I’m going to give this user app a try tonight to see if it helps. [Release] Reliable Locks
My other two locks FW 8.0 and 0.8.0 work far more reliably, but have also had a few ‘outages’ I have plenty of beaming repeaters including one just 5 feet away from the lock causing me the most issues.
This is my last ‘problem’ to resolve after an otherwise great migration from Wink to Hubitat.
@bobbyD do you know if any active development or debugging is going on with this issue? I’m sorry if there’s a better way for me to investigate potential open tickets and status without bugging you. Thanks!
