I have long been under the impression that the hub was built "over powered" and had more horsepower/storage than it needed. Based not only on this issue above but many others, and personal experience, it seems the hub is easily overtaxed, via too many z-wave messages, LAN devices, memory getting chewed up via leaks, logging too many device events. Those are all things I would have expected to hub to handle easily.
And like I've said before no HA system is perfect, including HE. I just was at the Wyze forum, no end to people complaining about sensors falling off, hub locked up, sensors turned into garbage simply because the battery dies. Same with ST, same with HA(this is PHD level automation). Wink haha, Vera haha
So I'll be staying here, taking my lumps, as in the very imperfect HA world, HE is the best combination of "works & don't work & enjoyment & frustration" at this current time IMHO, but I'm not going to pretend I don't invest many hours troubleshooting.
Might help to put about 50-100ms pause between MakerAPI calls, may be overflowing the queue or overwhelming the mesh, but doubt that the cpuLoad is the issue.
I've definitely caused issues by bombarding the HE with too many calls at once. Usually it's when I do a "full deploy" and all my initializations kick in. Other times just some errant coding/design/dev insanity causing the spamming. I agree with @thebearmay - put some small delays between calls.
The CPU load definitely was very high during that time
I've put in delays and it solved the reboot issue, but still reinforces my belief the the HE hub/os is "fragile". Along with memory leak that reguires me to reboot the hub every 5-7 days.
I'll accept a serious slowdown and events being delayed if overloaded. Be "graceful", don't "give up".
Two dozen on/off commands shouldn't cause a reboot, when the same group of devices & on/off commands worked fine using the simple automations app versus maker-api. Whether the events were generated internally or externally shouldn't matter.
For almost two years, I’ve only rebooted my C5 and C7 for platform updates and power outages. I’ve about 100 devices on each of them. And very heavy use of MakerAPI.
Not sure why our experiences are so strikingly different.
I'm at the same point as @aaiyar. 140 odd devices total (virtual, z-wave, zigbee, wifi) and 25 or so apps (mostly from HPM) and the only time I reboot is during updates.
That's interesting.. My C5 Zigbee hub is a lot lower than that right now and working fine. I do have a watchdog sequence that reboots if lower than 100K but thinking I should up this maybe to 131K.
All my hubs re slowly losing memory including the C7. Note: I don't use the RM apps so that is not the cause in my case. My C5 Network Hub loses mem rapidly - still sorting that one out. Both Z-Wave and Zigbee are disabled for that hub. The time span for this chart is the last 36 hours.
Interesting. My experience is more like @erktrek's.
My C-7 and C-7 start out about 600K, and then slowly drop to ~200K where they are stable. No apps stop functioning. Because both hubs are enrolled in the beta test, there are several reboots seen here on account of frequent platform updates. And as you can tell, the last reboot was on ~72 hours ago. Currently, the C-5 is at 378K and the C-7 is at 390K. The C-7 is z-wave only, the C-5 is zigbee only.
I don't use RM anymore, and as I move automations over to node red, I remove the apps and any drivers from my hub.
If my hub get below 300K the response time interacting with the hub becomes noticeable. The zigbee radio doesn't always stop functioning but it has enough times.
Only thing I can suspect is some HW/SW variance between C4s and later. And at this point I just mitigate it as best I can.
And given the stability and increasing maturity I've seen with Zigbee2MQTT I don't know if I would invest in another HE hub if mine failed.
Mine is the NR dashboard too using the "chart" node. It's a bit more hastily thrown together than @aaiyar's. I just wanted a quick view but will probably tweak as I go along.
Interesting - I ditched my C4's after one died. I have not played around with Zigbee2MQTT but have been curious about it.. C4 definitely has more memory "constraints" thanks to the 64 bit jvm vs 32 bit on the C5/7's.
