How about a new PLEG/PLTS thread?

I’m appealing to all you PLEG plug-in gurus for contributions.

If you all would consider listing your different PLEG configs in a common thread, we newbi’s could learn a lot about the methods to write conditionals and events.
It would be a tremendous help to everyone to how you are implementing this great plug-in for your uses.

By sharing your event control goal, then listing the inputs, conditions, and actions people like me could learn how all this comes together to make Vera magic.

Plus, at the end of the day, all of us could gain some great HA ideas to share among ourselves.

How about it? Let’s give back. I promise to contribute…once I get my systems going as well.

Plus this would take some pressure off of Richard answering dumb questions from newbi’s like me LOL.

It’s a nice idea, @bucko, but I wonder how useful it really would be. We all construct our logic according to what devices and plugins we have and how, exactly, we want our automation to behave. Is it feasible to encapsulate all this in such a way that it helps others with completely different system components and requirements? Most of the posts I respond to have subtly different automation goals. It would be great to be able to package-up solutions for typical requirements but what’s typical?

I have no problem in posting the logic from my various PLxx devices. I often do this in threads where I believe it is relevant but I usually extract the salient part of the configuration. My concern is that you would need to know a lot about my system, circumstances and careabouts before the complete logic made any sense at all. You would still need to learn how to configure PLxx in order to adapt what works for me to what would work for you.

I learned long ago that, the best way to learn stuff is to start doing it. Try, fail, try again, learn. I don’t believe that anybody can give you a recipe to short-circuit this process. Others may feel differently but I believe that forums work well when members ask for help when they get stuck and any other member can offer suggestions and advice.


I understand what you are saying. Everybody has a different setup for sure. But if one is able to just see examples in print, you can get a better understanding of the logic and syntax you all use to implement automation. If I was able to copy and paste say a condition expression, then I would have a good base to tweak with and better understand how it effects my devices. I could get a faster understanding how changing this syntax breaks or effects my devices. Starting from a blank page I write something that is broken in 5 places and even if I fix one or two correctly, I would never know which ones are right or wrong.
This is my point to seeing other people’s coding and following what is actually good code because it ia already working for you.

As another example, a while ago I took the Panasonic cam plug in and tweaked it until I got it working fine with my IPUX cams. Now I have PTZ control where before I had to settle with just getting a picture to actually appear. Once I fudged with the Panasonic plug in, I was able to to use my cam’s cfg commands to do PTZ. But if I never saw the Panasonic coding, I would not know where to begin where to paste my cam’s own commands.

If people had good working PLEG examples, at least we could break them in the process of learning how to have my own devices do something. It would really help out us newb’s get a handle how to even start.

I agree, it would help to see a few sample configurations. I do not understand the syntax instructions on the pleg website at all, nor their sample configurations. So any sample configurations, possibly with a little writeup of what it is supposed to do, gives you ideas of what you can do with it, as well as teaches you of how to achieve that

OK, I’ll try to cut some examples out of my PLxxs and write them up.

Meanwhile, I recommend setting yourself up a PLxx test lab. In my case, I keep two PLEG, two PLTS, four VirtualSwitch and two VariableContainer plugins in a dedicated room (Z_Test). When I am working on new logic, I check it out with the Z_Test devices. When it does what I want, I either copy/paste the conditions into existing PLxx devices or edit the triggers, properties and actions to the real hardware and move the PLxx to the required room - then create a new PLxx in the test lab. It beats waking up to no heating. ;D

“Z Test room”, wow what a great idea.

I gather that this is the genesis of a great thought provoking thread.

Being a green newbie, there is a lot to be learnt, hopefully this question isn’t bordering on the ridiculous, but where do I find the VirtualSwitch Plug-In that you use?

RexBecket, the Z-test room is a great idea. You see, this is the stuff I talk about. This stuff may seem routine to you, but many are standing in a dark room and have no idea which way to go. What seems basic and logical to you is an epiphany to many others!

I thank you in advance for your help.

OK, let’s see how this works…

