Author Topic: Are Scheduled Auto Reboots A Good Idea  (Read 509 times)

Offline jswim788

  • Hero Member
  • *****
  • Posts: 558
  • Karma: +34/-2
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #15 on: February 12, 2018, 12:38:00 pm »
- you can write the code without "tonumber()" section, but then all values should be in quotation marks (so [tonumber(Memory) < 50000)] is more or less equal to [Memory < "50000"])
Very small point on this: Lua string comparison is not the same as numeric comparison, so you do want to use the tonumber as you wrote it.  See this link: https://www.lua.org/pil/3.2.html

Offline kwieto

  • Sr. Member
  • ****
  • Posts: 347
  • Karma: +15/-10
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #16 on: February 12, 2018, 03:13:14 pm »
Lua string comparison is not the same as numeric comparison, so you do want to use the tonumber as you wrote it.

Good to know, thanks!
Fortunately this is not a problem with my current scenes, but definitely something which should be taken into consideration.

Offline Don Phillips

  • Hero Member
  • *****
  • Posts: 1098
  • Karma: +25/-25
    • Worthington Engineering, Inc.
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #17 on: February 12, 2018, 08:20:22 pm »
have you thought of using PLEG?

I made an approach to PLEG some time ago and my experience is very ambivalent.
I know PLEG is powerful tool, have some advantages over "native" scenes/lua support and has it's devoted users, but I personally feel better with lua than with PLEG.
The major thing with PLEG for me is the way of organization. If you write Lua, you can put everything in one place and make it process-oriented, so you can follow it through from start till the end. All pieces (variables, triggers, conditions, activities) are organized in logical order (check this and if it is like that, then to this, if not then...")
PLEG organization fragments the process into separate "drawers" (one for triggers, another for conditions, schedules, actions...) This way makes it harder to see the general picture of a specific "scene", especially when your "inventory" (defined trigers, conditins, etc) will grow.
It is like going from general picture to the details (top-down) vs. going from details to general picture (bottom-up) when designing scenes.

And, frankly speaking, I don't use that much of a code in my scenes to justify installing two additional plugins (PLEG and PLC) at least for the time being.

Edit:
I looked into the file you attached, and frankly speaking, it is really hard for me to get the picture of your action, there are a lot of things completely not related to clearing cache and everything is in various places (this is exactly my problem with PLEG). I found it a "detective" task to understand how your action is organized. However, I assume there are people for whom that way is easier to understand.

BUT: If I understand your conditions ("cLow_Memory_Available: pMemory_Available < 50000" and "pMemory_Available: memoryAvailable[urn:cd-jackson:com:serviceID:SystemMonitor]") you are checking amount of available memory instead of free memory.
That's wrong, because available memory doesn't take into consideration cached memory (cached = freable = available) while increasing cached memory is the main problem here. So checking available memory won't do the job (see red line at the screenshot above and compare it to the blue one (Free) - esp. around 6th Feb).
From the other hand, your amount of memory can be decreased from other reasons than increasing cache, so I decided to track amount of free memory as it cover all components. Of course if amount of free memory is decreasing because of the other reason than the growing cache, the first stage of the scene (clearing cache) won't help. But then you have reboot command at the next stage.

Edit2: And take care about luup reload variable (I see you track it), as it seems that it doean't show all luup reloads. See second screenshot. Purple line is LuupRestart, blue is LuupRestartTime. In the time period on the screenshot luup was reloaded 30 times according to what you have on blue line (and this is the true value), while only three of them are presented on the purple line

Thanks for looking at it and for the feedback. I looked at both variables but wrote the condition on available memory. The other stuff, like counters, is something I am playing with.

I updated it to look at memory free and will report back on that in about a week. For those watching this thread, here is the revised PLEG.
   
« Last Edit: February 13, 2018, 08:41:26 am by Don Phillips »
Vera 3, UI7 1.7.1017, CT101 t-stat, Everspring motion detector, GE/Jasco switch, Leviton outlet, AeonLabs door sensor, NuTone garage door, Blue Iris, Sricam SP011, iPhone locator, APCUPSD, VeraMate, VeraAlerts, PLEG, House Modes, Countdown Timer, DVR, Virtual & Multi Switch, Weather, Sys. Mon.