Speed of new switches and dimmers?

Any updates on this? I just installed two switches and it’s painfully slow turning it on from the switch.

1 Like

I converted from SmartThings to Hubitat over last weekend and wanted to revise my impression of the Inovelli switches after using them for a few days on the new platform.

I love them!

The delay is much less pronounced and they just seem much more integrated. I still have the Red and Black in the bathroom for a consistent testing setup and they are much more responsive on the Hubitat. I plan to swap these out for Red and Black dimmers and put a motion sensor in the bathroom so we can have the lights come on dimly during sleepy time, etc.

Really nice switches and it’s amazing how rapidly we’ve become accustomed to double tapping the Red at the top of the stairs to turn off the entire basement.

1 Like

This HAS to be WWST compatibility and allowing the switches to work LOCAL right? I mean mine are pretty damn fast (1-2 seconds), but not instant (under 1s). I’m on ST.

Any updates on WWST approval @Eric_Inovelli.

I also have been suffering from the described speed issues of theses switches, and have been considering returning them since I can do so in the first 30 days.

I wanted to be sure the speed problem was an issue with inovelli and not my hub or the protocol, so I bought a cheap ‘go control’ wireless remote switch and linked it to one bulb and linked the inovelli switch to another bulb. I moved dim rate and ramp rate to 0.

I consistently got a 1 to 1.1 second delay from pushing goControl switch until the light came on
and 1.5 to 1.6 second delay with the involli. I confirmed the difference by pressing both switches at the same time and inovelli always came on 2nd with a noticeable delay. For both switches, if it was the first push after a long period of no activity the delay could be an additional .5 to 1 seconds.

It from this test seems as though there is a 500ms delay caused by the double click timeout on theses switches, which amounts to about a 3rd of the delay time.

I’m pretty disappointed because the total delay times are too much in my opinion. I need non smarthome people to be able to operate my lights without thinking they are broken.

If it were configurable, I would cut the double click timeout in half but I think that still would not be enough. I’m wondering if a zigbee solution could be faster or maybe some optimization can be done on the hub. It really should be possible to have a fast response, if I control a light directly from the hubitat web interface it turns on nearly instantly. There is really no excuse for a 2 second delay and I would never replace all my switches at this speed.

I have tons of third party apps and drivers and have no slow downs on my hubitat…

Also as far as popcorn and delays… It sounds like some of you are using smart bulbs one these switches… Have y’all tried doing a direct z-wave association?

My first go around with HE and only a few GE switches and basic rules, the slow down was so bad that it would take 5s+ to fire an automation. Since the last ST outage, I moved everything over to HE and setup to reboot every morning. It’s been good since.

I use zwave association, and in my case the popcorn effect is so minimal it’s not even worth talking about. You have to really look for it to even notice in a 4 light fixture. I’m talking a difference of milliseconds between bulbs. There’s a video on here somewhere where the bulbs are turning on 2-3s apart, but I don’t think he was using zwave association.

1 Like

Sorry to drag out an old thread, but @EricM_Inovelli , can we get an update here? Or maybe direct me to a thread where there is one?

As a first mover on the new Red Switches, I deployed enough to get feedback from the family (positive, except very negative on the scene delay) and stopped there. Now that we’re spending so much more time at home I need to move forward or go back. It’s been some months, so I’m wondering if there’s at least an update.

In every other way, this switch hits all my requirements. Love the form factor and configurability of the notification light (and use it heavily). I just don’t use scenes, and would prefer a way to skip the associated scene delay.

Thanks.

@mattstein111

We are looking at an alternate firmware that disables scenes on the red series to reduce the on / off by ~1 second (that is the time it waits for another button press).

Having said that, there are kind of two issues at play here.

Issue 1 is for all devices. It is the delay from when the button is pressed to when the internal workings of the switch start to do their job. It is about 1 second. For me, this “delay” is not noticeable. It turns on & off well before my brain has time to think that something is wrong. Maybe my brain is slow though? :slight_smile:

Issue 2 is where I think most people complain. This is the time it takes for an LED bulb to ramp up from 0% to the % it actually turns on. For a lot of LED bulbs this percentage is pretty high. I’ve seen it up to 35%. So from 0% to 35% it looks like the dimmer isn’t doing anything when in fact, it is.

For issue 2, there are settings that can be adjusted to pretty much eliminate this delay.

Step 1 (minimum level): First, start at 0% and dim UP the device 1 or 2% at a time until the bulb turns on. Set the minimum level to this value. Note: Do not start with the bulb ON and dim down until the bulb turns off. This level is generally lower and will result in the dimmer not being optimally configured.

