I just realized how much more readable the Zigbee Route Info is when I throw it in a NotePad++ instance. I love the ability to mouse select a single device and then see how exactly how that device is performing system wide.
Seems like I read where the Route Table list does not include all devices and only includes 16 items. Why is there this 16 device entry limit?
Since I don't really understand much about what is seen in this Route Info listing, I'd love to hear what those with more knowledge glean from this screen grab that might be helpful to know about my zigbee mesh.
I just like your observation of using Notepad++, nice tip. Might be nice if the route table was more of a html page, with features like this, rather than, what I expect, is just a text dump.
Oh, in terms of your comment re 16 devices.... the neighbours are also devices.... if that makes sense..... They then provide a path for the children to communicate "back to base"
Even though HE only provides this for the coordinator, it helps to keep in mind that the categories of information shown here (child devices, neighbor devices and 'next hop' route table entries) are relevant to every Zigbee routing device (coordinator or mains-powered repeater) in the network. They all have unique children, will consider a maximum of 16 neighbors to select as the first hop for routed messages, periodically request and cache next hop destination routes, etc.
The intent isn't to list every device in the network, or provide a complete list of routes (though it does provide 'info' about the first hop of a recently requested route). Though this page only pertains to the coordinator, the Zigbee API does provide means for the same type of information to be extracted from other routers in the network. Digi's Xbee and XCTU make use of those API calls to display the full Zigbee mesh map.
So It's useful as an overview of the hub's 'first hop routing bubble' and for viewing its child devices. For diagnostic purposes, it indicates how well the coordinator is receiving transmissions from neighbor routers (via the LQI and the 'outCost' figure derived from it) and how well each of those neighbors are receiving transmissions from the hub (via the 'inCost' figure derived from the neighbor's LQI and transmitted to the hub during periodic link status exchanges). It's dynamic and gets updated constantly; though in a stable network RF-wise the neighbor table will also be stable.
The reason why there is a limit to the neighbor table is because it takes overhead (CPU cycles and memory) to manage the status exchanges and rank the viability of potential paths (based on the cost figures) for routing purposes-- for Zigbee, you really don't want or need too many repeaters. Every Zigbee router expects to hear status from a neighbor at roughly 15 second intervals; if it doesn't, it increments an 'age counter' for that link so it can tell if/when that path is no longer viable (after 6 missed intervals, an MIA neighbor can be evicted from the table and potentially replaced with a better one).
Sixteen happens to be the figure chosen by IEEE, likely based on some balance of bandwidth and hardware capability when the protocol was designed.
I believe that incost/outcost are rated 1-7, with 1 being the best which may be why only one Tradfri is listed on the route table.
You can verify from each Tradfri device page by hitting “link quality” and “get route table”. The info will be on the logs page.
That's right; also a '0' cost figure means that no link status report has been received for that link yet (or the threshold number of missed status intervals has been exceeded-- the link has gone stale).
Age counters get reset to '3' every time updated status has been received. That's why active links usually display age 3; age 6 is the stale threshold. Age counters in the 0-2 range are used when new links are being established.
Great info guys. Help me understand with an LQI of 255 how can the hub have trouble hearing (outcost 0). I know the info is last hop but the thermostat is direct to the hub
[Thermostat Sinope 60E7(3.18.22), 60E7], LQI:255, age:3, inCost:1, outCost:0
I can't explain why it is happening, but that scenario (LQI 255, outCost 0) actually means the hub can indeed hear the thermostat, but it isn't getting an acknowledgement from the thermostat that it (the hub) is being heard.
LQI doesn't determine how good a bidirectional link is (LQI is only a measure of 'hearing', not a measure of 'being heard'. It's part of the overall picture-- LQI gets mapped into an 'inCost' figure and that is used as the measure of reception quality (how well packets inbound to the hub will be received). You also need a measure of the other end of the link's reception quality (the 'outCost') to know how good the link is. That's derived from the remote receiver's LQI, mapped into a number ranging from 1 (best) to 7, and transmitted to the hub during the link status interval. If nothing is heard during a link status interval, an outCost of 0 is assumed (meaning: no status was provided).
Zigbee routing wants to prioritize links that are good in both directions along a route; so as the overall metric of goodness it chooses the lowest cost path (from the summed in- and out- cost figures for each segment along a multi-hop route).
So a hub with a neighbor table entry showing LQI 255 and outCost=0 is kind of like someone with excellent hearing trying to engage in a conversation with someone with poor hearing (or perhaps like someone whispering to someone speaking at normal volume). One person (the hub) is saying 'Yes, I am here, can you hear me' while the other person (the thermostat) keeps saying 'Hello I am here, is anyone there'.
@Tony thanks for that good hearing, hard of hearing visual. That helps.
Pretend you had been in charge of those names, inCost and outCost. Would you have used those names to describe those values or maybe something better descriptive?
1=best and 7 being not so good seems backwards in a world that says more is better. Bo Derek after all was a 10.
It seems like names and values make understanding this harder than need be. Going with your good bad hearing analogy, I play the role of the person always saying "huh, what did you say" so maybe that's why understanding this zigbee routing and quality seems hard to me.
Agreed, I'd probably go for something more intuitive. I can see where lower numbers make sense if 'lowest cost' is meant to be analogous to 'most efficient' routing; but the term LQI is a bit misleading. It's too easy for end users to assme that seeing 255 means that everything's great, reception-wise. Maybe ILQI (for inbound LQI) would have made it clearer that it pertains to inbound reception only. Hey nobody asked me..
No doubt most of the nomenclature was developed by a host of sublayer specification working groups (we have IEEE to thank for the Zigbee standard). In a former job I interacted with my company's reps on standards committees; the analogy of the camel being a horse designed by committee comes to mind. Yet no matter how tortured Zigbee's development must have been, it's functionality stands up pretty well, especially compared to Z-Wave (Zensys' proprietary- turned open- standard) which has been pretty much a moving target (feature-wise) since its inception.
