I just check once a day at 4 am. You could change it to whatever frequency you wanted with a rule like this though so memory changes aren't your trigger spamming the hub.
2 Likes
I find my main C7 is stable for about 3-4 days before the memory drops below 300k. The automation rule only runs between midnight and 5am so it doesn’t impact performance on it own.
I get your restrictions in place. I just don't want so many triggers during a window. A time based trigger covers this for me.
3 Likes
For my hub, it has:
- maxEvtDays : 365
- maxStateDays : 7
Where do I even change that? I went back and looked at the device/app states events, copied them to a spreadsheet and that is when it got interesting. Unless I'm 100% missing something, it doesn't appear to be observing the max state/event numbers.
The entire hub had a global 20/20 set for them. Some devices (like my nest doorbell), I dropped to 1 since I don't need to bloat the DB with images. When I look at all the devices, some clip properly, others like the dishwasher running indicator that I'm working on lists 322 events, 271 states and counting. That device has 16 listed states.
I checked on for the alarm panel inputs I linked in, some are clipped at 20 / 20, my living room is at 26 / 26. In those cases, each only has 1 state.
My gutt feeling is if you changed the max limit, and the device was already above the max, it doesn't clip and cleanup. If the device was below those limits, then the hub maintains them as expected.
http://hubIP/hub/advanced/event/limit/9999
http:///hubIP/hub/advanced/deviceStateHistorySize/9999
http://hubIP/hub/cleanupDatabase
1 Like
For max state and event age, there are these too:
/hub/advanced/maxDeviceStateAgeDays - shows current setting
/hub/advanced/maxDeviceStateAgeDays/123 - sets max age, with acceptable values being 7 to 365, inclusive. (default: 7 days)
/hub/advanced/maxEventAgeDays - shows current setting
/hub/advanced/maxEventAgeDays/123 - sets max age (default: 365)
2 Likes
Thanks, let me look at that. It seems to be an issue where the limits aren't being respected on some devices. I clicked the global "apply 20 / 20 to all devices" from the log section. Checked one of my devices, it was still stuck at 5 / 5. The "13-motion living room" from my image above was stuck at 10 / 10 (didn't accept the 20 / 20), but after a reboot, it just continuously climbed. Right now it's at 238 events / states and climbing (those are particularly spamming triggers, so I wanted them clipped low)
Did this:
http://hubIP/hub/advanced/event/limit/20
http:///hubIP/hub/advanced/deviceStateHistorySize/20
http://hubIP/hub/cleanupDatabase
I then rebooted, and immediately checked the device in question. It had been clipped to 20 / 20. After a couple of triggers, it climbed past the limits again.
What looks to happen is we reboot, everything gets cleaned up as we expect, and then they start to grow past where they should have stopped. That's why RAM is "disappearing" daily after a reboot. It's not a memory leak, the event / state cleanup isn't working.
Just thinking out loud, I wonder if it's a matter of it checking for value=limit vs value>=limit. And if you have a spammy device, it clicks by a couple times before the code can do the limiting? Some devices do appear to work, which would explain that.
Event / States will truncate at boot up and approximately every hour. Their growth affects the database size, but except for the memory consumed/returned during the write should have little to no impact on freememory.
3 Likes
Let me monitor that and see. I know initially, using the UI to set the limits didn't apply to that motion sensor, but using the web address did.
This might be considered an edge case but it is a valid case and will do as I suggested. If freeMemory drops to or below 300,000 at 4:49 AM and stays there until the hub is rebooted.
@4:49 AM the rule is triggered and the ELSE-IF condition is True. Reboot is scheduled for 5:01.
@4:54 AM the rule is triggered and the ELSE-IF condition is True. Reboot is scheduled for 5:06.
@4:59 AM the rule is triggered and the ELSE-IF condition is True. Reboot is scheduled for 5:11.
@5:01 AM the hub reboots and freeMemory should now be well above 300,000.
The rule is now outside of the Required Expression and won't retrigger and since it won't retrigger the Cancel Timed Actions won't be run so the hub will reboot at 5:06 and 5:11.
You posted that you update the Required Expression and Trigger Events. If you didn't change the IF-THEN logic too then there won't be anything to run the Canceled Timed Actions within your time frame and you'll always get multiple reboots.
1 Like
Ok, watched it, and that is correct. Top of the hour, it consolidated states at brought them back to the limits.
Question about the "states limit". I have it sent to a global "20". The ones I looked at, had only 1 attribute, and reset to 20.
If have a device that has 10 attribute/state variables, and a 20 limit, should I see it wrap at 200 then?
Answering my own question here. If a device that has 10 attribute/state variables, and a 20 limit, will wrap at (10 x 20) = 200 on the hourly cleanup boundary, and left events at 20 so I cab grab history from the log.
I ended up setting all devices to wrap at "1" state per attribute. I have no use for those states as history, which seems to be what's "rotting" my hub over time as they build up. I'll monitor it over the next couple of days to see if RAM was the root of my slow down or if it's something else.
Sure:
IF (Hub Information freeMemory(330620) > 300000.0(T) [TRUE]) THEN
Cancel Timed Actions: **This Rule**
Exit Rule
ELSE-IF (Hub Information freeMemory(330620) <= 300000.0(F) [FALSE]) THEN
Notify Derek's iPhone - HE, Email Notifier: 'Low memory detected, Rebooting Primary Hub' --> delayed: 0:11:30(cancelable)
reboot() on Hubitat Controller --> delayed: 0:12:00(cancelable)
END-IF
And here’s the JSON
2 Likes
@dJOS The comment you quoted was in regards to the updated Required Expression and Trigger that you posted today and the trigger not satisfying the first part of the IF-THEN logic. It won't show in your logs until the next time the rule runs and reboots your hub. Your hub, your rule, good luck!
I think you misunderstand the rule. It won’t even enable the trigger logic unless it’s between 4-5am.
And then the trigger condition is only going to be tested every 5 mins when the hub information driver polls and updates the free ram.
