I don't see the entire piston, but I expect that the use of the global in the every block, triggers are not allowed to run an every block.
I'm guessing it was considered because this piston is not using trigger conditions, so there is an early evaluation of promoting condition triggers to subscriptions.
See:
This is another example of using triggers in a webCoRE piston
As many of you may know, if a piston does not use any trigger comparisons, webCoRE will attempt to upgrade condition comparisons to a trigger (subscription). If your piston only uses condition comparisons, many times this is an easy way to code (ie only use condition comparisons).
The challenge sometimes, is you need/want a trigger comparison, and now all your condition comparisons are no longer subscribed to (automatically as …
and
I regularly see questions of folks having trouble getting a piston to work properly, due to not understanding time triggers vs. every blocks.
A couple of overall points:
time trigger comparisons are used when something needs to happen on a schedule.
for reacting to device changes, you want to use device trigger comparisons (vs. polling with time triggers) if at all possible.
For time based triggers there is a choice of:
if statements (time happens daily, etc)
every blocks
I…
and
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':
[image-3]
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 co…
