Below are screen shots of 2 instances of the same Hubitat rule (one was cloned from the other). One rule is for my office IB (the first one I installed out of 40+) and one is for our main closet (acquired and installed a 2-3 months later). Both units report a driver date of 2024-05-30, a firmware date of 20240412, and a firmware version of 2.18. The Hubitat driver for both units is identical.
The Office rule reports %value% as the string “off”. The Closet rule reports %value% as the string “0” [zero, not a capital letter O]. That seems to indicate that the firmware and/or hardware was changed in the few months between purchases.
Or is it possible that I have set some parameter that causes the difference in how values of %value% are reported?
Just a guess, but if you are testing by physical presses of the switch, ensure that to turn off you are using a quick tap down. There have been some cases where the minimum is set too low and a long press is used in the belief that is will turn off the light. The light goes out because it dimmed down to 0, but the switch is not off.
I am using quick taps when I use the physical switch to tap, but the result is identical if I use “run rule“. Indeed, the screenshots I posted are from using “run rule“.
Then %value% doesn’t mean anything. This built-in variable only gets set to the value of the last triggering event (manually running the actions is not a trigger). From your screenshots, that should be “on” or “off” since your only trigger is the switch state – but, again, you’ll need an actual trigger event to make that happen, per the Rule Machine documentation.
If that is not what you are seeing, I suggest enabling all logging for the rule and providing the output of Logs, filtered to just this rule and possibly the event history from the switch, after an actual trigger event, as well as the values of the Local Variables table after a refresh of the page (if you already had it opened at the time of triggering).
(As one possible explanation: if you previously had different trigger events, this could be leftover from that, and if you cloned one rule from another, the built-in “cache” of the value will come along with it initially.)
If you still see 0 as a value after that, the driver must be mistakenly sending this as a value for the switch attribute instead of level attribute, but that would be unusual and an issue related to the driver you’re using on Hubitat, not the switch firmware itself. (It’s also not really an expected value for level, but it would at least make some sense.)
Problem resolved: The Closet switch was found to be simply not working right with a lot of different commands (logging and identification, for example), so I reset it to the factory state and reconfigured it as a dimmer and everything worked right.
Side note: Hubitat’s Rule Machine sets the internal %value% variable as follows for Invovelli Blue paddle presses (all values are strings):
Switch state commands
Dimmer turns ON = ON
Dimmer turns OFF = OFF
Button state command:
Tap Up on Light Paddle 1x = 1
Tap Up on Light Paddle 2x = 2
Tap Up on Light Paddle 3x = 3
Tap Down on Light Paddle 1x = 1
Tap Down on Light Paddle 2x = 2
Tap Down on Light Paddle 3x = 3
Notice the results for Up/Down taps – the same values for the same number of taps. Accordingly, it appears that, for example, to distinguish an Up paddle double-tap from a Down paddle double-tap, a Rule must test for the ON/OFF state AND test the contents of %value%.
…to distinguish an Up paddle double-tap from a Down paddle double-tap, a Rule must test for the ON/OFF state AND test the contents of %value%.
That won’t work. When the switch is ON, and the Down paddle is tapped 2x or more times, the switch doesn’t go OFF. So, for example, if the switch is ON and the Down paddle is tapped 2x times, %value% gets set to “2” – which cannot be distinguished from a 2x tap on the Up paddle based on my logic above.
So I can’t see how to distinguish multiple Up from multiple Down taps in Hubitat’s Rule Machine for an Inovelli Blue in all cases (my logic example still works when the ON or OFF state is known to be true).
Is there a known way to distinguish multiple Up from multiple Down taps in Hubitat’s Rule Machine using %value%? (I know how to distinguish taps of all kinds used as triggers, but I’m using multiple triggers from the same switch to run different conditions in a Rule).
This is correct, but it’s not something Rule Machine invented, aside from offering the %value% variable built-in as a means to see this. It’s just the value of the event, in this case, the assigned button number according to Inovelli’s driver.
Correct.
What you want to combine with looking at the event value is to also look at the event name. With Inovelli’s driver, this will be a “pushed” event for taps up and a “held” event for taps down (other drivers vary, generally using the real-world meaning of these terms instead of this convention, but that’s how it works for these). Rule Machine doesn’t provide a way to get that directly, but it’s part of your trigger events, so often you’ll know. If you create multiple triggers for different events, you’ll have a harder time knowing (but might be able to parse it out of the %text% variable, depending on how the driver sets that), but if you want different actions to run in response to different triggers, the better approach is almost always making two separate rules instead. Then, you don’t have this problem at all.
If you’re looking to trigger different actions off different button events and want to keep all the actions organized under the same “parent” rule, Button Controller offers nearly the same functionality and would be a better choice – each “Button Rule” essentially being one that triggers off the specified button event name and value (e.g. button 1 pushed, button 1 held, button 2 pushed, etc.).
If you have problems, it might be best to provide a concrete explanation of exactly what you are trying to do, which may facilitate better suggestions.
I realize that Rule Machine is not necessarily the best tool for every situation, but I’m a good way up the learning curve for it and I like fine control over device actions and triggers, so I’m trying to stick with RM for this particular application.
In particular, I’d like one rule that, among other things, does action A when the top paddle is double-tapped, and action B when the bottom paddle is double-tapped. I previously DID use two rules for those actions, but I have about 39 IB’s set up as dimmers and I’d rather make 38 clones than make 76 clones (plus, I have to manually modify each pair of clones to update the name of a dimmer-specific hub variable sharing state between them, whereas a single rule doesn’t need the hub variable and thus clones to a final form).
The image below is of my triggers. I test the value of %value% to figure out what the actual trigger was (so the rule is actually a 5-in-1 rule – again, for ease of dissemination via cloning). The rule actually works mostly fine, except that double-tapping the bottom paddle could use a little tweaking IF I could make sure that a double-tap on the top paddle wasn’t the trigger.
Hence the desire for some way within the rule (post triggering) to figure out whether a top paddle or bottom paddle double-tap occurred. The %text% variable doesn’t seem to exist in RM – it returns “null” in testing when I try to log its value.
My driver for each IB (dimmer configured) is the official Inovelli driver. It’s a bit surprising that it seems to lack a way of distinguishing multiple taps on top vs. bottom paddles. Really, the buttons couldn’t have been numbered 1-21? So instead it takes 2 parameters (button# and event) to identify a button action, and one of those parameters (event) is apparently invisible in RM?
This really seems like a better automation for Button Controller over Rule Machine.
The Button Controller editor is nearly identical to that of RM, so if you like RM, you’ll like this, too. It just makes using different triggers for different button events – as you are trying to do – easier, while still keeping everything under the same “parent” Button Controller app if organization was your concern with separate RM rules. I would suggest one of these approaches for both the reasons already discussed and the general observation, through years of helping people with Rule Machine myself, that multiple, simpler rules are almost always easier to write and troubleshoot compared to fewer, more complex rules.
It does (a read of the Rule Machine documentation will probably be helpful), but it depends on the driver to set this (optional) value. Apparently, Inovelli’s custom driver does not – assuming you tested after an actual trigger event (like %value%, this does not get set by any other means, as in my original response).
But if you do go back to this approach … no, this really shouldn’t happen unless the driver reports that value for this event. You could try re-creating the rule just in case something else, like maybe a trigger you once had but removed, is causing problems? Or check “Event” history on the device to verify that this isn’t really happening (might have had you do that above, I can’t remember…); if so, that would be a driver problem, though an unusual one…
Or is it possible that I have set some parameter that causes the difference in how values of %value% are reported?
No, the problems I was having was that the 2nd IB unit I was trying out with my rule was simply not responding properly to a lot of commands, so I reset it to factory status and now all is well. The value of %value% is now “off” when the 2nd IB unit is turned OFF using the bottom paddle.
The %text% variable doesn’t seem to exist in RM
Yes, I found out from reading the documentation shortly after I posted that statement that the %text% variable does exist in RM. I did test with actual paddle presses to trigger my rule, so it appears that the Inovelli driver does not set that parameter value.
I do use Button Controller a lot for my 4-button remote controllers, but some of the parts of my rule need to know the state of a variable set by the other parts. I was using multiple rules and corresponding hub variables, but once I found that local variables are persistent across invocations of a rule, I decided that it was actually less complex overall to have the various button presses of each dimmer dealt with in a single rule (all of the interacting parts are in one place, no hub variables are needed, easier to clone without having to manually rename a hub variable that appears in 2 places in each clone to correspond to only that clone, etc.).
So my almost-perfect rule will get deployed for now, and I’ll make a feature request to have the Inovelli driver updated to actually identify the source of taps.
