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"
*/
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.
(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.)
@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
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!)