Zwave lock unreliability?

(Stuart Buchanan) #1

so a quick question to see if anyone is having the same type of intermittent issue with Zwave Locks. They work well and reliably but every month or so all my locks will fail to lock/unlock at the same time and will not work again. The first time I had this issue I removed and rejoined the locks and they worked again for a month or so (major PITA) second and third time it happened I tried zwave repairs etc… Nothing worked until the hub was rebooted. And again the locks have all failed at the same time. I’ve just done the same rigmarole as the second and third time but the locks still aren’t working.

Now I would like to state I can rule out signal as two are within 10ft of the hub. There are also zwave repeaters within 5ft line of sight of each door, and they were joined to the zwave network within 6in of the hub…i used a long ethernet cable and took the hub to the locks after the first failure. To me it just seems that the ST hub just stops beaming?

I can see in the logs that the hub sends the unlock/lock commands but that is purely all I can see in the logs…need more debug capability on zwave!


KInd/brand/model of lock???

(Stuart Buchanan) #3

all Yale locks of differing models, some Keyfree and Keyless 220 Locks


I have four 240s, and they’ve all been working great for a little over a year now. No problem like the one you’ve mentioned; was on the v1 hub, now completely on v2 as of last week.


The fact that they all fail at the same time sounds like a Z wave encryption problem with the hub.your other zwave devices aren’t failing then, correct?

I haven’t heard of anyone else having a similar problem. There are people who have problem with one lock, which is almost always either a problem with that specific device ( very rare) or not having a Z wave beaming repeater within 5 m of the lock (quite common). Z wave locks are the only devices which require a repeater that supports beaming.

There are also people who have had their entire Z wave network fail. That’s a known issue with runaway polling , for example. Or just local interference.

But to have multiple zwave locks all fail at the same time and only Zwave locks is unlikely to be the locks themselves. The most significant thing common to this device class is the special encryption on the commands. Which would be a hub failing.


One other thought…

Bringing the hub to the lock still counts as a “bench pairing.” So after you have completed the pairings and have the hub back in the usual position, you should run a Z wave repair utility to update all the address tables. Otherwise there may be some locks who think that they are within one hop of the hub when they are not.

But while that could certainly cause one lock to fail to communicate, it should not cause all the locks to fail at the same time.

So I don’t think that’s what’s involved here, but I did just want to mention it. :sunglasses:

(Stuart Buchanan) #7

yup that’s what I was thinking. I asked in slack a couple of days ago that I am seeing some CRC errors but I was asking how I can find out what the guid listed in the event was. I did look at all the guid’s of the locks and every secure encapsulation device I have but the guide don’t match


There is one other very small possibility, but I emphasize very small… If by chance the repeaters closest to your locks are not beaming repeaters and there is significant lag on the network, then the messages might be getting lost while the lock is sleeping.

I only mention this one because several members have reported seeing random but very significant lag in the last few weeks that occurs once or twice a day.

What repeaters exactly are you using near the locks? This could be ruled out very quickly as long as those are repeaters that support beaming.

(Stuart Buchanan) #9

I am using Aeon Repeaters, installed with the standard Zwave Repeater DH, AFAIK these support beaming.


The DSD37 model? Those do support beaming for both the US and UK models, although they’re not Zwave plus, so the range is shorter. But as long as they’re within 5 m of the lock, they should be OK.

You can check any Zwave device’s support for beaming in its official conformance statement on the Zwave alliance site:

(Stuart Buchanan) #11

yupe they are the DSD37 models, and they are both well within 5 feet far shorter than 5 meters

anyway i’ve been out all day. but just before i went out i did another zwave repair, but when i left it wasn’t working as i tried my fob unlock. but when i got home this evening all the locks are working again. have no idea what the problem was/is!

i do get a fair few of the following events with differing Guids in the ID’s

Err 116: Got CRC-16 encapsulated command with bad checksum

how do i find out from which device it was sent from…or does the hub not know?


Tagging @Duncan

(Duncan) #13

Yeah that CRC error is supposed to have a device ID attached but the cloud isn’t handling it properly. It wouldn’t be from a lock, though, because devices that use security encapsulation don’t use CRC-16 encapsulation. It does indicate that you have some congestion/corruption problems in your network that could also be causing messages from the locks to be lost.

Note that when zwave repair is active on the hub it blocks all outgoing commands. Did you make sure it finished before trying the locks again?

(Stuart Buchanan) #14

I certainly do i wait for the Repair finished message, and i also wait a while after that so i can be sure they all have committed thier routing info. so the question is how can i find out what is causing it? the locks have started working again, but this rigmarole has reared its head quite a few times.

(Stuart Buchanan) #15

@duncan so i’ve got myself in a pickle, i found the device causing the CRC errors, it was one of my Aeon Multi Sensor 6 devices. what drew my attention towards this was that it burned through its batteries in one week it seems.

so i did what you said to include and choose replace. but when i did this the first event was showing that the secure join was unsuccessful, i tried this twice with the same results. so i then reset the sensor back to factory results and then chose replace again and then put the device in to secure inclusion mode and this reported success, however the problem i have is this did not replace the device, it added it as a new device instead and the old device is no longer listed under my devices but is still allocated to smart apps and i am unable to unselect this device in the smartapps as its not visible in the lists when doing so.

so am a bit broken at the moment, using the IDE i have changed the name of the device to DeleteMeImBroken but i cannot delete from there either as its assigned to smartapps the network ID of the device is 14.

any ideas how this happened? i have in the past reset device configs and chose the replace option fine. unsure how this happened.