Would an additional hub help with severe load

If you look near the bottom of the Hubitat main menu, you will find an entry for Runtime Stats. The device stats will show you the total uptime for the hub since the last reboot. (Mine is showing 13 days, 21 hours). If you click on the App stats tab, it will show the total busy time for the hub. (Mine is 9 hours 17 min since the last reboot). Thus, my hub is busy less than 3% of the time.

That page also shows the amount of the busy time attributed to each of the apps on your system. In my case, I am running two cloud based apps that consume 87% of the total busy time on the hub. Those apps are Actiontiles and Echo Speaks.

Thus, before jumping to conclusions as to the cause and possible cure of your high hub load, look at the stats. That will tell you where to focus your attention. If the apps controlling your Hue bulbs are consuming a lot of the hub time, then separating them may help.

That being said, if you have Hue lights, especially a lot of them, you may find they work best connected to the Hue bridge. However, I suggest that any Hue sensors be connected directly to Hubitat rather than to the Hue bridge. Since the sensors play nicely with the hub itself, the integration does not include the sensors. If you already have a Hue bridge on the shelf; I recommend you pull it out and get it running again.

Although Hue bulbs will connect directly to Hubitat, they were designed to run using the Zigbee lighting protocol rather than the ZHA protocol used by Hubitat. Thus, connecting them directly might create issue, especially if you have a lot of the Hue bulbs.

Most of my lights are on a Lutron Caseta Pro bridge. My Hue lights are on a Hue bridge. I have both Zigbee and Z-wave sensors and devices. That divides up the workload so my Hubitat runs smoothly.

4 Likes

I am wondering if you are using a C-4 hub. I have 2 C-5s, one of which has most of my rules, ML instances, Homebridge integration, around 70 Zigbee devices,and 2 Hue bridges worth of lights connected via CoCoHue. It normally says around 5-8% processor usage.

1 Like

@Ken_Fraleigh I do have a C-4 yes, is there much difference in the newer versions?

@sburke781 I use CocoHue as we use scenes a lot rather than direct light control, we also have a lot of scenes/lights etc - I think my Hue hub is now at the max allowed. We do have switches connected to the hub in the room for the odd control, but no need for these to report back to HE. Most of our lighting is done by motion through rule machine

@rwclements228 - I had to reboot my hub recently has all automations had stopped and I couldnt access via the web interface. I see that CoCoHue App used 18% of Busy and the Bridge 19% in device stats and that is in the last 43 mins but appears consistent to what I have seen other times. I also have Tado which uses 11%

I've seen others post about this issue. Something to do with the 64-bit code on the C-4.

Look at "of total processing time", that's the important number.

These are my top culprits in the runtime stats

The switchbot I added last week but have had the hub slowdowns/lock ups for ages

I don't know anything about cocohue, or how it works, but it sure looks like it is consuming a bunch of hub resources.

You might want to post in the [RELEASE] CoCoHue: Hue Bridge Integration (including scenes!) thread and see if @bertabcd1234 can spot anything unusual with your setup.

It will be making lan-based calls to a hue bridge

Perhaps you could reduce the polling frequency?

1 Like

I have changed the polling frequency to 1 hour. I dont really need it to poll the hub just sent commands to turn lights on and off

Will see how that goes, thank you all for help so far

1 Like

This may not be your issue, but I personally have found that, in general, Hubitat is not usually CPU bound but rather I/O bound. That is, devices that send out a lot of messages (for example, power reports), tend to clog up the I/O.
In summary, I would turn off the power reports of any device where the power report is not being used.

2 Likes

I have 2 apps that report power that control our modes, i have noticed these are high usage. i could look to restrict the times that these rules run as they are our bedside phone chargers

Please forgive my biases.
I have also noticed (I'm sure others can confirm this), that there is a big difference in the I/O put out by a simple Zigbee plug with power reporting and a Zwave plug with power reporting. I don't know why, but the zwave plugs have many more options, and much more flexibility on what to report and how to report it. This leads to a lot more "chatter" from zwave plugs.
(I've used zwave = Zooz, Dome, Inovelli ; zigbee = Nue, Innr, Centralite, Tuya).

1 Like

Interesting comments, we are using Zigbee Salus SP600 plugs

From the screenshot, it doesn't look to different from what mine reports when I checked just now (and that hub is fine, but it is a C-5 and the underlying OS is indeed a bit different from a C-4, as mentioned above). Polling is likely the biggest contributor to this, so the less frequently you can do so, the better it will be. I see the OP just set it to 1 hour, so that should help--if this is is part of an issue in the first place. Polling uses HTTP (as does everything with this integration, like sending on/off, but again, polling is likely the biggest user since it will just happen on schedule regardless), and I've heard rumors that there are (small/slow) memory leaks with Hubitat's HTTP calls, but I'm not sure if those are substantiated or just rumors. If that is the issue, a periodic scheduled reboot, say every night or few (there are apps or rules that can be used to help with this), may work around that particular problem if needed.

2 Likes

I do have a periodic reboot scheduled for each morning at 3am, however sometimes the hub can lock itself up before midday.
I have stopped the reboot for now and will see how things play out with the polling reduced

Since making the change to the polling time, I haven't noticed any hub slowdowns and it has now been running for over 24 hours - this is a rare occurrence.. will see what happens over the weekend but things are looking good.

Thanks all for your help so far

2 Likes

Does it look any better when you look at runtime stats?

The CocoHub App is still the busiest App but the Bridge device isnt in the runtime stats...

As things go things are running well and no notification of severe load.

Well... too soon to say for sure but I guess that's good news. Still seems really high though even if it isn't causing a meltdown.

It may be worth resetting the stats or even restarting the hub to get a more accurate picture of the aggregate result

1 Like

I did this after making the change yesterday, however no harm in resetting now and then have a benchmark to monitor from