A zigbee routing question


Here are the items I got to make an enclosure around my Xbees.
Box gets attached to the charger with some velcro





Help a neophyte - what happens if there are too many repeaters in a z-wave network?



Zwave only supports 4 hops. You can't endlessly extend the range


Does z-wave not include algorithms to determine the shortest path?


Typically a z-wave repair will attempt to deal with the 4 hop max, but no it is not smart and doesn't handle this well or warn you. One of the many issues I have with Z-Wave... But that's for another day...


It is a bit more complicated. The controller usually knows all possible paths to an end device. It uses it in case one path becomes nonoperational.

Here is a nice article that scratches on the surface of how that works


Does anyone know how long devices remain in the Zigbee routing table because my table is still showing a Lightify lamp that I removed from my HE hub 4 weeks ago !!
Nothing is routing through it but it still shows in the Neighbor Table


The entry looks like what would be expected for a neighbor which has stopped communicating: the outcost has been set to zero ( 0 = 'unknown') since there has been no recent link status message update from the Lightify-- and the age field got to 7 which is the trigger to set outcost to 0 (6 16-second intervals elapsed with no link status received). My guess is that the entry will probably persist until it gets overwritten (probably if the table space needed to reclaimed). It shouldn't affect routing because the zero outcost should flag it as not usable.


Cheers @Tony, Thx for the explanation.
I thought it'd just drop out of the table so I was surprised to see it persisting.
It's not causing any issues so I'll just ignore it, now.


I suspect it is left in the table to minimize overhead of managing the routing table space if there is no need to do so. It's probably assumed that there is a fair chance that the device may 'come back' and if it starts sending link status messages again it is trivial to update the existing entry rather than allocate a new one.

On the other hand, to account for very large numbers of in-range routers where the space could be potentially filled, if an entry's age is 3 or greater it is flagged as stale and is eligible to be overwritten to make space for a new one. I've heard it said that "you can't have too many routers in a Zigbee network" but I suspect that isn't literally true, or it requires special care in provisioning (especially in the light of SRWhite's experience with his setup of 40 Iris plugs which resulted in updates to HE's Zigbee stack).

If there are an excessive number of routers in range of each other the amount of link status traffic that each has to deal with ( a status message every 16 seconds, for each router) starts to become a significant suck of resources. In commercial lighting installations (a common Zigbee industrial application) with several hundred 'always on' nodes that potentially hear each other I have read that special accommodations are required to deal with this issue.


off topic, whatever happened to SRwhite? did he end up staying on HE or moving to a different platform?


@Tony - I'm curious about where you've found documentation on this routing table report information. The only Hubitat reference I find is a page explaining last hop LQI/RSSI with a short mention of the getChildAndRouteInfo URL, but nothing about age, inCost, or outCost. And Google-search-wise, there are EmberZNet API references to routing table report information, but it's not clear that applies 100% to the Hubitat's report feature.


The EmberZNet documentation is all out there for the viewing. The one you might be most interested in is the serial protocol document.

This is a good start:


As JasonJoel says, it's all out there. Docs.silabs.com is where I started; it's my assumption that it is relevant to HE but so far it seems like a reasonable one. All the certified stacks have to interoperate so the concepts must be applicable. TI and NXP have similar resources online; Silicon Labs seems to be the most ubiquitous so I usually turn to their documentation first. They also have an active user community where many of the same questions that come up here from time to time are discussed and answered.

Many of the strings found in the HE report also match up neatly with those in SI Labs documentation.

Edit: The Ezsp string in the report ("EzspGetParentChildParametersResponse") is a 'tell' also that the report info is coming from an Siicon Labs stack.


It's definitely applicable to the c-4 bub, as that is the chip the nortek USB dongle uses.

Based on that I ASSUME the c-5 hub also uses a chip in that series of chips as well.


Ditto for my trusty C3.