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
3 Likes
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....
1 Like
That's the first thing I did with v2 of the echo-speaks. Almost every call is Async
I would reach out to the team in PM describing the issue you are seeing. I am sure they are more than willing to help.
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:
https://docs.hubitat.com/index.php?title=Devices
https://docs.hubitat.com/index.php?title=Apps
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.
2 Likes
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.
2 Likes
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.
2 Likes
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.
1 Like
I’ve been using echo speaks for around a month.
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!
1 Like
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.
Bruce,
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
I'm open to your ideas
Rick
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.
I use the botched drivers and haven’t seen any errors with them. I have a combination of iris V2 contact sensors, centralite and Hue motion sensors, zigbee bulbs, and 11 ge/jasco zwave plus dimmers and switches. I would disable the echo speaks app and all drivers and see if the problem is resolved. There is a new echo speaks app in beta that is attempting to address the issues with it. I had slowdowns across zigbee, zwave, and the web ui to the point of needing to reboot every other day before I started using the beta. My hub was immediately more responsive after installing it.
Speaking of things being challenging, are there any plans to make the logs that support has access to available to end users? It sure would be helpful if I could correlate the logs I see with the logs you all see to track down what is throwing errors on the HubAction process. I realize you all don’t want folks to have access to the device, but something like a setting for remote syslogging of the OS/Hubitat process logs would save lots of back and forth. I’m resorting to putting my hubitat on a span port to sniff traffic, then asking support for the logs of when my errors are occurring and trying to look through captures. As things are today, I’m with most of the folks above and have to reboot every 8-10 days.
search for "syslog" -- it's been covered repeatedly.
Synopsis: All logs visible to Support have been duplicated to the logs we can see. When they find one that isn't, they add it to the next build.
Exactly that happened, and for a day or two, people were seeing errors that didn't exist prior. "Sky is falling... oh, never mind" LOL
ws://[hub ip]/logsocket is also available.
