Conditions and Triggers: The difference?

conditions
triggers
difference
faq

#1

as new users join the community, we expect that at some point many new users will ask this question. so, heres a quick note.

conditions: if there are NO triggers in a piston, webcore checks the conditions to 
            decide which events that piston should be subscribed to. if there are  
            triggers in that piston, webcore does NOT subscribe to the events the 
            conditions refer to.

triggers: if there are triggers in a piston webcore ONLY checks the triggers to 
          decide which events that piston should be subscribed to.

2 common followup questions that come to mind:

1) why use conditions, why not only use triggers?

because 2 triggers can never be simultaneously true. in the following example, the AC will NEVER turn on. why? each piston processes ONLY ONE event at a time and each unique trigger’s data is sent to the piston as ONE event.

when room sensor’s motion changes to active the piston will receive an event. then checking the 1st condition, the motion changes to active will be true. the piston will then proceed to check the 2nd condition. since its a trigger, it will check the current event in hand and find that its not a temp sensor 1’s temperature event, so the 2nd condition check will fail. similarly if the event that is being processed was a temperature event from temp sensor 1, the 1st if condition check would fail since its a trigger and this is not the right event.

if Room sensor's motion changes to active
   and
   Temp sensor 1's temperature rises above 80ºF
   with AC
      turn on
   end wtih
end if

however, if you write the same if as following. when motion changes to active the piston will receive an event. when checking the 1st condition, the motions changes to active will be true. the piston will then proceed to check the 2nd condition. since its a condition, it will check the current value of temperature for temp sensor 1 and if that is higher than 80ºF, the 2nd condition will also be true and since all conditions for the if now evaluate as true, the AC will be turned on.

if Room sensor's motion changes to active
   and
   Temp sensor 1's temperature is greater than 80ºF
   with AC
      turn on
   end wtih
end if

2) why use triggers, why not only use conditions? :slight_smile:

mostly to avoid inefficiency. in the following piston, since this if only has conditions, it will be subscribed to events from both the room sensor’s motion and temp sensor 1’s temperature. when the piston receives and processes the event with temp sensor 1’s temperature, it will then check the if conditions and if both conditions are true then turn on the AC. however, we know motion is active not continuously but intermittently. so, its more efficient to check the temperature only when motion changes to active. hence, the example below while it would work, the example above is more efficient.

if Room sensor's motion is active
   and
   Temp sensor 1's temperature is greater than 80ºF
   with AC
      turn on
   end wtih
end if

while the processing efficiency would not be significantly degraded in a simple piston like this example, as you write larger and more complex pistons and have many more of them, you always want your pistons to be as efficient as reasonable.

other questions on this? please ask away on this thread.

EDIT: what i described here is the default behavior of a webcore piston. it is possible to override this default behavior and pick which triggers are not subscribed to and which conditions are subscribed to. once you are familiar with this default behavior those dont take long to understand and use. :slight_smile:


Generic past beginner guide
Conditions and Triggers: What's the difference?
Coming home lights on and when we leave lights off
Away lighting simulator not triggering automatically
Can I use is open or do i need to use changed to open
Having trouble setting variable
Thermostat driven ceiling fan automation with subscription issues
Controlling a contactor with a GE plug-in outdoor switch
Piston to prevent false alarms
Help with my piston
Light wont turn on for very simple piston
Help with Arrival Piston (Sonos Welcome Home)
Motion Light Control Help
I spent three hours trying to create 1st piston...stumped
Piston on Motion for X Minutes
If condition if time between
Hubitat Best Practices
Multiple, root level triggers within one piston,
Piston to re_arm alarm
#2

#3

Excellent write up


#4

Very good info!


#5

This is really helpful. Thanks.


#6

What I have noticed is if you have a piston with, say 4 IFS and ELSES i.e.
IF
blah blah
THEN
blah blah
ELSE
Blah blah

IF
blah blah
THEN
blah blah
ELSE
Blah blah

