Up to 32 devices can be paired directly to the zigbee coordinator. One possibility is that Wink treated Lightify devices as non-repeating zigbee end-devices.
1 Like
Just saw your post today; FWIW here's my two cents based on my mental model of how this stuff works:
So if a device appears in the Neighbor table, by definition it is a router and it is reachable from the hub as a single-hop routed destination. Packets outbound from the hub will be sent directly to it without going through any intervening router, as long as it maintains it status as a neighbor. But with the Zigbee 2007 and Pro stacks, routes can be asymmetrical, so it is possible that in the reverse direction the device may not transmit to the hub in a single hop (each routing device maintains its own next-hop neighbor table and link status).
Also, the table is dynamic and maintaining neighbor status depends on metrics in the periodic link status exchanges between hubs/routers (the LQI and link inCosts provided to the hub by the neighbor and outCost computed by the hub). This doesn't mean that the neighbors will always change; if the environment is stable the only changes in the neighbor table you would see would be the age figures which periodically increment (or get reset) as the status reporting intervals elapse. But the hub can only consider a max of 16 routers as neighbors and always evaulates their status; if the table is full and there are routers in a one-hop radius with better link metrics (or if a neighbor entry is considered 'stale' by virtue of the hub not receiving timely link status updates) a router in this table can be evicted in favor of a 'better' neighbor. So if network conditions change this device could conceivably pop in and out of neighbor status (in which case the hub would transmit to it through a different next-hop router (and that router would either see this device as its neighbor, or as a device in one of its Route Table entries).
Regarding the 'where are all the other devices in my network' question, the ChildandRoute info is not a static picture of the mesh routing and all reachable devices; think of it as a 'one hop radius bubble' that is a snapshot in time of where the hub has directed a recent message destined for a router or end device appearing in a Route Table Entry. If you keep refreshing the ChildAndRouteInfo page, at some point every device that is communicating with your hub would appear in a route table entry (along with the neighbor router that the hub used to communicate with it). There is routing information maintained by the hub that is not visible on this page (and none of the routing info used by other repeaters in your network is displayed here).
But it is informative... you can get a fair idea of what your mesh map looks like (at least for a viable 1-hop radius from the hub) and by examining the 'next hop' destinations for devices that happen to appear in the Route Table entries, you can get a sense for how things map out a bit further into your network. Also, from how dynamic the neighbor table is you can get a pretty good indication of the RF environment around the hub.
3 Likes
@aaiyar. Thanks. I’m going to play around removing the ikea repeaters and work on decrypting the routing data before migrating to the 2nd hub.
Before that, try rebuilding the mesh once (especially because you added the Ikea repeaters after the bulbs). For this, turn off the zigbee radio for ~20 minutes and then back on again.
1 Like
@aaiyar actually the first devices I added were the repeaters then I migrated devices one by one moving outwards from the hub. A rebuild may help as well.
1 Like
How much of a concern is it if this route changes rapidly for any device (lets say 4-5 times within 2 minutes)? I've just seen that with some Peanut plugs:
I don't really know; I have a pretty benign environment RF-wise with very little traffic on 2.4Ghz (aside from my own wifi and a rogue Zigbee network set up by my Echo Show that I can't do anything about). My neighbor table never seems to change. My Zigbee routing devices are primarily Iris V2 plugs (with a lone Sylvania and GE in the mix). I'd say my Zigbee network has been very stable with these.
Just remembered I also have a few (4 or 6?) Cree and Osram Lightify's in the mix; none of them have caused any issues (they don't appear as neighbor routers in my Hub's table; that is probably why).
1 Like
I don't believe this is a problem. I have 8 other zigbee repeaters and a 30 other zigbee devices. And I believe the Iris plugs, which are all 9, can handle up to 8 devices each.
2 Likes
Taking another look at the post you linked, I realize I might have missed the point of your question. I was referring to the stability of the Neighbor Table slots in my network, not the route table entries. I would expect those to be a lot more dynamic.
1 Like
Thanks, I was referring to the route entries. For most of my devices, they are also fairly stable (haven't changed a few hours at least). For a subset of devices (Securifi Peanut plugs), they change every time I reload getChildAndRouteInfo .....
I think it’s only 16 on Hubitat which is why no more than 16 neighbors are showing in the report.
1 Like
There is no guarantee as to which route a message is going to take.
Also, despite what might sound like common sense, a higher LQI isn’t necessarily a determining factor in whether a device is or should be the next hop router. Remember, one of the the primary goals of mesh networking is maximizing contour (coverage area). This can mean that devices further from the hub are promoted to first hop routers even when closer neighbors with better LQI exist.
The child device limit of the hub was upped to 32 shortly after it came out, as I recall. The neighbor table limit is indeed 16. Found the link: Limits?
Btw, this doesn't mean that only 16 routers can join directly to the hub, just that 16 are used for routing.... so a 17th repeater not in the neighbor table, but in single-hop radio range of the hub would still be a two-hop destination.
1 Like
I am suspect of that...
When you run the /hub/zigbee/getChildAndRouteInfo it shows only 16 entries in the routing table, and those are all end-devices.. In theory, there should be 32 entries in that table, but then again, I'm basing this strictly on that report. I've never seen more than 2-3 child devices under Child Data either. Who knows.
That is the neighbor table, not child table AFAIK. Only routers can appear there. Or am I missing something? I actually always have 0 entries in my child table (the nearby routers are much more adept at snatching them during device joins).
This screenshot should clarify the issue, I think.
1 Child Device (end device - its a sensor)
16 routing devices in Neighbor table
2 Likes
All the devices in your neighbor table are routers, correct? Edit: Never mind, I just read your post again where you confirmed this.
1 Like
I think this should help bring clarity to this conversation...
The hub uses the EmberZNet zigbee stack, a detail I learned around this time last year when I was testing some of the Zigbee improvements.
That platform has some in-built limitations which are called out in their official documentation.
Neighbor Table Size:
page 5, EZSP_CONFIG_NEIGHBOR_TABLE_SIZE, max 16, min 8 : The maximum number of router neighbors the stack can keep track of. A neighbor is a node within radio range.
We know that Hubitat is set to 16 because we see 16 entries in the ChildAndRoute table.
Child Device Table Size:
page 5, EZSP_CONFIG_MAX_END_DEVICE_CHILDREN min 0, max 32 : The maximum number of end device children that a router will support.
Hubitat is in fact set to 32 so disregard my previous post.. However unlike the ChildAndRoute table, unused entries are simply not printed out.
If anyone wants to read up on these, in the link above...
- "Child Data" table id on page 18: EmberChildData
- "Neighbor" table is defined on page 15: EmberNeighborTableEntry
- "Route" table is defined on page 15-16: EmberRouteTableEntry
4 Likes
I don't even try to understand how these devices choose their routes. I mapped it out with my xbee and I have devices in the basement that connect through a router upstairs just to get back to the basement hub.
As long as it works I don't think about it too much.
1 Like
