Hold/Push Command bug in Hubitat driver?

While testing some automations with Hubitat, I tried using the “Hold” and “Push” commands that are provided in the Inovelli driver (see picture…)

However, I get these errors every time

08:09:28.457 am [error]org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_InovelliUSA_Inovelli_Dimmer_Red_Series_LZW31_SN_462.hold() is applicable for argument types: (java.math.BigDecimal) values: [2]
08:15:33.184 am [error]org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_InovelliUSA_Inovelli_Dimmer_Red_Series_LZW31_SN_462.push() is applicable for argument types: (java.math.BigDecimal) values: [2]

Has anyone else used these command buttons sucessfully?

The driver I’m using is “Inovelli Dimmer Red Series LZW31-SN” dated 2021-06-30 which I believe is the most current at this time.

Same issue for me, but digging through the driver code, I found this section starting on line 123. Might be worth playing with it.

    // Uncomment these lines if you would like to test your scenes with digital button presses.
    command "pressUpX1"
    command "pressDownX1"
    command "pressUpX2"
    command "pressDownX2"
    command "pressUpX3"
    command "pressDownX3"
    command "pressUpX4"
    command "pressDownX4"
    command "pressUpX5"
    command "pressDownX5"
    command "holdUp"
    command "holdDown"
    command "releaseUp"
    command "releaseDown"
    command "pressConfig"

Haha yeah, I poked in the driver code too and tried that… :nerd_face:

It added all those extra buttons to the Device Page, but Hold/Push still didn’t work. :cry:

@EricM_Inovelli I think this is a bug in the Inovelli driver (groovy code error). Can you comment?

This is a “bug,” related to Hubitat’s changes in platform 2.2.6 that added push(), hold(), and release() as required commands for button devices that implement the corresponding capability (previously, these were customary but not required, and Inovelli implemented differently-named custom commands with similar intentions that are commented out in their drivers).

Eric, the fix, as you can probably tell, would be to just add these methods and generate a “virtual”/digital event with of the corresponding button event/attribute name and the the provided button number value when called — should be super-easy. :smiley:

(The use, if anyone is wondering, with this type of device would probably just be something like the ability to invoke the same apps/rules from a Dashboard tile or, maybe in the future the mobile app directly, without needing to use a virtual device as an intermediary — a digital way to simulate the same-ish event you’d get physically. In the meantime, it’s a pretty harmless omission; the only time this would error out is if you try to run the command for some reason.)

1 Like

Thanks for the insight :+1:

I added the following custom commands to my local copy of the Inovelli driver and it seems to work:

def push(value) {
    buttonEvent(value, "pushed")
def hold(value) {
    buttonEvent(value, "held")
def release(value) {
    buttonEvent(value, "released")

@EricM_Inovelli this is a pretty easy edit/fix to the driver. It probably needs additional bounds-checking for limiting the button range to integers 1-8? With just my code above it accepts any number, including decimals (“Button 3.25 pressed”) which probably shouldn’t be allowed :grinning_face_with_smiling_eyes:

Those commands must have been added by Hubitat to these capabilities at some point:

    capability "PushableButton"
    capability "HoldableButton"
    capability "ReleasableButton"

I’ll need to add the command methods that correspond to them. If you uncomment the section mentioned above you can use our implementation of basically the same thing (a way to do a “virtual” test on button presses). Or wait a bit and I’ll get their commands added to the driver.

Yep, 2.2.6, around March or so. Ones I can think of that might affect Inovelli drivers are:

  • button-related commands (the present topic)
  • new three-parameter setColorTemperature() (I think I’ve seen this planned to be addressed from other threads?)
  • possible FanControl capability updates (supportedFanSpeed attribute, cycleSpeed() command)
  • maybe the new Flash capability with flash() command, but this is a controversial issue if the device doesn’t “natively” have some way to actually flash/blink (otherwise, you can simulate it via repeated Z-Wave commands on schedule, but that’s not the best idea for most networks…though it is what one of Hubitat’s example drivers does)
  • if the bulbs or dimmer can prestage level, you could implement the new LevelPreset capability (I think I tried and couldn’t figure out a way, but you’d know for sure!)

Here is a post I found with all the updates:

1 Like