Battery operated Zigbee devices on HE are frustrating!

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.

Where are you getting the firmware version from? On mine it does not show. I am using the Yale Zigbee Lock driver..

I don’t know what to say - shows up both of mine.

Or zigbee bulbs. I have all of my end devices (around 60) on a separate hub with only 3 Samsung (zigbee 3.0) plugs, 2 Samsung (previous gen) plugs, 3 Sylvania plugs, and a couple GE in wall dimmers as repeaters. Almost everything seems to repeat through the 3 Samsung zigbee 3.0 plugs and I never notice any missed events with zigbee locks or sensors. I realize that I'm only seeing the last hop on the /hub/zigbee/getChildAndRouteInfo page.

2 Likes

So something is very odd with my device... it really is a YRD256 but I purchased the zigbee module separately. It's showing up as this:

Screen Shot 2021-05-20 at 10.32.14 AM

It's working though - but I need to make extra sure now.

1 Like

Did you push configure after the recent platform update?

1 Like

Frequently ... :laughing:

3 Likes

I got it from the HE Device page.

For those wondering how I solved this with repeats in my rules, here's my Door Manager rule: