Control flow - returning from a break - Breaks pistons

#1

Is there documentation on how control flow works in webcore?

I’ve tried searching for answers and all I could find was user frustration about how this works.

Applets that are supposed to run and maintain state longer than a few seconds don’t work for me (produce inconsistent outcomes) and I realize that I don’t understand how control flow works in webcore.

So let’s assume that we stepped into an IF statement that evaluates true on a motion sensor triggered.
We launch a chine on the siren (just as a note that something is wrong and giving me a chance to cancel it if it’s me who just got home)
We wait 30 seconds.
Now we comeback from the wait and…? tbh, I have no idea what webcore is doing now - it’s a mess…

Again, I’ve seen multiple threads on this where coming back from a wait is just a mess and nobody understands what is going on, Please if we can have a link to a definite guidance and documentation that would be great. Thank you!

Any input would be appreciated.

Thank you

#2

If you are using the IF block:
IF Sensor's motion changes to active
it is important to remember: That trigger is only true for a moment, and then returns to false.

This means if you have a WAIT in there, after the WAIT transpires, the remaining actions are canceled (because the trigger is no longer true). If you want it to continue to run regardless of external circumstances, then you can set that WITH block, Task Cancellation Policy to Never.

#3

@WCnore, thank you! I figured as much. That’s exactly what I’m looking for a Definite documentation for control flow. If you know where I can read more about this please direct me there, thanks again

#4

The Wiki is handy for reference…

Here are some of my favorite links

But I think this forum has the largest amount of information

#5

Only one more thing to add here (and guess what? It’s noted in the Wiki too :slight_smile: )
Whenever a trigger condition occurs, execution of the piston begins at the top. (It does not begin at the point in the code where you’ve placed the trigger condition.)
This is very different from languages that have OnEvent() type functions.

#6

Excellent point @qoheleth. An exception to that rule is:
Every day at X
will only execute the code contained in that block, and will ignore everything else.

For example, the following piston is harmless:

execute
    Every day at 8:30PM
        Turn on Hot Tub
    END EVERY
    Activate "Global Thermonuclear War"
end execute

That last command will never run. Whew :relieved:

What often confuses new users is, most triggers will execute a piston, even when it is the opposite of the trigger.

For example, if you have a simple piston:

execute
    IF Bulb-A's switch changes to on
        Then do "Something"
    END IF
    Send SMS notification "Test"
end execute

The “Something” will only happen when the bulb turns on, but the SMS will send even when the bulb turns off. This is because when a piston is subscribed to a device’s attributes (such as Bulb-A’s switch above), then whenever that attribute changes (in either direction), the entire piston will run top to bottom, and execute any code that the conditions allow.

#7

Can I ask a further question on the above?
If the bulb can also monitor power usage (maybe its a lamp plugged into a socket) will the piston be triggered if the power used by the bulb changes or only if the bulb turns on or off. I.E, is the subscribed event the device changing state (on/off) or any event from the device?

#8

Most devices have more than one attribute. (switch, level, colorTemp etc)
Each lightning bolt is a subscription to an individual attribute, not the entire device.

IE:
Subscribing to any one of them does not mean the others are also monitored.
Subscribing to more than one means that each of them will execute the piston

#9

Are you serious?!?!? I had no idea. I thought that the piston would ONLY run if the trigger was satisfied. Now I need to review many of my pistons.

#10

Yes. Notice there is no condition attached to the SMS command, so nothing to prevent it from executing when it runs from top to bottom

#11

Here it is in action:

temp
temp

At 4:01, I turned on the light (double log)
At 4:02, I turned off the light (single log)

Pro Tip:
–Conditions inside the IF, will be checked when the switch turns on
Conditions outside the IF, will be checked when the switch turns on OR OFF

Presence and not presence triggers?
#12

So I can use this logic to take action when a device changes state, no matter what change was made. Just so I understand…a piston will execute top to bottom on change of state of ANY of the triggers, regardless of the change?

#13

Well, not for “Every day at X” as mentioned above… and of course, if the lightning bolt is next to a switch, it won’t fire on level changes… but basically, yes. You are right.

It can be used like a more precise version of “On events from”

As always, I recommend keeping the trigger count to a minimum, but feel free to experiment.

PS. I forget if triggers based on global variable changes are also included in this logic.

#14

I haven’t even considered that. If so, it would open up new execution options for me.