Zigbee instability

I've been having persistent zigbee stability issues for weeks. What happens is that some of the routing outlets (Centralite) become unresponsive and have to be power cycled to clear up. Rinse, repeat.

The controller is a C-5 running 2.2.1.113.
There are 7 routing nodes: 4 x Centralite mini 4200-C outlets, 2 x GE ZB4101 (lamp module), 1 x xbee.
The end nodes are mostly Iris or Samsung sensors, an Axis gear, and a couple of the Iris/Orbit hose controllers.
The HE zigbee network is on channel 15.
All bulbs are on a Hue bridge (channel 11)
There are 5 Unifi AP's spread across the property using wifi channels 1, 6, 11.

What typically happens is that all of the Centralite outlets will lock up, at about the same time, and much of the mesh grinds to a halt. If I open XCTU, those nodes show red and LQI is ?. I can power cycle the outlets, and things may become stable for a while. Factory resetting and rejoining the outlets helps too but it doesn't last. I shut the hub down for 1/2 hour this last weekend, to force a heal, but I don't see much improvement.

During this process, the other routers (xbee and the 2 GE outlets) function as normal. I'm trying to understand why something would be affecting only the centralite outlets and what that "something" is. The centralite outlets are using the generic zigbee outlet driver.

I'm just learning to use XCTU, but one thing that sticks out (if I'm interpreting this correctly) is the disparity in the LQI for a link from the hub to a centralite outlet (255) vs the opposite direction (65).

image

If any of you can help me with some steps to troubleshoot and resolve this, that would be appreciated.

If your home is very large or has lots of RF obstructions, it's possible you may have one or two routers that are critical for accessing the repeaters in the rest of your network. If their link quality is poor and you lose connectivity to them, the rest of your network also becomes inaccessible.

Try looking at this page
{Hub IP}/hub/zigbee/getChildAndRouteInfo. It will show information about the link quality to the routers that are nominally within a one hop radius from the hub (the neighbor table). Don't confuse it with a routing table, though you can get information about how your devices will choose their first hop to the rest of your network.

