I asked support through an email but they didn't offer much assistance and just responded to say its a known problem... And ended the support request. Little strange and not very helpful.
So here I am hoping there is a way to find out what is slowing my box down after a few days. Can it be a memory leak or something? Why after a few days, then after a reboot it goes back responsive again.
I am not aware of any new apps, drivers or rules causing it all of a sudden. And wouldn't that mean it will be there all the time, not occurring a a few days after a reboot. There is no tool for me to find out is it a CPU thing, a memory thing... Poor programming if a rule or perhaps a device polling..
Is there a known bug that is getting looked into? I was a little disappointed with the response logged through through a support email.
For people experiencing issues with their hub this does seem to be a common symptom.
Slowdowns can occur due to (in no particular order):
custom apps/drivers.
lots of "heavy" rules in RM - better to use the lighter weight apps if possible.
Spamming Maker API app with too many requests.
flaky, ghost or out of range devices.
hub overheating.
bad power supplies.
misbehaving ethernet port.
possible but unlikely "bad" hub.
I've experienced 5 of the those in the list above - custom apps, spamming, flaky devices, overheating and a bad power supply. To be completely fair most of them except the powersupply were the result of my tinkering around with things using various devices not necessarily on the okay list etc. etc.
In terms of troubleshooting - yeah there is no way to get what you are looking for and the HE Staff have argued don't really need. Yes this can be a bit frustrating to hear if you are technically inclined.
I would be interested to know exactly what support has said here. Hearing that it is a known problem seems unlike the hubitat responce I have seen here that it is a problem with some other code or some other device.
I have recently noticed some slow downs after adding sonos devices(only one device). I have seen others mention nextwork side issues. I show a quality of 85% in UBNT. Whatever that means.....and I can connect a raspi with the same powersupply and network cable/port and it gets 100%.
Hoping to see a update that hints to something done in the network stack soon.
"heavy" rules in RM (with possible conflicts between rules)
Ghost/stranded z-wave devices (support discovered I had these)
Spamming MakerAPI
Identifying/fixing these issues took time (maybe 2 months). But since then, I've had zero slowdowns. The last several times I've had to reboot has been for platform updates.
Edit: For my RM issue, it was easier for me to move my automation logic to NR. Which is when I had the MakerAPI spamming issue - but that was relatively easy to resolve.
This is good advice. It's annoying to have to do. Of course the hub should do absolutely everything you need in a Home Automation set up, all for 100 bucks, and should perform perfectly with blinding speed at all times. But back in the real world it doesn't quite work like that. I moved all my lamps back onto Hue to separate out my devices into 2 separate zigbee meshes (this could also be achieved using 2 HE hubs) and put time-sensitive (motion lighting) rules into node-RED. It was worth the effort.
Sure. Making 100s of MakerAPI requests within a minute (or less) because of a badly configured NR sequence (for eg. one that has a msg going in a loop without an RBE node in the loop).
That is a definite plus. I swapped my zigbee devices from Hubitat to zigbee2mqtt and back again without completely redoing my rules - just the input/outputs.
Unfortunately Pinpointing a rule may be very difficult without a tool to monitor overheads as I haven't noticed a sudden change. Yes I have many rules and many probably not well written/efficient. I guess when the slow down occurs I could go through each of rules and pause one by one to find the one that stops the slow down (say my motion sensor to turn the light on as a guide of the slow down). Although this relies on it being only one rule otherwise this will be extremely difficult.. Also if I need to reboot as well then that would make it even harder as I'll need to wait a few days with a rule off to see if it fixed it.
The maker api being called frequently.. Well I may have say 10 devices at maximum call it each minute so assume that isn't it?
Moving to node red.. Well maybe that's an option. Off memory that offloads processing to a rpi. May go looking at that option again as I didn't realise the benefit last time I looked at it.
Poorly written apps and drivers... Hmm the latest I have is the broadlink and associated hvac app/driver so possibly that although I haven't seen any reports of that from others.
Questions. If it was a processor overloading due to poorly written rules, bad drivers or too many maker api polling then wouldn't it be slow all the time? I'm not expert on any way, but my experiences with slow downs after a period of time is a memory leak/usage and a reboot helps with this.
What is the best way to disable apps or devices to check if the slow down disappears? Might need to look a little more into this. Although it would need to speed up as soon as I disabled things. If I also need to reboot then this debugging will take forever as the next slow down may be days away.
Perhaps I misread the hubitat reply and they are still going to reply (see attached) ... Seems they just pushed me aside though as I also haven't heard anything back from them. Seems there is some good help from the community at least.
I know a lot of people have off loaded to Node-Red but in my opinion people shouldn't have to do this to get things to run smoothly.
Personally my hubs are running OK and I do do a restart in the middle of the night once a week just because I can.
Just my 2pence worth.
I suppose you could take that last statement a couple different ways. I don't think they intended it to be negative, but I can see how it could be interpreted that way.
Maybe it should have said "Please note that further replies to this ticket will not receive further response at this time." or "We ask for your patience while we investigate this issue, but in the meantime we are closing this ticket."
Probably not my best creative writing above, but I do think they could have been a little more sympathetic.
I have seen this same response before. It seems to be the boilerplate for..this isnt something support can fix so we are sending it to development to be looked at and prioritized, and added to a queue.
Do you have a any/any land integrations. Do you have a smart switch that could tell you if there are interface issues. I have seen of talk about a few times
I feel this should not happen for a dedictaed automation hub. Especially seeing it develops over time so its not an immediate bug in my rules, apps or drivers I feel..
However perhaps the next bet for me is to have a rule that says
"if 48 hours has expired, all lights are off, there is no motion sensed for the last hour and climate control are turned off then reboot the hub"..
I'd like to think that I could monitor a motion detection rule to say if it takes longer than 2 seconds to finish the rule (variable set to current time at the start and another variable set to the end time) then reboot the hub" however I believe the rules are likely running quickly, just they are taking time to trigger so this wouldn't work. Maybe I can look into that as a dodgy work around.
Yes I shouldn't have to do that, but it could be an easy band-aid fix for now.
