Hello @bobbyD - my C5 zigbee radio went offline overnight or this morning. I'm running platform 2.3.6.146.
The hub showed 3 alerts when I checked:
zigbee offline
hub load severe
Database large and growing
I shut down the hub, pulled power for 30 sec and rebooted.
The radio came back but it continued to show severe load and database large alerts for several minutes. After about 10 minutes, all the alerts had cleared.
In checking device and apps stats in the log, the only device or app that stood out was the Advanced Hue integration, which showed that it used over 200% of total time. I'm not sure I understand how that's possible, as I assume nothing should show higher than 100% under percent of total or busy time.
After about 20 min, the numbers seem to have settled down, but I'm still seeing numbers that add up to more than 100%:
Devices: 36m 37s / 29m 43s total (123.2%)
Local apps: 52m 55s / 28m 6s total (188.3%)
The advanced hue bridge integration is still the stand out at 94% of total time and 50% of busy time.
In looking at past logs, I saw this error for the Advanced Hue Bridge Integration:
Some more information..I looked at past logs for all errors, and saw quite a few with related characteristics: rooms with sengled bulbs being managed by the Room Lights app.
Here's an example for one of the bulbs - this one using the advanced zigbee rgbw bulb driver.
This room lights app is not the one managing the above bulbs - although it is managing another room that does have the same bulbs. Not sure if there's any connection there.
The hub shuts down Zigbee in effort to preserve resources to deal with overloading effects of a misbehaving app or device. C5 hubs exhibit this more so than newer hubs. Resolving the problems that caused the event queue to be full will help your hub to keep Zigbee online.
Got it. So do the errors in the logs I posted give any help?
Regarding the last group for app:882 - I checked the full log for those errors, and what's happening is the illuminance sensor being below the threshold continues to trigger the room lights app. I had asked about this a long time ago - because what's needed is to trigger it when the illuminance goes from above the threshold to below it - but the room lights app doesn't seem to have that as an option - so I think what happens is that it triggers continuously as long as it's dark.
However, this isn't the device or app that was showing high activity in the app stats - so it's not clear to me whether this is the cause of the severe load.
Also - this is not something I've changed recently - it's been months since I've made any changes to it.
If you doubt that this illuminance sensor may generate too many Zigbee messages, you can check the Settings -> Zigbee Details -> View Logs. Here, you will see all Zigbee messages from this device that reach the hub, even if not shown in the device live logs w/ Debug option on :
As an example, the activity of my Aqara GZCGQ01LM light sensor is quite normal :
It's not clear to me that this is the issue to start with. Despite all the errors I'm seeing on this room lighting app, the only thing that stood out in App Stats in terms of load was the Advanced Hue Bridge integration. So I'm looking for help in determining where to drill down.
To recap:
Device stats didn't show any device with a high load
App stats showed the advanced hue integration was very high load
Logs showed queue full errors for sengled bulbs.
Logs showed an error for room lighting that appears to be too many scheduled jobs
Unclear to me which of these is most likely related to the "severe load".
The Sengled bulbs are zigbee but are unrelated to the hue bridge. They are connected directly to HE and use the Advanced Zigbee RGWB bulb driver.
I pointed out the Advanced Hue bridge because of its very high activity in the apps log.
In retrospect, the zigbee overflow might have been because they were not responding due to radio shutdown. So the severe load may have started with that advanced hue bridge.
Thanks for the update. If you'd like us to check the engineering log for additional clues, please send me a message along with your hub id. The queue full is intriguing, as it usually isn't associated with hub shutting down the Zigbee radio.
Neh, neither will affect the hub directly, unless the Hubitat hub is processing the animation from itself via an internal app, or the application sends the animation "traffic" via network and the hub must process the increased load.
Animation traffic is sent by hue over the event stream. I might be able to define a filter to turn certain traffic off, I don’t know for sure. His isn’t really intended to be a very heavy protocol. The weight n the process is the JSON slurper that transforms the text received. Then couple that with the fact hue will send events that are incomplete, forcing my code to have to perform a point-query to get the missing attributes.
I won’t have much time before the new year to really dig into how I can improve this, but there may be some things I can do to help on the hue side.
