Tagging @bobbyD
1 Like
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.
1 Like
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".
1 Like
Checked all my illuminance sensors - none of them report more than about every minute. The hue motion sensors report less frequently than that.
1 Like
@bobbyD can you advise when this "... queue full..." error message is shown in the device logs?
I have seen this just once - a Z-Wave device was offline for a long time. But the Sengled bulbs are Zigbee?
Check out this recent post...
1 Like
Thanks! So the source of the problem may be the Singled bulbs.
@hokfujow are these responsive from the bulbs HE device web page? ( device ID 329)
What is the Advanced integration, and are the devices you've pointed out been created by this integration?
Hi all - thanks for the various responses.
This is the Advanced Hue Integration
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.
1 Like
In reply to earlier questions -yes, the bulbs are responsive from the device page.
Try turning off any animations on the Hue hub.
Now I remember I had a similar problem activating Nanoleaf LED Strip animations using their app.
1 Like
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.
I can try in the next few days to reproduce this scenario again - the Nanoleaf strip was sending endless updates on the level, color, etc.. changes.
2 Likes
That makes sense, then, as the hub is trying to process the high network traffic. No need to reproduce.
1 Like
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.
1 Like
Hi Armand - understand about not having time right away. Curious about whether any of the settings in the options impact any of this. I also saw some options under the Sensors tab that I don't understand. What are these sensors?
Sensors with null in them are virtual sensors on the hue hub. They are created by the various hue based rules that you can add from hue labs.
I have not removed them so that people can provide per virtual sensor requests. I should probably make that more apparent in the interface though.
