@EricM_Inovelli Can we clarify which button should be “released” and which should be “hold”? There are conflicts in various areas…
On the device page, button 6 is for “released” while button 8 is for “hold”
On the FAQ page, button 6 is for “hold” while button 8 is for “released”
Hubitat Driver for both on/off and dimmer:
a. In the switch-case statement (void zwaveEvent), button 6 maps to “released” while button 8 maps to “held”. So it’s same as the device page.
b. In the buttonEvent function, button 6 sends a lastEvent of “Hold ▼ or Hold ▲” while button 8 sends a lastEvent of “Tap ▲▲▲▲▲▲▲▲”. Button 6’s Hold event is obviously wrong while button 8’s event is also wrong.
c. In the holdUp() and holdDown() functions, button 6 is being sent. Once again, this is opposite from what is actually happening.
So can we decide on what exactly button 6 and button 8 should be doing?
If button 6 should be “released” while button 8 should be “held”, the buttonEvent(), holdUp() and holdDown() functions of both drivers need to be changed to reflect that. The FAQ page would also need to be updated.
If button 6 should be “held” while button 8 should be “released”, the zWaveEvent() function should be changed to reflect that. The device page would also need to be updated.
Also, in both cases, the buttonEvent() needs to also specify an if statement for button 8 to properly describe what happens.
I can make the changes as long as I have guidance as to what the buttons should correctly map to.
I never thought to look at the driver to see what it said, but just captured the events upon first install. I really do wish we’d get a held and a released event out of the driver so the button controllers could use that built in functionality.
I concur with your findings in Hubitat though. You get a Button 8 Push when the up-hold starts, and a Button 6 push when the up-hold is released.
If you use ABC, you can still ramp using held and released events. After asking the developer a couple of times, he was able to add that functionality recently.
Here’s an example. Obviously my buttons 6 and 8 are inverted (I previously edited the driver to make it work but update earlier this month broke it):
I’m seeing the same thing. Likewise for down-hold and down-released. It certainly appears that these are reversed from the documentation.
While there are way to workaround it, I think this should still be treated as an open bug until the official Inovelli driver and/or documentation gets updated with the correct Button 6/8 held/released mappings.
@EricM_Inovelli can you comment on which is the intended behavior?
I discovered the exact same thing when I finally got around to trying to build some button controllers in HE for Hue control from LZW31-SNs. I eagerly await the next firmware update so that I can easily get the LED bar to match the levels of wherever the Hue bulbs being controlled land. But that’s secondary.
At this point I have numerous rules and controllers built around the way it is as opposed to the way it is documented. I suspect others are in the same boat?
I also concur with the earlier comment that it also would be even better to add the released event so that we can catch those in a more “native” manner.
The reason why they didn’t add the released event is because SmartThings doesn’t support it. As such, they’d have to maintain different drivers between ST and HE where buttons mean different things.
To clarify, the way it works in HE is:
Assume the top paddle is button 1:
If button 1 is pushed, a “pushed” event should be sent.
If button 1 is “held”, a “held” event would be sent.
Then HE expects that when button 1 is released, a “released” event is sent.
This is completely different from how Inovelli’s drivers are written. In Inovelli world,
Button 1 “pushed” event occurs when the top paddle is pushed.
Button 1 “held” occurs when the bottom paddle is pushed.
As such, a button 1 “released” doesn’t make much sense.
Inovelli would need to change how every button is labeled to fix this. They’d also need to rewrite their manuals and since ST doesn’t support released, they’d need to maintain different drivers (with different buttons) between HE and ST.
I had previously re-written the HE drivers to make it work the way HE expects but I quickly realized it wasn’t worth it since I was missing important updates by Inovelli. Tbh, using ABC makes the “released event” a breeze so I’d recommend you go with that approach.
Yup, the point here is held events in Inovelli don’t mean the same thing as in HE. In Inovelli, held is used for the down paddle. In HE, held means you actually held a paddle. So in Inovelli, there are 7 held events. In HE, there are only 2 held events (1 for holding the up paddle and the other for holding the down paddle).
Didn’t even know that list existed. This list is yet another contradiction. It says button 6 is for hold and button 8 is for released. This is the opposite of how the switches/dimmer actually work now and also opposite from what posted here. We just need to get it to be consistent.
I don’t completely agree. HE doesn’t care if you actually HELD the button or not. All it cares about is that a specific “button event” happened. Yeah, I’ll grant you that the name of the event “Button Held” implies that you held down the button, but that is just a name.
HE couldn’t care less whether you actually held the button or if you tapped it down. What matters is that a specific “event” happened and you want that specific event to trigger an action. The odd naming does make the wording of rules look a bit weird when reading them (trigger on button 1 held when you tapped the paddle down 1x), but HE is perfectly happy performing the action as defined for that event.
Since the light switches only have 3 physical buttons (up, down, config), if Inovelli stuck rigidly to the event names “pushed” and “held” then we would only get a 3-button controller with no multi-tap events. I think its clever of them to map the multi-tap physical action to a virtual 8-button controller with only 3 physical buttons
The standard way for HE is held means held. That’s why HE can automatically perform events (like stop dimming) after “held” events are completed (because it expects the same button to send a “released” event).
HE doesn’t force you to its standard though and is flexible.
Just as a FYI, HE also has a doubleTapped event which as you’d expect, means the paddle was doubleTapped. HE has a lot of standards but is very flexible to accommodate other use-cases.
Where do you see that? I do not see that restriction and did not find an option in HE Rule Machine where it will automatically stop dimming “because it expects the same button to send a released event”. Is there an option hiding in there that I missed?
I just now tried creating a test rule in Rule Manager and as far as I can tell, it requires separate actions: one to start dimming and one to stop dimming. Each action can be triggered by any button event I choose and I don’t see any requirement for the same button being held and released. I can just as easily set the rule to start dimming with “button 6 held” and stop dimming on “button 8 held”. which would be the same as “start dimming with paddle down held” and stop dimming on “paddle down released”. (assuming Inovelli fixes the driver so Button6/8 Held events get fixed to match the documentation )
Arguing semantics of wording vs. features. It would not be possible for the Inovelli team to have this many scene events on ST without developing it this way (another platform, but a limitation nonetheless). Since they share groovy driver code 99% of the time, I can see why they went this route and the documentation is clearly available for you to use.
Thanks for pointing that out. I fixed it in the KB article.
As others have mentioned, the reason we initially went with the button mapping the way it is is because SmartThings and Hubitat did not support things such as 2x, 3x, 4x tap etc. Hubitat has since added double tap support, but changing things around would cause problems for those that have already setup rules or automations. After that point it was just a matter of staying consistent across devices. I don’t see this changing until Gen 3 or if Hubitat creates capabilities for 3x, 4x, and 5x taps.
Yes, for the most important part, the driver is correct. However, digital holds (holdUp()/holdDown() function) are currently wrong. Also, the button event that reports what button was held is also wrong.The 1st post has more details.
)