Zigbee devices stopped responding

If you think you may be experiencing interference I definitely would. But I'd hate to create 24 hours of havoc on your mesh and have you end up with the same issue...

1 Like

Any improvement?

Hi, Everyone. Nothing worked but what I did is replace all the batteries in the three Window sensors even thought they were showing 100% and 42%. Reset them and now they are working.
Thank You for all your help.

Wow were we ever on the wrong track :slight_smile:

It is weird. I just found another Garage Door Sensor that is hung up that I just changed the Battery about a month ago, I am going to just try and reset it to see what happens. Thanks Again!

1 Like

The battery level reported by devices using lithium batteries is notoriously inaccurate because of the chemistry of the batteries... though a month is pretty unusual.

1 Like

When I have ussues with a device I usually first check the voltage of the battery. I have found that the level reported is often inaccurate.

If the battery has genuinely discharged, it suggests a partial mesh failure, putting individual end-devices into panic mode where there’s high battery use.

2 Likes

I think you are right, It was weird that the Batteries failed on 4 devices all at once. Something must have happened to cause that. Thanks

1 Like

Usually when something affects a bunch of end devices simultaneously, they shared a parent that stopped responding to their periodic check-ins. Then all the orphaned devices go through a network rejoin, sending beacons and listening for responses from nearby routers that have enough child slots to accommodate them, potentially repeating the process on all Zigbee channels to account for a coordinator channel change.

When multiple devices do this simultaneously there are inevitable collisions and MAC-level retries that make it less efficient (this is why having an active SmartThings hub on the same channel could compound the problem).

Each device's radio could be powered up continuously for 20 seconds or more (depending on how many channels get scanned) which is thousands of times more power intensive than normal operation. So if all the batteries were in a near-depleted state (as has been pointed out, battery reporting is notoriously unreliable) it's likely that the rejoin activity was enough to fully exhaust them.

Now that things are working again, It's a good idea to take a snapshot of the getChildandRouteInfo page and note what the hub is using for neighbor repeaters and route 'vias' to those end devices (you may have to look at the Route Table Entry section over a period of time since these entries are transient; the neighbor table is normally stable). Then if you have problems in the future you can see if any of those repeaters are now MIA; it might indicate a problem with that device.

2 Likes

WOW, that makes sense. Thank You for the explanation and Tip.

2 Likes