Hello all
New to HE and starting to get the grasp of it.
I have been reading around about the getChildAndRouteInfo page, I know it's not the most accurate, but wanted to know some more details if the more experienced can help.
So i have around 3 dimmers that show up in the route table, but are not available in the child or neighbor table. I assume they are routers as they are connected directly to the wall and use a neutral wire, but how can I confirm?
I have a bunch of switches routing through the "Repeater guest room" instead of repeating off of each other. Anyway I can check their exact route? (Almost impossible for one of the devices to actually be connected directly to the "Repeater guest room" so I'm assuming it's actually connecting through the other dimmers but the getChildAndRouteInfo only shows the last bounce to the router via "Repeater guest room".
I have one of the dimmers becoming irresponsive when the dimmer between it and the repeater is turned off. Could it be that when the dimmer is turned off it stops routing?
Regarding your first question, there isn't enough info in the getChildAndRouteInfo page to definitively say that your dimmers are routers but you can probably take for granted that they are. Non-routing 'always on' Zigbee devices, aside from Sengled, are pretty much unheard of. What brand are they? Maybe someone has experience with them. If you want to experiment (and you can turn off other known routers without losing connectivity to the dimmer), you could try resetting one of your sensors and try joining it in close proximity to the dimmer. If it joins and doesn't show up in the ChildandRouteInfo page, it is a child of the dimmer, so the dimmer must be a router.
The fact that a device (router or non-router) doesn't appear in either the Child Data or Neighbor Table means one of these things (none of which are indicative of a problem):
it doesn't have a good enough RF link to reach the hub in a single hop and must send routed messages (or in the case of an end device, it has chosen another nearby router as its parent in preference to the hub)
or, (for a routing device):
the Neighbor Table entries are already full of routers which the hub has determined have better quality RF links. These are the only devices the hub will use as the 'first hop' to send routed messages, and the table will only accomodate a max of 16 (periodically evaluated by the hub, and potentially 'evicted' in favor of a better neighbor). Your Neighbor Table isn't full, so likely the routing dimmer doesn't have a strong enough RF link to the hub to be considered a neighbor.
For the second question, there's no way to see complete multi-hop routes from this info; think of this page as showing you the status of a one-hop bubble surrounding your hub. The Route Table entries you see are cached results of route requests sent by the hub so it can determine which router is the first hop destination in the path to a given device. So as you surmised, 'via Repeater guest room' means that the 'Repeater guest room' is the merely the first router in the multi-hop path to the destination switch, not that there is a direct RF link between those two devices.
Regarding your last question; the on/off state of a routing dimmer's load shouldn't affect its routing capability. Don't know what to make of that; have you tried swapping the two dimmers?
Hi Tony
Thanks for taking the time in answering all my questions. Appreciate it.
I do believe the dimmers are routers as you stated. I test joined one right next to the hub and it appeared in the neighbor table. I just wasn't sure what to make of it that they were not appearing on the neighbor table, so thanks for clearing that up.
In all honesty it seems like the dimmers switches, power outlets etc. are not the greatest routers, maybe that's why some devices are falling off. Gonna give it a couple of days see if the mesh gets better.
In the area where I have the repeater everything is working great so might just get me a couple more and just spread them around.
Also have a look at the LQI (Link Quality Indicator) number under you Neighbor Table Entry. You want all these LQI numbers to be as close to 255 as possible.You can try moving these around to find a better location (just remember these can take a while to settle). What you may need to do is add more "repeaters" between these with low LQI and the HE.
Thanks for that note.
In some instances there are better routes through a repeater but the device goes directly to the hub with a relatively low LQI. Anyway I can "force" the device to take the better route through the repeater?
Are you sure the LQI is accurate? I have 2 switches that are probably less than 1m apart on the same wall. One has a 254 LQI and the other LQI of 1.
Both working fine.
That is always the question on how accurate these are, what I understand is the lower the LQI, then the devices look for a better path if they can. also if you look at the age, the lower the number means something is routing through it, so if you see a 7 it means nothing has gone through it for a long time. Also the incost is the "difficulty" rating for lack of a better description, so the lower the inCost the more the end devices will try and use this repeater.
From your list I would say that Adam room dimmer and Entrance spot light and Master bedroom outlet are not doing much in that setup. It looks like the Repeater Guest room and the MAin door outside light are doing the repeating.
Sorry not an expert at all, just have been reading and working through my setup. YMMV
I would agree with your analysis of @a.taylor setup. I too am nowhere near an expert on this, but what you point out is also my understanding of this table.
Thank you both! really useful information.
Would it be safe to assume the outCost is the "difficulty" to transfer info from hub to other devices? Also the lower the better?
I think it works in the same way, lower the number the better, In my setup you will see the Main Bedroom has an outCost of 3 and this almost shows no devices routing through this device.
Both the hub and any given Zigbee neighbor router constantly keep track of the link quality and exchange information about it, roughly every 15 seconds during a status exchange message (the age number shown in each neighbor table entry is the elapsed number of intervals since the last status exchange was received by the hub; you can see this age counter increment by refreshing the page).
For a link to be viable, it needs to be symmetrical-- strong both from the hub's point of view (how well it hears the neighbor) and from the neighbor's point of view (it needs to be able to hear the hub). The LQI number shown in each table entry is a figure of merit (ideally derived from RSSI and link errors/retries, but in practice the value reported is left up to the implementation) based only on how well the hub is hearing the neighbor. But it doesn't indicate how well that neighbor hears the hub.
Routing preferences aren't based on LQI, but are determined by the summation of 'costs' for each hop on outgoing and incoming paths. For the incoming path to the hub, the LQI number gets mapped by the hub to a value which becomes the 'inCost'. It transmits this figure to the neighbor in the link status exchange. Meanwhile the neighbor router also computes its own LQI, generates the cost it perceives on the link inbound to it, and transmits that figure to the hub during a link status exchange. The hub shows this figure as the 'outCost' in each neighbor table entry.
Lower cost numbers indicate better quality links, except for zero, which indicates no valid link quality information was received (or too many intervals have elapsed since the last link exchange).
Normally an age value of 7 means that the link exchanges have timed out, so the link isn't viable for routing. That's why age 7 usually coincides with outCost=0, indicating a link that isn't usable. Note that it doesn't mean that the neighbor can no longer communicate with the hub; just that it won't be useful as a repeater for messages from the hub (and it may be using other repeaters when it needs to communicate with the hub)
If you want to try to get your Zigbee devices to do different routing you could put them in "panic mode" and they will all re-route. They may end up w/the same routes, could choose different routes, can't predict. If you really want to keep your devices from using certain devices to route you'd have to remove power from those devices.
To get your Zigbee devices into panic mode so they'll re-do their routing, turn off your hub (full power shut down) for 20 minutes, then restart.
But if things are working, probably not necessary.
Thanks for the info.
I went ahead and got a couple of repeaters but still facing the issue where a repeater will connect to another repeater for a couple of hours, great! then all of a sudden changes and connects directly to the HE hub and ends up with a LQI of 60 or so. All devices on that repeater then end up having connectivity issues
@bcopeland may have some ideas...generally options are to add more repeaters, move repeaters to different locations, or change to different repeaters. (Or maybe all three.)
Can't remember - what Zigbee repeaters are you using?
A couple favorites around here are:
Iris 3210L plugs - getting hard to find
Centralite plugs - available on Amazon for about $17
To be honest don't think I can add more repeaters. If they all connect to each other will have a very solid mesh. I have about 6 on two floors each about 3-4 meters apart.
I'm using the IKEA repeaters.
I'm not familiar w/those, but that does seem like a good amount. What construction is your house? Wallboard or plaster/lathe? (Or metal Farady cage walls? )
I would try this and see if it helps. Do a clean shutdown using the settings menu. Unplug the hub for 30 minutes. Boot the hub, and give things a couple hours to settle out.
Post your updated child & route screenshot. when done.
)