4 times.
Let’s say the top 2 IFS are conditions and the bottom 2 are triggers, then only the bottom 2 subscribe.
I would have thought that they would all subscribe as they are in their own exclusive IF statement.
I fully understand that mixing the 2 types in an IF can be ‘iffy’ (pun intended) but not in exclusive ‘ifs’.
Any thoughts?


#7

this one might be better answered by @ady624 because it goes to the thought process behind how webcore is designed. i will take a crack at how i perceived this as i got started with webcore … I am sure @ady624 will jump in if he wants to add anything.

its about understanding user intent when they are coding a piston. say the default behavior was:

  1. if in a IF clause there are both conditions and triggers, only the triggers are subscribed to for that IF clause.
    AND
  2. if in a IF clause there are only conditions, all the conditions are subscribed.

now, on a per IF basis the user will need to evaluate as they code the piston, if this IF is subscribed to any events. if you consider that this evaluation by the user would not only be for IFs but anywhere conditions are allowed like WHILE or DO … WHILE etc, it can get it a little overwhelming for users who are just getting started and not yet familiar with webcore logic. i know it did for me. :slight_smile:

to get started its much simpler for user to get started with:

  1. if you have all conditions in a piston all conditions will be subscribed to
    or
  2. if you have any triggers in a piston only the triggers will be subscribed to and not the conditions

once users get started and are used to webcore … they also find out how to override this default behavior and force a condition to subscribe even when there are triggers in a piston or force a trigger to not subscribe even when there are one or more triggers in that piston.


#8

Thanks for the reply.
I fully understand the conditions and triggers subscription process and when I mix the two in an IF I always put my trigger first. These then seems to subscribe the conditions that follow. But to be safe I change them to 'always subscribe.
I just assumed that in the scenario I quoted above, there wouldn’t an issue.
I think this now leads me to another question/request which is to be able to change the ‘preset’ defaults. That’s for another thread though. :smile:


#9

sure. right, its more about users that are just getting started. :slight_smile:


#11

Nice job @bangali!


Checking if two conditions stayed the same for a period of time
#12

thank you.


#13

There is also this snippet of information from @ady624 that you may find useful for additional clarification.
_____________________________________
A piston is usually executed on events that trigger it. Therefore, triggers - by definition - will always run pistons. In the event no trigger is present, conditions then fulfill that role by acting as triggers themselves (all the conditions in the piston do that when no triggers are present). The moment a trigger exists, conditions step down and act as just that, conditions (or restrictions, if you want), therefore not triggering pistons themselves.

Only conditions >>> all conditions act as triggers and they all subscribe to events
Mixed conditions and triggers >>> only the triggers subscribe to events
Only triggers >>> only the triggers subscribe to events

There is, of course, the manual modification of this behaviour, by forcing a condition or trigger to either subscribe regardless, or never subscribe. Those settings take priority over the logic described above.


#14

Very nice write up and good info.

Idea for enhancements

  1. Use an icon or other visual to mark triggers and conditions.
  2. Warning if you have triggers in a piston but have a if statement contained therein that has only conditions or other dead end builds.

BRB going to review all of my pistons.


#15

thank you.

this is sort of there on the piston view page. the lightning bolt to the left of the condition will tell you if its subscribed to an event. but yes, does not show in edit mode.

well you could legitimately have if conditions where it does not involve any triggers, even though the piston got fired by receiving an event from another if condition which has triggers. :slight_smile:


#16

Brilliant thread.


#17

An important point … It’s worth noting that you can have more than one trigger in your IF though if you are using OR instead of AND. Of course the same holds true that you still will not have more than one trigger that is TRUE but you can put more than one trigger in the same IF.


#18

thank you. funny that even as you were quoting that para i was also slightly modifying it. still keep it simple for new users without infringing on technical correctness. :slight_smile:

let me know what you think of this new version of the para. keep it or revert back?

EDIT: edited the para slightly.


A piston for the morning is failing by going off at night
#19

I think that works :+1:.


#20

sorry, but would you please review one more time? edited slightly :slight_smile:


#21

No worries. I saw the update. All good in my opinion.