PLEG device file size limitations?

Fairly sure I’ve read the answer somewhere on the forum but can’t find it again…

Are there limits to the size a single PLEG device can or should be? And does a single, large PLEG perform better/worse than multiple smaller ones? Does risk of device corruption increase as a PLEG gets very large?

Thanks.
Wade

Any time an input is triggered … ALL conditions are evaluated.
So the issues is really how active the inputs are.

It’s OK to have a LARGE number of conditions where the inputs are occasional.
For something that triggers many times or rapidly … you probably want a SMALLER set of conditions.

Helpful, thanks. One follow-up. If a PLEG contains more than one NOW statement, do they fire the conditions independently or is it no different than having a single NOW? Again, trying to better understand performance impacts.

Worse. And the issue is not just speed - but potential deadlocks that cause Vera to restart when multiple actions might be triggered by a single PLEG at roughly the same time. Those same actions spread across mutiple smaller PLEGs, generally speaking, would have less of a chance of causing a deadlock.

I know Richard’s answer is the correct one, and it really does depend on a number of factors, but I want to be a little less technically correct and steer you to think of creating smaller lighter PLEGs. Especially if the triggers are going to happen frequently. For example, trying to automate the lighting for an entire house in a single PLEG would not work well, as it would be noticeably slower and cause regular restarts (in my experience). I have 5 PLEGs for lighting and they respond almost instantly and even a house full of people (motion detection triggers firing constantly) will not generate a deadlock.

Long-term get rid of NOW completely from your logic and use timers (AKA schedules). But when you are first building your automation, NOW is easier and won’t become a performance issue until you have a lot of logic…

Thanks for the additional explanation. This aligns with my experience of seemingly increased restarts as my lighting control PLEG has become more complex and lengthy.

So far I’ve managed to use only schedules/timers but was thinking of combining a 3 functions that would be very simple using NOW–if doing so would be the equivalent of using NOW only once since they’d be in a single PLEG. My thinking being that wouldn’t be a great burden on the controller. But maybe best to continue to avoid it altogether…just requires a bit more head-scratching for a PLEG neophyte such as myself.

Worse. And the issue is not just speed - but potential deadlocks that cause Vera to restart when multiple actions might be triggered by a single PLEG at roughly the same time. Those same actions spread across mutiple smaller PLEGs, generally speaking, would have less of a chance of causing a deadlock.

I know Richard’s answer is the correct one, and it really does depend on a number of factors, but I want to be a little less technically correct and steer you to think of creating smaller lighter PLEGs. Especially if the triggers are going to happen frequently. For example, trying to automate the lighting for an entire house in a single PLEG would not work well, as it would be noticeably slower and cause regular restarts (in my experience). I have 5 PLEGs for lighting and they respond almost instantly and even a house full of people (motion detection triggers firing constantly) will not generate a deadlock.[/quote]

can you explain more specifically what a deadlock is? why it’s happening?
I have a “automation pleg” and when my garage door is opened, 2 things happen. a voice announcement is made and a disarm code is sent to my alarm.
almost every time this happens, i get a luup restart. i’m not sure why.
I have a night time task, that kicks off 6 or 7 actions plus voice alert and never get a luup restart.
so i’m not sure how to think about what is causing the issue? pleg? resources? zwave? vera/luup?

[quote=“mvader, post:8, topic:197493”]can you explain more specifically what a deadlock is? why it’s happening?
I have a “automation pleg” and when my garage door is opened, 2 things happen. a voice announcement is made and a disarm code is sent to my alarm.
almost every time this happens, i get a luup restart. i’m not sure why.
I have a night time task, that kicks off 6 or 7 actions plus voice alert and never get a luup restart.
so i’m not sure how to think about what is causing the issue? pleg? resources? zwave? vera/luup?[/quote]

First you need to verify via LuaUPnP.log what is causing the restart. Might be deadlock, might be something else. A place to start would be http://wiki.micasaverde.com/index.php/Logs and http://wiki.micasaverde.com/index.php/Luup_Debugging.

If deadlock is confirmed via the logs, then we could recommend ways to space out the two actions…