Step 2 (ramp rate at switch) Change the ramp rate from its default to 0, 1, or 2. Setting it to 0 will instantly turn on the bulb.

These two adjustments will take care of most complaints.

That being said, we have made the default minimum level 10% on the new dimmer firmware which should help with the problem. Also, we are trying to create an alternate firmware that:

  1. Gives the user the option to disable the scenes that cause the device to wait ~1 second.
  2. Does an auto calibration by the dimmer to determine the best value for min & max level.

We have tried to fit those things into our standard firmware, but there just isn’t enough room.

Edit: To demonstrate what I am referring to, here are a few videos. Excuse my dangerous looking home office LOL.

Example of ON/OFF Scene Delay (~1 second)

Example of Non-Optimized Dimmer Delay
Can’t get this one to upload past 4% :frowning:

Example of Optimized Dimmer Delay (Minimum level set to 35% & Ramp Rate (From Switch) set to 0)

2 Likes

Eric, first off, thank you for the prompt and fulsome response. Awesome. Just one of the reasons I love Inovelli. You guys are awesome.

Second, I use the Switch, not the dimmer, so ramp rate doesn’t factor into it. I am referring to the delay after press/release the switch before the light flips on (your “Issue 1”). I realize that it’s fast to you, and it doesn’t really bother me either, but the family are still annoyed by it and have outright objected to having more of them in the house.

So I suppose I’ll check back with you guys over time and if you are ever able to come out with an alternative firmware, I’ll consider them at the time. For now though, I’ve got what I needed most, which is certainty.

Again, I have to say it - you guys make the best Zwave switches out there, bar none. (but just this one quirk!)

1 Like

@EricM_Inovelli @mattstein111

Just wanted to chime in here as well. I purchased 8 Red Dimmer switches and installed them a couple of weeks ago. When it comes to our “non-smart” LED lighting the switches integrated easily. I am very happy with the quality of the hardware, and super impressed with the customizability of the switch.

I am however displeased with the delay that occurs between pressing the switch and the lights actually turning on/off. I’ve set the ramp rate to 0 and the minimum brightness to 35%, and even flashed beta firmware to see if this was addressed. When toggled remotely from Hubitat or Home Assistant, the lights turn on/off instantly. The delay is only when turning the lights on/off at the switch, because it is waiting to see if we’re triggering a scene.

We’ve been conditioned to expect an instant response from light switches over entire lifetimes, and so when one doesn’t behave as expected, it’s jarring. Even after a few weeks of using these switches, and despite understanding exactly why there is a delay, using the switches feels “wrong.” Guests have also commented on it (and suggested we replace our lights because they are on their way out). The best user experience is the one that isn’t noticed – unfortunately with the current firmware, it’s simply impossible to achieve.

I’m not sure that disabling support for scenes entirely is the correct solution either. I had originally planned on cycling through scenes via the config button. If that functionality was removed altogether, I would definitely miss it. A more flexible solution would be to make the scene delay customizable: on some switches I would simply set it to 0, on others I would set it to 250 milliseconds.

Thanks for reading :slight_smile:

2 Likes

Thanks for the suggestion. We aren’t planning on getting rid of the scenes completely, but would have a configuration parameter to disable the ones that make it have a pause before turning on the light. You would end up with 1x press on up / down & 1x press on the config button. Ok, so now that I write it out it is basically all the scenes.

The problem I see with adjusting the delay is that you might have to be super human to push the button fast enough to have it register a 2x, 3x, press etc.

1 Like

Not a problem. Years of experience. All in the elbow.

4 Likes

Thanks Eric! I really appreciate the way you guys engage with the community. That was one of the main reasons why I chose to go with Inovelli. I believe in your mission and your team.

For reference, the default timing for double-clicks in Windows (which I’ve always found to be way too slow/lenient) is 500 ms. That’s what the folks at Microsoft think is a good default for their billion+ users, including those folks with lower dexterity.

The reason why I suggested making the delay configurable is that I think it fits with the Red Series’ philosophy of allowing for a deep level of customization. I personally can’t ever see a scenario where it would be useful to set a ramp rate of say 10 seconds, or 30 seconds, etc. But the switch allows for it and I’m sure someone, somewhere is using this functionality and loving it :slight_smile:

1 Like

Let me chime in here…

