Conditions and Triggers: The difference?

conditions
triggers
difference
faq

#42

See if this helps. This is an old CoRE latching piston:

And here it is reborn in webCoRE:


#43

Thanks for the visualization and explanation. That’s how I thought it worked, but wasn’t sure (and needed to be for the pistons that were latching).


#44

you are welcome.


#45

Is it better to put conditions in a Restriction rather then in an IF statement? Or is it purely just preference?


#46

preference.


#47

Could someone please expound on the difference between triggers and conditions besides how they affect event subscription?

For example, how do they affect task cancellation policy? If triggers are only briefly true when the event arrives, does that mean my task will get canceled a few milliseconds later? (in this example, I’m using the emulated “Fade” action) Will triggers ever cause task cancellation, or is that possible only with conditions?


#48

In a word, yes. That’s why people set the TCP to ‘never’. This way when the expression becomes fslse, the actions will continue.
If there is a wait 5 minutes it will continue and mature. The only time this will stop is with motion for example. If motion should become active again before the timer matures, the timer stops and the actions run again. When it becomes inactive again the actions just carry on.


What is the optimal design for this simple goal
#49

8 posts were split to a new topic: Piston not subscribing to anything


#50

Great write up and explanation! Thank you


#51

Thanks for the info. I have a question using condition:
If the outdoor temperature is below 70
Then say "open the window."
So for example, if outdoor temperature goes from 80 to 65, does the even get executed each time the temperature changes when it is below 70?
Should I use trigger so that it only execute once the first time it drops below 70?
If the outdoor temperature drops below 70
Then say “open the window.”


#52

:+1:


Piston not subscribing to anything
#53

I’m still trying to wrap my head around TCP and how it applies to Triggers, Conditions/Restrictions - in particular when I’ve got a few of those things nested in a Piston. Not sure if this is the right thread, but if anyone has some great insight into exactly how that works with a few examples it would be greatly appreciated. (BTW - I usually make up for my lack of understanding of this by just going through every Trigger and Condition in a particular Piston and changing all the TCPs to none - but I feel like there would be more elegant solutions to my problems if I understood this better.)


#54

Have you read the wiki about it?

https://wiki.webcore.co/Task_Cancellation_Policy


#55

Yes, read it. Great info, and it certainly helps. But I’m not clear about nesting various Pistons Triggers and Conditions. Like if I have a Trigger and then several more IF Conditions below it - followed by a WAIT. If the Trigger state changes does the Piston reset back through all of the Conditions? If a Condition changes does the Piston simply exit that particular IF comparison? If I change the TCP to none on the inner-most IF Condition, that has no effect on the primary Trigger - and the task (which task?) will still cancel on a Trigger change?


Piston not subscribing to anything
#56

By default anything in the THEN section of that IF will be canceled. To negate this you can change the cancellation policy.

I am not 100% sure on this but I do believe it will only cancel the tasks for that condition.

The inner most if would not cancel its check if you change the IF statements TCP. The actions however might cancel because there was a condition change.

You are kind of getting into a weird area without have an example to help you with.


#57

Thanks for this post!! I’m brand new to webCoRE, and was having some struggles until I read this. Mostly due to the fact that I did not understand conditions vs triggers and had pistons with several triggers in them. I believe I’m getting a decent understanding now, and was actually able to fix a few of my funky pistons But had a few questions, if you guys don’t mind?

If I have a piston that is simply “at sunset turn on porch light”. The condition/trigger would be sunset and the event would be turn on. Therefore the piston subscribes to the event of turning on the light based on the condition/trigger being true, correct? Just trying to make sure I have the terminology correct.

I have been able to successfully have pistons with 1 trigger and several conditions. To make these work I put the trigger first in the “if” statement followed by each condition (thanks @bobbles). For each condition I check always subscribe. This seems to successfully override the fact that webCoRE will ignore conditions in a piston that also have triggers present. But can I do the same if I want to have more than one trigger in my “if” statement? Checking always subscribe for each trigger?

