Can you share the refresh logic you used? Iād rather do that at least temporarily.
@mike.maxwell anything I can do to help with debugging the issues since it looks like its driver or z-wave stack related.
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.
Brian
1 Like
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!
Iām using reliable locks and my mesh has finally worked out after adding some zwave plus repeaters. Canāt say I have any noticeable issues any longer.
Thatās great to hear and gives me hope. I just installed reliable locks and put fresh batteries in along with kicking off a z wave repair. Hopefully this does the trick!
Iād also invest in some zwave plus repeaters. Not regular zwave, but plus. Mine were only zwave which canāt help beaming devices like locks. Aeotec range extender or iris 3210-L seems to help (even if they are right by your hub because the hub could get busy).
What you really need to do is check the Z-Wave Alliance product database and find the specific repeater in question. Z-Wave Plus is actually a bit newer than beaming, so there are some older "classic" Z-Wave devices that do support beaming (though I've chosen to replace all mine with Plus anyway). All new certifications are required to support beaming, but all new certifications have been required to support Z-Wave Plus for a bit longer. So, there's no for-sure way to tell without actually checking.
2 Likes
RE: Z-Wave Beaming Repeaters
From day one, 5 feet to the left of the lock, I have an Inovelli NZW36 Z-Wave Plus Plug In module, that according to the manufacturer supports beaming.
I am using their driver from here: Hubitat/Drivers/inovelli-1-channel-smart-plug-nzw36-w-scene.src at master Ā· InovelliUSA/Hubitat Ā· GitHub
From this master repository:
I have a few of these throughout the house to ensure a strong Z-Wave mesh.
Iām really frustrated. In addition to the Inovelli NZW36 Z-Wave Plus Plug In module 5 feet to the left of the lock, yesterday I added a Zooz Zen15 Z-Wave Plus plug in module 5 feet to the right of the lock. Itās in an unfinished garage so there are no walls or other barriers between the locks and the repeaters on either side.
I installed the Reliable Locks app - and it refreshes the locks every 30 minutes but after a few hours the refreshes will stop for 2 of my 3 locks unknown reasons and I canāt identify any patterns with timing or other rules.
I did a z-wave repair last night. This morning the lock wouldnāt open via Hubitat so I kicked off another repair - watched the logs to ensure all nodes were successfully repaired, including the locks, and they were. Prior to the repair this morning I rebooted the hub, then shut down the hub, then unplugged the hub for 40 seconds and plugged it back in.
These locks worked flawlessly with my Wink without issues for 3 years. These are the only devices on my network that are misbehaving. I really donāt want to spend $600 for 3 new locks, especially ones that were working great on Wink.
Does anyone have any ideas of other things to try?
The ZEN15 docs don't mention support for beaming. They actively monitor this community - perhaps they could weigh in?
It supports beaming, per the zwave conformance statement anyway.
1 Like
OK, good. I couldn't find any mention of beaming support in the Inovelli docs either.
Do you know - do all Z-WAVE Plus plug in devices support beaming?
1 Like
I'm not 100% sure if it is a SHALL in the protocol spec or not, I would have to check.
All the zwave plus ones I've ever checked do support it though ...
I just ran a Z-wave repair and my Schlage lock (which is working) does not show up in the Z-wave logs. Mine is the FE-599. I guess it's different. I didn't think battery powered devices would show up in a repair . . .
1 Like
I was just wondering if I was wasting my time checking on that (beaming capability) for the Plus devices.
In any event, it sounds like the conformance data is a better place to check than the manufacturer's literature - that's good info.
yes, supposedly on is on its way to me...
2 Likes
