Zigbee radio shutting down/hub load severe

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:

  1. zigbee offline
  2. hub load severe
  3. 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:

This is not the first time I've had the zigbee radio shut down - it happens every few months.

Thanks

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.

I'm also seeing a long list of errors for a room lights app:

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.

1 Like

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