Hubitat’s Rule Machine sets the internal %value% variable as follows for Inovelli Blue paddle presses (all values are strings):
Switch state commands
Dimmer turns ON = ON
Dimmer turns OFF = OFF
Button state commands:
Tap Up on Light Paddle 1x = 1
Tap Up on Light Paddle 2x = 2
Tap Up on Light Paddle 3x = 3
etc.
Tap Down on Light Paddle 1x = 1
Tap Down on Light Paddle 2x = 2
Tap Down on Light Paddle 3x = 3
etc.
Notice the results for Up/Down taps – the same values for the same number of taps. Accordingly, %value% cannot be used to distinguish an Up paddle double-tap from a Down paddle double-tap.
Instead, the “lastButton” attribute can be used to determine the number of taps. That attribute returns strings like “Tap ▼▼” (down paddle double tap) and “Tap ▲▲▲” (up paddle triple tap). Example test code:
Note that you may still need to test %value% for being equal to “on” or “off” for cases in which a dimmer is turned on/off by another rule.
This is an interesting idea!
From our previous discussion, others may wish to note that the Button Controller app is often a better choice for this kind of automation — or that, in general, multiple rules with one trigger each is generally a simpler approach compared to one rule with multiple triggers when a good chunk of your actions is figuring out what the trigger event actually was and then doing different things anyway (something Button Controller helps with while, unlike multiple completely independent rules, still keeping things organized if it’s all for the same device).
Personally, that’s still what I’d do, but there’s no one “right” way to do things. 
If some of your actions are “shared” among all possible triggers, I can see how this alternative could make at least that part easier (though, as is again often the case, there is more than one way to handle that, e.g., creating another trigger less rule shared among all these whose actions you simply run as part of each Button Rule or RM Rule’s actions).
Just some clarification: the %value% variable is the value of the trigger event, so this statement is dependent on the event you are looking at, which in the original topic was the button-related events (pushed, held, released, etc.). This is partially an artifact of how Inovelli mapped the real-world actions to button numbers in their driver (though with hold and release being supported on multiple physical buttons on the device, it’s probably something that would be run into in any logical way you do this, even if not as often, if you care about any possible event…).
…but the information above is relevant for this: %value% won’t be “on” or “off” unless your trigger event is the “switch” attribute (i.e., you chose the “Switch” capability when creating the trigger). So, if you need to test this in a rule like the above, you’ll need an alternative approach. The simplest one is just using a conditional action with a condition to test the on/off state of the switch (a more complex one is to assign the value of this attribute to your own string variable somewhere in your rule if you need it in that format for some reason instead).
All good points, thank you!
