Condition acting like a trigger?

#1

1) Give a description of the problem

Wrote a piston which is supposed to only run if I execute it - no triggers. Don’t understand why the piston is firing in full when a switch is flicked.

2) What is the expected behaviour?

image

To allow me to manually turn on the Virtual Device (switch) “Alarm Contact 2” without actually firing the piston.

3) What is happening/not happening?

image

As per the lightning bolt, it appears the action of turning the switch on is being treat as a trigger.

I expected the code

if switch x is on
    do y
    endif

…to do nothing. I expected the piston to actually fire up if I used the code

if switch x changes to on
do y
endif

so at the moment, it appears that there’s absolutely no difference between either approach.

Has my understanding really been that flawed for this time, or has something broken somewhere ?

Cheers!

**4) Post a Green Snapshot of the piston![image|45x37]

n/a due to simplicity / theoretical question.

5) Attach logs after turning logging level to Full
(PASTE YOUR LOGS HERE THEN HIGHLIGHT ALL OF THE LOGS AND CLICK ON THE </> ICON TO FORMAT THEM CORRECTLY)

REMOVE BELOW AFTER READING
If a solution is found for your question then please mark the post as the solution.

#2

I think if there are no triggers, a condition will be used instead.

If you edit the piston and click on the if statements condition, and click the settings cog, you can change the subscription method to “never subscribe”. The piston should only run then when you test it, or its called from another piston.

#3

It seems so, but you are not alone. If someone pastes a piston onto Facebook that doesn’t include an explicit trigger, as sure as eggs is eggs a comment will appear announcing that the piston needs a trigger or it won’t run. Even when the piston is self evidently firing just fine …

The differences between a trigger and a condition are essentially:

  1. By default, the piston will only subscribe to device attribute events used in triggers, and also only schedule timers needed for triggers. However if there aren’t any triggers the conditions will be examined instead as webCoRE really wants to run your piston for you. This is the ‘automatic’ subscription in action.
  2. when the piston runs, the comparisons for triggers work with the contents of the event that fired the piston, but the comparisons for conditions check current values.

As @Paul1964 has pointed out, you can alter the subscription method if necessary. There is also something in the piston settings that turns off subscriptions completely, but I forget what it is called.

#4

Cheers guys. Can’t believe this is the first time I’ve noticed it.

#5

I seem to remember that the documentation, such as it is, does rather lead you down that path by starting you off with a simple trigger example. As I hadn’t seen that example, I started off using conditions. Sometimes they are just a better idea.

A classic example is using a motion sensor over night. If you use a ‘motion changes to’ trigger along with a ‘time is between sunset and sunrise’ condition, you have the problem that the piston misses there already being motion at sunset. If you use ‘motion is’ then the piston fires at exactly the same time for motion but also at sunset and sunrise and sees the motion.