Is this a fan-only switch, or a combination fan/light??? 
1 Like
Dangit… I always miss something when I copy/paste lol.
It’s a fan only switch. I’ll delete that part 
3 Likes
lol. keeping you honest.
2 Likes
Since we’re here, can all of the future products either default to or have a configurable option to physically act-on and/or send an instant “on” command even if the switch has the delay for scene commands enabled? The perceived responsiveness of the system would be dramatically improved (especially for lights) if ON happened right away followed by dimming, etc as normal. I like 700ms before a held/dim action is performed, but hate that a simple click up/down also has a 700ms delay in it.
I think I’m tracking, but just so I’m clear – are you saying that regardless of if the switch is set for, “instant on” or 100-900ms, the signal sent to the hub (or associated devices) should always be instant?
1 Like
Here’s an example of what current state and new state would look like unless I’m misinterpreting what I see, and I think similar/same behavior occurs in the switch-local control as well.
Current state:
Press and hold switch up
700ms pause
Scene command for button held is sent
New state:
Press and hold switch up
Scene command for button pressed is sent
700ms pause
Scene command for button held is sent
2 Likes
Ok, that makes sense – tagging @EricM_Inovelli for visibility as we’ll want to implement this on our other switches.
The problem with that is it doesn’t allow button held events without first sending a button pressed. I’m not sure if that violates any zwave rules because currently button held events happen without being preceded by a button press. They are supposed to be independent actions and it likely would break a bunch of existing automations where button press and button held events trigger opposite actions
1 Like
I’d gladly take is as a configurable option. It’d really increase the guest acceptance level to get a more immediate response.
Have you tried this existing configurable option?..
1 Like
I feel like sending a button press event immediately would mess up most scenarios where long press is used.
I would think the most common use of long press (up or down) is to control dimming, in which case - if you’re trying to dim a dark room up to 20% you’ll get greeted with a immediate blast of 100% brightness followed by needing to write a really complex automation to handle the dimming. I say complex automation, because you are no longer grabbing the current brightness level and slowly ramping it up, you now need decide if the current brightness level was the result of a single press immediately followed by a long press. But once you’ve determined that, you can’t simply bring the light back to 0% brightness and start fading up, you need to know what the brightness was before (eg. If it was at brightness 10% and you long pressed to bring it to 30%, it would be a poor user experience for that automation to begin by first taking the room down to brightness 0%).
I think the best way to handle this is how button presses are handled in most software; leveraging the on release action. On release can be acted on immediately because at the time it’s triggered, you already know if the intended action was a long press or short press.
1 Like
Agreed. From a firmware perspective, that is the correct way to handle button presses. Not sure why the Inovelli’s don’t seem to do that.
Pressing a button should fire off this routine:
START timer with TimeOut = button_press_delay
WAIT UNTIL button_released OR timer expires
IF timer < button_press_delay THEN /*button was released before button_press_delay*/
trigger button pressed event
ELSE /*button still pressed after button_press_delay*/
trigger button held event
WAIT UNTIL button release
trigger button released event
END-IF
This logic will allow short clicks to fire off button_pressed events as soon as the button is released yet still be able to detect longer button_held and button_released events after the button_press_delay
1 Like
It’s been a little while, bit I recall parameter 51 disabling held and multi-tap scene commands. I’ll try to experiment with it again this weekend. It is the very first parameter I enable on my black switches.
I do like the logic you and @kendrosg propose. It would resolve the majority of the issues I see and complaints I get. Most of the time it’s not the delay in initial brightness during a hold/dimming action, but a delay from a single tap action.
1 Like
My understanding is that’s how it works now, right? I’ll be honest, I don’t often get as far into the weeds as maybe I should on a lot of the intricacies of the firmware, but I swore we made it to when the button is released it sends a command.
Tagging @EricM_Inovelli as he’s the real MVP behind the firmware.
1 Like
All the evidence points to that not being the case. 
Its hard for any of us to say for certain without being able to see the source code (which I know the manufacture keeps hidden from you). BUT… its fairly easy to test by setting the button_press_delay to the maximum 900ms, then quickly click a button. (quick press/release click)
I’ve tested this quite a bit and can see that it waits almost a full second (~900ms) before it sends a command - even though the button was released within about 100-200ms. This tells me that it is waiting for the timer to expire and not immediately acting on button release. IF it was acting on button release (before timer expires) then we wouldn’t have had all those discussions and enhancements regarding the original 700ms fixed delay
To be clear, if the button is HELD longer than the button_delay, then a button_held event gets sent and after then when the button is released a button_released event is sent. BUT if the physical button is released BEFORE the button_delay then it does not immediately send a button_pressed. Instead it waits for the button_delay and then sends the button_pressed event.
Ahhh, I see – ok, so we’re saying there’s still a delay after the button is released?
I missed this part (sorry) and just read it as there was no command being sent after the button was released.
Ok, this makes sense – @fatherdoctor & @kendrosg is this what you’re talking about?
Sorry, my comprehension skills are not there today lol
Yes, if the release happens before the button_delay_time expires, it still waits for the timer to expire even though the button was released. AFTER the button_delay elapses, then it sends button_pressed or button_held depending on whether the button is still pushed or not. Either way it waits for the timeout before ANY events are sent.
This is the problem why a simple click ‘on’ has delay and why we pushed for the adjustable delay parameter which was, frankly, a bit of a hack around the problem of not acting immediately on button release.
After thinking about this a bit, I realize now WHY Inovelli does it this way…
It NEEDS to wait for the timeout before sending a button_pressed event because it needs wait for a possible 2nd, 3rd, 4th, or 5th button ‘click’. That is how it will know to send a button_pressed (or button_held) event for Button1, Button2, Button3, Button4, or Button5.
This is necessary because Inovelli on/off switches and dimmers emulate multi-button controllers using multiple taps of the same button. Therefore it must wait after the first tap in order to see if there is a 2nd, 3rd, 4th, or 5th.
Sorry about the prior lengthy analysis. But now looking at all the data, it appears the current method is the best compromise that covers the most scenarios overall.
3 Likes
It makes sense but… I do believe there are still ways around it and at least to me (a software engineer obsessed with quality) any noticeable delay is not acceptable but maybe … this is the ocd talking 
Anyway… just look around, there are multi tap events implemented all over, starting with your computer. Imagine if you had to wait 700ms every time you double click to open something? 
I know it is not a fair comparison but my point is: this is nothing software engineering hasn’t solved in the past in a gazilion different ways.
I iunderstand inovelli doesn’t own the source code but if we had at least some pseudo code to start with I’m sure we could figure something out that could later be presented to the manufacturer as a suggestion.
1 Like
I agree …but… this is a bit different. When you double-click the mouse, TWO events get generated. The first click still triggers the “select_object” event and then the second click triggers the “open_object” event. In the case of the Inovelli switches, a double-click should NOT trigger two events. If there are two (or more) clicks, it must NOT trigger the event for the first click. I don’t think there are any actions with a PC mouse that have this same restriction.
The good news is we don’t have to wait the fixed 700ms anymore The new firmware allows us to set the delay in 100ms increments. I have mine set to 300ms which is still a delay but much better than 700ms. I tried 200ms but that was too quick for other people in the house. TBH a setting of 250 would be almost ideal for me but that is not an option at this time 
I agree there is probably some way but I think the special conditions may make this more difficult than it first seems. I have provided psuedo-code on a few of my previous recommendations, but I have not been able to think up a good code stub for this. If you have some ideas and can provide some pseudo-code for this it would be great 
2 Likes