PLEG Usage Rule of Thumb?

Plugins & Plugin Development Program Logic (PLEG)
1

Hi all,

I have just obtained a veralite and am trying to start off the right way and use PLEG from the start rather than built in scenes etc.

Can someone tell me however what the rule of thumb is for creating an additional PLEG instance. i.e. do I create one for every collection of related scenes I want to provide or lump everything into one PLEG?

I have more questions but this is my first :slight_smile:

Thanks.

2

I have 2 PLEGs, one for my heating, the other one for lighting and that one also deals with my iphonelocator (turning alarm/heating/lights on/off depending on home or away). Each of those have about 40 conditions plus schedules and actions. So far they are working fine. I think it makes sense to have this in 2 seperate PLEGs, otherwise it becomes a bit too cluttered. I am considering splitting into 3 now (seperate the iphonelocator logic) but so far cannot be bothered as its not easy to just transfer, i would have to redo all the conditons (as far as i am aware there id no easy way to split a PLEG)
So depending on what you are planning, if it is going to be a little more complex, i would consider starting up with a couple of PLEGs. If not one should do for the beginning. You can always add another one at a later stage

3

Thanks,

I was thinking about creating one for each “category”. So “lights & sockets”, “security”, “heating” etc. however I guess if I want a scene which involves all of those parts then it becomes a bit convoluted anyway. If some people just use 1 PLEG instance for all then I’ll equally do that, just need to be more descriptive with any attributes so I know what they refer to etc.

4

The down side of too many conditions … is that when events happen … all of the conditions are evaluated.
So there is wasted CPU cycles if you evaluate 100 conditions but only need to evaluate 2 or 3.

5

I am slowly coming to the point where i should split PLEGs, as i now have about 40 conditions each. Is there an easy way of doing that ?

6

Not at this time. Save a copy of the original report until you migrate things.

7

[quote=“RichardTSchaefer, post:4, topic:178133”]The down side of too many conditions … is that when events happen … all of the conditions are evaluated.
So there is wasted CPU cycles if you evaluate 100 conditions but only need to evaluate 2 or 3.[/quote]Richard, is there a way to only evaluate the conditions in which a variable has change or has the NOW condition?

8

I have to evaluate all … because of cascading of conditions. I do not have a static dependency graph for the expressions.

i.e. A condition could reference other conditions … which reference other conditions …

9

Doesn’t that would meet the same criteria?

eg. I have 100 conditions and 30 triggers. One trigger changes that affects only one condition, so only one condition es evaluated. The state of that condition changes, that condition applies to four conditions, so those four conditions are now evaluated, one of those four conditions applies to another condition, so that new condition is evaluated. That condition is not used in any other, so evaluation stops. The count is 6 conditions evaluated instead of a 100.