See this part right here is not the fault of ES.
If you can remove ES and the hub still runs like crap there is a larger platform issue at play. The hub should be able to regulate the logging which is likely why the lockup is occurring.
1 Like
And I am sure this is a yes BUT did you run a zwave repair?
1 Like
I had to Shut one of my Switches off yesterday Hubitat didn't like that very much the log went nuts and things slowed to a crawl. After getting the switch back on all the Speak Notifications that I have in RM4.0 wouldn't work the ones I have setup in ES actions worked fine. I had to shut the hub down and do 2 zwave repairs to get things back to normal. No clue Why I had to do a zwave repair but it worked to get things running like normal.
1 Like
I started thinking about this today... In an effort to help work through the cause of the issue and point the engineers in the right direction.
- I did find some minor bugs in the request logic, but nothing that could cause a loop or massive resource drain.
- The code works well for a majority of users, except newer users.
- The code works flawlessly on ST.
I agree btw. I am just prescribing troubleshooting methods to get Hans back up and running with his zwave network.
2 Likes
I know... I'm only trying to document my thoughts in hopes it might spark a light bulb in someone as to were to look for the issue.
The truth is that Echo Speaks is very complex app and driver which seems to be good at bringing out this platform issue 
So maybe it will be useful in finding it and fixing it once and for all...
2 Likes
I'll also add one more weird thing once I got my hub back to normal it ended up processing all the prior notifications for like 15 minutes straight I was getting speech notifications. Even after a hub shutdown I thought that was crazy.
Can you share your platform and hardware version?
is this what you need?
My hub slow down and weirdness was self inflicted this was the first time I had any trouble since beta
You should never be able to slow down the platform...
2 Likes
Hi, @tonesto7. Here’s my info. I would note that after I removed Echo Speaks and deleted the apps/devices and code, completely shut down the hub for a few minutes, and booted it up again, the problems began to resolve themselves. Performance is mostly back to normal now for me. I do think the issue must go deeper than Echo Speaks to the platform itself, as it would seem bizarre that the slowdown continued for a while for me after the app was uninstalled.
1 Like
I agree it's crazy. I can't even say for sure that ES was the cause or really what was going on. Why doesn't Hubitat let us look at the hub resources and real time processing things like that.
Thanks for sharing... can you post in that other topic just so it all in one page
I think the complexity of ES is was forces this issue to rear its head more often than other apps.
ES makes a lot of repetitive web requests every couple minutes so if something is amiss in the platform network stack it will show it's face much sooner than other apps.
1 Like
For my own info, if I use the local version of the server software, does that eliminate the web requests?
EDIT: Some of them. I understand the software obviously still has to go out to Amazon servers.
nope... the server is strictly for authentication and cookie refresh (We can't host the login proxy in Groovy)
RELEASE (V3.1)
══════════
Main App (v3.1.0.0)
September 24th, 2019
══════════
• UPDATED: Massive overhaul of the web request response and exception handling.
• FIXED: Required updates message for actions app. Even after pressing Done.
• UPDATED: Optimized and reduced the amount of repetitive web calls.
• UPDATED: Converted most async commands back to synchronous calls for speed.
• FIXED: Notifications device support
• UPDATED: Notices for upcoming SMS support removal from Hubitat and SmartThings (UK) platforms.
• FIXED: Device test fixes.
• ADDED: Duplicate existing Actions. (ST only at the moment)
• ADDED: Support for actions guard triggers.
• UPDATED: log output cleanups.
══════════
Actions App (v3.1.0.0)
September 24th, 2019
══════════
• ADDED: Guard Trigger events.
• ADDED: Control switches (on/off) when executing action.
• FIXED: notification capable device support.
• FIXED: Alexa Mobile notifications should now work.
• FIXED: Action test would not run on new incomplete actions.
• ADDED: Support for Duplicating existing Actions.
• UPDATED: Notices for upcoming SMS support removal from Hubitat and SmartThings (UK) platforms.
══════════
Device (v3.1.0.0)
September 24th, 2019
══════════
• ADDED: Follow up Auto Reset Queue (xx seconds) after last speech command. Adjust each device under the devices setting page. Default is 180 sec.
• UPDATED: Massive overhaul of the web request response and exception handling.
• UPDATED: Converted most async commands back to synchronous calls for speed.
• UPDATED: log output cleanups.
• FIXED: Minor bug fixes.
2 Likes
Please let me know if you find anything broken. I've been testing it pretty hard.
I have really good exception handling now. So this should be a lot more stable
3 Likes
I ended up removing ES and then doing a shutdown. When the system came back none of my MS worked. Did a reboot and the MS came back but my multizone MS rules weren't firing. Deleted them and remade them and the work again (they were showing motion, and the logs were saying they were switching on the lights but they werent). I cant say that is a ES issue, but thats my experience after removing ES. IF ES gets to a stable level I am sure to revisit it as I have way too many echos not to want to use this.
ES has been stable but has had some minor bugs with handling erratic responses from Amazon which seems to bring this thing crawling.
I've rewritten all of the request logic... It should now handle all of the responses good or bad in a graceful manor.
I recommend you try it out now. If your hub slows down again then I'm about 99% sure that it's not ES anymore.
2 Likes
