Hub process slowdown after several days

I also experience the slowdown over several days and a reboot seems to speed the rules back up. I have 2 HE's with 1 hub with all the Zwave and Zigbee devices and the second hub with all the cloud connections like Rachio, Hue, Sonos. I made this move hoping that cloud connections were the problem but I didn't notice an improvement. I have avoided a bunch of the third part apps and drivers to try and avoid any poorly written drivers that might drag the hub down.

I'm not using Netgear nor Asus, and my dashboards are actually usually pretty zippy.

It's my lighting rules that drag. I'm wondering about Hue as well, since that seems to be a common thread. I'd hate to delete my Hue, though. I can't do the kind of automations I want in the native Hue app. Complex automations were one of the features that sent me to HE.

I have Hue as well and No issues going on 48 hours, which might be a record as I was rebooting daily for a while. I had NST Manager and uninstalling that made a big difference. I also disabled several TP-link lights and plugs. I have read that unresponsive lan devices can crash the hub, like wifi lights and other integrations.

I have found the built in Ecobee app or for that matter any Ecobee app installed on HE slows down the hub. Not sure if anyone experiencing issues is using the app.

I dont use Ecobee, so not that for me.

Here's the rule

2 Likes

I'm having slowdowns so bad it's taking up to 2 minutes to trigger a light switch via the portal or sharptools. It's unusable right now. This just started about two weeks ago for me. Been running it fine for about a year with no changes in the past 4 months

No NST, TP-link, or Ecobee here.

I also went through all if my device pages and discovered that they were still showing up as being in rules that they had been removed from. As in opening the rule showed they were not there. I ended up deleting and rewriting a lot of rules, which may have been an issue. I also removed most of my scenes and just created rules for them. I also had several null devices in the zigbee routing page.

Just a thought.... do you guys have older rules than 4.0 still in operation ??
Changed all mine over last the weekend (thx @denise.grider) :slight_smile:

It might be another thing to explore !

1 Like

All of my rules are RM4. I changed them over pretty soon after RM4 was released because I like it better than RM3.

I don't use a lot of scenes, and what I do have are usually triggered by RM4 rules twice/day. Rarely I have another couple of rules that might be triggered a couple of times per day.

I don't have any null devices.

I think I saw in another thread that someone -- Bruce, maybe -- said that the leftover rules showing up on the pages of devices that were no longer in the rule don't really hurt anything. I haven't tried to do anything about those.

All RM4 here. the only integrations using LAN are Sonos, Lutron, HubConnect, and Hubduino on my main hub, which seems to be having the slowdowns. Tried disabling all and it had no effect. I am thinking that there is something about RM4 hanging onto resources, or a process not releasing resources, such as logs, and as the resources disappear, the hub slows down. Not sure, not really my forte, but seems plausible! lol

All RM4 here too. I dont have any chromecasts either. That has been a problem in the past, from memory.

I do have Google home on my main hub, and it's been faster than me pulling out my phone, opening a dashboard (and waiting) and pressing a button.

Hmm Ok, that pretty much rules out old rules conflicting with RM 4.0.
FYI I'm also pure 4.0 and do not experience any hub slow downs and have only ever rebooted my C4, twice in more than 12 months. Those times were to rewire or for a planned system change.
I've also just got the single Hub and have beta Chromecast doing TTS to a single GoogleHome Mini.

It's been a good while since the HE guys pushed out a release so perhaps there's a big rolled up version in the wings ?

1 Like

Just to add here. My hub has always had slowdowns. I have issues where lights on my Hue hub take about 1-2 seconds longer to activate than my Sengleds (yes, I know, local Zigbee versus TCP/IP). If I trigger the lights from the Hue app, they respond instantly. But from HE -> Hue, they can take a second or two. I only have RM4 rules and only four LAN integrations: Sonoffs, Hue lights, Harmony hubs, and Sonos.

Everything I have here is locally processed and I still have slowdowns. I agree with others that it seems to be the Ethernet port (or just flooding of the eth0 interface) that causes the HE hub to have issues (among other things going on in the engine).

Gonna chime in here. I also have problems with slowdowns after a few days. Re-booting speeds it back up. I have disabled all non standard apps, drivers, etc. Doesn't help. Checked logs and found nothing.

I'm on day 3 with no reboot and no slowdowns since my hub was patched with "lanautonegconfigenable". I haven't made it this long ever without at least some lag with automations and zigbee devices. This has been a problem since my C-5 hub was new. Also, my homebridge-hubitat-hubconnect modes and device states are reliably syncing to the Apple Home app for the first time ever (the modes always stopped syncing after the first mode change).

3 Likes

To all the people that have slowdowns and have really disabled all of the custom apps and drivers: Have you reached out to support@hubitat.com ? I would highly recommend you do so. The team always says that they will fix slowdowns if they are caused by the platform.

There is a lot of confusion when it comes to this topic. The team does NOT say that they don't look at the slowdowns, they only ask to disable custom apps and drivers as a first step of troubleshooting. If they are all off and you still experience the issue, I am sure they will jump all over that. However, to do so, they need to know that you have the issue. They can't read all posts on this forum

6 Likes

I've been in contact with support over my issues, it's how I found out that there were issues with the influxDB and echospeaks smartapps.

The problem that I have with this troubleshooting approach is that these slowdown issues aren't apparent immediately. I've disabled all smartapps, done a reboot and tried the whole enable each smart app individually thing - but it didn't give me any meaningful data. Sometimes a rogue smart app might go on for days before causing issues, sometimes it might be instantly after it's activated. Other times, it won't cause any issues at all. I have about 2 LAN based smartapps that I absolutely cannot live without.

IMO, core hub functionality and at least the inbuilt rules engine should be isolated from custom smartapps. I'm not really sure if the processor in these hubs is strong enough for this kind of "containerization" though.

It can be... Buy a 2nd hub.

I do understand what you are saying - and completely agree. In a more robustly architected system, user code wouldn't be able to take down core system functions in the first place.

But there is zero indication from Hubitat that they intend to re-architect the underlying system to provide that level of segregation. Or provide a new hardware model with more cpu/memory/IOPS resources to work around this.

So right now you either have to live with it as-is, or get more hubs and segregate it that way.