Conditions and Triggers: The difference?



Is there a time when a Condition becomes a Trigger?

I have a piston where I turn on a virtual switch, but within the piston, I use the state of the switch as a condition. But when I turn it on, I get a timed event that executes the piston. This seems to cause a

Piston waited at a semaphore for 10022ms

message since nothing was waiting on this event to occur.

Here is the log at the time that this occurs.

Here is the piston.

Any insights would be appreciated.


If you have no triggers in a piston (like this one), then all conditions become triggers. Notice all the lightning bolts in the left margin. Each one of those are acting like triggers, and executing the piston at any event.


Pistons have timeout handlers set on them so they are “time monitored” pretty regularly

During piston executions these timeout handlers try to recover the piston. When a piston is idle the timeout handlers check if the piston missed some early time setting. I expect this code was added during the ST platform issues in regards to schedules, run-in, etc.


I thought the On Events at the top is the Trigger, and all other IS’s are Conditions. I did see the lightning bolts for the Conditions, which is why I was asking.

I just changed the On Events power statement to If power changes, and that seems to have fixed the IS-becoming-a-trigger problem. Now the only lightning bolt is for the power change Trigger and not any of the Conditions later.


I would like to cut down on the number of times my piston is triggered. Therefore, I put a condition in in an attempt to stop the trigger from firing.

This piston controls a “My Ecobee thermostat”. The condition at line 58 should stop the trigger in line 60. What is happening is the piston is triggered every time there is a temperature change even though the setclimate is not “Low Heat”.

This piston has two jobs. When IFTTT detects an event starting, it triggers the piston and puts the thermostat in the “Home” climate for 5 hours. When IFTTT detects the end of an event, the piston is triggered and the thermostat is commanded to resume program.

Just looking for the reason that the piston is triggered all the time reguardless of the setclimate setting.
The second job is if the setclimate is “Low Heat” the thermostat is to just keep the building from freezing. Since a furnace’s exchanger will corrode when operated below 55 degrees, the room temperature has to be brought up to 55 degrees before it should be turned off. So when the setclimate is “Low Heat” the furnace is to turn on at 40 degrees and turn off at the heat setpoint. Therefore the piston only needs to be triggered by a temperature change when the setclimate is “Low Heat”


Any line with a lightning bolt will trigger if that device’s attribute changes in either direction.

In your case, anytime:

  • Thermostat 1’s setClimate changes, or
  • Thermostat 1’s temperature changes
    Your piston will start at the top, and work it’s way down to the bottom.
    (executing any code allowed by conditions)

You cannot prevent a trigger from triggering unless you unsubscribe to it.
(and then it will never trigger)

The method I employ is keeping only one trigger per piston, and let my conditions below decide which path to take afterwards.

By the way, when I say “one trigger per piston”, I really mean one attribute for one device.

For example:

  | execute
ϟ |    IF Outlet's switch changes to ON
  |       Then do stuff
  |    END IF
ϟ |    IF Outlet's switch changes to OFF
  |       Then do other stuff
  |    END IF
  | end execute

Even though there are two lightning bolts, there’s really only one trigger. (Outlet’s switch)


(repeated for emphasis)
I also strongly recommend this policy. In typical coding environments, one usually groups all the similar functions into one program. In webCoRE, one can group similar functions into a single category, but putting them all into one piston often results in odd interactions and unnecessary triggering. (To be honest, this particular programmer had to learn this through an annoying amount of experience :slight_smile: )


I see the point of one trigger per piston. So I could have a master piston that pauses and resumes another piston that controls the thermostat. A paused piston will not fire correct?


I have created a control piston that pauses and resumes a piston for the Low Heat climate. When the piston is resumed in registers itself and starts working. Now there is now triggers at all when they are not necessary. I designed it like calling a subroutine. The control piston enables the Low Heat piston. the Low Heat Piston Pauses itself when the Low Heat climate is no longer in effect.

Works like a champ.