it could be inconvenient or tedious with that much of your own code running, but how can support be expected to ignore the possible contribution of custom code to the problem a user is reporting?
3 Likes
There's a big reason I run almost all my app and automation logic external from Hubitat.
Not because I couldn't run it on the hub - it is plenty capable of handling it - but rather I do it for portability, disaster recovery, and enhanced troubleshooting capabilities.
4 Likes
My zigbee hub used to do this about every 2 weeks. The only "non stock" app I have is hubconnect. The only "non stock" drivers are hub connect and hub information. The hub information driver was only recently so that I could monitor the memory level when it did crash. Found out it was usually below 400k. So now I use a flow in node red that when the hub information driver reports below 400k, to reboot the hub.
No more crashes.
I did (what I call option B above - scheduled/triggered reboots) for quite a long time.
Now my memory drop rate is low enough (still drops though, and eventually the hub will slow down or crash) that I just do a reboot manually every month or so.
1 Like
Thamks will monitor the memory and do a reboot. I know.it is not heat or cpu as I have monitored those in hub statistics. I also don't see any app or device in the stats constantly going up so I don't think it is a leak in that dept. Pretty sure it is a leak somewhere in the is itself. But who knows
Do you have [RELEASE] Hub Information Driver installed? While it won't tell you what is causing the issue, it does give a good overview of memory and database use.
Another thing I might suggest is to watch your database size. I recently set every device to only store 11 events and 11 states. (Don't use less than 11, it makes the database do constant cleanups, which can slow the hub.) I also set the length to store events to 14 days. I had stuff from a year ago in the database, and I was never going to use that data. Between those two things, it made my hub much snappier. It wasn't slow before, but it was noticeably faster after pruning all that cruft out of there.
And while we are at it, maybe try a backup and restore? Maybe something is corrupted, and that will clean it up.
I already went through and reduced database size for high using devices that I.don't need history. Thanks
For now I added the following rule
Hmm I.have a bunch.of them set to 10 thanks will have to go back through and set to 11 good to know.
Already tried the restore and the fact that it is.occuring on more than one hub says to.me its not.corruption.
Here is the URL to set all devices at once, rather than have to dig through every device.
hub IP address/hub/advanced/event/limit/<desiredSize,1-1000>
hub IP address/hub/advanced/deviceStateHistorySize/<desiredSize,1-1000>
How did you do this?
I found it searching on the forum. gopher.ny posted it in a thread where he was helping someone. Maybe I can dig it up again.
1 Like
No need. My database size is OK. If it starts to be a problem I will search the forum. Thanks
/hub/advanced/maxEventAgeDays/nnn
/hub/advanced/maxDeviceStateAgeDays/nnn
Where nnn is the maximum days to retain. (7..365)
4 Likes
Not sure that HE staff ever really intended them to be used/seen by anyone outside, and since most are unofficial they can, and sometimes do, change or are removed. Most were spread by word of mouth until someone created a wiki post to start collecting them.
1 Like
what is the default.. becuase i need some to be 30 days.. the rest i dont.. so i dont want to set to 30 and make things worse
ya unfort. that wont work .. some i need 30 some 100 the rest 11.
I think it is 365 days. You can check by not entering anything after "days" in these. It will return the current setting.
no longer works.. 404 error
was pilot error. the hub is not the hub ip.. it is hubip/hub/cleanup...
misunderstood url sorry.
Set the default to be 11.
Then for individual devices change the value to whatever is appropriate for that device. This value can be set from the device page for each device.
1 Like
ya already went through every device individually on one of the hubs.. will do the other later.. burned out for now....
1 Like
Pretty sure that’s correct. I checked one of the devices and the earliest event was from June 17, 2020. Needless to say, I’ve changed that!
4 Likes
