Repeat Scene Until - Run Pump while temperature is freezing

Developer's Corner Scene Scripting
#1

Trying to get a handle on schedules and triggers and reading devices …
My goal is to turn my pool pump on when the temperature is below 32 degrees. I want to run the pump for 10 minutes then turn it off. I’d like it to stay off for 20-30 minutes and then check the temperature again.

I have four scenes to turn equipment on and off - 1 scene each to turn the pump and polaris pump on, 1 scene each to turn the pumps off. I’ve setup schedules for these scenes - turn the pumps on at 6:00 a.m., turn the pumps of at 11:00 a.m. for example. That all works fine.

I created a scence call FreezeConditions that will turn the pumps on. I found and modified some luup code to check the temperature and only allow the scene to run if the temperature is below 32. I put this in the luup tab of the FreezeConditions tab - seems to work correctly when I manually run the scene.

local dID = 31 -- Device ID of your thermostatic/temperature sensor local tLow = 0 -- Lowest temperature of range local tHigh = 32 -- Highest temperature of range local allow = true -- true runs scene when in range, false blocks it local tCurrent = tonumber((luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature",dID))) return (tCurrent <= tHigh) == allow

I thought I would create a schedule to run the scene every hour - if the temp is below 32 it will run the scene, if not the scene will abort and the schedule will run again in an hour.
But, I thought that’s a lot of schedule running 365 days a year and pretty pointless most of the time (I live in the south). So I thought adding a trigger would be a better way to go.
I added a trigger in the triggers tab of the scene that checks the Wunderground temperature device and runs if the temp is below 32.

The trigger fired fine the first time - ran the scene and sent a text to my phone as requested. But the trigger did not fire again. I am suspecting the trigger will not fire until the temperature changes, i.e. the status of the device actually changes. Is this a correct assumption?

Keeping the solution simple, yet elegant, what is the best way to re-check the state of the device and re-run the scene without setting up a schedule to run periodically?

Once I get this sorted, I will want to figure out how to keep the scene from running if the pumps are already on - i.e. the regularly scheduled scene is in progress. Pointers on this would be very welcome as well.

Thanks in advance!

#2
The trigger fired fine the first time - ran the scene and sent a text to my phone as requested. But the trigger did not fire again. I am suspecting the trigger will not fire until the temperature changes, i.e. the status of the device actually changes. Is this a correct assumption?
The trigger will not fire again until the temperature rises to equal-to/greater-than 32 and then falls again. That is the nature of triggers.
Keeping the solution simple, yet elegant, what is the best way to re-check the state of the device and re-run the scene without setting up a schedule to run periodically?
You would need to set up a luup.variable_watch(...) callback to be notified if the temperature variable changes. This level of logic is really best handled by the Program Logic Event Generator (PLEG) plugin. This will allow to to make it all event-driven rather than polled.
Once I get this sorted, I will want to figure out how to keep the scene from running if the pumps are already on - i.e. the regularly scheduled scene is in progress. Pointers on this would be very welcome as well.
See the previous answer. PLEG would make this easy to implement.
#3

Attached is the PLTS report I use to automate my water pump for Rain water collection.

I circulate twice a day for 15 minutes … every day.
As a result, in a little over a month I cycle all of the water in my storage tanks through the filters and UV purification.

During the winter when the temp is below 36F I do this every hour … To make sure my outside pipes never freeze.

After about 2 days below freezing I end up cycling all of the water through the filters.
My Rain Water storage tanks have clear water …
After I get some new rain I might have some contaminants. But it’s a continuous filtering process … NOT just when I consume the water.

#4

Thanks for the pointers. Attached is the PLEG report I created for FreezeControl. Please look it over and let me know if this is a good approach or if I should try something different. Below is how I think this is working …

I am currently using a variable container and light over my couch as my pool pump for testing. I have a temperature device in the device properties and will start using the actual temperature, pCurrentTemp, in place of pFreezeTest when testing is complete.

I set the variable container’s, pFreezeSP to 32 - using the container, I can change the setpoint value without modifying the PLEG itself.

When I start the vera (reload) the PLEG evaluates the defined inputs. Also, when I change the variable container’s, pFreezeTest value, the conditions cBelowFreeze and cAboveFreeze are evaluated because they both reference pFreezeTest.

If the value of pFreezeTest is lower than the pFreezeSP, the condition cBelowFreeze becomes TRUE and starts the Actions for the condition cBelowFreeze. The couch light (pump) comes on and a schedule, RunCycle is started.

RunCycle becomes true until the interval expires. When the interval expires, the condition cRunCycleEnd is evaluated because it references the RunCycle schedule. Since the RunCycle interval has expired, the value of RunCycle is False, so the actions for the cRunCycleEnd condition are fired. The couch light (pump) goes off and another schedule/timer, PauseCycle, is started.

The schedule, PauseCycle, becomes True until its interval expires. When the interval expires, the condition cPauseCycleEnd is evaluated because it references the schedule. Because the interval has expired, the value of PauseCycle is false. If cBelowFreeze is true, the actions associated to the condition cPauseCycleEnd is fired. The couch light (pump) is turned on and the schedule RunCycle is started.

If the value of pFreezeTest changes, the conditions cBelowFreeze and cAboveFreeze are both evaluted since they reference pFreezeTest. If the value of pFreezeTest is greater than the pFreezeSP the condition cAboveFreeze evaluates to True and the actions associated to it are fired - the couch light (pump) is turned off. I think this effectively stops the PLEG until the value of pFreezeTest becomes less than pFreezeSP.

I would like to have used a value in the variable container to control the interval of the two schedules but I did not see away to do that, looks like the interval must be set in the schedule.

How do I create another PLEG device if I want to use it for different task?

Thanks for your help and advice – it is scary to think of the code I’d have to write if PLEG did not exist!

#5
How do I create another PLEG device if I want to use it for different task?
You can create a new PLEG by going to: Apps -> My Apps Click on the PLEG Link ... Then the [b]Create Another[/b]

But you can do a couple of related tasks in the same PLEG.

I would like to have used a value in the variable container to control the interval of the two schedules but I did not see away to do that, looks like the interval must be set in the schedule.
I have already made a change to support changing the interval for self started intervals. It should be in the next release. (5.9) I needed it for some of my logic. It will be an optional argument to the StartTimer action. When it shows up you can delete the existing actions ... and re-create them to get access to the new argument.
#6

[quote=“Bb98, post:4, topic:179068”]Thanks for the pointers. Attached is the PLEG report I created for FreezeControl. Please look it over and let me know if this is a good approach or if I should try something different. Below is how I think this is working …

I am currently using a variable container and light over my couch as my pool pump for testing. I have a temperature device in the device properties and will start using the actual temperature, pCurrentTemp, in place of pFreezeTest when testing is complete.

I set the variable container’s, pFreezeSP to 32 - using the container, I can change the setpoint value without modifying the PLEG itself.

When I start the vera (reload) the PLEG evaluates the defined inputs. Also, when I change the variable container’s, pFreezeTest value, the conditions cBelowFreeze and cAboveFreeze are evaluated because they both reference pFreezeTest.

If the value of pFreezeTest is lower than the pFreezeSP, the condition cBelowFreeze becomes TRUE and starts the Actions for the condition cBelowFreeze. The couch light (pump) comes on and a schedule, RunCycle is started.

RunCycle becomes true until the interval expires. When the interval expires, the condition cRunCycleEnd is evaluated because it references the RunCycle schedule. Since the RunCycle interval has expired, the value of RunCycle is False, so the actions for the cRunCycleEnd condition are fired. The couch light (pump) goes off and another schedule/timer, PauseCycle, is started.

The schedule, PauseCycle, becomes True until its interval expires. When the interval expires, the condition cPauseCycleEnd is evaluated because it references the schedule. Because the interval has expired, the value of PauseCycle is false. If cBelowFreeze is true, the actions associated to the condition cPauseCycleEnd is fired. The couch light (pump) is turned on and the schedule RunCycle is started.

If the value of pFreezeTest changes, the conditions cBelowFreeze and cAboveFreeze are both evaluted since they reference pFreezeTest. If the value of pFreezeTest is greater than the pFreezeSP the condition cAboveFreeze evaluates to True and the actions associated to it are fired - the couch light (pump) is turned off. I think this effectively stops the PLEG until the value of pFreezeTest becomes less than pFreezeSP.

I would like to have used a value in the variable container to control the interval of the two schedules but I did not see away to do that, looks like the interval must be set in the schedule.

How do I create another PLEG device if I want to use it for different task?

Thanks for your help and advice – it is scary to think of the code I’d have to write if PLEG did not exist![/quote]

Hello There. :slight_smile:
Can you tell me which PLEG you are using for this project.
I have version 5.7 in PLTS and under conditions I have not found a way to rename the pre-defined condition names.
and in PLEG version 5.7 I can not find the "Start Timer action.
Can you help with this. I think I could you this for my own project.
Thanks

#7
I have version 5.7 in PLTS and under conditions I have not found a way to rename the pre-defined condition names.
You cannot rename the Conditions in a PLTS. @Bb98 was using a PLEG for his logic.
and in PLEG version 5.7 I can not find the "Start Timer action.
When creating the Action, select the [b]Advanced[/b] tab. Select the PLEG you are using from the drop-down box and click [b]Add[/b]. Select [b]StartTimer[/b] from the list of actions and enter the name of your Schedule.

Have you seen PLEG Basics?

#8

Thank You for the insight I will go back and read the PDF on Actions again. :slight_smile:

#9

[quote=“Bb98, post:1, topic:179068”]I thought I would create a schedule to run the scene every hour - if the temp is below 32 it will run the scene, if not the scene will abort and the schedule will run again in an hour.
But, I thought that’s a lot of schedule running 365 days a year and pretty pointless most of the time (I live in the south). So I thought adding a trigger would be a better way to go.[/quote]

I think you are on the right track with what the others have said. But I do question this logic.

What is wrong with having Vera run a “useless” schedule? Its not as if Vera has anything better to do. (Computer processors are always doing something)

#10
What is wrong with having Vera run a "useless" schedule? Its not as if Vera has anything better to do. (Computer processors are always doing something)

I agree Vera is probably not taxing itself at this point, but an event based approach usually has some advantages and since it is possible, I wanted to learn that approach. I still don’t know what Vera is doing all the time but as I gather, it is cycling through the devices frequently and checking their statuses and I suppose with the PLEG, checking for triggers to see if they should be fired. With the event approach, within a minute or two of the weather app reporting it is below freezing, Vera is activating the trigger which sets the condition which causes the pump to start running. Likewise, within a minute or two of the weather app reporting it is above freezing, Vera stops the pump from running (assuming it is within a run cycle). A schedule could be configured to run every few minutes but, as I said that’s a lot of additional activity going on within Vera to capture an event that is only occurs a dozen or so times a year. And, to get the pump to stop mid-cycle, I’d have to have another schedule running to check the temperature and see if it is above freezing.

I could see where the schedules could get a little confusing, overlap one-another, continue to run when it is below freezing and cause other conflicts etc. The event approach is just cleaner logic once it is all set.

Hope that at least partially explains the desire to use the event method …

#11

The PLEG/PLTS plugins do NOT poll … The design is totally event driven.
If no inputs (Triggers, Device Properties, or Schedules) fire … it consumes NO CPU cycles.
If you use the NOW keyword, that is an implicit 1 minute interval timer, and so it will use some CPU cycles once per minute. It is however designed to be more efficient than a user defined 1 minute timer.

Vera’s internal design is mostly event driven. It does POLL Z-Wave devices that do not provide instant status back to the controller.
But the inputs to any automation scene’s (i.e. Scene Triggers or Schedules) are all event driven. There is NO gratuitous polling loops in the Vera design.

In Vera, Schedules are just events.

Violating the event driven model of Vera is a fast ticket to a Vera restart.

#12

In MY PLTS example I use a timer … because I circulate water all the time … not just based on temperature.

In the summer I cycle the water from my Storage tanks through the Filters and UV light to purify the water. Over a 1 month cycle all of
the water is cycled.

I just do it more often when it’s cold. But I never leave the pump on all the time.