If I see a number of incorrect/sub-optimal routing relationships, or lets say I am doing some major device relocation/renovation etc. there should be some way for me to easily disable routing for battery devices.
I know that the general recommendation is
to turn off Hub for around 20 mins.
Then to first turn on mains powered devices
finally turn on battery devices.
But, if I have a huge amount of battery devices, this is not a practical step.
It would be nice if somehow, Hubitat may allow me to create sort of groups of devices
e.g. tier1 (mains powered and closest to hub),
tier2(mains powered and second hop extenders),
tier 3)(all rest)
so that I could turn on routing for those devices one by one in order to rebuild routing correctly.
These choices are not made at the level of the platform. I'm not even sure the platform can make these choices. The best way to achieve what you want is to power up a subset of your routing devices (tier 1), followed by the rest of your routing devices (tier 2) after a gap of 20 minutes, followed by the sleepy end-devices.
Normally you don't need to worry about managing this; practically speaking there is no architected way for an end user to maintain or specify routing paths for Zigbee devices.
Zigbee routing devices (non-sleepy devices) adapt to mesh changes 'on the fly' since they constantly exchange link status even when no messages need to be sent. If they lose a link to a neighbor repeater, they'll automatically establish another if possible, tracking their best 16 neighbors. Unlike Z-Wave, this is done proactively at the link level; message delivery failure is not a pre-requisite for this to happen (Zigbee is designed to be self-healing).
Zigbee sleepy devices (and non-routing mains powered devices like a Sengled bulbs) do not route; normally they will use only one path to/from the rest of the network: via their 'parent' device. If the link to their parent is lost; they determine that they've been orphaned and will attempt to find another, choosing the best one RF-wise if more than one is in range.
It's a persistent relationship that lasts as long as the sleepy device and its parent continue to check-in successfully; it needs to persist because the parent device buffers all messages inbound for the sleepy device and likewise stores and forwards all messages outbound from the sleepy device. Again it's unlike Z-Wave where a sleepy Z-Wave device can use a set of calculated routes to the hub that may involve different mains-powered Z-Wave repeaters.
You can affect what choices the sleepy Zigbee devices make when choosing their parent router by limiting what repeaters are 'live' when the sleepy device initially joins the network after it is reset (the sleepy device must be reset, not just power cycled, since it stores its current parent's device ID in nonvolatile memory). If the repeater they join continues to provide the strongest link vs. other potential parents, they'll normally maintain their link to it and won't try to rejoin another unless the link becomes error prone or fails.
Since zigbee is self healing (as you described), couldn't you affect the parent choice at anytime by limiting what repeaters are 'live' when the sleepy device checks the connection (which I might presume would, or at least could, happen when a device is power cycled)?
You can take the parent device away at any time and that would cause the sleepy device to go through the orphan rejoin process. But from a practical standpoint you probably wouldn't want to do this as it would be disruptive to the rest of the network (especially if there are other end devices hosted by the parent that just got turned off).
There are also provisions in the protocol for an 'orphan rejoin' process that is different than a 'network join' and lots of configurable time intervals for the check-in/rejoin protocol. While it seems simple in concept, it's fairly complex.
Just as end devices remember their parents, every router maintains its current child table in nonvolatile memory. Things can get messy when the routers in a network are powered up and down at different times-- depending on the order that things power up. and how quickly the end devices rejoin, you could wind up with a scenario where more than one router has the same end device in its child tables until things stabilize. The parent router will 'evict' a child from its table when a certain time interval has elapsed without a check-in; that will free up space in the child table (assuming the original child is no longer in the network, or has found a new parent).
All that said, I've had good luck keeping a half dozen of the problematic Xiaomi buttons on my network functional, even though only two of the dozens of repeaters I use are 'Xiaomi-friendly'. When joining the Xiaomi devices, I make sure to do it in very close proximity to the 'compatible' repeaters, and always keep the device within range of the parent; they then 'stay put' and work fine. The nature of the Xiaomi incompatibility only relates to the time intervals of parent check-in/rejoin process, so you don't really need to worry about incompatibility with any other routers in the network; they are fully capable of repeating messages to/from the Xiaomi devices as long as they are relayed by the compatible parent. The only time I had to rejoin a Xiaomi device was when one of the compatible repeaters got knocked out of its wall socket.
Edit: Actually I'm not certain that the parent device ID is retained in the child device's nonvolatile memory. The child device retains its PAN ID and when it goes through the orphan rejoin process it essentially waits for a parent to respond to it; if it doesn't receive a response within a certain interval it looks for a new one.
Yes; while they take special care to set up initially, they've been remarkably stable; I do use @markus 's Zigbee drivers. Without a mesh mapper it can be tricky to verify that they've attached to the intended parent, since they'll work perfectly well for an hour or so even with an incompatible one, then get orphaned and fail to rejoin. If you keep them literally inches away from the device you want them to join, though, inevitably they'll choose the one you expect.
I've wondered exactly how this scenario is handled and found a good explanation here: TI Z-stack Overview (this is documentation for TI's Zigbee stack but is pertinent to Silicon Labs Ember as well; it's also one of the easiest to read and most concise descriptions of Zigbee routing I've seen yet):
"
Parent device ‘A’ has a child device ‘c’.
Parent device ‘A’ is power cycled.
Child device ‘c’ finds parent device ‘B’ and joins it.
When parent device ‘A’ restores its network parameters, it starts a timer to send parent annce (of 10 seconds plus random jitter of up to 10 seconds.)
After the timeout, parent device ‘A’ broadcasts parent annce containing IEEE address of child ‘c’.
Parent device ‘B’ finds a match with its children and responds with a parent annce response containing the IEEE address of child ‘c’.
Parent device ‘A’ removes child ‘c’ from its table "
