So, I'm about 3 weeks into using Hubitat. I think I may have went overboard with shiny and sparkly Apps. First week or two of using Hubitat, response time was fantastic. Lights would come on in like a second.
I've noticed a gradual slow down for everything over the past week or two. Now, some lights take up to 10 seconds (or even longer) to come on. Definitely not acceptable WAF, and embarrassing when guests are over. Also, going into the Apps, Logs, Devices sections now take like 5-10 seconds to load. It wasn't like that in the beginning.
Do I have too many Apps running? Any way to track down what is slowing everything down? I've seen people mention running two hubs - can I dedicate a new hub to just motion based rules and apps to keep it snappy? Then, I'd leave all the fun Apps on the secondary hub.
You can certainly use two hubs, though at the moment you'll have a hard time finding a second one (they're currently out of stock--hopefully more coming soon?). But what you suggest is indeed possible. I actually do almost exactly what you're suggesting: all my motion-lighting rules are on one hub (I want those to be as fast as possible), and the rest is on another. Technically the first hub also does all my Zigbee devices (I didn't want another mesh) and the latter all my Z-Wave (most of which aren't used directly for lighting), but I think my lighting hub is now free of all custom apps except ones I wrote myself, so it's more or less achieving my goal.
However, the problem with your hub is one I'd be interesting in solving regardless. There's no good way to track things down without putting in some effort, however. Some things you can ponder:
- Did you notice a change after installing a new app/driver? Try disabling (see the "X" icon in the upper right of the device and app list to expose this option) or uninstalling it to see if that helps.
- Are you using any apps that are known to cause issues for some people? I hate to point any fingers here; older versions of webCoRE were problematic for many, but I think people have better luck with the current fork. The beta Chromecast integration seems to cause slowdowns for some. If you went wild installing custom apps and drivers, those are definitely things to consider (and a second hub dedicated entirely to questionable code could indeed help the other)
- If you're using all stock apps and drivers, the above would be less of a concern, but I'm sure staff would be interested in anything you find. If you have poorly written rules (one of the few built-in ways you can cause problems for yourself given the power it provides) or questions about those, feel free to ask! If you are using lots of custom apps/drivers, consider built-in solutions first--they can do more than some people give them credit for.
- Sometimes you can also look at logs (or really Past Logs) to figure things out: anything throwing a bunch of errors? That could be a poorly written app or driver, or it could point you towards another problem. But general slowdowns may not produce much of interest here.
Finally, you can also consider some odd cases that might make things worse:
- "phantom" Z-Wave devices (should be cleaned up automatically overnight and probably not an issue for many people in the first place, especially if you didn't have problems including a Z-Wave device and had to try multiple times)
- Dashboards with "use all devices" selected (makes them slower to load but I'm not sure it would have much of an effect beyond that) or "ghost" tiles that point to a since-removed device (something we've been told recently isn't good)
- probably more that others can add to this list that I can't remember at the moment
... but these are all less likely and probably not where I'd start my work.
Rather than doing much troubleshooting, some people also schedule a reboot if they find that a reboot is helpful (as it may be, at least temporarily). There are different ways to do this, including a few rules in this thread and some community apps you can find in others. I'd consider this a band-aid myself, and it's not something you should have to do, but if it works...
That's what I do. I wanted to run lots of "fun" 3rd party apps without slowing my hub down (not that they did, just my preference). I use HubConnect to send "real devices" to the 2nd hub. My "Devices hub" runs just lighting, and locks. All other rules and apps run on my "App and Rules" hub (and a couple troublesome Zigbee light strips).
Did it make a difference, marginal. Does it make me fell like I'm not "bogging down" my device hub, yes. However this may need to be a longer term goal, do to the shortage mentioned.
I'm in the daily reboot camp. I have more devices then I care to go thru to find the exact issue. While I will concede it is a band-aid 'solution', it works for me. IMHO its a no harm no foul rule for my hub to reboot while I sleep (stay away from the 2am maintenance windows if you do).
If you want to get to the bottom of it. I would disable apps, and devices starting from newest to oldest. It did not seem obvious to me at first, so if you do not know the gray "X" shown below, and at the top right in apps and devices will display a "disable" check box. You can use it to do the above, and then re-enable them after finding the offending device or app.
If you find out exactly what it is please share!
Are there alternatives to this?
I'm not sure--there are a few community Google-oriented integrations, but I'm not sure any would replace the TTS function if that's your reason for using this. There might be workarounds if you have an ST hub (or at least ST account) by putting that in the middle of things, but I only have Alexa at home to test with (and nearly gave up on all TTS besides Sonos), so other people probably have better ideas here.
I'm keeping an eye on the logs, and noticed this noisy device... Nobody has been in that area for at least 20 minutes... Seems a bit noisy, no?
Guessing I need to reset it and remove / readd - but any ideas? Would something like this slow down Rule Machine Apps?
@bertabcd1234 By the way (should have mentioned this before) - thank you for your detailed response.
I've been watching the logs for about an hour (and found that kooky door sensor above).
I also removed the Chromecast integration (I couldn't get it working anyway), and restarted the hub.
I happy to say the response times are back very impressive. I think I will implement the 2:00 am reboots. (Thanks, @TechMedX!)
You might get better help if you provide more information about the device, but I might assume from looking at your logs that it's a SmartThings Multisensor. The events it looks like it thinks it's moving, which I'm assuming it isn't. With some Zigbee devices, I've seen them send spurious events if the battery goes low, though your still reports a pretty high battery level (side note: these reports are notoriously unreliable). Changing the battery might help (but might not); I'm not sure I've heard of a re-pair solving issues like this, but it's also pretty harmless to try (tip: easy for Zigbee if you don't delete the device from Hubitat first since it will recognize the re-paired device, unless you also want to remove it from all apps/rules). Even as-is, I'm not sure this would be enough to noticeably slow down a hub unless you have a lot of complex apps/rules subscribed to events from this device, something you might have a better idea of.
In the meantime, glad the reboot helped! If you automate this, I'd probably avoid 2 AM specifically since that is when the hub does its nightly maintenance. If you ever narrow down a specific app/drive or combination, I'm sure others would be interested in hearing...but sometimes just settling for the reboot is good enough (I do this on one of my hubs...some day, I'll probably try setting it up from new again and see if I can do better).
Yup - SmartThings multi-sensor v1. I may end up ditching that one anyway. At the very least, I'll change out the battery. Correct - it's not moving, nobody's even over there since about 2 hours ago.
I'll give it a few days before implementing the nightly reboot to see if maybe it was the Chromecast Integration. I'll update here in a few days.
Another thing you could try: if that ST Mutlisensor (v1? wow! I thought I was the only one who still had one of those...) paired with the wrong driver and you changed it after the fact, hit "Configure" on the driver page. You could try that even if it did, I suppose (re-pairing usually also forces this command to run, probably one of few ways that might help). It does seem odd that it's sending reports without anyone there, though it wouldn't necessarily have to be a person in this area to cause this sensor to send events since it's detecting vibration--possibly slight--and not "motion" in the sense of a person (or object with a similar IR signature) moving across a lens.
DO NOT set your reboot at 2:00am that is when the hub does maintenance.
Pick another time like say 1am? or 3am?
Just to check back in on this... It appears I need a reboot about every 3 days. I've been waiting to see how it behaves, and then manually rebooting. I'll set up a 4:00 am reboot daily and I should be good.