I have attached PDFs of the Reports from a PLEG and two PLTSs. The PLEG is an extract of my main heating and hot-water logic. The two PLTSs are simple monostables that give a five-second pulse whenever the associated VirtualSwitch changes state. The need for these is peculiar to how I like my logic to work: When I change the state of one of my master switches, I want the logic to syncronise regardless of where it is in the timing cycle. The pulses make this easy to achieve.

My main heating is controlled by a Horstmann HRT4-ZW thermostat which is directly associated with a HorstMann ASR-ZW relay. I don’t really ever turn the heating on or off - I just change the temperature setpoint. The required setpoint is calculated in the PLEG according to various states. When the master switch HouseHeat is off, the setpoint will be 8 degrees for frost protection. During the night or if I am away from home, the setpoint is 14 degrees. In the morning it is 20 degrees and it drops to 19 degrees after 10 am. The calculation is in the condition SetPoint supported by Heat and DoDrop. The setpoint is sent to the thermostat by the condition SendTemp which evaluates the circumstances under which I want the temperature to change.

My master switches include: EarlyStart which enables a separate pair of on and off schedules for a one-time override of the normal ones. This activates both heating and hot water and I use this when my clients demand my presence at uncivilised times of the morning. HouseHeat is the main enable for heating above the frost-protection point. HotWater is the enable for water heating. HWBoost triggers a one-shot 30-60 minute cycle of water heating which is useful when guests are staying. It is also fired automatically when returning from vacation (during which the water heating will have been off). Most of the master switches are set and cleared by various remote controls scattered around the house. They are also on the Dashboard for access by 'phone.

The schedules should be mostly self-explanatory. In addition to the normal weekly on and off times, I have absolute times for start and finish of vacation (Away and Home) and a 30-minute interval (see later).

The device property HWRelayMode is used to capture the last command sent to a second Horstmann ASR-ZW relay that controls the hot water tank motorized valve - which in turn “calls” for heat from the boiler dependent on the tank 'stat. The ASR-ZW has a fail-safe mechanism that requires periodic resend of the required state. The condition HWPulse, triggered every 30 minutes by the I30M schedule, fires an action which re-transmits HWRelayMode thus refreshing the ASR-ZWs watchdog. This will work even if I have set the relay state external to the PLEG.

The conditions include three sequence expressions: EarlySeq, NormalSeq and AwaySeq. These conditions are true when the sequence has completed. E.g. AwaySeq is false when I am away and true when I am home. The remaining conditions use the state of these sequence conditions along with the master switches and schedules to determine when to change the heating thermostat, what setpoint to send and whether the hot-water should be on or off. The DoAway and DoBack conditions also fire actions to set or clear a VirtualSwitch called Away which activates another PLEG to manage lighting and other security features when I am not at home.

The actions should be fairly obvious given their names and the above explanations.

I really don’t know how useful this will be to others. I did it this way because that’s how I want it to work. ;D Some of the logic is designed with future enhancements in mind - so there are simpler ways to achieve it if that is all you need.

If you want more details on any of the above, please ask.

Thanks RexBeckett

Now I got homework to do. But this is great for me to look at.

HI RexBecket,
You did a grreat job explaining your setup and then posting the configs for it as well. I’ve been studying this and I kinda see the process.

Your example of heating controls may be a little bold for me. There is a lot going on. Do you have a more dummied down scenerio at hand? Like maybe just some lights with various triggers and conditions?

Do you use the PLEG for doing all control of lights, or do you make Vera scenes and have PLEG give scenes more functions to lights?
If I make a PLEG including many lights and conditions and events- can I create different scenes and pick and choose from my single “PLEG library” to add triggers to these scenes. Like say I create a PLEG condition and use it in a Vera scene as a trigger?

As for most software, the last person you want to explain things is the guy that wrote it :slight_smile:
So I thank @RexBecket and others who have assisted others to understand the PL plugins.

