My hubitat c-7 hub has been running great since I got it a few months ago with very few issues. Recently, however, I've been experiencing tons of problems with zigbee devices. All my zigbee bulbs work fine but I have four Sonoff buttons and 3 Sonoff motion sensors. These worked flawlessly for months but all of the sudden they are constantly disconnecting. If I reset and re-discover them they work again for a day or two but then they stop again.
I have 3 Centralite zigbee smart plugs throughout the house to act as repeaters and those have been reliable as well. Just wondering if anyone has noticed reliability problems with their stuff after any recent updates. It was after updating all apps/integrations/whatever that these problems began. I've restarted it multiple times and nothing has helped.
I should note that I've only got 8 zigbee bulbs total so my zigbee network isn't terribly crowded and nothing has changed in terms of wireless devices or routers that might have caused this.
Any advice on how to stop this would be appreciated! Thanks!
With Zigbee, it appears that the #1 problem is the issue of WiFi interference.
The first step is (I hope that you have an android phone), to download the WiFi analyzer program (there are several), and to map correctly your 2.4 WiFi frequency and your Zigbee frequency.
Please see this thread for further details.
I second that idea that it could be WiFi interference. I manually set my router to use WiFi channel 1 for the 2.4 GHz network. That keeps it as far away as possible from Zigbee channels 20 and 25 which are used for my two hubs. Since I did this, my Zigbee network has been solid.
My utility company installed new smart gas and electric meters around 6 months ago. Shortly after my zigbee network started playing up after being very stable for a couple of years. Scouring the web I found other people have had the same issue.
I changed the zigbee channel of my hub and this solved the problem.
The point I'm making is there can be many external influences that can create havoc on your mesh.
As said above, I've also set my wifi router to a fixed channel of 1 as it did change occasionally.
I am having the same issue and nothing has changed around here as far as Wifi goes, meters, etc. It has seemed in the last 2 week, just things locking up and needing reset, batteries draining at the same times on several devices, etc. I have had to pull the battery on items and unplug the others that are plugged in. It is really odd and it is only Zigbee that just started. Nothing changed.
I must tell you that I didn't have Zigbee issues for a very long period of time.
Then, all of a sudden, I started to lose devices.
What happened?
One week, in my zealousness to make my Router faster, I installed a "time out" schedule. It restarted every week, at 3am on Sunday morning.
For the first few weeks, there were no issues!
However, I finally noticed that when it was rebooting, it was choosing it's own wifi channel automatically - based on which channel didn't have a lot of wifi interference.
After several weeks, it finally chose the same channel as my Zigbee network.
Presto! Zigbee devices go down, just like magic!
One thing that might help troubleshooting is to know the topology of your Zigbee network; not just in terms of repeater placement and coverage, but the parent/child relationship of the battery operated devices since they are the ones experiencing issues. This 'parent/child' concept doesn't exist in Z-Wave but the difference is key to how Zigbee operates.
When they join the network, battery operated Zigbee devices become 'child' devices of a single parent repeater (mains powered device, which can also be the hub); the parent is chosen by evaluating the quality of the RF link it can provide and also requires that the parent have sufficient resources to support the child: child devices actually fetch from and store their messages in dedicated buffers in the parent device, kind of like a mailbox that they periodically access (hence the 32 child limit for the hub and a smaller limit for most other repeaters).
The chosen parent device becomes the only device that a battery operated Zigbee device will communicate directly with (because its send/receive buffers reside there) until it becomes 'orphaned' which typically shouldn't happen often in a stable Zigbee network. When it does, the reason is either an issue with the parent device or persistent disruption in the RF environment. Zigbee radios use direct sequence spread spectrum encoding are actually pretty resilient when it comes to dealing with interference; unless it's extreme (a wifi router on the frequency would probably qualify) a Zigbee network will exhibit increased latency due to retries rather than stop working. But since only a subset of your devices are having problems, wifi interference would seem less likely to be the cause.
When a Zigbee child device is orphaned, it should transparently choose another parent if one is in range and available. It happens very quickly, within seconds, when it goes 'according to the book'. But some vendors implementations are more interoperable than others, and in some cases the automatic rejoin may not work well at all, in which case manual intervention is required.
Child devices of the hub will be listed as such in the hubip/hub/zigbee/getChildandRouteInfo page. It's not unusual to see no child devices listed there, in which case they are all relying on other mains powered repeater parents to communicate with the network. Since your issues appear to affect only your Sonoff sensors/buttons; its possible that they are child devices of the same parent router. A mesh mapping tool (Xbee with XCTU) could show if this is the case. If that parent device has issues (maybe its SOC is periodically crashing, orphaning all its child devices) it could cause the type of problem you are seeing.
If you have an inkling of what parent the Sonoff devices are joined to (usually but not always it will be the closest repeater) it might be worth trying to swap in a different repeater (obviously if they are child devices of the hub this wouldn't be possible).
