Battery operated Zigbee devices on HE are frustrating!

Just to be clear, I'm not talking about devices like sensors that report info back to HE (eg motion sensors), these work great IME. I'm talking about devices like Door Locks and Thermostats that get sent commands and then nothing happens.

I've got 2x Zen Thermostats and 2x Yale Door Locks that I've had inconsistent results with. I've had to add "repeat" logic to my rules so that if the state of them doesn't change after a period of time, the command gets resent till it does. This is annoying!

I'm not certain why this is happening, the only thing I know for sure is that I've been seeing this since 2.2.6.x and it wasn't an issue on 2.2.5.x. I'm using Zigbee Channel 25 and after conducting a Wifi survey I've found this channel is fairly clear of Wifi interference.

This only happens to Battery-powered devices, none of my Mains powered Zigbee devices exhibit this behaviour. I've even gone to the expense of using only Energizer Lithium batteries in these.

Any Ideas?

EDIT: I have the Yale Assure Lock SL's

EDIT 2: Here's Lock my rule.

I have two Yale locks that have been extremely reliable on HE from the get go. I do have a large number of powered zigbee devices, so perhaps my mesh is a little better.

Or, it could be differences in lock firmware version. FWIW, one of my locks is a "YRL226 TS", and the other is a "YRD356 TSDB". The YRD256 has firmware version "101D-8002-010E002B", while the YRL226 has firmware version "101D-800C-010E001C".

1 Like

I have a Zen Thermostat and a Zigbee Schlage lock, I haven't noticed any issues yet. I do know I'll see that slow response with the Zen thermostat when the batteries get low (even though they are reporting at 80%) once I change them everything is back to normal for months.

I found the Zen's improved with the install of Energizer Lithium batteries - If I change the setpoint manually on the Zen or manually lock a door, they always report back without issue.

The problem is when I send a command from HE, they don't always respond and I need to add extra logic to validate if the device received and acted on the command.

FWIW, I have 19 Zigbee devices connected directly to my C7 - 2/3rd's of them are mains powered and act as repeaters.

My Zen's are on the latest FW version (2,32 iirc) and my Yales are both as follows:

  • firmwareMT: 101D-C002-0105002A
  • softwareBuild: 0105002A

If I hit the refresh button from within the device page, they usually respond fairly quickly, although the Downstairs Zen can be slow to respond.

Not to derail this thread... but is this lock their lever lock with the keypad? I just picked one of these up with the zwave module, but it’s S0 and I have a feeling it’s causing my mesh some problems.

So I was considering picking up a zigbee module to replace the included zwave module as my yrd256 works well with zigbee. Just couldn’t figure out if the lock would work with the zigbee module or not, their docs are unclear.

My YRL226 doesn’t have a “TS” in its model number, so not sure if it’s the same.

Yes. Its the keyless lever with just a keypad. Works flawlessly.

2 Likes

I updated the main post, but for those interested, I have the Yale Assure Lock SL's (YRD256NRSC).

Zigbee devices can be what is known as a Sleepy End Device and most battery powered only devices are. Essentially they only listen for commands after transmitting a report and then only for a short period. This saves battery life by shutting down the communication hardware.

In my device driver I queue commands and transmit only after an event is received and this works ok but obviously not useful for devices that need to act on a command quickly.

Why a device like a door lock would act like this I don't know but if the device is directly connected to the hub you can check if it is a sleep end device using the /hub/zigbee/getChildAndRouteInfo endpoint and it should say so.

I get that PM is a thing Battery-powered devices do, what I don't understand is why Hubitat seems to treat Zigbee commands to battery devices as a "hail mary" (to use a US football parlance) and then not bother to check that the device has A/ received the instruction & /B executed the instruction. This is imo basic networking good practice.

@bcopeland @bobbyD Am I missing something here? Is HE not checking that issued commands are acknowledged?

ZigBee enhances reliability through mesh networking, acknowledgments and use of the robust IEEE 802.15.4 standard.

https://www.sciencedirect.com/topics/computer-science/zigbee-specification

Command acknowledgement is at the driver level I think. Generally every command sent generates a response from the device that you can check for.

I don't know much about the low level networking for zigbee (indeed I don't know a lot about zigbee beyond what I got from writing a basic driver for temp/humidity sensors) but I think it works more like UDP (broadcast) rather than TCP (request/response) so if the device is not listening there is not much you can do.

I originally thought that repeaters might queue commands for me but I have only ever been able to get responses from sleepy devices during the period they wake up and transmit first.

You mentioned using the rules engine so I assume you are not writing a driver. What is the driver, perhaps it's code can help figure out what is going on.

That might explain why my Iris v3 security keypad (Zigbee and battery powered) is 100% reliable compared to my thermostats and locks. All 3 are using Hubitat writen drivers tho.

That's the one I have as well. I don't appear to be having any issues but the lock is used very infrequently.

I also recently got a Kwikset 912 w/Zigbee to use in a door with no deadbolt and that gets a lot of use. No issues to report there either. I have "rules" for locking at night, and auto-locking. Battery seems okay as well.

For your lock have you tried using the Reliable lock app. I use it on my Z-wave locks and it works great, I think it would work on a Zigbee lock as well. I have one Kwickset Zigbee lock and it's has always been spot on, never had an issue with it. Never added a wrapper around it.

1 Like

I’m running my locks and thermostats via rule machine. My logs show actions firing, but I’ll get random failures of those actions.

I use a Schlage Connect Z-wave lock. I could never get it to work reliably until I placed a Z-wave repeater in the closest electrical outlet to the lock. I suspect adding a Zigbee outlet near your Yale Assure Zigbee lock might convey similar benefits.

1 Like

I’ve got 2 or more Zigbee mains powered devices in every room of the house. They are all good quality Samsung smart plugs.

Btw, to clarify the failure rate, at a guess it’s something like 10%. Enough to be very annoying.

I'm using a similar lock - the YRD226. I placed line-powered zigbee plugs near them so they have a convenient repeater, as it looks like you did too. I do occasionally get a misfire but I have found (as someone else posted) the "reliable locks" app works pretty much all the time.

2 Likes

Yah that is annoying. You've no doubt checked this out but you have no other devices that could be "flaky" like peanut plugs or tuya stuff? Maybe figure out via the child report where the Zigbee device is routing and disable that device temporarily.

Also good timing on your post - Was reading the comments and remotely updating a client's system this morning and noticed their garage lock (YRD256 w/Zigbee) is returning a lock status of "unknown". Will now have to go pay them a visit I guess. This is on a C-5 with the latest firmware (2.2.7.126) and a fresh reboot. Last response was a battery report at 2021-05-20 07:27:26.000.. suspect the door is not closed all the way and the lock is jamming but 100% battery is a little odd too.

2 Likes

That's the same deadbolt I have. Strange that the firmware versions are so different.