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 triggers). What to do?
You could:
- in the webCoRE IDE go to each condition statement (like an if) and change
-
the comparison to be a trigger comparison
-
OR
-
change the setting to 'always' subscribe
-
-
automatic means webCoRE decides
-
if the comparison is a trigger comparison, subscribe
-
if the comparison is a condition comparison, and the entire piston has no triggers, subscribe
-
-
Always means webCoRE will subscribe to the device/attribute regardless of condition or trigger comparison
-
Never means webCoRE will not subscribe regardless of any of above states
This however may not solve your needs. Let's take for example this piston that controls my Venta humidifier which is connected to an outlet switch:
- it not only controls the humidifier, but it displays 'status' in the piston state which is seen in the webCoRE IDE/dashboard:
Piston:
Notice the setVariable statements:
These are not comparisons (trigger or condition). They could be if we put them in an if statement, but as we look at this piston we will see we wanted them as variables to be able to print out status
-
so we cannot make a setting on those setVariable actions to say 'always' subscribe on these statements.
-
we want the device changes to be events (subscriptions) so the piston re-calculates the desired humidity correctly as temperatures (indoor/outdoor) change, or indoor humidity changes.
-
we could have used an ON EVENTS FROM statement. However this causes the piston to not always update state if it were run by test, or called from another piston. (on events is an async block so it only runs that block for events that wake due to on)
What we can do is add these devices in the piston as a trigger comparison if. (but otherwise not change the main logic)
Few things to note on this:
-
trigger comparisons anywhere in a piston (that are subscribed to) cause the piston to run top to bottom (with the exception of 'every' and 'on' blocks we discussed in another tip).
-
this can help in cases where you want to nest a tracking trigger comparison if you first use the device:attribute comparison in an aggregated (non-nested) if statement (same comparison, same device:attribute)
- the IDE will still warn on the nested use, but if you know it is used in a non-nested aggregation you can safely ignore the IDE warning.
-
the if statement does not have any statements to execute, the if is there to use a trigger comparison and force the desired subscription(s) to events that cause the piston to execute.
-
this coding style can make it easier to test pistons, or have pistons run by other pistons (in addition to running on their own), as the core logic always runs regardless if the trigger was a device, test, or an execute piston.
References:
