You would turn on the preference allowing the driver to reboot the hub, then in webCoRE you can create a piston that uses the driver and the attribute freeMemory to check for a drop below a minimum value and then issue a reboot command to the driver.
4 Likes
Here’s my RM rule:
Grab 2.3.4.150 if you haven't yet... it has a couple of fixes based on the review of the hubs people PM'd me about.
11 Likes
2.3.4.150 looks promising. I've been fighting the elevated loads and just general sluggishness, with the CPU starting to have random spikes 12-18 hours after a reboot before just going nuts and having all sorts of issues. This latest version has been running for about 20 hours and I haven't seen the uptick in CPU usage that I had. So, fingers crossed... Thank you for the continued effort.
5 Likes
In case it's of interest of people, since I learned about the Hub Information Driver I've been sending my free memory and database size out to InfluxDB. I'm still running 2.3.3.140 on the three hubs, but thought I'd throw this graph here as a comparison.
Database size isn't really changing much, but there's a gradual decrease at about the same rate on all three. I don't know what happened to Hubs 1 and 2 around 11/12th Feb, but they took a dip, while Hub 3 (which only does the Xiaomi light switches) cruised on with no dip.
They're all working perfectly at the moment, curious to see if Hub 1 (the one with the lowest memory) does some cleanup at some point.
While there is a cleanup routine that recovers some memory, over time, as you are seeing, there is a gradual overall loss that will eventually drop below the minimum operational level required (usually somewhere about 120M-150M) and you’ll need to reboot. If this occurs over a period of weeks you’re looking at the normal loss, if it is a period of hours then you would have an issue.
Also note that three initial large drop you see after a reboot is normal as that is when the hub is loading apps, drivers, and other data into cache. Other large drops may be due to apps/drivers being rebuilt after a code change, additionally sometimes a backup will trigger a drop ( most, if not all, of the loss from a backup is generally recovered).
I’ve found .150 doesn’t eat through its memory as quickly as previous versions. And it tends to settle into a range and hover there for much longer than previous versions.
4 Likes
It's probably been asked/answered, but what's the best way to do an auto reboot at, say, 150M?
Thanks.
Most often a rule / piston with freeMemory as the trigger, and a custom command (reboot) to the driver. (Note that the driver has a safety preference setting that also needs to be set to true to allow a reboot.)
2 Likes
When I try to create a custom action in RM, it doesn't give me any choice for the reboot capability. I did enable it in the device page.
Actuator! Who'd a thunk it?
Interesting! No Hub Info driver required?
no not required, but is required if you want to monitor memory usage. .but usually the first thing that goes on too low memory is zigbee crash.. But lately i have noticed some sluggishness on low memory . SO i am adding this rule which Does require hub info .
i recommend if you are going to do this to use the "stays that way" as memory can dip low during nightly maint and backup but quickly goes back up..
6 Likes
IRRC the httpPost method won't work if you're using hub security, the driver has an option that will use supplied credentials to bypass that issue.
3 Likes
Not that I know anything, but I read on another post by @thebearmay that using reboot is better than restart.
Not using security as not necessary as my network.is secure.. and i use a vpn
1 Like
You can also use an "HTTP Momentary Switch" and set the post up in that. Then when you need a reboot, just turn the switch on. It turns itself off.
2 Likes
