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

Offline jswim788

  • Hero Member
  • *****
  • Posts: 754
  • Karma: +51/-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

  • Hero Member
  • *****
  • Posts: 557
  • Karma: +27/-12
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: 1290
  • Karma: +33/-32
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, 1.7.1030, CT101 t-stat, Everspring motion detector, GE/Jasco switch, Leviton outlet, AeonLabs sensor, NuTone garage door, Blue Iris, Sricam SP011, iPhone locator, APCUPSD, VeraMate, VeraAlerts, PLEG, House Modes, Countdown Timer, DVR, Virtual/Multi Switch, Weatherunderground, LB60Z-1 bulb

Offline MtView

  • Sr. Newbie
  • *
  • Posts: 46
  • Karma: +1/-0
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #18 on: March 07, 2018, 06:55:26 am »
When Vera reboots, does it need to re-establish the zwave neighbor network?

Offline thief

  • Jr. Member
  • **
  • Posts: 85
  • Karma: +3/-0
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #19 on: March 07, 2018, 08:25:59 am »
kwieto, from which plugin/app are those screenshots from?

(Plus_memory_history.PNG and Luup_reloads vs time.PNG)

Offline Don Phillips

  • Hero Member
  • *****
  • Posts: 1290
  • Karma: +33/-32
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #20 on: March 07, 2018, 05:00:19 pm »
When Vera reboots, does it need to re-establish the zwave neighbor network?

My understanding is Vera needs Internet access to set its clock, and after successful bootup, will establish the z-wave network.  After about 5 to 10 minutes, the Vera should be functioning normally (assuming it was acting normally before the reboot).
Vera 3, 1.7.1030, CT101 t-stat, Everspring motion detector, GE/Jasco switch, Leviton outlet, AeonLabs sensor, NuTone garage door, Blue Iris, Sricam SP011, iPhone locator, APCUPSD, VeraMate, VeraAlerts, PLEG, House Modes, Countdown Timer, DVR, Virtual/Multi Switch, Weatherunderground, LB60Z-1 bulb

Offline kwieto

  • Hero Member
  • *****
  • Posts: 557
  • Karma: +27/-12
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #21 on: March 08, 2018, 05:17:42 am »
kwieto, from which plugin/app are those screenshots from?

Datamine2.
Just be careful using it as setting saving data to USB stick is tricky sometimes (I had an issue when data were wrongly saved to internal memory, which of course caused problem with filling it rapidly)

Offline kwieto

  • Hero Member
  • *****
  • Posts: 557
  • Karma: +27/-12
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #22 on: March 08, 2018, 05:36:50 am »
I've found interesting thing.
Both my controllers performed very well since last issues (about 6-th - 7th February). Then at the beginning of this month both had unusual drain of memory (on 5th March) and the clearing scene was triggered.
Maybe just coincidence, but it looks like some regularity. I'm curious if there is some activity Vera or some plugins do at the beginning of each month?

Offline gniknalu

  • Full Member
  • ***
  • Posts: 167
  • Karma: +3/-2
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #23 on: March 08, 2018, 09:10:24 am »
I've found interesting thing.
Both my controllers performed very well since last issues (about 6-th - 7th February). Then at the beginning of this month both had unusual drain of memory (on 5th March) and the clearing scene was triggered.
Maybe just coincidence, but it looks like some regularity. I'm curious if there is some activity Vera or some plugins do at the beginning of each month?

I'm worried that the reset button on my Vera Secure is going to break one day as it is pressed (for 30 seconds) so many times because the unit becomes non-responsive. Can you give more details on how I can set up a "clearing scene"? Maybe it will help

Offline thief

  • Jr. Member
  • **
  • Posts: 85
  • Karma: +3/-0
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #24 on: March 08, 2018, 09:16:31 am »
Quote
I'm worried that the reset button on my Vera Secure is going to break one day as it is pressed (for 30 seconds) so many times because the unit becomes non-responsive.

Whaat? Doesn't a normal reboot help?



Offline gniknalu

  • Full Member
  • ***
  • Posts: 167
  • Karma: +3/-2
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #25 on: March 08, 2018, 10:38:39 am »
Whaat? Doesn't a normal reboot help?

Yes - it does help. But I have to remember to do one every week. If I forget, I pay by getting a message saying my controller is down. . . .

Offline thief

  • Jr. Member
  • **
  • Posts: 85
  • Karma: +3/-0
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #26 on: March 08, 2018, 03:58:03 pm »
Cant you access it from lan either?

Or just power cycle it?
« Last Edit: March 08, 2018, 04:04:48 pm by thief »

Offline MtView

  • Sr. Newbie
  • *
  • Posts: 46
  • Karma: +1/-0
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #27 on: March 08, 2018, 05:27:07 pm »
Reupping :When Vera reboots, does it need to re-establish the zwave neighbor network?

Offline jeubanks

  • Full Member
  • ***
  • Posts: 195
  • Karma: +6/-2
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #28 on: March 08, 2018, 10:46:46 pm »
Reupping :When Vera reboots, does it need to re-establish the zwave neighbor network?

It shouldn't have to as the network map should be saved.

Offline kwieto

  • Hero Member
  • *****
  • Posts: 557
  • Karma: +27/-12
Re: Are Scheduled Auto Reboots A Good Idea
« Reply #29 on: March 09, 2018, 05:46:25 am »
Can you give more details on how I can set up a "clearing scene"? Maybe it will help

First you have to install system monitor plugin, to get data about memory.

Then you create a scene with the code I provided before. You can run this scene on schedule, or you can set your system to watch changes in the free memory and then trigger apropriate scene (see this post for how to do it: http://forum.micasaverde.com/index.php/topic,18679.msg217315.html#msg217315 )

Consider using a datamine2 to track history of your system data, like memory, luup reloads, etc.
This may give you some hits about what causes your problem, as it doesn't have to be memory issue.