Is it better to have triggering switches set to auto-off in the device page or is it better to reset the switch in my piston?
What are you judging by?
Usually I like logic in 1 place, otherwise you have to keep in mind 1st order, and then 2nd or 3rd order behaviors...
I guess this comes from my not-so-sure understanding of triggers. If a device triggers my piston to run, and then I reset that device mid-piston, does that state change trigger the piston again? I know that the piston won't run because of the state of the device. But when the piston is triggered the second time, what happens to the first running piston?
There are several possibilities:
a) you are subscribed to device:switch attribute.
You are correct every time switch attribute changes, the piston will get an event
b) you are subscribed to device:switch:on.
you only get only on events (assuming you use the proper comparison)
Event are typically processed by webcore in order, on, then off is seen by the piston as two sequential events.
None of this is a problem per se. Whether this piston does the turn off or some other piston/app/device, this piston will still get the same events...
There is more on this in the webcore wiki articles:
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…
webCoRE pistons (automations) typically execute statements sequentially, There are a few types of execution starts for a piston:
Normal execution:
An event occurs, Start at the top of the piston, and proceeds step by step until the end of the piston. Events that may start execution:
a device event the piston is subscribed to
like a switch going on / off, a motion or contact sensor, a presence device arriving or leaving
a virtual event the piston is subscribed to:
mode event…
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 …
1 Like
That clears it up for me. Thanks.
