I've just begun experiencing an issue with my Sengled Color Element bulbs with my C8 v2.3.9.158. I have 13 of them and they all fail to be be controlled. It's happened 3 times in the last week. Not sure if it's related to the current hub firmware, as these were rock solid since I've first connected them.
Only these bulbs lose the ability to be controled. I rebuild zigbee network, scan channels, reboot the hub, and lastly I attempt to reboot the zigbee radio. It magically works after a few minutes of rebooting the zigbee radio.
Not sure how to troubleshoot and log what it could be that's causing this the next time it happens. Can someone provide me more info on what would happen if I change power level or change the channel my self? What does that affect?
You need to add more Zigbee repeaters/routers, like the "Zigbee PM Outlet Repeater"—according to the Zigbee map, this one is working well.
Can you temporarily move one of the problematic Sengled bulbs close to your C-8 hub, pair it there, and if it works OK for more than 2 minutes - then move it to the final permanent position?
Are all the problematic Sengled bulbs situated away from the repeater?
All "Bulb" and "Lamp" devices are sengled bulbs. I use the "Button" devices to control them and these devices are working and have activity, yet the sengled bulbs don't provide any signs of life during outage. The bulbs connected to the repeater function the same. The living room fan bulbs are about 6-8 ft away from the hub. Kitchen Fan Bulbs are 15-20 ft.
Adding more repeaters would be great if necessary. However, I'm curious why this has become an issue nearly a year later. Is there a specific change in the environment that requires it and how can I confirm?
I'm going to troubelshoot by checking what my wifi router's 2.4ghz channel is set to. Maybe my router switched channels recently when I ran channel finder due to slow wifi behavior. That was about a week or so ago, as well.
I'm leaning towards my neighbors getting some sort of device that's interfering.
WiFi interference seems to be one of the most common reasons for similar Zigbee mesh issues.
I counted 30 Zigbee devices connected directly to the hub. The maximum number of directly connected devices is 32. For more , you need repeaters. And there must be at least one free slot in the Zigbee coordinator routing table, so that the new router/repeater can be paired as a new device for a first time.
SiLabs explains the meaning of the line you highlighted in the route table entry list as follows:
routeRecordState
For a High-RAM Concentrator, indicates whether a route record is needed (2), has been sent (1), or is no long needed (0) because a source routed message from the concentrator has been received.
.................................................................
If you believe what you read (from studies of how Zigbee meshes perform even under deliberately induced heavy wifi interference) they typically exhibit slowdowns rather than complete loss of function... the protocol includes collision detection, backoff and retransmit so they'll drop packets and retry (slowing down rather than completely flat out die).
The coordinator also picks the quietest channel automatically when the network first organizes itsef (though this selection happens only once, so for obvious reasons it's not foolproof).
And you said your button devices are indeed working...You would expect issues with these if interference was crippling your mesh so I wouldn't mess with channel changing yet.
It seems that something els is at play here. I agree with @kkossev that lack of repeaters (you only have one) is the first thing to address, just on general principles if nothing else since your bumping up against the hub's child device design capacity.
Unlike Z-Wave, Zigbee's always finding new routes and expiring old ones that haven't been recently used. The Route Table entries are evidence of this. (no 'heal' is necessary for this to happen, unless you want to force changes to stable hub-child connections by shutting down the hub and waiting for its child devices to find a different parent).
The [Unknown,0000] via [Unknown 0000] looks kind of odd but since 0000 is the hub's device ID-- and sometimes the hub sends packets to itself when the network is quiet-- this might be normal. Do you see changes in the Route Table entries when refreshing the GetChildandRouteInfo page?
As to why this loss of function has happened after a long period of normal operation, that is puzzling and unfortunately not an uncommon complaint among C-8 users. Was setup migrated from C-7 originally?
One more thing, is the repeater a Zigbee 3.0 device? When I beta tested the C-8 I found that doing a 'network rebuild' would result in a loss of connectivity to non 3.0 routers for a period of time which eventually resolved itself within a half hour or so (oddly, the loss of connectivity didn't manifest until the next reboot of the hub)
Yes, migrated from a C-7 with cloud functionality. It went smooth and I've been enjoying not having any troubleshooting nights for all this time.
It's a Sengled E1C-NB7 which is zigbee 3.0.
I bought a 2 pack of these plugs. I just need to figure out optimal placement. 2nd floor? Since my hub and other plug is on the 1st floor? If this helps, I can always grab another or maybe get a few of the USB repeaters from Tuya for a smaller footprint around the house.
Would upgrading the C8 antenna's benefit in anyway? Or is that route placebo effect?
LQI seems to have been recalibrated when the C-8 came out (so the 122 figure can't be compared to what you'd see on a C-7) however the 'age:4' indicates that at least one status update didn't get through to the hub.. seeing this frequently at 4 (or higher) may indicate that reception between hub and router may be an issue.. especially when involves the sole neighbor router.
What changes (if any) do you notice when refreshing the GetChildandRouteInfo page? The repeater and hub exchange status roughly every 15 sec which includes measures of the reception between the repeater and hub (inCost and outCost). The age counter will indicate a status interval that get missed since the counter will reset to '3' every time link status is received at the hub, and increment with every interval that elapses with no status.
I usually see 'age:3' displayed for the key routers in my mesh (not all, but I have several redundant routers). Seeing a '4' occasionally doesn't necessarily indicate an issue; but do you ever see any age 3 counts?
I'm seeing an LQI of '97' on all refreshes. It's been age: '4' for most of the refreshes, but did see a handful of '3' and once or twice at '6', '8'. But mainly '4'. In/Out Cost has been consistently '1'.
I've added the 2nd repeater plug. I have 1 in the back of the house on 1st floor, and 1 upstairs in the front of the house on the 2nd floor. While the hub is in the center on the 1st floor. Powered off my hub for 20 minutes to force the mesh reset.
Looks like everything is in order and 36 devices connected. A handful on each of the repeaters. Hopefully this resolves it.