Do you use the PLEG for doing all control of lights, or do you make Vera scenes and have PLEG give scenes more functions to lights?
For me, I only create scenes for two reasons: 1) I want to invoke a bunch of things together. i.e. it's a named macro. I invoke these scenes manually (typically) and they are not part of my automation. 2) I need to drop into LUA coding.

With the PL plugins I have removed almost all LUA coding.

create a PLEG condition and use it in a Vera scene as a trigger?
You can trigger any Scene from a [b]PLEG[/b] or [b]PLTS[/b] device. A single [b]PLEG[/b] can generate lots of unrelated events. I typically group similar events into the same [b]PLEG[/b] device (A [b]PLEG[/b] device to handle lights and bathroom fans, . A [b]PLEG[/b] device to automate house occupued and secured status, A [b]PLEG[/b] to manage my various water pumps, ...)
Do you have a more dummied down scenerio at hand?

Not really, I usually add simple tasks to existing PLEGs as RTS suggests. I extracted the heating example out of a more complex setup. These devices can handle a huge amount of logic so you don’t need one for each task.

The most simple device I have is the one that only manages a single bathroom fan (at the moment). This is a PLTS and I did post an earlier version elsewhere. The light and fan are controlled by a dual relay module (Fibaro FGS221). Each relay has a local on/off switch and is also controlled via Z-Wave. The module reports local change of state immediately - which is essential for this application.

When the light is turned on, the fan does not start immediately. It starts if the light remains on for 3:00 to 3:59 minutes and is enabled by a timer set for 10 minutes (Interval2). If the light remains on for 8:00 to 8:59 minutes, the timer is restarted for 1 hour (Interval). The fan will also be started for 1 hour if the bathroom humidity exceeds 40% - regardless of whether the light is on or off. The fan can also be started for one hour by turning on the local fan switch. The fan timer can be cancelled by turning off the local switch (or turning on then off) if required. The fan can be started for 10 minutes by turning the light off then on (or on then off then on) within ten seconds.

The ten minute timer is started by Trigger2 which is fired if the light remains on for 3 minutes or is switched off/on in 10 seconds. The one hour timer is started by Trigger which is fired if the light remains on for 8 minutes or the humidity exceeds 40%. The condition Restart copes with the situation where a second shower happens whilst the fan is still running from the previous one. In this case, the one hour timer will be restarted if the light remains on for 8 minutes. The condition Reset stops the timer if the local fan switch is turned off. The condition On is fired if the local fan switch is turned on. Note that PLTS will start its main timer (Interval) when On is fired so the fan will be turned off after one hour when the timer expires.

The reason for the variation in trigger times (E.g. 3:00 to 3:59 minutes) is down to how the term Now > mm:ss is evaluated. An expression that includes Now will be evaluated once per minute - exactly on Vera’s minute. If the time mm:ss has not been reached, the clause will remain false. So it is possible that the clause Now > 3:00 is checked at 2:59 and remains false until checked again - one minute later - at 3:59 when it will become true. If you need timing to be more accurate then -0/+59s, then Now is not the way to do it.

The principles of Triggers, Conditions, Schedules, Conditions and Actions are the same in PLTS and PLEG and similar logic could be implemented in a PLEG. The advantage of PLTS in this case is that the dual-interval timing and “flip-flop” mechanism is built in.

Thank you again RexBeckett. I am just off to HK this morning, but I will study your fan control when I return.

This is helping me a lot.

I have been testing the PLEG in my “testing room”. The biggest frustration is that if I delete stuff in the PLEG, it does not seem to update the Logic core engine. Even after deleting triggers in the Automation tab, PLEG still errors out. If I make a mistake in the PLEG, I usually have to delete the PLEG or PLTS entirely and start over.
I tried refresh, reboot the VERA, but PLEG errors never go away until I just create a new PLEG and start all over. This “discovery” had me going crazy and was the cause of me being so confused when I play around in the PLEG. It turned out my configs were correct, but the PLEG kept “failing to start” due to old junk floating around somewhere.

You MUST delete the conditions that are effected when you delete inputs for a PL plugin.
When you delete a Trigger from the Automation tab when a scene is not selected … It will effect either a Scene or a PL Plugin … and harm the associated automation.

