Need to be able to activate Buttons Pushed and Held in Driver(s)

Sorting Category
#1

@EricM_Inovelli I have the following Rule Machine Rule that I created to close the garage door and lock the doors if everyone left and forgot to do so before leaving. Happens more times than I want to admit :smile:

image
image1272×606 22.3 KB

However, upon testing, the rule failed and the logs captured the following error The same thing happens for button 3 pushed:

image
image941×82 3.06 KB

Initially, I thought there was an issue with RM. But as was pointed out, although pushable and holdable buttons are in the drivers (for all sceen capable devices) the commands aren’t present in the drivers.

Can we add these?

I could always recreate this code everywhere I wanted to use it. But it doesn’t seem efficient, time-wise, and I could see inconsistent behavior

#2

Some background, if you care: Hubitat’s button capabilities don’t technically require implementing pushed(), held(), and released() commands, but most devices, apparently by convention, do. (There was some debate about this in when the capabilities were debuted, so this could also be leftover from that.) What they do is simulate a “digital”/virtual press so that you can, for example, trigger an automation that would ordinarily require a “real” button press by way of these commands instead. More for Inovelli than for you, in case they aren’t familiar. :smiley:

Looking at Inovelli’s drivers for the products I assume you might be talking about, the Red Series switches and dimmers, I seem to remember their drivers doing this at one point. And it looks like all the code is still there, just commented out — and it’s also implemented a bit differently, but again, the above is just a convention and not a requirement of any “standard” Hubitat capability (e.g., PushableButton). It appears that you could get this functionality back if you uncommented this block of code towards the beginning of the file (this is from Inovelli’s LZW31-SN driver, but I imagine the others are similar):

    /*
    command "pressUpX1"
    command "pressDownX1"
    command "pressUpX2"
    command "pressDownX2"
    command "pressUpX3"
    command "pressDownX3"
    command "pressUpX4"
    command "pressDownX4"
    command "pressUpX5"
    command "pressDownX5"
    command "holdUp"
    command "holdDown"
    */

(and by “uncomment,” I just mean "remove the enclosing /* and */ symbols).

Again, at least as of the current version of their driver code, this will still work simply because these methods are still defined later on in their code. And you’ll have to use the commands as written, like pressUpX1() instead of push(1) or RM’s built-in action that does the same, which means you’ll also need to use Rule Machine’s “Custom Action” type to execute these methods. The “mapping” should otherwise be straightforward from the custom command names.

So while Inovelli will have to comment on whether they want to implement this in their driver by either un-commenting the above or switching to Hubitat’s conventional-but-not-standard commands like push() and hold(), the above should work either way with very little modification on your part.

(PS - I also wrote a new-ish custom driver that implements these commands and I think is as Hubitat-ty as possible while still giving “access” to all device features, but the button-number mapping is different from Inovelli’s. I could share that with you if you were interested, or I might post about it sometime here…)

#4

Like @BertABCD1234 mentioned, you can uncomment the commands from the driver meta data. They are commented out as most people don’t use them and they clutter the device page in Hubitat.

You would use a custom command in Rule Machine to call the commands.

#5

@EricM_Inovelli I see them in the current drivers for the Dimmers and Switches… But not for the fan?

@BertABCD1234 Thank you for the offer! Please share the link when you get around to it.

I need to learn how to program so I can do some of this stuff for myself. :wink:

#6

@Ma2J, here are my drivers:

(for importing, click the “Raw” button and use that URL or copy/paste)

They are sort of a cross between Hubitat’s and Inovelli’s. They’re as Hubitat-ty as I like (Hubitat-like logging, typical Hubitat button events…more on that later) while still providing all the Inovelli features that the Hubitat built-in drivers lack (mostly anything >2 taps).

My button mapping is:

  • “Up” paddle:
    • 1 tap up = button 1 pushed
    • 2 taps up = button 3 pushed
    • 3 taps up = button 5 pushed
    • 4 taps up = button 7 pushed
    • 5 taps up = button 9 pushed
    • hold = button 1 held
    • release (after hold) = button 1 released
  • “Down” paddle:
    • 1 tap down = button 2 pushed
    • 2 taps down = button 4 pushed
    • 3 taps down = button 6 pushed
    • 4 taps down = button 8 pushed
    • 6 taps down = button 10 pushed
    • hold = button 2 held
    • release (after hold) = button 2 released
  • Config button: button 11 pushed

They also implement the pseudo-standard pushed(), held(), and released() commands, so apps like Dashboard and Rule Machine can use these commands without needing a custom action.

So, the events nearly match Hubitat’s built-in driver (except I didn’t use “doubleTapped” since it doesn’t really fix the numbering conundrum, and the config button is different) while exposing the rest as odd numbers for the remaining “up” taps, even numbers for the remaining “down” taps. The “held” and “released” events are also used for their intended purpose. The fan numbering is a bit different due to the extra “side” buttons but still follows this general pattern (Hubitat’s driver is actually pretty odd here: the buttom/fan button is button 1?!).

I think I have any custom command that the Inovelli drivers implement (and more than Hubitat: enough to do the notification LED plus the “regular” LED and “off” LED adjustments), but I guess setParameter() is there (like Inovelli) if not. I don’t have child devices for ease of control for anything right now (which I know the latest Inovelli drivers do); I experimented with that in the past but didn’t find it as useful as I thought, and the custom commands seem more practical to me since I’m usually in Rule Machine for this anyway. But I could add them if there is demand.

3 Likes
#7

@BertABCD1234 Thank you!! I’ll play with these over the weekend for sure!

#8

I would urge you to reconsider what you are doing. On, off, & level are states that are maintained by the dimmer. So it makes sense to send those events to the switch. Button press events are triggers only. There is no state. By calling the button press function from a rule results in inefficiencies. Is that RM has received an event and needs to set the scene, by calling the button driver’s button press function you must now push another hub event that must then be picked up by some other rule to react upon. I personally suspect this is why such an option was removed from HE.,
Instead, consider simply re-working the rules so that the button press event or the alternate conditions execute the event tied to that button.

I tried doing what you are doing a while back, and I learned the hard way how destructive this type of activity can be to the performance of your hub.