Looks like many people have had this issue... I've had two different C7 hubs since weeks after the release... both hang after running a day or two. And pretty much they do nothing. Only Amazon Echo app and MyQ app installed; no Z devices at all. For a year I only had Echo app, nothing else and it still hung daily.
I hard reboot and update to the latest OS anytime I care to mess with it... never helps.
I have the Rebooter app installed and it doesnt help.
I'm assuming Hubitat is just flat unstable but thought I'd ask before giving up and getting rid of it.
They're both on the latest platform version, and I only reboot them when the platform version is updated. The current up time is about 26 days.
The one on which the zigbee radio is active has about 50 zigbee devices and no z-wave devices. The other one (with the zigbee radio inactive) has about 60 z-wave devices and no zigbee devices. This one also has the Amazon Alexa Skill and the community MyQ integration.
If you are not on the latest platform, I'd recommend updating, and posting information that can help the community debug the stability issues with your hubs.
I hard reboot and update to the latest OS anytime I care to mess with it... never helps. At most its about 4 days before it hangs.
I just realized it might not have been rebooting with the App... I did not have the security switch on, so maybe it wasnt. Though, the apps screen didnt warn it is needed (not the best error avoidance), which it should if it is really necessary and the app doesnt have admin rights to do the only function it is made for
the C7 doesnt run anything needed - just voice notification on Echos - so I dont really care to mess with it much.
Seems odd that I've had 2 different C7 (got rid of one a year ago) and they both did the same exact thing... maybe I've just been unlucky and got faulty hardware but since my C7 does virtually nothing it seems very unstable.
A lot of things changed in the past few years. The need to reboot the hub more frequently is one of those things that have changed. Disabling the auto-rebooter might in fact immediately improve your experience. Other than that, older version of Echo Speaks is known to cause hub's performance issues. I strongly suggest to update the Echo Speaks to see if that resolves the problem. If not, you may want to share some of the errors/warnings you may see on Logs page so that others who are using the apps you are using may be able to point you in the right direction on how to fix the problems.
I've updated everything every time I log in... and I even removed Echo Speaks and re-setup the entire thing a few months back... at most it stays alive 3 to 4 days before becoming unresponsive.
I know exactly when it becomes unresponsive since I have my Homeseer enviro monitoring it and sends me alerts with pings fail.
@aaron3 Have you even done a soft reset? What do your logs say? Why hadn't you reached out earlier so the support team could look at your engineering logs?
One thing that stands out to me is that it is all wifi/lan based. It is quite easy to overload habitat with poor config choices with WIFI/lan devices hitting the hub hard. I have done it with one device that just sends a fair amount of updates from Node-Red to Maker API.
What is Maker API doing. Is there a polling or heartbeat action going through echo speaks or MyQ Lite. How frequent is that.
Load up your live logging and see that shows for your busy devices and apps.
Dont know what you mean by Soft reset. I reached out to support over a year ago, they sent me a new unit, which did the exact same thing so I assumed they didnt know this was a software problem.
@mavrrick58 I have it plugged into Ethernet literally inches from my HPE switch.
Maker API was added later so I could communicate directly with Homeseer... this issue was exactly the same problem when I only had Echo Speaks installed, and nothing else.
Check this out for more details about performing a Soft Reset. While it is a safe procedure, I wouldn't recommend doing so without a valid reason. Presence of errors in logs, is a good indication that a Soft Reset (replacing a potentially corrupted database with a new one and restoring a previous backup) might help: https://docs.hubitat.com/index.php?title=Soft_Reset
the fact that both do/did it points to a network issue on your network not the hub.. maybe ip address is changing.. have you set a static ip for the hub on your router via dhcp.
I'm happy to post the Logs (I dont see a way to DL the logs?). The last hang happened on 8/14 and I unplugged/replugged today, 8/16. You can see the gap but there is nothing really there. The OS and apps were all on the latest version as I updated everything on 8/7
dev:392022-08-16 09:01:29.269 am infoEcho (v4.2.0.7) | Echo - Jennifer's Echo Show 5 2nd Gen Executing initialize()
dev:12022-08-16 09:01:29.224 am infoEcho (v4.2.0.7) | Echo - Jennifer's Echo Executing initialize()
app:42022-08-16 09:01:12.288 am info EchoApp (v4.2.0.7) | running initialize...
app:42022-08-14 06:01:40.777 am warn EchoApp (v4.2.0.7) | 408 DnDResp
dev:402022-08-14 01:03:29.916 am infoEcho (v4.2.0.7) | Echo - Master Bath Executing initialize()
dev:332022-08-14 01:03:29.410 am infoEcho (v4.2.0.7) | Echo - Tyler's Room Executing initialize()
dev:362022-08-14 01:03:28.472 am infoEcho (v4.2.0.7) | Echo - Office Executing initialize()
dev:122022-08-14 01:03:28.413 am infoEcho (v4.2.0.7) | Echo - Master Bedroom Executing initialize()
dev:92022-08-14 01:03:28.320 am infoEcho (v4.2.0.7) | Echo - dot 3 Executing initialize()
dev:82022-08-14 01:03:28.041 am infoEcho (v4.2.0.7) | Echo - Media Room Executing initialize()
dev:72022-08-14 01:03:27.865 am infoEcho (v4.2.0.7) | Echo - Living Room Executing initialize()
dev:62022-08-14 01:03:27.781 am infoEcho (v4.2.0.7) | Echo - Play Room Executing initialize()
dev:52022-08-14 01:03:27.601 am infoEcho (v4.2.0.7) | Echo - Noah's Room Executing initialize()
dev:42022-08-14 01:03:27.464 am infoEcho (v4.2.0.7) | Echo - Kitchen Executing initialize()
dev:32022-08-14 01:03:27.297 am infoEcho (v4.2.0.7) | Echo - Everywhere (WHA) Executing initialize()
dev:22022-08-14 01:03:27.196 am infoEcho (v4.2.0.7) | Echo - Jennifer upstairs Executing initialize()
dev:392022-08-14 01:03:27.077 am infoEcho (v4.2.0.7) | Echo - Jennifer's Echo Show 5 2nd Gen Executing initialize()
dev:12022-08-14 01:03:27.009 am infoEcho (v4.2.0.7) | Echo - Jennifer's Echo Executing initialize()
app:42022-08-14 01:03:10.349 am info EchoApp (v4.2.0.7) | running initialize...
app:682022-08-14 01:01:00.046 am infoRebooting hub
app:1342022-08-14 12:00:00.887 am infoChecking for updates for Hub Rebooter
app:1342022-08-14 12:00:00.760 am infoChecking for updates for Hubitat Package Manager
app:1342022-08-14 12:00:00.628 am infoChecking for updates for Echo Speaks
app:1342022-08-14 12:00:00.482 am infoChecking for updates for MyQ Garage Door Integration
app:1342022-08-14 12:00:00.187 am debugRefreshing repository list
Though plugging the hub directly into the switch is good, it doesn't really apply to what I was saying. My point is that the hubitat hub is a small low power arm based SOC. It is fairly powerful for what it is, but it isn't as robust as lets say anything Intel/AMD based. When I had Node-Red on my unraid server reading a UPS dameon and then updating a virtual driver on Hubitat with many attributes i was able to kill the hub daily. It was because the APC Dameon pallet in node-Red had to refresh every 12 seconds. Then I was having it send the data to the hub for processing via the virtual driver for every attribute (10) the HE driver had. It seemed to work fine, but after 24-48 hours it would flake out and cause issues. The problem was completely about the amount of data i was sending it. after i reworked my node red flow to reduce the updates being sent everything was fine. Node Red actually interfaces with Maker API to load data back to the hub.
My question is really about how much continuous activity do you have with the services you are running. I don't know echo speaks, or the MyQ app, There is likely some kind of polling happening and how frequent is that.
In some cases infrequent polling can cause issues as is the case with Ecobeee Suite. With that application because it does so much, waiting to long to retrieve the changes from the cloud can cause it to have long runtimes on the hub and actually slow stuff down.
You may want to click on the Live Logging tab to display logging and then click on App stats. Then make sure everything is checked. That may be able to tell you if you have a application causing issues. You may also want to check this periodically as it may not be real good data after a restart. It also shows you total time and busy time so you can see in a way how busy the hub is.
You may also want to go into those apps and turn on debug logging as that may also help us understand what they are doing. what is shown up there is very minimal.
Thanks all for your feedback. After working with @aaron3 the problem may just be as simple as changing the Ethernet Speed in the Network Settings. In some cases, when the hub is plugged into a network switch that is able to auto-negotiate the link speed, keeping the hub on Fixed 100mbps could have unintended consequences. @aaron3 changed the setting to auto negotiated and also disabled the auto-rebooter, which may solve the problem. He will keep us posted.
I can second this observation and the proffered solution.
I have a LAN device updating 26 attributes via MQTT every minute that were passed on to a custom HE device via Node-RED. After a few days, the hub would get sluggish. Filtering the attributes with an RBE node solved the issue.
