Currently, you need to have workarounds for each variable type (boolean is true or boolean is false, etc). A more general event would streamline and simplify workflow.
Bumping this one by reposting a comment from the SmartThings Forum:
"As it stands, the power of the context variables is not being used to its full potential to simplify rules building.
Let’s say I want to develop a rule that executes on doors or windows opening and closing around the house. To monitor both opening and closing, the user has to enter two triggers for each contact, as follows:
Front Door contact changes to Open
Front Door contact changes to Closed
If you have a lot of doors and windows, that’s a lot of extra triggers. It would be easier to have a trigger like this with an additional, less specific operator:
Front Door contact changes
From that point, one can build the rule’s conditions and flow around $context.event.deviceName and $context.event.value. And instead of, say, 20 triggers, there are only ten.
Add to this (eventually) the ability to select multiple like devices (i.e., contacts) in a single rule, and the entire process is greatly simplified."
New here on SharpTools and I would love to see a generic change event.
I have several groups of Zigbee RGBW bulbs that are controlled by a SmartThings simulated RGBW bulb. When I change the color of the simulated bulb it updates the color of the physical bulbs. I would like to create a rule that runs when the color changes.
The new feature enables you to opt for a general ‘updates’ comparison operator, eliminating the need to specify conventional operators such as ‘updates and equals’ (==) or ‘updates and is greater than’ (>). With this configuration, the rule gets triggered any time the value updates rather than requiring a specific condition to be true.
In addition, we’re debuting a new ‘On Transition Only’ option. This refines your comparison to only take place when the value changes to your desired state. This comes in handy in scenarios where a device might report an ‘update’ with the same value, and you are only interested in the initial transition to your preferred state. It’s also helpful for situations where you only want the rule to trigger when a value ‘rises above’, ‘drops below’ or ‘changes from’ a specific value.