Thanks
@dJOS,
Thank you for your incredibly quick, detailed and fantastic explanation! Thank you so much. This is what makes this community so great!
Using your ideas, this is what I did (let me know what your thoughts are):
I set a Required Expression so that the Rule would not constantly run whenever the free memory value changes, but only if it goes below my set threshold. In order to be able to be flexible with this threshold, I set up a local variable so that it could easily be changed in one place but makes the changes throughout the rule. I set my Trigger the same as my Required Expression only so that I could easily see in my list of Rules whether the Required Expression was met. I also set my polling interval to be 5 min but set a cancellable delay of 13 minutes prior to initiation of the IF-THEN-ELSE logic so that 2 polling cycles would be considered prior to rebooting to take into consideration any fluctuations that might occur (if the free memory remains below 250K in my case for two cycles, then the Rule will initiate the reboot procedure). In addition, I put in a slight delay following the notification so that if I wanted to cancel the reboot for whatever reason, this would give me a little time to do so. The ELSE condition is for if my free memory does not remain below my threshold for two polling cycles, then any delays are cancelled and the rule is exited.
Again, I am relatively new to all this so any help or constructive criticism is much appreciated!
1 Like
I made mine like this initially, but the way my rule works it needs to run when the memory is above the 250k threshold too or it can't cancel itself. I think your implementation gets around this. TBH, it's such a simple rule that it isn't going to create much overhead imo.
I think you have a good take on it, my only suggestion is to have the cancel logic first as it makes the rule more efficient. You also dont need to create hub variables as the fields from Hub Info are visible from RM.
1 Like
Thanks for the cancel position suggestion. It makes a lot of sense. The reason I generally use variables in my rules where a value has to be repeated in said rule is that I find it easier to change the variable (in this case the reference value, not the value from Hub Info) anytime I wish to change it, rather than having to go through the rule and edit each instance of that reference value.
One thing I am curious about however, is that does the use of variables significantly increase the overhead? I just find that it makes things a lot easier to modify and to test out different values. I like that the reference value clearly shows up right on the bottom of the Rule rather than having to make sure that I have to carefully go line by line in the rule to change each instance of the reference value should I wish to “play” with the variable value.
I dont think so, shouldn't be an issue.
Makes sense. 
Interesting observation, my primary hub seems to be less responsive once the free memory gets below 300k.
My secondary hub only manages cloud integrations and isn’t working anywhere near as hard.
I’ve noticed similar, have my memory warning set at 250, but generally will reboot around 280. Wonder if it is because it can’t hold as much in cache and has to start swapping information in/out of cache more.
1 Like
Apparently not @bobbyD. It’s 5 days now since I sent the email and noted that here above on this forum. No reply.
1 Like
I saw your comment the other day and meant to come back here, to let you know that I didn't see your email, but I forgot. You didn't get a ticket, did you? You can PM me and will go from there.
Same for me only automated response
We got yours, but if I remember correctly, you have worked extensively with our platfom engineer, a while ago. Is this a different hub or the same one? In any case, will review your case early next week.
Z-wave issues on c5 got a c7 to fix
Thanks, I see it now. It ended up in the Spam folder. For future reference, if you don't get a ticket number, it means that we didn't get your email and something happened. We usually check our spam folder frequently but, it was a busy week 
2 Likes
UPDATE: I let my hub get into the 250k range and it was getting slower and slower with some automation failing. So I changed the reboot logic to 300k as that seems to be the sweet spot for my primary hub. It takes about 5-6 days to get to this point so I'm happy with this reboot frequency.
EDIT: Btw, I was looking through my old notes and I found there is a DB cleanup option that doesn't need a hub soft reset to work:
http://your.hubs.ip.here/hub/cleanupDatabase
You'll eventually get a "Done" message and should notice the DB size has reduced.
After seeing all this discussion, I set up a "memory check" rule on my two Hubs.
The one running rules and most everything except the Z-Wave devices was clearly working itself out of memory over time.
It had been a while since the last reboot when I wrote this new memory checking rule. At that time, it was mostly above 235K but, occasionally dropping under that for short intervals (sometimes dropping under 223K).
Then, as the days went by, it was increasingly dropping down farther and farther. Eventually, yesterday, it got down to about 190K.
My original rule set a warning at 235K and scheduled a reboot 20min later at 223K. But, it cancelled the reboot if the memory rose at all in 20 min. Because that clearly was letting the hub venture increasingly into "memory constrained" territory, I put some additional logic in there to require it to recover more completely before the reboot is cancelled,.
So, my experience would indicate some degree of leakage over many days. I've got 2 C-7s.
(my "zwave & zigbee devices only" hub doesn't seem to share the issue (at least not as dramatically/quickly--it has a few RM apps, but very few.)
@bobbyD or @gopher.ny could you clarify what goes on on nightly maintainance, in regard to state/event limit.
I've turned quite a few down to between 2-5 and might be unrelated seem to see the free memory go down a bit quicker and cpu go up a bit.
Sure, nothing is going on. There is no "nightly maintenance".
so state trim is instant? the setting is still there to input a time is it just backup?
Right, the time setting is for when the backup is generated. There is an hourly clean up. I think @gopher.ny explained this previously, in more details.
