I regularly see questions of folks having trouble getting a piston to work properly.
Many times it is incorrect ordering / use of trigger comparisons (displayed with lighting bolt in webCoRE UI)
This example follows 'best practices':
Few things to note from this piston:
-
In the first if statement (line 21), there is one trigger comparison (since it uses AND; more than one trigger events can never occur at same time), and a condition comparison. (You can have multiple trigger comparisons in an IF, if it is OR, or FOLLOWED BY comparison).
- In the webCoRE iDE (dashboard, staging, or local) when you select an if statement and add condition, the comparisons are organized by triggers (event subscriptions occur) and conditions (event subscriptions normally do not occur).
-
Looking at the overall piston, All of the trigger comparison statements (if in this case) are at level 1 (looking left to right). ie trigger comparisons are not nested below other statements (such as then or else statements).
-
This is 'best practice' as:
-
many trigger comparisons are tracking - looking for changes vs. previous states, so the statement that includes the trigger comparison should be executed on each run
-
many times if statement actions (tasks) should be canceled on condition state changes, The if should be evaluated for cancel to properly operate on each run.
-
-
-
If you are using trigger comparisons and condition comparisons in an If (as shown in line 21), put the trigger comparison is first in the if statement.
- in the latest version of webCoRE you don't have to do this, but it likely will help keep things clearer for you (and allows webCoRE to optimize your piston execution more)
-
In this example there are two if statements, each with one trigger comparison
- the overall flow of the piston should be that both if statements are crossed over (if statements are executed or evaluated) on a run (this example shows this correctly)
-
if you put in an exit statement in the piston, this may cause statements below the exit to not be crossed over, that may affect trigger comparisons or cancel evaluations below the exit to track incorrectly (ie not track).
-
do remember that if your hub is down for a while, and then comes back up, piston trigger comparison tracking may need to be updated to deal with any changes that happened (but were missed) during the hub downtime
- this can be done by using systemStart occurs trigger
-
- the overall flow of the piston should be that both if statements are crossed over (if statements are executed or evaluated) on a run (this example shows this correctly)
References:
