No, sounds like it works as intended!
@EricM_Inovelli added in the stealing of lunch money – nice touch 
1 Like
I think your right. After flashing 35 switches, 33 started up in instant-on mode, 2 started up with the delay
I flashed all of my LZW30-SN to 1.19 on Hubitat yesterday as well as updated the driver and noticed they all defaulted to instant on and off as well, however as soon as I clicked save on the parameters without making changes then it went back to the 700ms delay. Most of my switched I’ve turned off the delay so I’ll see if my wife notices. I like the quicker response and don’t use that many scenes anyway the ones I do use I have moved to button 6 press/hold (hold up/hold down) or button 7 pressed (config button pressed, now that all of my config buttons are the lower profile version). Thanks for the update!
I haven’t yet installed the update yet so this might not be the case. You mention that the on/off events fire on paddle-up. Since the motivation for removing the delay is to have near-instant feedback I’m curious why the switch wouldn’t activate on the initial paddle-down event? That would truly be the fastest way to get feedback and most closely resemble a regular switch action.
That is the correct interpretation, and yes, it does contribute to noticeable latency! I have some Lutron Pico remotes (that I have configured through Home Assistant to take the same actions as my Inovelli switches), and because they trigger on the button press (not release), they are still noticeably faster than the Inovelli switches in “Instant On” mode.
That being said, the latency in “Instant On” mode is much improved over what it was before, and it’s worth celebrating that!
If there is not a mechanical limitation that prevents it. I would love to see some detection on button press (even a basic zwave event that emits on press and one that emits on release)
The amount of people that jam their finger into the switch and hold it wondering why the light does not come on would astound you
I want to quickly followup to my earlier question. IMO it’s fantastic to see the devotion to your users. I think it’s the #1 reason why a relatively new company like yours stands out in an already crowded nearly-commodity market.
Had I not thought you were listening I wouldn’t have even bothered to ask the question.
4 Likes
Lol, I’m just messing with you guys. We strive to be the best of the best and we can’t do it without your feedback, so we do appreciate it. I’d rather have it where we come out with something and you want more than we come out with something and no one wants it, so I’m good with you all helping us be better!
I’m going to ask the manufacturer tonight to make that slight tweak on button pushed down vs released to gain that true instant on.
Strive for the best 
6 Likes
Awww yea… Playing Skyrim on Inovelli Switches will finally happen!
Tod Howard will be proud.
@Eric_Inovelli
The only drawback I can think of is consistency across products. If you trigger on push vs release it may work fine for the on/off switches, but it may prevent the dimmers from properly dimming.
Also, with the current 1.19 setup I still have access to the “hold” scenes. Would this go away if the lights trigger on push vs release?
Funny you should say that:
I think the hold scenes would go away in favor of Button 1 (single tap on/off) and Button 7 (config)
How do you feel about that?
I’m ok with the inconsistency of on/off and dimmer as they’re meant to be two different switches. But curious what others think
They said they could fix this in one day but it will delay mass production by 5 days as they require 4 days of internal testing.
I personally like like the idea of still having a hold scene (I actually just changed my automations around earlier today with the hold scene in mind: single tap to control the kitchen light, config button scene to toggle the living room light, and the hold scene to control both the kitchen lights and dining room lights.)
It basically gives me almost instant status changes, but still allows that extra scene.
The Developer in me says. Do it both ways and make it configurable
The QA in me says. Keep things consistent for customer expectations.
I think you should leave it alone. If its possible to in a next .21 firmware to make it configurable or even just emit a zwave event on press so that if a person reallllly wants it to they can program the switch to turn off instantly through their hub them.
So, how about a 3rd value for param 51 that gives us the choice?
I agree that the on-off and dimmer have different functions, but I think the question is less about base functionality (dim/no-dim) vs scene/no-scene.
For my purposes I’ve replaced several regular Lutron on-off paddle switches with these switches and the only thing I want over the dumb paddles is the ability to automate the on/off. I don’t mind scenes, generally, but anything that degrades the ability to swipe at the switch as one normally would on a dumb switch makes for a degraded experience and slower reaction time to turn the lights on/off.
If I want scenes I’ll mount a multi-button scene switch or something else that doesn’t interfere with existing switch functionality. I haven’t done this yet and it’s not high priority.
I don’t have a great answer for how one would do this with dimmers. Until now I’ve kept most of my dimmer switches as Lutron Diva (with the little sliding tab) over the Lutron Maestro because I can get the best of all worlds: Instant on/off along with instant dimming to any level I want.
I truly think the Lutron Diva is the epitome of perfect UI.
If I were to make a switch from scratch I’d make the paddles with a longer throw and simulate the dimmer slide switch of the diva with some kind of touch strip that I could dim up and down but wouldn’t get hit accidentally when pawing the switch on and off.
Ahhh. One can dream…
In summary, I think there’s a large category of customers who want “normal” switch mechanics with the addition of basic automation.
Thanks for saving my marriage!
2 Likes
@EricM_Inovelli any news on the config files for OpenZwave ?
After upgrading to 1.19 I am noticing that OpenZwave does not like the energy reports any more and is throwing warnings about missing Value Indexes
Can anyone try this?