Would an additional hub help with severe load

I often get severe hub load and loss of my zigbee network. I think, but not 100% sure, that is down to my Hue bulbs and the use of CocoHue.

Would I benefit from adding an additional hub to the mix? Moving my Hue stuff to a separate hub potentially?

The second hub can at least isolate your lights from the impacts of resource hungry apps and devices, so one hub could host those and one the lights, so your lighting and associated rules can continue to run even when the other hub is under load. That is the setup I currently have and it works well.

That said, I would encourage you to work through any issues with your setup here on the Community first to see if there are any simple changes you can make to try and resolve some of your load issues, before outlaying $$ for a new hub. Take a look at the Runtime Stats section of the Admin Web UI to try and understand what may be consuming resources and work on adjust any settings or usage of those devices / apps, posting on the Community and questions on these as you work through them.



@sburke781 is right - yes you could move that stuff off but I'd be a bit surprised if CoCoHue is causing lots of aggravation. I have a second hub as well and every time I think I have an app that is causing issues I move it to my 2nd hub, only to find the issue stays behind! What are your polling intervals set for? I only use HE to control the Hue lights so nothing else will turn them on/off, and I have my polling set for 5 min on both CoCoHue and the native Hue integration. (I use CoCoHue only for the one device I can't use the regular integration with - a single smart plug in the dark recesses of the basement that is reachable by nothing else.)


I'd also add that I am considering setting my Hue bridge back up to host my lights, thinking now that I don't need to have them linked to the second HE hub. I can still run rules on the HE hub and initiate control through other devices, but don't need the lights paired to HE. If I / you only initiate control from HE I can't see a need to poll too often from apps like the HE Hue integration app or CocHue, which may then reduce load on the HE hub. If, however, you control lights from other apps outside of HE, then you would need to poll regularly to ensure status is up to date, if that is what you want / need.

1 Like

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.


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.


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.


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


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