Conditions and Triggers: The difference?



thanks @Nezmo. it stays then :slight_smile:


I’m still a bit confused about 2 things:

1)WHAT is a trigger?
2)WHAT is a condition?


when editing a condition, the kind of comparison defines if it is a condition or trigger.

Piston reading stale door sensor value when triggered by a timer?

OK so a condition is just the state of something, where a trigger is an action to something.


Heres goes my noob question.

I have 2 motion sensors and a single dimmer. My desired logic is for the light to turn On when any of the sensors is active… so that’s easy since its and OR the piston executes when either sensor activates as expected.

Problem comes when motion stops. I want the light to turn Off when there no movement on BOTH sensors. Instinct tells me to do the same as the On part but using AND instead of OR… but from what I’ve read here that won’t work.

How can I make the light turn off when both sensors are deactivated (no motion).


Instead of making two different conditions, select both motion sensors and then you can choose ALL or ANY. So for turning them on you would select ANY. For the part turning them off you would select ALL.


Ok ok… so no matter how many devices are selected it still counts as a single condition?


That is correct


Just tried but it doesn’t work. Can I PM you or is it OK to paste my current code on this thread?


Thanks for your time, Really appreciate it… It’s working and I learned something today.


Great thread guys! I have a couple of questions to better understand the piston building process:

  1. Does the order matter within a piston of the trigger and conditions to make a piston work correctly? It would seem as though triggers should always come first in a piston or does it matter, both in the piston actually working properly and for overall efficiency?

  2. Very curious when folks keep talking about efficiency in pistons, what are they really speaking of? Is it efficiency that I, the user, will actually see in terms of lights turning on faster when events trigger, or just general stuff in my part of the WebCore world happening faster for me - or are we speaking in terms of server efficiency in the background, but not necessarily stuff I can ‘see’? (i.e. more efficient pistons from everyone x1000’s of users will help reduce the overall server requirements of the system) ?


thank you. having seen many questions around this, thought i would put this up right up front when the new forum was created. :slight_smile:

while generally triggers should be listed first in a condition and that usually works more efficiently, its not always necessary to do so and sometimes it can actually be less efficient to do so. like when you have chatty triggers and you want to limit execution by another condition combined with the trigger. like in this example, over a 24 hour period its actually more efficient to have the time condition first followed by the motion changes to condition:

if motion changes to active
   time is between sunset and 11pm
      do something
end if

i keep talking about efficiency, dont i? its certainly one my pet topics. :slight_smile: when i am talking about efficiency in these forums its usually about users seeing their pistons work more efficiently without semaphore waits which can cause piston actions to be delayed seemingly unpredictably.


I am so glad you brought up semaphores @bangali ! I am not a programmer but have a masters degree in Tinkering so love playing with WebCore and its awesome capabilities. I have the below piston which simply looks to see if my skylight blinds have been lowered ( works on a momentary switch within Smarthings). If they have been lowered earlier in the day it simply then activates the blinds up momentary switch (not the same switch as the blinds down switch) 2.5 hours before sunset.

The problem is that every three to four days it does not activate the blinds up. What I have found is that the days it does not activate are the days that the ‘piston waited for a semaphore…’ statement is in the logs (see above circled in red) .

What can I do to make this piston more efficient and avoid this semaphore issue which causes the piston not to run every 3-4 days?


sure … though in this case the 1/4 second semaphore wait should not be causing this issue. :slight_smile:

if you still wanted to make it slightly more efficient, please change to a timer statement:

every day at 150 minutes before sunset but only in may, june, july, august, september
   if lower kitchen blinds switch changed in the last 12 hours
      with raise kitchen blinds toggle
   end if
end every

@Levahj if you do try this, it will be interesting to hear if this solves the problem of piston not activating every 3 to 4 days. please update if possible. thanks!


I will give it a shot with the new piston and let you know within the next week if there have been any issues with it not activating. If you don’t think the semaphore wait is long enough to affect the piston, could there be a bug in WebCore? Just wondering why this sporadic semaphore is popping up every few days and sporadically with no correlation to anything I can see…


great, thank you. both of the if clauses are conditions so they are both acting as triggers. so, when the lower kitchen blinds switch changes the piston is getting evaluated. at around 1:27pm the switch may have changed quickly a couple of times so the second event from that change waited for a little bit before the piston could process it.

if you switch to the every format, this at least will not happen any more. after you build the new piston, if you still see the bolt against this line then edit the piston, click that line and change the subscription to never.

EDIT: i verified it, that you wont need to do that last part.


You are absolutely correct. Since the switch is a toggle it does change twice every morning. Once on and once off within .5 seconds so that is probably why the Semaphore takes place? Though it is strange it is not consistent.

Just so I understand this…

‘Changes’ is a Trigger
’Changed’ is a Condition

Would either ‘Changes’ or ‘Changed’ work in this case where a timer is used? Or is ‘Changed’, since it is a condition, the better solution since the timer defaults as the Trigger in this example?


thanks, that always sounds good. :slight_smile: yes, that is likely when this is happening. maybe sometimes people adjust it manually and do it a few times quickly?

your understanding is correct. just add to that this part:

so effectively when there are only conditions in a piston, the conditions act as triggers.

When a timer is used within the timer block, the changes would not work. changed is the right condition to use.


Sorry if this was covered and my brain hasnt grasped it yet, I am FAR from understanding programming enough to not ask questions. Ive been out of the SH game for 7 months on a deployment and Im just getting back to find out that CoRE is deprecated and replaced with this tool.

Coming from CoRE I had latching pistons (using “But if”, and some using “Then, But-If, Then”), Or-If, a bunch of basic and simple piston frameworks.

Im pretty sure I can handle recreating the basic and simple ones, so my questions are:

How do you recreate a Latching (But-If, Then, etc…) piston?

How do you create the Or-If pistons?


no worries. me too. :slight_smile: thank you for your service.

i have been using webcore for about 7 months and had no experience with latching pistons. have only seen a few postings on the forum. from looking at the those examples, typically a latching pistons seems to act the same as the following structure in webcore, though there may very well have been more to it:

if condition2 or trigger2
   do this
else if condition2 or trigger2
   do that
end if

i am also tagging @webCoRE_Minions here, so if i got that wrong someone else will correct it.

as for or, just click on the and between the conditions and you will get a popup that will allow you to change it to or and a couple of other operators. in this snippet i would click on the and on line 14 to change the and to or.