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.
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
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."
}
I've always used Number in mine to be safe, either because I wasn't sure or maybe noticed the same thing a while back and went with this approach over def/nothing. I can't remember. 
PS - A common implementation in this kind of driver would be to generate the equivalent button event, often with type "digital," mostly helpful for users who want to be able to trigger automations (maybe with Dashboard) via something other than the physical event.
I usually leave it undefined/a variant. But for whatever reason this time since it said integer, I specified integer... 
Yeah, that would make more sense than doing nothing
Download the Hubitat app
