Hub process slowdown after several days

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.

I'm eagerly awaiting the release of the "Hubitat Even More Elevation" hub.

1 Like

I've given up any short term hope for that.

That's why I'm doing more and more in Node-Red and Home Assistant these days.

Yes, I have to write a bunch of py script to do simple things on home assistant, but I have almost infinite cpu/memory resources to play with too... As much as I'm willing to pay for, in any case. That isn't an option presented to me in Hubitat.

3 Likes

Personally I find this a bad approach from a consumer perspective. Reward a company for a product flaw by purchasing more of the same product to work-around the flaw? It's a great business plan from the company perspective though :slight_smile: increased sales!

How history repeats itself.... Vera all over again... same design... same problems.

1 Like

Completely understand. This kind of an architectural decision usually happens in the planning stages of product development so I'm not hoping for much.

Dare I say it - it seems like the ST approach to running custom apps and drivers on the cloud.. actually makes sense?

Also, I don't quite agree with having to buy another hub - that's another point of failure and an additional piece of hardware to maintain. The whole point of a hub for me at least is to have everything home automation related under one umbrella. I hate the segmented nature of HA today, it was fun when this was just a hobby for me, but I've really just gotten to "I just want these things to work without babysitting" stage.

I will say this - at least Hubitat gives you a LOT of options for external integration. The maker API is very cool and now the inbuilt MQTT support is also amazing. This means power users will always have the option to offload logic processing to some other box (homeassistant/nodeRED) on the local network.

1 Like

I largely agree that it is a similar problem. Although I think Hubitat is supported much better than Vera, and as long as they don't get bought by a larger company they have a chance in my opinion.

Agreed. I see the rue future of Hubitat being:

  1. Casual users - use hub as-is with built in apps, no custom code.
  2. Power users - use Hubitat as a zwave/aigbee conduit, do all rules and apps externally in a high capability box.
1 Like

From my understanding that was the original intent/plan of Hubitat from the beginning. It was the users that given the "ability" to do so went wild creating apps which over consume the limited resources. Not that we were bad but given freedom to do so it happened.

I backed off from developing apps or integrations because I saw this problem a LONG time ago. Instead I went with option 2 of integrating with other platforms and use Hubitat as a device controller which it's good at.

1 Like

Yeah, I remember you saying that. I should have listened then. Any opinion/preference on yhour side on which platform it is better to integrate with? I assume you'll say Homeseer to get another license sold, but thought I would ask anyway. :slight_smile::slight_smile::slight_smile::slight_smile:

I currently integrate with Node-Red and Home Assistant, but the way I'm doing the hass.io integration is really clunky.

1 Like

I don't think they know if this is common, or exactly which routers are involved. It appears that the HE must come factory set to 100M and the fix changed it to auto-negotiate the connection. It can't hurt to email support and ask for the patch as it can be undone with a reboot, or made permenent by the user if it works. btw, my router is a Netgear X6S.

Only if you are willing to use the built in hub link tools. Because HubConnect is still a custom app.

One thing that would be REALLY nice is a built in app for syncing devices on 2 or more hubs. Then you really could just put all of the custom stuff on a 2nd hub.

HubConnect is custom, however many of Hubitat staff has openly recommended using it.

I'm not sure that just getting a souped up Hub will solve the "slow" hub issue.
Who knows? Perhaps there is no reasonable upgrade that will soup up a Hub enough for malformed, or "out of control" code.
It is true that the competition (ST, specifically) has an advantage in this regard. Apparently (not sure) they have a faster (and more memory) Hub, and much more processing power (due to execution in the cloud).

I for one, am willing to pay for a "souped up" Hub to ensure I don't have this issue.
"Throw hardware at the problem - sometimes it's cheaper than spending a lot of time making code more efficient.:

Actually no I wouldn't say HomeSeer. If you want to know why you can PM me.

I run several systems for various uses/purposes. I like flexible systems and I develop for a few and with Simplex Technology I get to do that for fun as well as profit. I run an ISY + Polyglot at home. That provides my primary Insteon and Z-Wave interfaces. I have Polyglot Nodeservers that integrate with other systems including Hubitat for Zigbee. I have Nodeservers for all my other systems. The beauty of Polyglot is that it runs on an external system. Does not use/consume resources from the ISY. I also run Home Assistant which interfaces with the ISY. This gives me a nice "pretty" UI for things when needed but it's not often as my setup is designed around automation and not user interaction.

I also have Node-RED that can glue things together when needed for prototyping and then if useful I develop it out to a Polyglot Nodeserver :slight_smile:

I don't "promote" any one system as each use case and user expectation is vastly different from another. I like Hubitat it's a great consumer system. Just accept it is designed for consumer use.

1 Like

The V3 of ST was less RAM and lower powered CPU than the V2. They can do this as they use cloud processing and not local....