My Hub has been relatively slow acting most of the time, especially RM. I had the issue the other day about the time not updating when my internet was down. I contacted support to let them know I was one of them affected.
Their response mentioned it was hard to trouble shoot my hub as Echo Speaks was filling up the log with errors, about 1 per second. Now that was really interesting. I had disabled Echo Speaks about 1 week prior to this. And I DID NOT see those errors in the log. Apparently support can see logs I can't. And with the app disabled it didn't make any sense.
So I deleted Echo Speaks and all the Echo devices. Just to be safe I also re-booted hub. Ever since my system has been very fast. All the slowness is gone. RM responds like I always thought it should.
So just something to be looked at if others have the same problem. Still don't understand why I couldn't see the errors in the log or why they were even occuring with the app disabled.
Thanks to support for seeing this and letting me know.
Didi just disable the app or also the devices? It could be that the devices were throwing the errors since they couldn't use the parent app as it was disabled.
Just keep in mind, this is not normal Something is causing this... Often, but not always, is it related to apps/devices that try to talk to 3rd party services via ethernet/cloud or apps that subscribe to all kinds of events. The latter exaggerate the issue if you run a "massive" good night routine that turns off all kinds of devices. Most of the time, people look for that ONE app that is causing it but keep in mind, it might not be limited to one app.
Agree completely. However, I couldn't figure it out by disabling apps. And scheduling a weekly reboot through my Odroid resolves the issue sufficiently for my needs.
What I've noticed is that the httpGet and httpPost methods sometime struggle with the response from Amazon.
It returns a exception error of no json exists. I'm not sure what's different in Hubitat's version of the httpXXXXX methods to ST's but it's definitely struggling with this. It seems to work for some users and not others.
Amazon doesn't always return pure JSON data. Some of the json contains a stringified version of JSON in the sub elements.
If someone has a more efficient way of doing this stuff I'm listening... I don't think that asking people to remove an app is a solution. There is clearly an underlying platform issue somewhere. I'm willing to work with the engineers to help solve it they feeling it's worth there time to solve
I think I have moved almost all of my apps and drivers to use the asychttpXXX methods to circumvent any "bad" behavior there. It is more work for me as I need to think about more edge cases but it has proven (not scientifically) that I had better behavior then.
I agree with you, there is something in the area of the http communication that is definitely a factor here.
That is really not what the Hubitat teams wants either, but it get's often misunderstood. What they are saying is:
Disable the app
if it fixes your issue, contact the developer of the app
We are very happy to work with the developer to fix the issue, especially if it is on the platform end, however, we will wait for the developer to reach out to us
Often people think that the Hubitat team asks to remove the app even though they ask to disable the app (or driver). They just want to isolate the issue.
I know it can be frustrating, especially if you want to rely on the function that that app or driver provides. At least for me, I rather take this approach than a completely locked down system that wouldn't let me add apps or drivers....
We are not asking people to remove their custom code. But in our effort to troubleshoot what might be causing a hub to go unresponsive, we ask to temporarily disable custom code. If someone doesn't know how to disable an app or a driver, please see "Disable Device Drivers" and "Disable Apps" sub-headings in the following documents:
I hope I didn't mislead anyone here. In my case it did appear as if Echo Speaks was at least part of my problem. Re-boots never helped before. Support didn't ask me to delete the app. I just did that to see if it solved the problem.
What is still puzzling as to why I couldn't see the errors in the log. But if they were occuring about every second I can see where that used a lot of resources.
I hope @tonesto7 figures this all out. I like Echo Speaks and would like to use it again. But for now I can get by without it.
""In @j715 's case, it appears that the app was disabled but the Echo Speaks drivers were not, and they were likely still used in some rules.""
As far as I could tell I had removed the reference to any Echo devices in any of my apps. But it's always possible I missed one somewhere.
EDIT: I knew how to disable apps, but never realized the same thing applied to devices. My bad. Now I know.
I'm also in the reboot club, every 5-8 days it seem like. I know it's time to reboot when my motion lighting is slow to respond, after a reboot its back to normal. I do run some custom code/drivers - dsc envisalink integration, driver for lux from apixu, driver for fibaro dimmer 2, drivers for xiaomi. I've noticed these slowdowns early on as well before I had the custom code. My zigbee network has been 100% stable even with the handful of xiaomi devices until yesterday. None of my zigbee devices were responding but the radio still showed online and I was able to see all devices through the zigbee logging. Oddly I noticed that the hubitat nightly backup didnt happen at 3:05 am like it normally does for the last few months, instead it did it at 10am. Shortly after that is when I noticed the zigbee issues, my channel changed from 20 to 11 on it's own too. I immediately thought db corruption and restored from a couple days prior, all is well now for almost 24 hours. Odd why this would of even happened, I may just get rid of the xiaomi devices it this happens again.
I didn't take it negatively... I know my codes not perfect
I did make a lot of optimizations in v3.0 to hopefully make the json errors occur less. You can join the slack channel to access the new beta and let me know if it runs any better for you.
I will throw in another "me too" on the slowdown. After rebooting the hub it runs great for 5-6 days and then starts to bog down. It has never gotten to the point of crashing but if I left it I gather that it eventually would. I don't run Echo speaks or Alexa or any other voice response system, I do run that other rule engine though. I make heavy use of http get statements that contacts my hub every two minutes to make sure its still on the network. Starting usually on day 7 or 8 I start noticing the remote http get statements starting to periodically time out. The longer I keep running the hub the more timeouts I get. Also the nightly backups take longer and longer to run. On day 9 the hub is barely running. The backups that start at 2AM never finish by morning. The hub has all the classic signs of a memory leak but without any diagnostics there is no way to know. I just put up with it hoping they figure it out. Because I run that other rules engine I don't contact support but I am pretty confident it isn't the problem.
No issues until, today, when I noticed that it had stopped working. I spent a bit of time trying to get it to refresh the cookie... then my hub started hanging and I had to reboot....
Isn’t it apps and drivers that have memory leaks ?
That’s what support tries to locate BUT you need to work with them. They KNOW the Hub, their Apps and their Drivers. They’ll try to get you Hub to a known good state and work from there.
It sounds like you’re suffering unnecessarily.
“They” are probably never going to figure out a solution for the exact problem YOU have because it’s unique to you and who are “they” ?
Hubitat Support seem willing to work WITH YOU, Are you ?
My setup is obviously very different to yours especially as it NEVER gets rebooted !
I decimated my hub over the weekend. Slow. normal split second responses taking 20 min to happen. Editing a malcontent RM4 was taking 20 min to get into the (large complicated) rule. I did it to myself, some how I wound up with an "IF()" The hub did not like that. Seemed impossible to correct. Open rule, go do something, come back hit "edit IF()" go do something, come back attempt to edit (add conditional action). watch it not do it, start again. Eventualy the stars aligned, and it worked, as did the rule,and every thing else. now back to flash Gordon!
Lately it seem to take 4-5 seconds for lights to respond to RM4 commands. Today when leaving, I open the laundry room door and it's supposed to turn on a GE outlet that controls my garage door....... 28 seconds later according to the logs, the outlet was turned on.
The days of milliseconds, everytime, seem to have gone the way of the dodo bird.
Is this Z-Wave or Zigbee? This is definitely not normal. Do you have anything going on with LAN devices / integrations? Something is dragging your hub down. Challenge is to find what it is.
The contact sensor is a Centralite 3320-L Zigbee, the outlet is a GE Z-Wave.
I use Alexa Speaks, Amazon Skill, Enphase Solar, Welcome home.
As for drivers, I do use GE Z-Wave Switch/Dimmers from Botched1 and Iris Smart plug from Shackrat. The rest is stock.
The day before, it was nearly instant. In my case, it doesn't slow down to the point of needing to reboot the hub, just sometimes it's super fast, other times... not so much
Typically they recommend first eliminating user device drivers and apps as much as possible, so I would switch out your GEs for Generic Z-wave Smart Switch/Dimmer, and for the Iris smart plug, the Generic Zigbee Outlet driver, both work well for me.
Something is causing this... Often, but not always, is it related to apps/devices that try to talk to 3rd party services via ethernet/cloud or apps that subscribe to all kinds of events. The latter exaggerate the issue if you run a "massive" good night routine that turns off all kinds of devices. Most of the time, people look for that ONE app that is causing it but keep in mind, it might not be limited to one app.
