I have a number of GE 14294 dimmers, as well as several other dimmers. I had some scenes set up with durations for them to come on, and I noticed that the other dimmers slowly changed to the desired level, but the GE dimmers switched instantly.
Then I went to the device page for one of the 14294s, and tried the setLevel command with a duration. Even there, the change was always instant.
Do these devices just not support setLevel durations? If not, I know I can write code or use RM to fake it, but it would be so much easier if they behaved like the others.
I'll check when I get home as I have a few 14294 switches, but unless I'm remembering really incorrectly I think the duration parameter should work (in the in-box or user driver). I would swear I tested it when I wrote my user driver.
But I admit it has been a while since I've tried it, so could be wrong.
Do you think I should try @JasonJoelOld's driver? I looked at his code in GitHub, and there's definitely some code related to setLevel duration. So maybe it's not the device itself, but maybe the built-in driver isn't handling setLevel duration properly?
It doesn't hurt to try it - can always just switch back to the in-box driver if it doesn't help.
However, level + duration is a pretty hard thing to mess up at the driver level. I can't imagine that the in-box driver is doing it any differently than I did.
I guess that is a long way of saying I'm not convinced switching drivers will help.
Just got home and tried it out. Switched one of them over to your GE Enbrighten Z-Wave Plus Dimmer Driver. Now setLevel duration works perfectly! I think the built-in driver must be handling the parameter incorrectly.
Question: Do you recommend using your "GE-Jasco Z-Wave Plus Dimmer.groovy" or your "GE Enbrighten Dimmer.groovy". I thought enbrighten was the newer devices from GE, but it looks like your other driver has been updated more recently.
Interesting question.... both the new and old model #s are the same 14294...
So my guidance would be that all of the new "shallow mount" ge devices should use the enbrighten driver. All of the older "deep" models should use the other one.
The devices actually have pretty different capabilities so if you use the enbrighten driver on a non-enbrighten device it won't fully work. Meaning some things will, some things won't.
The non-enbrighten driver was updated more recently because jasco keeps dicking with the firmware, slightly changing the behavior of the devices. So I had to update the driver to fix something that worked perfectly on older firmware versions.
LOL I'm starting to see a taste of what you go through. I just discovered I have one odd dimmer. It's definitely the older (deeper, with metal tabs) model of 14294. But from inspecting values and testing behavior with "Basic Z-Wave tool", it looks like it utilizes at least some of the configuration parameters that the newer, shallower 14294s have. Go figure.
(The one specifically I noticed is that the newer devices have config param 30, which sets a minimum dimming level. My older 14294s do not store or respond to param 30. This one device though... definitely an old 14294. Definitely also does store and utilize param 30.)
Yes. parameter 30 is unique to the new firmware, as is scene based reporting and triple tap in hardware.
The hardware support for triple tap made me have to change the enbrighten driver to use "buttons" instead of the native HE "tap" events (as hubitat doesn't have a triple tap event at all). I haven't really thought about it, but I would expect double tap would not work when using the enbrighten driver on the old firmware devices.
Out of curiousity.... Was this behavior on hub v2.1.7, or on 2.1.6 or earlier? I ask because there was a change make in 2.1.7 that (probably didn't) but might have affected this.
