Many triggers in webCoRE are tracking, ie the trigger comparison compares to previous values. Examples include:
- examples include: changes*, drops*, rises*, remains*, stays*, range*, becomes*
All of above are comparing the attribute value vs. previous values.
For the above, the device's attribute value is persistent within the piston, ie you can compare it to previous values to understand both if it changed and if changed in the way you want to analyze.
Momentary device triggers
There are other types of triggers for momentary devices. Momentary devices are typically things like a button device. Momentary devices report a button has been pushed / held / doubletapped / released.
The event has meaning each time it occurs, but because it is a moment in time, the above tracking trigger comparisons are generally meaningless (and not available to you in the IDE) as tracking old values generally does not have much meaning (if you need a sequence you can use followed by)
With momentary devices you want to know the event occurred (ie a button was pushed), and also which button was pushed.
Original webCoRE had a single momentary trigger type:
- gets - for example:
note that for each button number, you need to have a separate gets comparison to match to that specific button. If you have many buttons on a single controller, your piston can have many if statements.
webCoRE on Hubitat adds additional trigger type for momentary devices:
- this allows one to code the piston in a simpler fashion when dealing with button controllers with many buttons:
gets trigger allows webCoRE to attempt to subscribe only to the specific event value (ie pushed:1 or pushed:3) vs. all push events from the device). This can reduce un-needed piston wakeups.
gets any allows you to write your piston with a simpler if statement, and then using system variables like $currentEventDevice, $currentEventAttribute, and $currentEventValue to code the logic for differentiating momentary events values.
So what if I want to do specific attribute value subscriptions, or generic coding for persistent events?
webCoRE on HE has triggers for that:
- receives can be used to attempt to subscribe to only specific attribute values such as switch:on (vs. all switch events)
event occurs can be used to get all events of an attribute without having to check for the value in the trigger comparison.
event occurs is similar to changes, the key difference is changes is a tracking comparison so all the rules for use of tracking trigger comparisons needs to be followed with changes.
There are cases for system events like System Start that you need to use event occurs as the event is not otherwise an attribute.
On events from
You can get somewhat similar behavior to gets any, event occurs using on events from.
- The key difference is on events from is an async block - ie a mini piston within the piston which may not be what you desire for your automation.
So the net result is you can write pistons
to only wakeup for specific event values (get/receives)
or you can write pistons that are generic for all event values (gets any, event occurs).
In both cases these are not tracking triggers (so some of the rules about nesting triggers can be safely ignored)