Hub process slowdown after several days

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....

Shipping a product with the eth port fixed at 100/full is asking for trouble. The device its plugged in to would typically be set to auto, and unable to negotiate with the other side, likely ends up at something other than 100/full and the mismatch will cause horribly intermittent connectivity. I doubt this is the cause of these slowdowns though as you would have problems from the first moment you try to connect to it. I do wonder what the Asus patch is actually doing.

Sorry for derailing the thread but.. @jeubanks @JasonJoel How are you guys interfacing Hubitat with NodeRED/Hass? I've recently started beta testing the MQTT integration from kevin, and it works quite well. However, I'm noticing some lag (around 300-500ms), which I'm not quite sure I want to live with.

Is there a way to connect NodeRED/Hass to Hubitat using the Maker API and would this be faster? Hass recently came out with a native ST integration - it works really well. Something like this using the Maker API for Home assistant (similar to the HomeKit integration, which is blazing fast) would be great!

Also.. wow. Homeseer is going to have a major update and enhanced Zigbee is coming. Things are about to get interesting!

I build my original "multiple Hubitat array" using HubLink/Link2Hub pairs. It has limitations. I worked around all of them. I had to make virtual devices and Rules/Automations to get unsupported attributes and commands to be visible on another hub. It's more work, true, potentially quite a bit more work.

Before transitioning over to HubConnect 100%, I had both running simultaneously. At a time before EventSocket. Both HubLink/Link2Hub and Hubconnect in those early days ran only as http (oAuth).

I had slow downs before transitioning to multiple hubs, never since.

Some of this delay is that some messages posted to MQTT - for example the state payloads are acquired from the device and if that is Z-Wave or ZigBee there's a time delay. Nothing I can do about that. I post the update to the device and it responds with an event. I could of course 'fake' the state so if you ask it to go to state 'off' I immediately update mqtt with 'off' and then just send off the command to the device. HomeAssistant does this - it's called 'predictive state' .

One other observation more on topic for this progressive slowdown. I've noticed in my MQTT app that it was very easy to get concurrency - i.e. several instances of one app running simultaneously. In my case I noticed it when the MQTT broker connection broke and I was recovering by restarting the app when this happened - but this created mutiple instances of the app , and the more there were the slower HE got. Of course a restart fixes this, but running the app again with a config change through 'done' makes it worse.

This could be another aspect that can cause hubs to progressively slow down - really easy to accidentally create - and it's not at all obvious that you even have multiple instances running - I only noticed because of duplicate log messages ..

1 Like

LOL... yeah interesting is a word for it.... LOL.....

1 Like

I interface things through Polyglot into my ISY. My ISY controls all of the logic. I use HASS for the UI to have a nice dashboard of my overall system. I use Node-RED for one off things mostly prototyping to then develop a nodeserver for things I intend to use long term. I do use other Node.js services stand alone such as jinshi's Sonos HTTP API which is excellent.

Networking is not my specialty, all I know is that the command I sent the HE ended in lanautonegconfigenable. This would seem to enable auto-negotiation, yes?

It's very interesting that auto negotiate would be disabled by default. That used to be the case years and years ago as auto negotiate between servers/switches was sometimes a problem (looking at cisco) but I haven't encountered that problem for over 10+ years now. Interesting.

I go hubitat <-> Node-RED (event socket or MakerAPI depending on what I'm doing) <-> home assistant. It definitely has some delay doing that, though.

I'm using EventSocket and MakerAPI between systems.

Hubitat <--> ISY

Several things feeding/reading from ISY including Home Assistant.

It's MY belief that that command does the opposite of it's label... it's a disable of autonegotiation. It's like a Monty Python sketch. :slight_smile:

2 Likes

Oh now that would be interesting.

It's my belief that THAT command is a forced "100/full" vs the more correct "auto/auto" out of the box.

The hub is shipped, auto/auto and that command will change it to be 100/full.

It's also my belief that the problem is C-5 specific. I have one, I have it plugged into a Netgear switch and I asked about this patch. I didn't need it.

I have a C-5 hub and a Cisco router. Courtesy of Comcast, trying to get any interesting info out of it is next to impossible. For a variety of reasons, I live with it. I don't want to buy another hub or move to Node Red/Hass. That's where I came from, as well as ST. I'm in the "I want it to just work" camp. I don't mind tweaking now and then, especially when adding new things. But I don't want to babysit it constantly.

I'm trying an experiment.

The automation that gives me the most trouble is the one that runs my kitchen lights. It's always the one that slows down first, even when other things are working as expected.

Most of my lights are Hue bulbs attached to a Hue bridge. My kitchen has 5 can lights. The Hue app sees them individually and as a group called "kitchen." Both the individual bulbs and the kitchen group are visible on HE. I always turn the lights on/off as a group. The kitchen lights automation uses the Hue kitchen group to prevent popcorning when turning the lights off and on. When I start having problems, it usually shows up first as one or more bulbs not turning on or off correctly, or not turning to the correct dimmer level. Following that, eventually the lights will turn on correctly, but slower and slower and slower. Reboot fixes it. For a time.

Now... my experiment... I've created an HE group called "Kitchen Lights" using the 5 individual Hue bulbs. I've changed my kitchen lights automation to use the new Kitchen Lights group instead of the Hue kitchen group. Then I rebooted, to get a fresh start. So far, it's all quite snappy. We'll see how long that lasts. I've turned off my auto reboot rule so I'll get a fair representation.

1 Like

This is not scientific but more of an observation of the slowdown. I have noticed that the HE hub (C-5) in my case seems to process everything as a single thread, or single file. As long as everything is working correctly the line moves along nicely but if for some reason there is an issue, whatever it is clogs up everything behind it. An example may be an app trying to communicate to the outside world and it can't so the app sits waiting for a connection. Instead of stepping out of the way (de-prioritize) everything behind in the queue piles up waiting. It could be a matter of this queue filling up and causing everything to slowdown. I can understand support wanting people to disable custom app/devices because they could have been written without the logic to handle unexpected conditions. I am speculating on this but believe the SmartThings platform they detect these conditions and can disable or limit these apps so they don't snowball and bring the system down. Very early on they had platform problems caused by misbehaving apps.

Just my 2 cent opinion based on what I experience.

3 Likes

I have barely any drivers or apps installed. Iā€™m also experiencing slow downs.

Is the slow down to do with rules? For instance do the motion sensors continue to detect as quickly yet the rules run slower, or is it everything ?