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.
Where the choices with the triangles supplied by Hubitat as choices or did you have to type them in? If the later, how did you do it?
I copied them from events generated by Hubitat. For example, the 2nd action shows "Tap ▼▼", generated by actually double-tapping the bottom paddle the physical switch. So I copied the triangle and used it however many times it was needed. Same with "up" pointing triangles, by double-tapping the top paddle.
I'm sure that must be some way to get those symbols from a standard Windows PC character table, but I was too lazy to hunt them down that way.
Also, you can just copy the triangles from post #1 and paste into your rule.
While this can work, it seems like it would be more straightforward to just trigger on the button event (e.g., button 2 pushed or whatever). You'd still need an additional test in a rule like this if the goal is to get everything in one, which is not normally something I'd suggest for its own sake, so I'd really do this in Button Controller myself if the ultimate goal is just to keep related automations together. That app is built to handle these kind of "triggers" for you. Just my two cents!
Understood, but my actual rule (of which I have 30 instances) requires knowledge of previous states when a switch paddle is pressed. Rather than use hub variables and MANY more rules per light switch (which was my ver. 1.0 approach), for sake of my sanity in keeping track of (and replicating) rules, I put everything for each dimmer unit into one associated rule, hence the need to distinguish UP taps from BOTTOM taps (which is NOT straightforward with Inovelli Blue dimmers). Button Controller also doesn't quite work without passing a bunch of hub variables around to track state.
Here's an example of my rule (which is "self programming" in the sense that ALL internal rule variables can be set by the rule itself reading a File Manager CSV file; all such files are written by a single master rule that sets the parameter values):