Unlike XCTU, on this page there is only one LQI figure shown for each neighbor link (XCTU is showing you two different LQI's due to the asymmetrical nature of RF links-- the hub may be able to hear its neighbor better or worse than the neighbor can hear the hub. A route needs to be chosen which is viable in both directions, signal quality wise). But the LQI in both directions can be inferred by the inCost and outCost numbers shown on this page-- the LQI that the hub calculates is mapped to the inCost figure shown; the LQI computed by the neighbor (based on how well it is hearing the hub) is map to the outCost figure for that link (the outCost is transmitted from each neighbor router to the hub periodically).

By looking at the link cost figures you can determine if a route through a given neighbor router is viable-- lower-cost numbers indicate low error rate links. But if 0 is shown, that's an indication that no cost figure has yet been provided by that neighbor. The table is constantly updated as periodic link status updates occur roughly every 15 seconds. You can refresh the page and see this happen. The age figure in the neighbor table indicates how many intervals have elapsed between a neighbor status update (it can flag a stale link, one that is not providing status and which will not be used for routing). Ages 0-2 are typically seen when the link is establishing with the hub. 7 means the link is stale; usually you will see it count up from 3 to 5 and then start again at 3.

You should see at least one or two stable neighbor routers, showing in cost and out cost in the 1-5 range for a decent link. If not, you'll need to find out what is attenuating or interfering with them.

2 Likes

Changing the Hue Channel to 25 help any?

1 Like

I only have 9-10 plugged in zigbee devices right now and I have been having persistent issues with my Halton bay fan controllers. I knew these were sensitive when I bought them so I am not complaining

I originally switched from channel 20 to 15 - my 2.4g wifi is on channel 9.

Just last night I flipped to channel 25 on the zigbee. So good so far.

1 Like

@tony that's a great explanation for incost and outcost, and now I can see how it reflects the LQI for links between the routing nodes. I added some more information to the Neighbor Table entriesd from getchildandroute:

Neighbor Table Entry
[Master Fan, 0FA1], LQI:254, age:4, inCost:1, outCost:3 <-- routing 0 devices; 10 ft from hub with clear line of sight
[Garage Window Fan, 4589], LQI:219, age:4, inCost:5, outCost:7 <-- routing 1 device; detached building 45 ft from hub
[Xbee, 57A7], LQI:255, age:4, inCost:1, outCost:1 <-- routing 4 devices, sits beside hub
[Foyer Purifier, 5CD4], LQI:254, age:4, inCost:1, outCost:1 <-- routing 0 devices; 12 ft from hub through 1 interior wall
[Living Room Purifier, 6D5C], LQI:254, age:3, inCost:1, outCost:7 <-- routing 4 devices; 40 ft from hub thru 2-3 interior walls
[Basement Table Lamp, 7E9A], LQI:254, age:4, inCost:1, outCost:7 <-- routing 11 devices; 18 ft from hub thru 1 floor

The last two entries are centralite outlets that route most of the end devices. I'm trying to understand what would cause such a big difference in the incost/outcost for these nodes. 7E9A, for example, has hub->outlet LQI of 255 but outlet->hub of 77. What would cause the same route but in a reverse direction to be substantially worse? Is that most likely a sign of RF interference, weak radio transmitter on the outlet, a physical obstacle or something else? Maybe the answer is E, "All of the Above". I'm open to moving around routing nodes, changing channels, etc. but I need to get closer to understanding the true problem(s) first.

Also, I don't understand why 0FA1 and 5CD4 (both GE ZB4101 lamp modules) are routing zero nodes, despite the better LQI's and being closer to some of the end nodes. I bought them specifically to act as routers but it appears they're doing nothing.

Thanks for all the good information!

1 Like

@SmartHomePrimer, @steve.maddigan I've tried channel 20 before but didn't stick with it, 15 gave better results (but that's been a few months ago). I thought I read that 25 had reduced power? Or there was some other issue with using it, don't recall exactly.

I’m not sure about reduce power. I have read that some devices may have issues with the higher channels but I don’t know if this has any merit behind it. I figured what do I have to loose with trying.

My neighbours seem to using the lower 2.4 wifi channels so I thought I would see what happens.

It’s been 36 hours and both of my fan controllers are still online. So good so far.

Channel 26 is a lower power Zigbee channel. This is to comply with FCC regulations. There are devices which do not work well, or at all, with channel 26. 25 is usually fine. Certain devices, eg (most/all?) Konke Zigbee devices, can only operate on channels 15, 20 and 25. This is not the norm, it is an exception. Most Zigbee devices should be fine on any channel from 11 to 25. 26 is not normally a channel I would recommend since even if it would be supported by all your devices (which it very well might not be), they would then be limited in transmit power.

EDIT: After having continued the talk on this subject further down in this thread and a related thread, it is clear that since most chips NEVER transmit at maximum allowed power (they were not designed for that), even though 26 (and 25) are lower power channels, that is not truly going to affect performance in most cases.

3 Likes

Agreed.

Just want to add that in addition to devices like Konke sensors, the other reason to consider using zigbee channels 15, 20, and 25 is to minimize interference from 2.4 GHz WiFi.

Edit: assuming people stick to 20MHz channel width for WiFi.

1 Like

Yes, if the 2.4G WiFi channels used are 1, 6 and 11 (which most commercial routers use by default). Outside of the US Channels 12 and 13 are also in use (and would interfere with channel 25). There is nothing stopping a neighbor/you from using a WiFi channel that interferes with any of the Zigbee Channels, including 15, 20 and 25. Doing a site survey would be one way to know with better certainty which channel to choose.

EDIT: This illustration has been shown here in the community a few times:

This one is not as pretty, but illustrates everything in a more complete way:
zigbee_wifi_overlap_additional

1 Like

Since you have mapped our mesh that gives you a good idea of the child/parent split between the routers and end devices. It's not great for determining the actual source routed path, however-- that's when a sniffer trace is needed. The ChildAndRoute info page is really only good for showing the eligible 'first hop' routers in a multi-hop route, but not the route itself or the current routes to all end devices . So I assume that you are seeing no 'via' for these GE devices in the 'Route Table Entry' listing.

That doesn't mean they are not routing for your network. That listing is really just a cache of the output from recent route request/discovery broadcasts; meaning that no route to a given end device was found in the hub's Zigbee routing tables (not shown on this page). Your Zigbee lamp modules (as viable neighbor routers) may still be first-hop routers for other destination paths (but again, not shown on this page). I posted this link a while back in another thread; it's an overview of the multi-layered strategy used for routing and emphasizes the point about why the childandRouteInfo page can't be used by itself to provide complete routing details: https://www.silabs.com/content/usergenerated/asi/cloud/content/siliconlabs/en/community/wireless/zigbee-and-thread/knowledge-base/jcr:content/content/primary/blog/what_logic_does_the-cIRv.social.0.10.html

Are they also parents of zero end devices? That would indeed be unexpected, at least if there were potential end devices that could form good quality links to them.

1 Like

I meant to move Hue to channel 25, not HE in order to give more separation. There's for sure reasons not to put HE on 25 as have been explained very well here.

2 Likes

I’ll apologize first because I don’t mean to hijack the thread, but if I only have three ST outlets, four Sonoff Basic ZBR3 Zigbee Switch, and two Hampton bay fan controllers, plus a dozen battery powered ST sensors, is there any reason I should not have my HE on channel 25? I do have three TRÅDFRI signal repeaters on order but they are not here yet.

I reread this thread and did a quick search as well but didn’t find any comments saying to keep HE off channel 25.

I am kinda new to zigbee. Most of my stuff is zwave.

With those devices, there is no reason to keep off channel 25. One thing to note, the Sonoff Basic ZBR3s are good repeaters, but they have a rather weak signal, don't place them where they can't easily reach another stronger repeater or HE directly.

1 Like

Cool and thank you for confirming about Chanel 25 and for the feedback. I do remember you made that comment back when we were having trouble adding them to HE.

Yes, and this goes for any device using the CC2530 chip without a signal booster like the CC2590 (or equivalent). It was never really designed to be alone in anything that needs a good range.

1 Like

Love 25, been using 25 for almost 2 years, and its served me well. It way far from my wifi on channel 1 and far enough from neighbor's wifi on 6.
I was on 26 but then discovered it is lower power. I have a mix of samsung, aqara, ikea, hue, iris all working fine.
The tradfri repeaters are just okay, weak signal comparatively speaking. I returned my ikea plugs, way too weak and kept falling off, although others seem to like them, plus they're gigantic and ugly without a manual switch(WAF killer)

2 Likes

I have doubts that most or many devices drop their power for the high channels 25 and 26. I've been using channel 26 throughout a 40,000 sq ft. condo complex for more than a year now. No problems at all. However due to each of the 24 condos having it's own wifi, often set to auto-channel, all the lower channels suck.
Also the specification calls for only -4dBm drop in power for the two high channels. That's about a factor of 2.5. For signals that decay exponentially with distance it's not really that much difference.

'Actual channels available vary by country. For example, in the USA, Wi-Fi channels 1 through 11 are available, and zigbee channels 11 through 26 are available, although channels 25 and 26 require reduced transmit power levels to meet FCC requirements.'

There are more devices dropping transmit power for channel 26 than 25, that is for sure. What many seem to do instead of dropping transmit power for channel 26 is to just not support it. Many zigbee chips do not support variable power. I have not measured a drop in transmit power on channel 25 in any device I have. I have seen it on some devices with channel 26, when supported. I don't have the most sensitive of equipment to measure this (I use an SDR), but there is none that I can see.

2 Likes

I kind of agree with this. I just happen to play around with the Zigbee radio and pay a bit attention to their datasheet.

Zigbee radio can transmit up to +20dbm. In USA, the transmit power on channel 25 and 26 should be less than +20dbm.

Most Zigbee radio without dedicated power amplifier can push a lot less than 20dbm. For example, plain old CC2530 can only push 4.5dbm. An NRF52840 (much newer radio) push max 8dbm. Anything comes between those MCUs will have roughly similar power. If I were to build firmware with those radios, I would not reduce the power on the 2 said channels.

It is kind of expensive to validate. I would not even dream buying test equipment to test the antenna. But, I suspect there could be something in the antenna that is not as efficient at the 2 channels for the smaller repeater out there.

Thanks for sharing. The real world of user experience at the end of the day is what's count.

2 Likes