I see there are new Enbrighten drivers in 2.1.8...
A few feature requests for future version:
Support Triple Taps. The device supports triple tap in hardware, the driver should too.
If they were not added because Hubitat doesn't have a Triple tap capability, then that should be added or the driver revamped to expose the double/triple taps as button presses so that we get full functionality of the device.
EDIT 1: if the "pushed" commands were supposed to handle triple tap (not sure what else they would be for), they don't on my devices - so that could be a bug...
EDIT 2: Sometimes double/triple taps will create a pushed event, but usually not. Something not right there...
Expose/Support setting the Default Level % as a command. The device supports pre-loading / setting the turn on level, the driver should too.
Sure, I'll bring this up for an internal vote, there's devices that support 5x tap, so if we add three where does it end? None of our apps support 3x, so those would all need to change too, hence the vote...
Hubitat doesn't have a 3xtap capability, so this add is a big deal.
I can look at adding a prestaging preference option, I'm not inclined to add a custom command to support this at this time.
Then expose them as button presses, and have no built-in command for it other than "push". That would be fine with me.
But whatever you guys decide is fine. My user drivers I published back in July 2019 support all of those things, so I'm ok either way. I just thought it would be nice to get rid of the user driver altogether.
Here is how my user driver does it, for what that is worth:
dev:11912020-01-10 04:57:07.440 pm infoBreakfast Nook Light had Tripletap down (button 4) [physical]
dev:11912020-01-10 04:57:05.016 pm infoBreakfast Nook Light had Tripletap up (button 3) [physical]
dev:11912020-01-10 04:57:02.139 pm infoBreakfast Nook Light had Doubletap down (button 2) [physical]
dev:11912020-01-10 04:57:00.830 pm infoBreakfast Nook Light had Doubletap up (button 1) [physical]
Presumably with quintuple tap, the current maximum I've seen in any device. But I definitely see the problem, even if this might be one way to solve it for some devices. Another idea I've thought of for these devices: why not make the up and down scene/button events be from be from child devices instead? So we could have buttons 1-5 pushed for the down paddle, 1-5 pushed for the up paddle, and eliminate the button-number math or n-tuple-tappable question. This still isn't 100% non-messy given that the button model assume all button numbers support the same events (and on the devices that do support it, you'll likely only get held and released on the buttons numbered 1 in my hypothetical model), but there are already devices with this issue. It would also work with existing apps as-is, though many only support "pushed" anyway, so even with quintuple tap, I'm not sure that would be a problem as long as they were usable in Rule Machine like they are now.
As a thought, rather than try to extend the singleTap, Hold, Released, DoubleTap, theme, find a more flexible way forward with a single more flexible Capability - let's call it "MultiTapButton". This capability would report two values: Button Number, and Value. A driver should also be able to apply a label to ButtonNumber which could be displayed in the User Interface (e.g., of Rule Machine) ("Top of Paddle", "Bottom of Paddle", etc.) Any positive value would be the number of taps while -1 is "Hold" and -2 is "Released". Released should also report the number of milliseconds the button was held or "undefined" if the value can't be calculated from the hardware. For 2 taps or less, this MultiTapButton Capability would be redundant with the existing PushableButton, ReleaseableButton, HoldableButton, DoubleTapableButton which might be considered a "depricated" way of handling taps (but implementation should still be required in the driver). For anything beyond 2 taps, only MultiTapButton will trigger and provide the sole report. That way, you have a single consistent interface regardless of the number of taps and buttons. Also, the "negative" values could be further extended if anything beyond Hold and Released were desired - E.g., perhaps there's a "Simultaneous Press" with the value being a JSON array identifying all buttons simultaneously pressed (though I don't know if any hardware current supports such a action)
I just got WD200+ that supports up to 5 taps and I would really like supporting up to 4. Single tap to turn off that light, two taps to turn to 20%, three taps to turn all the smart switches/bulbs in the area off, and 4 taps to turn off the whole floor and go into nightime mode.
But I definitely see the problem, even if this might be one way to solve it for some devices. Another idea I've thought of for these devices: why not make the up and down scene/button events be from be from child devices instead? So we could have buttons 1-5 pushed for the down paddle, 1-5 pushed for the up paddle, and eliminate the button-number math or n-tuple-tappable question. This still isn't 100% non-messy given that the button model assume all button numbers support the same events (and on the devices that do support it, you'll likely only get held and released on the buttons numbered 1 in my hypothetical model), but there are already devices with this issue. It would also work with existing apps as-is, though many only support "pushed" anyway, so even with quintuple tap, I'm not sure that would be a problem as long as they were usable in Rule Machine like they are now.