For the PL plugins it does not hurt to have more inputs than you use in your conditions.
You must have inputs associated with each variable name in your condition expressions (or references other condition names).

Even if the PL plugin complains … it does not stop other activities from running on your Vera.
My recommendation is to ONLY use the Triggers tab in Automation when a scene is selected (to add/edit/delete a trigger for the scene). The only legitimate value this tab has outside the context of a scene … is to show when the trigger last fired.

Ok Richard. At first I just deleted the condition and the event. But on reload the PLEG lupp failed to load. That’s when I did the trigger delete thing ( which now I will not do again.)

Thanks for the heads up. I will try your way again next time.

Here is my first and finally, with a lot of help from RichardTSchaefer and others, successful attempt at using PLEG
I have two outside lights, bot being able to be switched on individually. I also have a motion sensor, which is supposed to switch on both the lights for 90 secs, but only when it is dark. If i manually turn on the lights, triggering the motion sensor should not switch off the lights. So far thsi works, but only if i only switch 1 light on manually, then triggering the motion sensor does not switch on the second light, and the light stays on all night until a certain light level is reached, then it is switched off automatically.
I would prefer if i could switch both lights on manually and the motion sensor then being ignored, but i have not managed to get that to work without involving something like on-off-on, which i have seen in one of the sample PLEGs

I think your problem is that ManualOnx and ManualOffx are just the states of the relays. These will change when the light is switched on or off by either the manual switches or PLEG actions. To have conditions based on only manual switching will require some form of memory as to what caused the state change.

You could use the arm/bypass state of the motion sensor as a memory but that would prevent the motion sensor switching on the second light if you had manually switched the other one on. You probably need to separate the logic for the two lights. I have not been too successful in getting PLxx conditions to work reliably as memories - although I haven’t tried this in the latest release. RTS can probably show us how it can be done. Meanwhile…

One solution is to use a couple of VirtualSwitches as memories. Note: I have changed your trigger names from Manual… to Light… to avoid confusion.

Manual1On LightOn1 and !MotionOn
Manual1Off LightOff1

Manual1On VirtualSwitch1 SetTarget = 1
Manual1Off VirtualSwitch1 SetTarget = 0

Would turn on VirtualSwitch1 if Light1 was switched on without the motion detector triggered - i.e. manually. Now you can have conditions like:

DoLight1On (Lightlevel < 70) and MotionOn and !VirtualSwitch1On
DoLight1Off Light1On and ((!VirtualSwitch1On and (DoLight1On; Now > 1:30)) or (Lightlevel > 100))

and corresponding actions. Repeat for Light2 with appropriate changes. This is not tested so may need a tweak or two.

Here is what I would do:
I would rename the triggers to accurately reflect the actual state

Rename: Trigger ManualOn1 to On1
Rename: Trigger ManualOn2 to On2

I would delete the triggers ManualOff1 and ManualOff2

My conditions would be:

Dark LightLevel < 70
BothOff Not (On1 or On2)
AutoOn Dark and MotionOn and BothOff
BothAutoOn (On1 and (AutoOn; On1 < 1:00)) and (On2 and (AutoOn; On2 < 1:00))
AutoOff (BothAutoOn and (AutoOn; Now > 1:30)) or (Not Dark)

Appropriate Actions for AutoOn and AutoOff

Rex if i look at condition Manual1On LightOn1 and !MotionOn, that would not be the manual on ? I would need to negate the MotionOn, could I do that instead: Manual1On LightOn1 and NOT MotionOn ? Not sure about syntax, also is there a reason you have ! in front of MitionOn ?
I was thinking about using a virtual switch, but did not know how to set it out of PLEg, so thats taught me a bit more again, which is great

I forgot to mention, an additional problem with the manual on/off condition could be, i am using LightwaveRF lights for the outside lights, and to turn them on/off manually i use a LightwaveRF remote, which might make it all impossible. In the meantime Richard your programming looks a lot neater, so i think i’ll change mine.