That's probably a discussion for another thread 
1 Like
I don't even know where to start with this... I don't fancy debugging this the hard way.
My only workaround so far is I ordered some HomeKit-enabled Meross power outlets which I will put ahead of my Hubitat. When the zigbee radio goes offline, I will trigger HomeKit to power cycle the hub, because apparently, rebooting the hub is not enough, it needs a power cycle to reset the zigbee radio.
1 Like
Unfortunately, when a user connects and continues to use untested devices that we have had reports in the past that they can cause problems, the first step in troubleshooting the issue, is to isolate the misbehaving devices. Often, this is done by temporarily removing these devices from the hub (one by one or all). While this is truly an onerous task, it is the only one available to remotely troubleshoot untested devices that may negatively impact your hub's performance.
I'm going to chime in here in part to jinx myself. . .
I'd have those sometimes sporadic / sometimes frequent zigbee drops. Six days ago I replaced my first Hue Outdoor sensor with a new one (about 4 years old). While I expect that whether I relate this experience now or later, shortly after doing so I'll get a drop - it's unusual not to encounter one in 6 whole days.
There's a history on that #1 sensor - the white cover was damaged by a Sapsucker about a year ago, and when it rained it would go wonky. It was taken out of service, but earlier this year I had put it into indoor service. It worked well enough, though I'd notice that more than any other sensor it would shine red at times. (I suppose I should mention as well my Hue motion devices are installed in HE, not through the Hue hub). The good news is, the rest of the outdoor sensors have been left alone by the birds, since I painted eyes on the sensor cover above the white plastic. But I digress. . .
Just sharing what may be a relevant anecdote, and testing the jinx factor [shrug]
...bob t
6 Likes
The face painting is FUNNY!
Hard to un-see that!
2 Likes
I am trying to determine to what devices you refer. I have no knowledge of which devices you have had reports for and you didn't share that knowledge. Is there a list of known incompatible devices I could refer to ?
Part of my confusion comes from the fact that, in the ticket, you refer to both "incompatible devices" and "custom drivers". I have the following combinations on the hub:
- devices listed as compatible, using system drivers (generic or not)
- devices listed as compatible, a system driver is available but I chose to use a custom driver instead
- devices NOT listed as compatible, using (generic) system drivers
- devices NOT listed as compatible, using custom drivers (no system driver is available/works)
Is only the first combination considered safe? should I remove anything that falls into the other three categories?
This prompts additional questions:
- Are untested devices = any device not listed in the compatible device list?
- Do I void my warranty if I choose to use an "untested device" ? What if the hub eventually dies?
Thanks for your help !
[chuckle] Each of my 4 outdoor sensors have a personality all their own. Not on purpose, mind you. 
...bob t (The Artist Previously Known as He's No Artist)
1 Like
I have several different manuf. of IR motion sensors and the IR window's shapes do lend themselves to "facial expressions".
I just might do some face painting to give them their own personalities!
Thanks for starting THAT idea!
Maybe this is another thread starter!
Show us your IR motion sensor faces
1 Like
Anything that is not listed on Compatible Devices could potentially create problems. It may not be your case, but the reason they are not on the List of Compatible Devices is because either we received a significant number of incidents, or our engineers observed issues during their testing, like the Aqara devices.
1 Like
This is a bad idea. This can cause corruption of the database without a clean shutdown.
Actually pretty easy. Like using wireshark. Simply watch whats flooding the system
1 Like
Pretty much.
No
That's not going to be caused by pairing a device.
The issue with diagnostics is you have to start with the known. Use stuff on the known compatibility list with built in drivers. And remove any devices not on the list.
Does this solve this issue? Yes/no
If Yes then you add the other devices in one by one. Did the issue kick up again after adding the device(s) back in? yes/no.
If Yes, then back of some of the devices...so on and do fourth. It's a process of elimination. Also watching logs, turning off power reporting, disabling lan based integrations and devices. This is all part of the diagnostic process. Every single solitary installation is different. Trying to narrow things down can be painfully tedious. Support though again has to start at a known baseline and go from there,
1 Like
These are the model I have. Note, until I can verify the behavior is in fact these plugs, it is only a fact that by removing these and a number of other Zigbee outlets, the problem went away. This is somewhat circumstantial to be sure.
S.
As a followup, a couple things that I noted during this exercise.
- The location log seemed to show a series of events, and there could be long periods between such events.
| zigbeeStatus | Zigbee radio is offline | offline | 2023-08-28 11:58:35.862 AM EDT | |
|---|---|---|---|---|
| zigbeeStatus | Zigbee radio is online | online | 2023-08-28 09:37:54.115 AM EDT | |
| zigbeeStatus | Zigbee radio is offline | offline | 2023-08-28 09:37:47.027 AM EDT | |
| zigbeeStatus | Zigbee radio is online | online | 2023-08-28 07:26:37.190 AM EDT | |
| zigbeeStatus | Zigbee radio is offline | offline | 2023-08-28 07:24:36.281 AM EDT | |
| zigbeeStatus | Zigbee radio is online | online | 2023-08-28 07:24:33.278 AM EDT | |
| zigbeeStatus | Zigbee radio is offline | offline | 2023-08-28 07:24:25.169 AM EDT | |
| zigbeeStatus | Zigbee radio is online | online | 2023-08-28 07:22:29.012 AM EDT | |
| zigbeeStatus | Zigbee radio is offline | offline | 2023-08-28 07:20:28.052 AM EDT | |
| zigbeeStatus | Zigbee radio is online | online | 2023-08-28 07:20:24.044 AM EDT | |
| zigbeeStatus | Zigbee radio is offline | offline | 2023-08-28 07:18:22.923 AM EDT |
-
In my case these periods of zigbee radio disruption appeared as much as 12 hours apart, and ultimately led to a Zigbee Offline notification and typically a power cycle to restore.
-
Reproducing the error appears to be related to overall network activity, but this is a subjective evaluation.
-
While an XBee might be helpful, I can't say for sure, it may be that it and/or Wireshark could deliver too much info to lend itself to ready analysis.
-
My suspicion is that I damaged the Sengleds with too larege a resistive load.
S.
Well, the alternative is a hub that stops working randomly and doesn’t come back, I don’t have much of a choice to power cycle it. What does it matter if it happens automatically or I get up to unplug it and replug it ?
Understand that this is something that happens every few weeks or so. With a 2-3 weeks cycle, I will be 6 feet under before I can identify the faulty device.
If the unit is still accessible by port 8081 then you will serve nothing but to corrupt the db more. If only the zigbee radio is offline then you will most certainly corrupt doing a dirty shutdown and making things worse. You neee to figure out the cause of the issue but you seem unwilling to go through the diagnostics to do so and also seem to be willing to make it worse by doing dirty shutdowns and risking more corruption.
Sound advice in general. In this case, the problem manifests itself only every two weeks, making this approach impractical. Instead, I spent money to order a third C7 hub. If I get this issue a fourth time, I will replace the hub, changing nothing else. Then, we shall see.
I don't expect Hubitat support to troubleshoot this problem for me. I am only asking for information. To summarize:
- are the engineering logs hinting at anything or do they look normal?
- are some of the devices I'm using known to be more problematic than others? "Anything not on the list" appears to be the answer.
- what tools can I use to detect hub overload, which I am told is considered to be the likely cause of this behaviour ?
1 Like
So… I am supposed to keep the hub online forever without a working Zigbee radio ? The Zigbee radio does not come back on its own. I tried rebooting it, it works after 3-4 reboots, maybe, maybe not. I was told that only a power cycle would bring the radio back for sure.
It is not that I am unwilling, it is that going by trial and error will take years. I might as well drop Hubitat if it takes 2 years to diagnose… and I don’t want to do that Hubitat is great when it works. Problems started when the firmware was updated with the new C8 stuff back in March or so.
Assuming the hub is still live when the zigbee radio goes offline, would it be practical for you to automate the hub's shutdown after sending yourself a notification so that you can power-cycle post-shutdown?
1 Like
