Divide PLEGs?

Richard,

As you already know, I have only one PLEG with more than 80 conditions of all types: lights, security, music, presence… I am thinking of splitting them into three PLEGs in categories:

[ol][li]Lights[/li]
[li]Security and Presence[/li]
[li]Music[/li][/ol]

Not exactly, but I think that I could have like 30 conditions for each PLEG. But many triggers would be in every PLEG, for example, I always check the status of a light for turning other lights (lights PLEG), the same light is checked when opening the lock (Security and Presence PLEG) and the same light is checked with a schedule to see if music should be turned on or not (Music PLEG). Do you think that I would have a performance improvement? I don’t worry about ‘organization’ and that, as you remember, I use pretty long names, although it is weird, but it let me find my way very easy in my actual > 80 conditions in only one PLEG.

May I ask how many Plegs do you use? What type of Vera do you have? I have VeraLite with USB logging.

If I do it, I found a way (I think) to make the splitting a little ‘easier’:

[ol][li]From my actual 80 conditions PLEG, in the advanced tab, I copy in a safe place the value of triggers, condition map, schedules, properties and actions. I am ignoring the Object Status Map as I don’t see any sense in saving it.[/li]
[li]I create two new instances of PLEG[/li]
[li]I do the Vera Dance, (reload, ctrl+f5)[/li]
[li]I create on each new PLEG instance an arbitrary input, schedule, property, condition and action so the variables are created in the advanced tab (they do not appear at first).[/li]
[li]Vera Dance[/li]
[li]I delete the contents and paste on each new instance of PLEG the values backed up in step 1 into the advanced tab[/li]
[li]Save and Vera Dance[/li]
[li]Now I have three identical instances of PLEG[/li]
[li]Start deleting the triggres, schedules, properties and conditions in each PLEG so I only leave the ones I need in each category[/li]
[li]Save and Vera Dance[/li][/ol]

I know it works, I tried, my question is more inclined to the performance effects that I would have. Should they improve? I am looking more for an opinion.

Thanks as always.

I need to (or want to) split one of my PLEGs, and that is a really good way. I was thinking of copying and pasting from the status report, but i think your way sounds a lot easier, especially with bigger PLEGs. I will try that.
Very good idea.
I do not think it will give you any performance increase, if anything you might loose a little as you are using a tiny bit more ram from what i understand about PLEG. But i think you would only notice if you are close to using up all the ram on your vera, so i would not worry about it. But i think it all makes up for in the easier error finding and debugging, so well worth it i think. I have about 40 conditions in each of my PLEGs, and they are becoming cumbersome to edit now… hence the thought of splitting…

I did it and works fine. As you say, not a lot of performance improvement, but is more organized. Tell us how it goes.

Hi all,

I am trying to do the reverse - merge PLEG’S - any one tried it / done it with any success?

Haven’t try it, but it should be really easy with a little patient.

First, if you have repeated triggers, name them exactly the same way in each of your plegs, this will update your conditions to share the triggers’ name so your conditions become “compatible”.
Then, pick the PLEG that is going to persist and create any non-existent trigger right there with the same name. When you are done with both things, you could move your conditions from one to another without modifying anything, just copy and paste.

Okay I gave it a go and since the code is lengthy I ghink I went wrong.

I asume I need to merge the data in that I need to paste inside the [ ] or can I just add it all at the end?

Also I was not going to go through and rename triggers but more over fix duplicates later if they arise. Will that work or will duplicates cause issues?

Thanks for your help :slight_smile:

EDIT:

All worked. I simply reversed the above. i backed up each instance of pleg first. then copied each relevant line of data into Notepad++ then in Notepad++ joined them, then created a new device, inserted data, vera dance, looked in report for any duplicates (there were a couple) I changed / amended them. Shazam - all seems to work fine.

I wanted to do this as I have 12+ PLEGs and seek to combine each rooms lighting pleg (x8) into one thus improving the system speed hopefuly.

I find tweaking Vera to have less apps/plugins is always an improvement to support reduced ‘laggyness’.

@LightsOn, I was not suggesting to do the merging through the Advanced Tab, I was suggesting doing it the old fashion way: cutting and pasting all the conditions, that is why yo first have to rename the triggers so they are coincident. If you don’t rename them and then delete the duplicated ones, it will not work.

Hi Vroe

that is why yo first have to rename the triggers so they are coincident. If you don't rename them and then delete the duplicated ones, it will not work.

I found they do work - I just received a duplicate in PLEG - I simply deleted the identical trigger and all works? is there something behind the scenes I am not seeing?

I haven’t done what you are doing, I am just guessing what it is logical, maybe RTS can be more specific, but if you did that through the advanced tab and manage to generate duplicated triggers with exact names and then delete the reapiting ones, maybe that is a bug that is working on your favor or you could end up with corrupt plegs…

Yes, I see what you mean - I shall PM Richard tomorrow once I have had a chance to run some tests. I would guess if I edited the instance and saved it again it would add a “1” as it does in other multiple cases but due to my merging perhaps it lets me get away with it? So far all is good. Spotting the odd duplicate is easy enough in my set up and seems to work great after removing them. I am cutting from PLEG, adding to notepad++ merging all data and pasting it back so not actually merging in the PLEG but close enough.

Nice, let’s see what RTS says. It seems like a very good work though.

PLEG will not fall apart because INPUTS have the same name.
You will just get weird results if this is not fixed. Both actual devices change the same variable. So value and time stamps will be meaningless.

Deleting the duplicate input will not be a problem … because it does not remove the variable from the conditions … I do this so you can create a new input with the same name …
I do this a lot for testing … I change an input to a device that’s easy to manipulate … then change the input to the real device after testing is well under way.

I am not sure of other operations … such as renaming … it will likely change the others …

The user interface is designed to keep you from re-using the same user name. So I do not know what will happen in all cases.

Deleted

Thanks Richard, I am yet to fully test but initial results agree with your statements. e.g duplicates and obvious errors left will cause anomalies / errors. if corrected - all should be fine if nothing is too ambiguous.

@EarlyMorningHours
I agree - I am merging all my Lighting PLEGS that were originally for each room now moving them into one so i can then begin new projects on other spare plegs otherwise the 12 i already have will grow further and although happy to buy more is not the best for minimising app etc on the system.

One thing I do to split things up for lighting to just throw it out there. I split up my lighting into two plegs. One for motion activated and one for schedule. I do this for scene control so that if I enable a scene for when I have company over I can just bypass the motion pleg to keep it from turning lights off. For me it’s easier than bypassing the sensors themselves.