What about having more than one “if” statement in a piston? Does each “if” statement have separate rules regarding conditions/triggers? Or does the conditions/triggers rule apply to an entire piston regardless of how many “if’s” there are? This piston below is an example that I’ve yet to be able to fully test, but it has 2 “if” statements. What I’m trying to do is when my wife’s or my phone comes home (changes to present) the smart bulb in my porch light goes from 45% to 100% when it is on which is between 45 minutes to sunset - 15 minutes after sunrise (which is controlled by another piston). Then, once either of our phones presence stays present for 10 minutes the light goes back to 45%.

Thanks again for the discussion in this thread. The terms are a little confusing for me, but I’m getting the hang of it. webCoRE is VERY powerful and interesting to me. I’m amazed all you can do with it!! I currently have a smart bulb in my porch light, switches for my foyer light, living room light and 2 kitchen lights as well as a Schlage connect deadbolt. Plan to add some more switches and eventually some cameras. So I’m sure I’ll be using webCoRE more and more as I add all this stuff.


#58

the condition/trigger would be sunset, the event would be a time event and the task would be turn on.

yes. when using triggers its better to not change all conditions to subscribe. the thinking here is anything that should cause the piston to executed should be a trigger, one or multiple. any conditions that should be evaluated when the piston runs should not be a trigger but evaluated when the piston executed through one of the triggers.

applies to the piston as a whole. but you cannot nest triggers. because each trigger is one event no 2 triggers are true in any single run of the piston. so in the snapshot piston above the second if condition would never be true. instead of nesting those ifs both ifs should be at top level so it looks like this:

if trigger 1
   and
   time condition
   do something
end if
if trigger 2
   do something else
end if

#59

Thanks. Starting to make even more sense to me, but I still have a lot to figure out. Some of my pistons were still not acting as I had in my head when writing them. But I’m getting the hang of it.

So what your saying is in my snapshot piston, I should have separated my if’s with a “end if” instead of “end with”? This would separate the triggers allowing the piston to evaluate each separately, correct?


#60

Alright, I seem to be confusing myself the more I dive into all of this. Correct me if I’m wrong, but below is how my mind is understanding writing a piston in regards to conditions and triggers.

  • A trigger is what causes a piston to begin/execute. If a trigger is the only condition in a piston that sole trigger begin true or false causes the piston to either fire (true) and complete the task or not fire (false).

  • A condition is just that, a specific condition. If a piston contains only conditions then all conditions must be true before a piston will fire.

-Now, if a piston contains a trigger and condition(s) then the trigger being true starts the piston. The piston then checks each condition, and if all are met the piston proceeds to execute the task. If any of the conditions are not met (false) then the piston does not execute the task.

Am I thinking right with the above? Here is one of my pistons that is designed to turn my porch light on 45 minutes before sunset and set the level to 45%. Then at 15 minutes past sunrise it turns off the light. Now, this piston contains 2 triggers so I did what @bangali said above and ended the first if with “end if” instead of “end with” and then added my second trigger (15 min. before sunrise) which then turns off the light. Am I putting these triggers in the piston properly?

Another, slightly more complex, piston I’ve been trying to get to work is one that is designed to turn on my living room and 2 kitchen lights when the front door is opened but only if my wife or my phone presence is present and only if either phone was not present for at least 10 minutes, and only between a certain time. So what I did was set the trigger as front door sensor changes to open as the trigger and then if is the 3 conditions mentioned above. Does the “then if” separate the 3 conditions properly from the trigger to make this piston work? Or should I be listing the conditions in the same if as the trigger? Maybe I’m overthinking things? But I’m still struggling with properly separating conditions and triggers to make things work as I want.


#61

right.

the piston always fires on the trigger event. then in the piston the if checks determine whether tasks should be executed or not.

if a piston contains only conditions then all conditions act as triggers. so the piston is executed on events associated with each condition. then in the piston the if checks determine whether tasks should be executed or not.

this is true for both triggers and conditions. independent of what triggered the piston to be run all triggers and conditions are checked and if true the associated tasks under the condition are executed.

yes this is correct.

just list them in the same if. so long as one of them is a trigger and the rest conditions it will work fine. also if you keep the wait 9 seconds in there and the door changes from open to close during that time it will cancel the tasks. so you may want to remove the wait 9 seconds.

try a couple of example pistons combining triggers and conditions in various ways then use trace to see what is happening or not. just a matter of practice.