Non-repeating battery-powered devices must always have a parent to talk to, either Hubitat Elevation or mains powered repeating devices. When the device first joins the network, it will choose a parent that provides the strongest Zigbee signal. Once a device chooses its parent, it will hold on until it absolutely cannot communicate with it, even if a different parent with a stronger signal is introduced into the network. Only when the device can no longer effectively communicate with its original parent device, will it then select a new parent. However, if the device can still occasionally communicate with the hub, it will not select a new parent repeater..
For ZigBee devices, communication must worsen before it will automatically heal. Devices must completely lose communication with their parent before they will seek a new one. To put this process in motion, you simply shut down the hub for 20 minutes. When Hubitat Elevation boots, routers and the end devices will re-establish an optimal path for communication with each another. Allow up to 24 hours for this process complete.
Blockquote
But I have a situation where I have two SONOFF Zigbee relays (downstairs), one 1 meter apart from the other and one of them connects to another SONOFF(upstairs) switch to reach HE(upstairs). The other one, which I am having issues instead of connecting on the Switch besides it, it tries to connect to another switch and the route stays in Discovery, some times works, sometimes not.
Is there a way to force it to pass throwgh the one besides it instead of trying to go directly to that router which is giving issues? If I force it to pair again, it would take another route? Or do I need to delete it from the HE.
First, you don't delete it from HE... just put HE into pairing and then do a factory reset on the nuisance device. (Or Factory reset the device if it's a drawn out process; put HE into pairing; then pair the device.)
Second, the device will drop right into its old HE "slot" so you won't have to redo Rules, etc.
Third, leaving the device off and factory reset for a few minutes will help insure that its expired from the current devices in the path. Remember, Zigbee devices have hard coded node numbers and that's the reason it can drop right back into its previous 'slot'. Ideally you'd like the surrounding devices to not recognize it when it re-pairs.
perfect, so the information regarding the path stays saved only on the device. Understood.
and regarding the path itself, how do I force it to move away from that path I dont want it to follow?
the common term is "panic mode" -- where the devices can't find their way back and begin a furious search for neighbors, etc. thus rebuilding the route. There's no mechanism for you to be able to force the route and even if you could, you couldn't count on it sticking.
So the better way would be to factory reset and without deleting from HE put in pairing mode again for it to joing. Would be this a good procedure by the time I add another repeater that is more near that device than the one before? Like a room with sensors and then I add a repeater on that room so instead of the sensors going after a repeater in another room and crossing some walls they would access directly the repeater on the same room.
Best Practice is to work outward in concentric rings (or spherical). And Yes to adding repeating devices before battery / non repeating devices.
A "bigger hammer" approach is to power off the Hubitat Hub for 5 mins or more which puts ALL your Zigbee devices into Panic and the entire routing is rebuilt. But be prepared for it to take more than a few hours to completely stabilize.
I haven't done that in a year or more... mostly because I hate powering down the hubs. But when I was first installing some Hampton Bay Fan Controllers, (they need to have repeaters in the same room, and in some cases, two) I did the full Panic mode experiment at least twice. I benefitted from it... but that's mostly because those Hampton Bay devices are so "delicate." They have been operating perfectly ever since and that makes me even less interested in powering down the one hub I have (of 5) with Zigbee enabled.
This is a Zigbee topic and Zigbee at 2.4ghz is more susceptible to attenuation by walls, floors, appliances, furniture, humans and animals, Pretty much anything.
I have 5 hubs so I'm the WRONG person to be asking about multiple hubs... Clearly I'm in favor..
Hubitat is great because we can rather easily create a System from multiple hubs using Hub Mesh, or my favorite (still ) HubConnect. I have a hard time coming up with downsides beyond the obvious cost. But even then, so many of us have thousands spent on devices that another $150 is almost a drop in the bucket.
But I don't think it's necessary. You'll buy more repeaters and at $25 each (estimate) it's not long before another hub sounds sweeter.
The 146 LQI shown for the F3B7 device in the neighbor table is what the hub sees as inbound signal quality of the direct (single hop) radio link, directly from that device; that LQI gets used to compute a 'cost' for that segment of the path in order to rank it as part of a direct or multi-hop route involving F3B7.
But since the hub has other routing neighbors, it doesn't have to talk to F3B7 directly if there is a better (lower 'cost') way... the hub can use a multi-hop route through one of the neighbors that has a stronger link to F3B7. If so, that other device's LQI/RSSI is the one shown in the Zigbee logging page as the 'last hop' of the route from F3B7-- hence the 255 LQI's you are seeing.
Since F3B7 is a router, it also tracks its own 16 best router neighbors and likely has a better link to one of them than to the hub itself. Though its direct link to the hub is marginal (low LQI, high inCost and outCost) and it probably isn't being used to route messages, it still appears in the hub's neighbor table because there are 16 neighbor slots available and there may not be any other better routers in range of the hub to take its place.
Bottom line,146 is the number that matters if you want to improve that device's direct link to the hub; practically speaking you can only do that by relocating the device or eliminating whatever is interfering with the signal between it and the hub. But a repeater would be alternative fix, and you already appear to have a repeater that's helping out: the Zigbee logs you posted are showing a LQI 255 on the last hop to the hub. There could still be a marginal link from F3B7 to this first hop repeater. Unfortunatley you don't have enough info to tell how strong the signal is between F3B7 and whatever first hop repeater it is using (you'd probably need an XCTU mesh map or Zigbee sniffer trace to see that level of detail).
Pretty much anything.
Clearly I'm in favor.. 
