Try this...
1 Like
I would, and thanks for the rec, except the author expressly states that it's unsuited for GE 14xxx devices, which mine is. I'll definitely check out his older driver, though!!
You can also try @JasonJoel's older dimmer driver... I use both his older and newer version and it depends on the version of your GE/Jasco Dimmer or Switch...
Here is the link.
I suggested the newer one because your device is specifically Enbrighten labeled. That usually can take advantage of his newer version. Stuff without the Enbrighten label and even the Enbrighten stuff can use his original older version.
Use it or don't... Just making a suggestion. 
I have 10 Jasco Dimmers. I use his original driver on 8 of them because they are older and not Enbrighten. I have two newer Enbrighten dimmers I use his newer driver on. His stuff just works better than the builtin drivers.
1 Like
What firmware are you on for this device? There is 5.07 and 5.20.
CHANGELOG:
- Updated the multilevel command class to version 2
- Added parameter 6
- Fixed dimming behavior
- Modified the default setting for LED indication
1 Like
Yup, looks like mine's got f/w revision 5.2 in it, so that's comforting.
I switched over to the older version of Jason's driver, and it's pure gold.
THANKS for all the suggestions, guys, and hope to return the favor one day.
1 Like
Wow, guys, I no sooner start kickin' the tires on this new user driver than I manage to throw an Error in the Logs, to wit:
[dev:66] (http://192.168.86.38/logs#) 2022-09-09 01:28:15.900 pm [error] (http://192.168.86.38/logs#) org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_Botched1_GE_Z_Wave_Plus_Dimmer_917.push() is applicable for argument types: (java.lang.Long) values: [2] Possible solutions: use([Ljava.lang.Object;), run(), run(), dump(), wait(long), parse(java.lang.String) (method push)
This happens every time I do a "PUSH" ► Button ► 1 on the Device status page. (Don't ask me WHY I decided to push that, I simply wanted to try something out, LOL)
Should I report this to @JasonJoel ? (EDIT: Will tag him here)
P.S. In case you're curious, no, the "thing" I was testing did not seem to work out. I had set up a Button Controller, which takes as its Trigger the pressing of Button 1 on my GE Dimmer device, and was supposed to perform the action of adjusting Level by +15. It did nothing. That's why/when I noticed the error in Log.
Its actually @JasonJoel's... I've tagged him a couple of times in this thread. He's pretty active so you should address it with him...
1 Like
Well that's interesting. I'll try to take a peek this weekend and see if I can understand what happened there.
I've never had one of those devices, so it doesn't surprise me that it doesn't necessarily work. Multifunction devices usually need device specific drivers.
Sweet. I stand ready to send along whatever debugging info you may want to request. Trust me when I say this isn't a priority at all, just something I happened to notice. Nothing in my workflow appears to be affected by this error.
Heck, I see red ERROR entries in the Log all day long, but most appear to be of zero consequence.
Oh I'm sure it's a driver problem.
That driver was never made with the intent of supporting multifunction devices at all.
I have one of the dual outlet plug-in dimmers, but it's the model where both outlets operate simultaneously, not independently. So I'm not exactly sure what the messaging looks like.
Assuming the issue is just the error in the quoted message, this seems like it's an easy matter of the now-required (once only conventional, if that) button commands not being implemented in the driver when you have the corresponding capability: push(), hold(), etc. This was changed back in 2.2.6 -- 2.2.6 capability update cheat sheet.
That being said, if you never have a reason to "virtually" generate these button events, you can ignore this omission--so it shouldn't be a problem in real use of the device itself, only when playing around with the device detail page like this (or setting up an app to do the same).
1 Like
Just to be clear, Jason, the KW1307 / 14280 dual-outlet plug-in dimmer in my home also controls both outlets simultaneously, not independently.
NOTE: If what I mentioned earlier about "pushing buttons" has muddied the waters, please disregard that altogether. I was honestly just poking around the UI and had a "brilliant" thought about using either button-press action as a Trigger in RM. I was knee-deep in that rabbit hole when I noticed the error posted above.
Next week, I plan to start a Community game here, called "Everybody Post The 1st Red Error in Log" to begin comparing notes on real trouble spots in the HE-sphere. 
Ah, ok. I think I have one of those somewhere still. I don't think I ever used my own driver for that device, though, I think I only used the in-box driver. I'll dig through my stuff and see...
2 Likes
OK. Got it setup @LibraSun .
By default it uses the in-box "Generic Z-Wave Smart Dimmer" driver, which makes sense / is correct. Everything I tried seemed to work with that driver.
Mine updates status as expected, when operated via digital commands (from the hub) or by pressing the physical button on the device:
The one I tested is probably 3-4 years old, running the newest firmware available (5.20).
Mine:
Version Report - FirmwareVersion: 5.2, ProtocolVersion: 4.34, HardwareVersion: 255
1 Like
I'm looking at your work, and appreciate what you've done, but wonder, are you referring to the original "Off" vs "On" issue I was gabbing about in the beginning of this thread – which i essentially resolved by switching over to your driver – or the later one, wherein I mentioned the odd "Error" message in Log whenever I attempted to invoke a buttonPress event on the dimmer? (Which admittedly I should probably never have tried...lol)
Yes, I was going back to your original issue on the in-box driver. Is that not a problem any more?
I will look at my custom driver next (after dinner). I wanted to start by seeing if the in-box driver worked as expected (it does).
Sorry for the confusion.
1 Like
So long as I keep using your driver, I'm happy on that note. I intend to stay away from the in-box "Enbrighten" driver(s) based on the sketchy feedback mentioned above. Thanks!
Well, the "Enbrighten" ones are really for the 4xxxx series devices. the 14xxx ones shouldn't be using Enbrighten branded drivers at all, and should all work with the in-box Generic Z-Wave Smart Dimmer/Switch drivers.
That said, I'll still go back and fix mine. I'm sure Bert is right and it is because I never updated the button events/support.
Summary:
12xxx series = Generic Z-Wave Dimmer/Switch
14xxx = Generic Z-Wave Smart Dimmer/Switch
4xxx/5xxx = Enbrighten
1 Like
Full disclosure: The "Generic Z-Wave Smart Dimmer" driver was indeed the one C7 assigned when I first included the GE device, but I felt "ripped off" by that, so I clearly went poking around to find a better driver. Silly me... what drove my quest as well was hunting for one that offered a FADE commend right there on the Status page, which the "Enbrighten" driver did. Suddenly the lamp was coming on and going off so much more smoothly...
...that's part of why I'm enamored of your driver, as it surfaces so much of the underlying possibilities. Call me a maximalist?
P.S. Further, fuller disclosure: I came to Hubitat from VERA of all places, which meant I was accustomed to many years of being "ripped off" due to clunky hardware, aging firmware and lots and lots of hacks and workarounds due to such limited drivers. HE is such a breath of fresh air in comparison, yet I got a little cocky I suppose thinking I could freely swap out drivers without repercussions. On VERA, those repercussions were immediate and often fatal; here on Hubitat, they are far more subtle and therefore, sometimes embarrassing.
@bertabcd1234 was right, as usual.
@LibraSun I've rev'ved up my 14xxx GE drivers that have pushable / doubletap button capabilities. Updated code in HPM and on github. I'll get to the other 14xxx (motion switch/dimmer) and 4xxxx/5xxxx Engighten later this weekend.
Side note / just an FYI @bertabcd1234 and @mike.maxwell , that post of Mike's you link to ( 2.2.6 capability update cheat sheet ) says:
//PushableButton capability.pushableButton
add command push(Integer buttonId)
//DoubleTapableButton capability.doubleTapableButton
add command doubleTap(Integer buttonId)
But unless I'm just sleepy and missing something obvious, they aren't integers, they are BigDecimal. If you explicitly specify the argument as integer like this:
def push(Integer buttonId) {
log.info "Push command does nothing in this driver."
}
You get a casting error like this:
dev:7032022-09-09 06:35:15.608 pmerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_Botched1_GE_Z_Wave_Plus_Dimmer_1084.push() is applicable for argument types: (java.math.BigDecimal) values: [1] Possible solutions: push(java.lang.Integer), use([Ljava.lang.Object;), run(), run(), dump(), parse(java.lang.String) (method push)
This works fine, though:
def push(BigDecimal buttonId) {
log.info "Push command does nothing in this driver."
}
1 Like
