Replace hubitat-ip with the IP address of your Hubitat hub.
Put them on Channel 1 or 6. And leave your Hubitat on zigbee Channel 20.
Thank you for that.
Okay so several things become apparent. First off, the first outlet you added is definitely a repeater, so all the other outlets will also work as repeaters, when they are added back. However, the inCost and outCost of that outlet are kind of high. I am hoping that once you complete your mesh, both those numbers are closer to 1 for all your outlets.
Second, it looks like you may have added all the leak sensors before you added the outlets. So when we are done re-pairing the outlets and are convinced the mesh is stable, we will re-pair your leak sensors.
1 Like
Okay, it looks like I have some work to do!
I’ll re-pair them as you instructed and let you know.
Thanks
1 Like
When I re-pair them, and It says “found one previously joined device” and then its name.
Do I click on the name?
Sure. That will take you to the device page
I can’t seem to pair any devices now. In the messages icon, top right, it says my Zigbee network is offline.. I didn’t turn it off. This is warranty hub I just received today.
I also can’t change the channel, it keeps reverting back to 11.
- Make sure all your apps are still disabled.
- Shut your hub down from the Settings menu.
- Remove power (unplug it from the wall, not the microUSB end)
- Wait a couple minutes.
- Power up the hub.
It still says offline.
Attached is a screenshot of the Zigbee mesh after re-pairing the outlets.
I also received confirmation on the outlets later today, they said:
Hi,
I just received my new hub today as a warranty and I set it up but can’t add devices because it says Zigbee network offline.
Did you try doing a shutdown, and pull the power cord at the wall for a minute or so before powering up?
1 Like
Yes
Hi there, I checked your new hub and your ZigBee controller appears to be working as expected. If you see a message in the upper right corner stating that Zigbee is offline, do you mind sending me a private message or share a screenshot of your hub's interface?
Have consolidated 2 of your threads into one.
That page gives you a good picture of what repeaters are good enough (RF wise) to be used for routing on the first hop to the rest of the mesh. You want to see one or more repeaters with strong bidirectional links to the hub. Ideally, they will be stable so that routing paths also remain stable.
There's two ways of looking at the info here and they corroborate each other since this page reports link status as well as recently used first hop routers: repeaters with low nonzero cost figures (shown in the Neighbor Table) should be the repeaters actively being chosen for routing (shown in the Route Entry section).
It's easy to see which repeaters have been used recently from the Route Table entries, which show Outlets 11, 12, 19, 20 and 26 as the first hop 'vias' being used to send messages.
From this you'd deduce that the other repeaters aren't as active (at least in the timeframe the page was captured; if a route hasn't been used recently, a new route request is generated and route table entries may change).
The inCost/outCost figures give you a clue as to why the other repeaters aren't being used. For example, the link to Outlet 5 has a very weak signal at the hub's receiver (hub reported low LQI on this link, resulting in high inCost) and outbound at Outlet 5's receiver (Outlet 5 reported high outCost; from this we can infer that Outlet 5's LQI is low). Similar story for the unused repeaters; Zigbee's routing strategy favors low 'cost' routes so it will pick repeaters with good bidirectional reception (link costs get ranked in order of best =1, poorest=7; with 0 meaning no status/unusable).
So as of the time of that snapshot, outlets 11, 12, 19, 20 and 26 are your key repeaters. Their status gets reported roughly every 15 seconds; if conditions change (signal blockage, interference, HW failure) , the hub may change routing to use a better repeater if one is available. If there's no viable repeaters (or only ones with poor cost figures), communication issues result.
The destination devices (the nulls followed by short ID's in the Route Table section) would normally be showing their assigned name instead of null. As the short ID's change with every rejoin (and eventually get re-associated to their assigned name), it looks like many of these have been recently rejoined; probably they are the end devices that were previously child devices of the hub.... now they are child devices of the repeaters elsewhere in the mesh. The nulls should be replaced by the device's assigned name after a while if things are stable.
If you're not seeing issues with your end devices or repeaters, you don't need to worry about the repeaters showing poor cost figures; the mesh is finding a useable path in spite of them. If you are seeing issues (can't reliably send commands or see correct status on the device page) you should probably try to improve the mesh (by relocating marginal repeaters or adding an intermediate repeater somewhere in between).
If you are having issues with mesh stability (the devices in the neighbor table change significantly within a short amount of time, nulls always showing instead of device names) something else is going on... that's when you'd be looking at the environment (for interference) or possibly a flaky device.
4 Likes
Thanks Tony for this informative post.
A couple of questions:
-
What are low non-zero cost figures? And how can I get them into the Route Entry table?
-
InCost is the repeater signal back to the hub and outCost is signal back to repeater?
-
What would be the reason why some devices have a high LQI, low inCost and outCost but still in the Neighbor Table Entry?
Thanks
