Ha ha ha, so true.
2 Likes
Well it does seem some people find it useful, and I believe steve is even someone I recognize as a user of my drivers. So I guess I will add it to the drivers for an update soon.
Sorry off topic but I found info in a very old post and was not sure if it was still relevant. When should the "Sensor" and "Actuator" capabilities be included in a driver? I feel like it would only be needed if you don't have other capabilities defined, but if I am using "Switch" already should it still have Actuator as well?
Reason I am asking is because it seemed to be effecting the way the devices got reported to Alexa (see this post): Amazon Echo Skill not working with devices using capability "RelaySwitch" - #3 by jtp10181
I think the only way they show up in the button controller section is if you have the capability defined. You can see in this example doubleTap does not show up, but on another device where it is defined (but has never been used) it will show up in this list.
1 Like
Guilty.
Edit. I was hesitant at first b/c Brian’s drivers were working well for me and at that time I had about 25 Zooz switches / dimmers and didn’t want the WAF to plummet during the conversion. But after testing on a few devices the change wasn’t that bad and having the return of the “pushed” capability is very nice to have.
1 Like
So question since we are on this topic. Whats your opinion on using "DoubleTap" vs Button X pushed. The switches support up to 5x taps, and the docs consider it to be buttons 1-5 (or 1-10 for an up/down toggle). I was planning on just sticking to what's in the docs and not using DoubleTap at all, and would just remove it from the drivers. I am currently not sending any doubletap events but had included the capability for some reason.
these are really global categories of device types, they don't have or imply any commands or attributes.
They offer a rather simplistic application selection mechanism.
By convention a device that can be commanded is should have the actuator capability, and a device that measures things should have the sensor capability.
A dimmer that provides power reporting would have both.
actuator and sensor aren't evaluated by GH or Alexa, other capabilities are though, and they can determine the icon and or commands available in those integrations.
To me, the hold and release are important. The double-tap vs. having button 3 and 4 from the user side of things is a “do not care”
I can see it from a code perspective that it’s easier to handle button 3 and 4 than calling out the double taps specifically as special cases.
I will test it out again if I have time but I fairly certain that when I included Actuator and Switch, Alexa would pick the device up as a "light" and not allow it to be changed. When I removed Actuator then it would start as a "switch" and you can then set it to light if you want or keep it as a switch. The way this is handled in Alexa is actually quite terrible compared to Google, so I am not really sure if the issue is coming from Hubitat or just Alexa doing random things. Google lets you pick from a bunch of different device types and Alexa is very limited.
In my opinion, having Held and released are a function that I believe was missing. I have been forced to use smartthings as this is supported there. I use it for local control of dimming (start dimming when held, stop dimming when released) This is because i only want dimming to be activated with a switch and I do not want to mirror a device otherwise. I also want triple tap, but the Guy (@mike.maxwell) don’t see why anyone other than me would want this function. But, I will take what I can get.
I use the double tap and triple tap to activate scenes and such. not having triple tap limits my ability to simply active scenes (it can be done, but it is not intuitive).
Mean ole Mike.... 
You could always make your own driver that supports triple tap. My GE Enbrighten drivers do, for instance. Just because there isn't an in-box capability for Triple Tap doesn't mean you can't do it. Might have to map it to a button press, but it can still be done.
I don't understand; these changes to the capability do not affect how these events are reported--and these events have always been supported (or at least since Hubitat introduced these button capabilities shortly after the launch of the platform, when they weren't quite there yet). The "held" and "released" events are not new. Button drivers that implement these capabilities are now also required to implement the held() and released() commands, but unless there's a practical use for that like there apparently is with at least some events on Lutron, all this really does for other devices is give you another (digital, virtual-ish) way to generate that event.
In fact, I don't think SmartThings supports "released" events natively for buttons, or at least their schema documents only "pushed" and "held" as valid values (and the model works differently from Hubitat's). Some vendors have worked around this by usurping other button numbers or events for their custom DTHs (cough, cough, Inovelli...and that practice has leaked onto Hubitat where they don't need to, at least not until you get beyond two taps 
).
To be 100% fair, that's all one really CAN do if they have a device that supports >2 taps (as you mentioned)... I think it is a platform deficiency that we don't have up to Pentatap capability. But falling back to using buttons is OK too.
1 Like
For multi-taps, yes (I understand that issue well, as am also forced to use button-number arithmetic to expose all taps in custom drivers I wrote for these). For "held" and "released" events, no. They usurp the "held" event for pushes in the down direction, use even more button numbers for actual holds, and don't use "released" at all, which itself gets exposed as a yet a different button number with I think a "held" event too.
Again, I understand you have to do something and that this works on both Hubitat and ST with minimal modification of the DTH/driver between the two. I'm not sure it's the best way to do it on Hubitat. But until we get capability "QuintupleTapableButton" and whatnot, I do understand that workarounds of some kind for all of these are unavoidable. 
2 Likes
Agreed. I forgot they did that. Which is funny since I posted on that before...
Mapping to buttons = 
Mapping button presses to held/released = 
3 Likes
I am aware. However, this does not allow you to select triple tap or held or released from the button device rule machine option. I have been able to make it work, but the idea that it’s not out of the box support for an out of the box device feature is what I disliked.
But if you map triple tap to a button (or even a custom command), you CAN select that as a trigger or action in an RM rule.
Anyway, no worries. I would prefer to not have to do that as well.
I agree with that too, but unless you start mapping to different button numbers, there isn't a good way to make it work right now. In any case, the 2.2.6 changes, being just a minor command addition to the longstanding capabilities, aren't really related to this issue.
3 Likes
Was able to simulate double/triple taps in NodeRed thanks to the node-red-contrib-timed-counter node. Seems to work well with the lutron "q" drivers in HE - also you have the ability to adjust the timing between presses to suit your needs. If anyone is using NR it's a nice/easy way to go..
1 Like
