I just observed a Luup/Lua restart due to PLEG taking a long time to complete an action (> 20 seconds). The action was simply to change the state of a switch (I suspect it’s the Zwave network causing the actual delay and will need to report a support case to MCV to see if they can figure out what’s happening to my Zwave network)
Unfortunately, as it happened, my terminal window was scrolled to the top and the info dropped out of the buffer. Additionally, the LuaUPnP.log file rolled over at the very same moment so I didn’t capture any of the debug info, sorry.
If all of this happened at the same time … are you sure you not have memory exhaustion ?
When you rotate logs, that unix process need some memory … that takes away from Vera …
maybe causing Vera to pause … then PLEG to pause/ overrun.
[quote=“RichardTSchaefer, post:2, topic:178110”]If all of this happened at the same time … are you sure you not have memory exhaustion ?
When you rotate logs, that unix process need some memory … that takes away from Vera …
maybe causing Vera to pause … then PLEG to pause/ overrun.[/quote]
According to /proc/meminfo, I’ve got ~49MB free and ~104MB allocated. Not sure if there’s an upper proc limit for luup/lua though?
Of course, the SysMan claims I’ve got ~80MB free, and according to ps -ef the /usr/bin/LuaUPnP process has 122m allocated. So basically, it’s hard to tell…
Caught it in the log w/debug on. Unfortunately, the full trace exceeds the forum max character limit…
It looks to me like the transmit to the thermostat - set the temperature up or down & set the HeatOn state - is what’s causing the restart. However, so far I’ve been unable to reproduce it by making changes to the Thermostat through MIOS UI5 and a scene that changes the temp & sets the HeatOn every 5 seconds for 30 seconds.
I’m going to test an interval schedule for that scene to see if I can provoke it later today.
This sounds like you ran out of memory to me!
It’s probably not a single plugin, but a couple of them getting events at the same time.
When I plugin get’s event it’s memory utilization goes up as it starts to use it’s program stack.
Each plugin (not controlled by parent) has two stacks (can be doing two events) at a time.
So it can be a burst of events at a single time that cause you to run out of memory.
Also if it’s at the same time Linux wakes up to rotate the logs … it instantaneously eats up some more
memory.
Do you have a USB stick for logs ? If Not the logs are also going into memory.
I do and it’s configured.
I’ll clean up the XML files to ensure nothing unneeded gets loaded and remove any plugins & instances I’m not using.
It seems odd to me that it’s only the 2nd floor thermostat that has this problem though…
Are you using a Wifi thermostat or Z-Wave thermostat ?
Instantaneous memory required for Wifi thermostats is much larger because of the Network layers; and can last longer which opens up more windows for memory contention.
[quote=“RichardTSchaefer, post:8, topic:178110”]Are you using a Wifi thermostat or Z-Wave thermostat ?
Instantaneous memory required for Wifi thermostats is much larger because of the Network layers; and can last longer which opens up more windows for memory contention.[/quote]
Z-wave only.
And one more thing I have seen that destabilizes the Vera System … Do you use the Energy Plugin ?
If you mean the Ergy plugin then no, I got rid of that “abomination” a long time ago (for those reasons - instability).
I’ve migrated my PLEG logic into a single instance and it raises a question:
Since PLEG does not appear to check the state of the devices until something causes it to have to (an event related to that specific device), the status for that input and related condition(s) is false, correct? As a result, the “correct” way of triggering on an inverse condition (i.e. Light Switch Off vs Light Switch On) would be to have one input [LightOn] = Switch is turned on and then the inverse “LightOff” should be “NOT LightOn”?
This way, the ‘LightOf’ condition will always be true until somebody actually turns the light on.
If this is the “best practice”, what safe-guards exist to ensure that if a switch is manually changed during a Vera restart, the associated PLEG value reflects this change?
Is it possible for PLEG to
In version 5.3 I added logic to handle setting state of new inputs as well as synchronizing with changes that may have happened while Vera was off.