So I've noticed as I've added devices and more rules hubitat is getting slower. Much Slower. and by slow I mean:
Alexa tells me a device is not responding a few seconds before it responds.
The device page taking 14 seconds to load up.
7 seconds for a rule to load up and each action in the rules taking that long.
Completely local Rules taking 5 seconds to complete.
I have tried removing things and I upgraded to groups 2.1 as soon as I can looking for the speed boost. and I've never installed webcore.
The question I have: is hubitat going to release a new hub soon with the processing power needed to handle these process in a more reasonable time?
OR Will Hubitat have the ability to offload most of its processing power to a PC?
How many devices do you have? About the only time I notice mine running slowly is if I try to open on of my weather devices (I think because of the massive amounts of events stored there), on bootup for the first few minutes as things are starting, and when I go to make a backup. Otherwise my hub runs along just fine with motion or switch/button/contacts triggering motion lighting, simple lighting, or Rule Machine rules within about a second.
What type of network switch are you connected to? There is an incompatibility with some network switches (e.g. Netgear) and auto-negotiate that can cause communication issues and cause the symptoms you are having. There is a fix available that you can get by contacting support@hubitat.com
I got my main hub running more smoothly again this morning by doing a shutdown, pulled the plug for a few sec, plugged back in, and loaded the latest backup file. I had been doing an every-2-day reboot from the web interface with a cron job from my server, but that alone didn't seem to be keeping things up to speed consistently.
Everything is faster after doing the power cycle and loading the backup file, even pulling up the Dashboard pages, and general responsiveness of the Hubitat GUI.
I remember Asus and Netgear, not 100% sure about TP-Link. I would shoot support@hubitat.com and email to find out. Your symptoms definitely sound like it could be that issue
Your seeing a pretty large example of the "Hub Slow Down" issues we're all been trying to identify... There are several known situations that result in the same symptom: slow. One is, as already been discussed, the speed/duplex issue with specific Ethernet ports -- most often a NetGear, but certainly possible with any number of vendors. The specific symptom of this is usually: the web UI is slow, but the automations are running just fine.
You might well have that issue plus another.. so get the easy one cured first
The Hub itself is not CPU bound, meaning there's enough processing power for a large number of devices. A normally working Hub will typically be I/O bound. ZWave and Zigbee devices both use radio speeds that are a tiny fraction of Ethernet speed, which is a fraction of the quad core CPU/memory speed. Analyizing these factors is quite complex because of course it takes CPU and memory to manage queues of Events and to be updating the giant DB. You can perform a few known workarounds to see if any of them narrow down the specific component that is leading to YOUR specific slow down.
Reboots will reset counters and empty queues and unlock DB tables. It's a good second attempt (after checking out the 'netgear' issue, above) and would be followed by a third attempt, the Soft Reset. The technique is to get a Backup on to your PC then use the Diagnostic Menu to perform a Soft Reset which deletes the DB and doesn't automatically reuse an existing one. Then you restore the DB backup you just made and a large percentage of the time, any DB corruptions that might have crept in are eliminated.
In parallel, get a Ticket started with support, as many have said above.
I was still facing issues until I rebuilt a lot of my rules that were looking at multiple motion sensors. I ended up consolidating them and having it turn on or off a virtual switch. Then my other rules used the virtual switch as a trigger.
This seems to have fixed my issue.
Lastly, I took advantage of the motion grouping app and the motion lighting app.
I've also been told by the Hubitat team that shutting down of the zigbee radio is the first response to over-processing and over-heating. The two statements don't seem to be compatible to me. When my hub is really having problems, the zigbee radio goes offline. I haven't found the reason why after roughly a year of looking into it.
Yeah I have seen my zigbee network shut down about three times now in the last month or two. I’m not quite sure what the cause is yet either. The first time it happened I opened a ticket and was told it could be due to something hitting the websocket too frequently. I disabled a couple possible culprits but in the process of re-enabling the issue has started up again, so I’m still trying to figure it out.
I've connected a logger to the websocket in response to the poor performance, because leaving the live logging open in a browser just doesn't work out. By the time I review the logs, the browser is at a crawl due to memory usage of the logs.
Hadn't used websockets with the hub previously. So the problem preceded websockets.
I also authored my own occupancy app for managing the lights, because MLA and RM were exhibiting this behavior and I can't see what's happening inside of those apps. Now that I have, I can log the processing of the actions and I see once the event subscription is fired, the action is processed in milliseconds. So it's clearly not the apps. The hub doesn't log the reception of the message from the motion device during the delay that is occurring and event subscriptions can be even further delayed.
You have to see the device fire off the message and mark the timing in order to diagnose at all because reviewing the logs appears as if everything happens in a couple seconds max. When the problems begin, the messages stack. So in passing through several rooms walking across the house, the first room, 10 second delay, the second room that 10 second delay plus another 10 second delay for a total of 20 seconds, and so on.
I'm beyond my capability to diagnose further at this point. If I didn't see the hub struggling, I'd believe it was my mesh, but the hub will slow down, the radio drop off line and some times the hub shuts down all the way (though that's very rare).
I have rolled back, soft reset, etc etc. I'm out of ideas at this point. For the most part things work fine, it's just that 10% of time or so that this occurs.
I've also noticed if I leave a chrome tab open pointed at the hub that it massively slows down over time. if I reboot it and close all tabs then it runs much faster.
I have like 6 rules in the simple lighting app and that's it. I use this setup to control 2 bedside lamps. My rules run pretty slow. I hit the up toggle on the switch and sometimes it takes 2 - 3 seconds before the light comes on. Same thing with turning it off. It has never been even remotely close to "instant".
To be honest it's put a big damper on my enthusiasm and expanding.
That’s crazy man. There is NO way such a small system should run slow !
C’mon, do you really think the product would have been designed to be slow ??
I’ve no experience with those exact devices you’ve got but with the number of devices you’ve indicated, HE should be instant, fast. Like lightening !
Go in and pause EVERYTHING but 1 plug and 1 button and start over. Something’s been screwed up which can be quite easy when you’re starting out.
I still struggle at times but when it doesn’t work how I want it, I usually remove the Rule or App and start the Rule over.
I’ve noted a few times that trying to get an App / Rule working how I’d like, means I’ve often corrected and re corrected it and then I’ll remove the rule completely and start over. Just to clear out any “junk in the trunk” and ensure the Rule or whatever is clean and clear.
You may be experiencing poor communications due to the lack of devices. Zwave and Zigbee are mesh networks and rely on being able to relay messages between devices to get reliable communications between hub and device. With so few devices, there may be a poor direct communication between the hub and device.