@EricM_Inovelli I’ve asked since the release of the red switches and dimmers to make the delay configurable. I want scenes but even with scenes, your delay is too long. I have GE switches and dimmers that support double tap and their delays are less than half yours. Right now, like you said, it’s about a 1 second delay for your switches and a bit less than that (maybe 900ms) for your dimmers. For GE switches and dimmers, it’s about 400ms. To me, it makes a world of difference. Also, I never miss a double tap on the GE switches/dimmers. It’s really very very natural. They nailed the delay right!

Please please make it configurable. I’m glad that you’re looking into disabling local control to make room for more features on an alternate firmware. However, it’d be very disappointing if that alternative firmware maintained the delay if scenes were enabled. A configurable delay would mean anyone can decide what speed works for them. If they set it too fast, then multi-taps won’t work. If they set it too slow, it’s their prerogative. It’s really a win-win.

Thanks!


2 Likes

One more interested in speeding up switch response!
A wait time config sounds like a good answer to me, and seems similar to the other parameters - maybe a choice of 0-10 in units of 100ms? (so 3 would be 300ms), 0 would be no scenes (or selectable with some other button combination).
Just checking, I presume the time we are discussing is the interval between each button press, not the time that all the presses need to be entered in? (the comment about needing to be really fast to get 3x… in made me wonder).

It seems like our expectations have gone through several changes in the last decade or so. Starting with simple switches & incandescent bulbs, response time was “instantaneous” (give or take a millisecond or two for the filament to heat up). Then came CFLs, early ones were terribly slow to start, becoming better but still a noticeable delay. And they were replaced with LEDs, again starting with a significant delay, current ones are better, but still noticeable - looks like current CA-24 & Energy Star rules allow 500-750ms delays.

I have a gen1, non-scene, switch. Off time seems a bit less that 1/2 second. On time somewhere between 1/2 & 1 second, with the relay clicking about half way through - so < 1/2 second switch time + < 1/2 second bulb time.
My gen2 scene dimmer I’ve got a bit below 2 seconds.

2 Likes

I too am a member of the “speed up” club!

I concur that a configurable parameter would be wonderful. I assume the delay is the switch waiting after each time the user has released the paddle to see if they are going to press it again. If we could configure this delay, I think everyone would be happy. Note that if this were configured to zero, it would eliminate the ability to initiate scenes with the paddle (I assume you could still use the config button) and the switch would respond instantly.

The other delay I would like to be able to configure is the amount of time it waits when the paddle is held down to decide if it’s a press or a hold. Setting this to zero would cause EVERY touch to be considered a hold. This would cause dimming/brightening to begin instantly but would prevent the user from actually turning the load on or off with the switch. Setting it to whatever the maximum configurable value is should invoke a special case where it would prevent the user from adjusting the brightness via the switch; i.e., every touch is a press no matter how long it’s held.

While on the topic of the paddle, I believe I saw a suggestion to enable the ability for a press on either the top or the bottom to “toggle” the load, i.e. turn it off if it’s currently on, or turn it on if it’s currently off. I would like to add another vote for that feature.

I would hope that if any of these configurations are applied to the switch, they would automatically apply to any connected add-on switches. Along that same line, I would also like to see the ability to initiate scenes from the add-on switches.

2 Likes

@Eric_Inovelli @EricM_Inovelli I’m curious if it would be possible for the config button to do multiple scenes (i.e. double/triple tap) but the main button have scenes turned off (and thus have no delay). That would be pretty darn sweet.

1 Like

Ah yes; I use the hold for both switches and it’d be great if the delay for a hold was configurable also. Dimming my Hue bedside lights takes a bit long to get started so would appreciate this.

Essentially, please make the delays for a 2nd press and the delay for a hold configurable. By far the feature I’m most hoping for!

For me, Ive been super happy with the new switches and have raved about them to pretty much anyone interested. I do however experience some delay when triggering these through my smartthings automations and I was pretty sure the delay was due to cloud processing vs local processing which you’ll notice is the case when using the custom device handler. Is that not a factor worth considering?

Cloud processing is a factor, but only for SmartThings setups. I actually started with SmartThings, and was disappointed with the delay in the switches. So I purchased a Hubitat Elevation (a hub with local processing) hoping that it would improve responsiveness. It helped, but only a little. I thought perhaps the meager hardware specs of that hub were to blame. I then set up Home Assistant on a fairly powerful system, and that’s what I’m using now. When I toggle lights from HA, they turn on and off instantly. And I mean instantly – there is absolutely zero delay that I can notice, and it’s incredibly satisfying. It’s only when turning lights on/off at the switch that the setup feels slow and awkward. It’s pretty disheartening considering how fantastic the rest of the product is.