I thought we were advised against that.
Against doing a reboot using the POST url? I've never seen any HE staff post that, but I could have missed it somewhere.
It was not the recommended way of "fixing" the issue. The staff believed that doing scheduled reboots to avoid a crash was simply masking the issue. I agree, if there is something bringing down your hub, it's best to find and deal with it. The longer you wait and the more app/drivers you install, the harder and more inconvenient it would be to find the culprit. That's what I ended up doing. A real PITA but at least my hub has been humming along since.
2 Likes
sure. or HE could provide us the tools to actually find the issue....
2 Likes
I'd love to run ps aux, or top on this device to narrow down the service causing the issue.
Search the forums. This has been discussed ad nauseam. Not gonna happen anytime soon if at all.
2 Likes
or just better hub specific logging. hell, being able to redirect logging to my syslog server would be handy.
2 Likes
I can't disagree, however, to be honest, my hub is damn near stock. I have literally two custom apps running (Alexa TTS Skill and NOAA Weather Alerts) and 5 custom drivers (ApiXU Weather Driver, Child Alexa TTS, Child Switch, Logitech Harmony Hub Parent, Sonoff-Tasmota). Everything else on my hub is stock HE apps/drivers.
I've disabled all of them at one point (for days) and my hub still slows down at random times. I'm fairly confident in saying that the blanket statement of "it's a custom driver or app causing the slow down" is exactly that; A blanket statement.
I truly appreciate the HE staff members and the insane amount of effort they put in day in and day out, but I do have to say that I am a firm believer that there is something going on in the core OS of the hub itself that causes the slow downs and not just a custom app or driver.
6 Likes
You can do that, but it's not supported (obviously).
So it sounds like we'll have to manually go into our hubs every 3 days and do a reboot ?
Isn't the device ID named at the beginning of the line. If you click on it I thought it would take you to the device.
Not sure though.
Guys,
One thing I have noticed when looking at hub logs is that cloud/online stuff is very often the cause.
More so than ‘bad’ code.
If the hub calls out to a cloud service, it can often sit there for a while waiting for a response or waiting to timeout.
If you have any cloud based apps etc, this is the first thing I would disable, then reboot and see if the issue comes back.
Unfortunately, I know this is a pain and it can take a couple of days to show anything like a result but it’s where I would start first when troubleshooting.
Andy
2 Likes
Define "cloud/online". You mean local lan, or actual cloud stuff? That would say to me HE needs to work on their async a bit better so the whole hub doesn't basically lock up waiting for a response.
1 Like
You know this was my next suspect. I have seen a lot of Ecobee errors in the logs lately and even some for Sharptools. So now you got me thinking if Ecobee could be the cause.
2 Likes
I do have Ecobee enabled... and they have been having issues (Ecobee). Still... HE shouldn't just grind to a halt if it doesn't get a response. =/
1 Like
I also have ecobee
1 Like
I've thought about that as well and wondered about going in and changing them over to asyncHttp calls (if they aren't already).
As do I and it's one of the apps I didn't disable when I was doing my hub troubleshooting. Maybe it's time to finally pull the trigger on the C5 thermostat. 
We should test first.
Man that will suck if I have to switch my thermostat now. Does the c5 control a humidifier ?
fwiw: https://status.ecobee.com/ (sadly, ecobee doesn't offer response times like some other status pages do).
But yes, test first. Maybe also see if HE staff can chime in on if they've seen anything on their end. Or if driver changes might help with this.
