It is all over the place depending on who writes the driver.
Most often I see authors make each state a different button # (double tap up=button 1 pushed, double tap down= button 2 pushed, triple tap up = button 4 pushed, triple tap down=button 5 pushed, etc).
I would say it is more "non standard" to use "held" as "pushed" just to keep the button # the same. But that said, I don't think the zwave police are going to come and give you a ticket or anything.
As long as it is documented and consistent (which it is in the inovelli drivers) it is merely a stylistic decision.
And, while it's not entirely sticking to the literal meaning of pushed & held, using them in that manner makes it much easier to read the scripts (e.g., Button 2 means 2x up/down, Button 3 means 3x up/down, etc.--so you don't need a conversion chart to follow along--which isn't a minor matter ).
@JasonJoel Any type of button mapping isn't the ideal way of doing things. I would love for Hubitat to support triplepress, quadruplepress, etc. so the mapping wasn't necessary. They do support double press, but I believe that capability came after our initial drivers were created. To be consistent and to not break people's current rules they have not changed. I will definitely provide a version that supports more than double press if Hubitat does add the extra capabilities though. It would be great to just see events for:
button1 pressed
button1 held
button1 released
button1 doublepressed
button1 triplepressed
button1 quadruplepressed
button1 quintuplepressed
for all of the buttons. People may say that if it is done this way, well where does it end? The answer is that it should end at quintuple because that is the highest number Inovelli uses.
Joking aside, that's actually the highest number I know of with any device, with HomeSeer's switches and dimmers matching (and at least some others I know coming in at triple tap). There may be other classes of device that I'm not even thinking of that might fall within the realm of these capabilities, but none are coming to mind.
I once joked that Hubitat should do exactly what you suggest. Or maybe I wasn't joking--I'm never sure with this idea. Staff do not appear to have been moved:
(That being said, I still find Inovelli's button numbering odd on Hubitat, though I understand that pretty much anything you can do is odd. What makes it even more odd than ST is that Hubitat can do "released" events, which gives "held" a bit more meaning, IMHO, in that the former would logically follow the latter for some real-world actions, but then the latter is already usurped for another purpose. But again, no great way to do this...)
@JasonJoel, you may not realize it, but your driver worked for my GE Enbrighten DIMMER, and allowed me to use Associations to associate the GE Enbrighten dimmer with my ancient non-Plus Linear WD-500 switches! This is a life saver for me! This is exactly what the old Z-Wave Tweaker did in Smartthings. I can now reassociate all my three-way switches that use the GE Enbrighten as the satellite switch. Thank you!
So am I! I was so disappointed that Z-Wave Tweaker doesn't work, since it did associations for all my switches and dimmers; even my old Linear switches. But I have everything working now, so all good.
@JasonJoel - I've been using your Enbrighten drivers w/the new Honewell Z-Wave Plus switches and dimmers I have.
I have a Honeywell dimmer that I want to use to control some non-dimmable lights. I just happen to only have dimmers in my current equipment stock. Can I use this switch driver w/the dimmer to disable the dimmer's dimming features, or is that a bad idea? If so is there a better idea?
Crap, don't know how I missed that setting in the dimmer settings. Embarrassed to say that I actually looked at the settings before I asked here. [eek!]
2.3.0 (02/13/2021) - Added Alternate Exclusion mode to preferences.
Turning this ON will change the button press sequence for excluding. HOWEVER, it also seems to make status reports from these devices come in almost immediately (instead of having 1-3s delay).
I would recommend turning this ON - but the driver will not do that by default/automatically, as I don't think it is right to change people's pairing/exclusion steps automatically.
Thanks @velvetfoot for tipping me off to this 'quirk'.
Staff do not appear to have been moved:
