Looking at the paths my devices are taking back to the hub it is aparrent that there are favored repeaters.
In fact one repeater has become what I would consider a point of vulnerability despite others being just as available to take the traffic. Sometimes this defies logic as I notice the favored repeater chosen over a more proximal repeater to the device.
I'm under the understanding that (with all things stable) the devices will eventually work out their optimum path back to the hub ....so trying to force some path is frutile?
So what about repeater failure, how quickly will devices establish a new path in the event of a loss of their favorite repeater?
That's what I really care about....if the redundancy is there in the Zigbee network will real time resiliency be accomplished.… or is this more of a "healing on it's own time" thing?
I've wondered about this as well and have done a few experiments to see how long it would take for an end device to recover from the failure of its parent node. Bottom line, it can be very quick-- within seconds, and transparent to normal operation if things go 'by the book'.
Starting with a current XCTU mapping of my mesh I picked a router (Iris V2 plug) that had two child end devices (a SmartThings motion sensor and MCT340E contact sensor) and identified its neighbors, one being a Cree bulb in an automation triggered by that plug's child motion sensor. The plug was also in the hub's fully populated getChildandRouteInfo neighbor table (inCost and outCost both showing '1') and also showing in two Route Table entries as 'vias' for the motion sensor and Cree bulb; those were good indications that this plug was actively being used for routing both those devices.
With a tablet and phone open so I could watch the devices and the getChildandRouteinfo page, I pulled out the plug, waited 15 seconds (one link status reporting interval) and triggered the motion sensor. It didn't show a change state immediately as it normally does, but did so within 20 seconds. The Cree bulb that it should have triggered also showed a lag but within a minute was responding just as it should have. The contact sensor end device also was showing normal operation by the time I got around to checking it (probably a couple of minutes later).
Refreshing the getChildandRouteInfo page (I did this a few times during the first minute) I could see the plug still in the neighbor table but with outCost now showing '0' and age=7 (as expected, indicating the plug was no longer providing link status updates). Even though the plug was disconnected, the hub continued to show the plug in its neighbor table (inCost 1, outCost 0, age 7) for about 6 more minutes, at which point the neighbor slot it had occupied was taken by another router.
So had I not been timing these events, I probably wouldn't have noticed anything amiss had this router silently died. A success story in this case, but I purposely selected a router on the fringe of my Zigbee network not wanting to break too much if things didn't go well.
With my Zigbee lock, I've also seen quick and seamless recovery from yanking its parent router. I had my sniffer going and by the time I restarted the trace it had already rejoined another parent. But I'm also pretty sure I could cause a scenario that would break things badly, since a couple of weeks before I had temporarily unplugged the same V2 plug and re-purposed it for a while to take a power measurement elsewhere. I later noticed a light in the kitchen was no longer working, even when the plug was back in it usual location (it took re-joining the bulb to fix things). Why this 'failure' wasn't as transparent is a good question; in spite of their rep the few Zigbee bulbs I have are normally trouble free. And days before this anomaly, I had a complete power outage which lasted several hours; everything worked normally when power was restored...
agree with the above. I also use XCTU with my xbee and have watched my network heal practically instantly as I unplug or move things. It's really rather good compared to zwave. Also I have noticed some zigbee devices are just stronger than others. Like the Iris Plugs. Those tend to take on the role of router for many devices. I'm assuming because their signal is possibly stronger to those devices...even if another powered device is closer.
I would not worry about your vulnerability of a single device routing...unless there are NO other routes for distant devices. Great thing about zigbee...it's really easy to test...just cut power to it.
If you do have an xbee it will be even easier to determine what other routes devices have.
