Ughh.... I have 40 of these Red Dimmer switches and I need help not hating them

Though this thread does bring up a question for @EricM_Inovelli; as well as making that delay configurable, could we check if there’s some similar delay before starting to process a button held (to dim/brighten the light)?

2 Likes

That would be a would be a wonderful news because this is the only concern I have with my 23 red switches.

Hi @phillabb, I think we are observing a slightly different delay here - the time it waits before beginning the ramp - presumably the button has to be held for some time to differentiate a slow push & release (that turns the light on/off) vs. starting a dim process.

1 Like

The delay to detect whether the button is held vs pressed (and start the dimming process) is 700ms but I believe the customization option we are releasing will effect this as well. Adjusting the minimum and maximum level and the dimming speed settings should make a big impact on how fast the dimming occurs though.

Is there any plan to add the option to perform an immediate “on” the moment the switch is held so that it jumps to its parameter 9 default local level without waiting the 700ms? In my case, I have a dimmer switch set up as a two stage low/high requiring either a push or a hold. If I push, I get instant on, but if I hold, it has to wait 700ms before doing anything. It would be much cleaner if I got instant on to the default level the moment the button was held then a ramp (instantaneous in my case) up to max after 700ms.

@fatherdoctor - Have you tried the latest firmware where you can adjust the ms response times?

@harjms I’m on 1.4.8 firmware and just grabbed the driver dated 2021-03-10. I assume I’m missing something. There is only one parameter exposed that has to do with delay, and that’s parameter 51, which I’ve had set to yes (showing up as a 0).

@fatherdoctor - Beta 1.49:

V1.49 - 12/16/2020

Remove local configuration mode (to make space for extra features).
Adding parameter 50 to adjust the delay when parameter 51 is set to 1. 1=100ms, 2=200ms, 3=300ms, etc.

!@#!@#!

Thank you. I just go direct to files.inovelli.com and hadn’t noted anything because it’s in the beta folder.

1 Like

Just so you’re aware, there should be a new firmware no too far off. It’s replacing the one that was pulled, and enhancing the SBM/DLC thing.

Unless you like flashing dimmers . . . :joy:

Just the old trick of @EricM_Inovelli planting Easter Eggs.

2 Likes

Well that was an adventure. Firmware update through the new Hubitat tool factory reset my switch (it’s been a while… is that normal?), but the driver doesn’t appear to have parameter 50 set up.

Edit: Appears the LZW31-SN driver has it, and I got it to take the parameter change, but the switch still doesn’t act like I want. When I hold, there is still a very noticeable delay before it goes to full power, and not something closer to 100ms, whereas the single button press is still near instant.

Double edit: Could be even though the black and red series have the same firmware versions in the beta directory, parameter 50 isn’t working on the black series yet?

Doesn’t sound normal (I flash through PC Controller). I will say that if parameters were not identified before, you’ll have to go through the switch details and setup those parameters.

@harjms - if I’m understanding what your suggesting correctly, you’re saying that setting parameter 50 (adjust delay) to say “1” would set BOTH the on/off delay from single press AND dim delay to 100 ms. This would require having parameter 51 (instant on off) disabled - i.e., set to “1”

Seems like this is the only way to control the dimming delay? I haven’t tested yet but just trying to understand the suggestion. Thanks!

The thing to do first is to set the minimum level. This will make sure that you are not “dimming up” over a range in which the bulbs won’t turn on. Set you Min to 1 and Max to 99. Then find the lowest level you want your bulbs at and set that value as the Min. This will decrease the perceived delay. That new Min will also become a pseudo 1%.

@harjms will address your question.

1 Like

Parameter 50 is just the delay in response to your tap. Originally, the dimmers only had a 700 ms response time, meaning it waited 700 ms before sending the command to the hub. This was designed for sending multiple tap commands to the hub without needing to be Flash and double tapping at the speed of light.

I thought parameter 1-4 dealt with the dimming delay.

Parameter 1 (and 2, 3, 4 if 101) represent the speed at which the switch dims/brigtens, or fades off/on via z-wave or local control.

Parameter 50 controls the delay between a button press and a scene event being sent. This is the delay that allows for a second press to show a different event.

Parameter 51 disables the delay period, and therefore ONLY sends scene controls for single presses/holds based on the available scene chart.

All of these and minimum level play into this conversation and should be understood/set accordingly.

Ok, this is all helpful to better understand. I’ve been playing around with these parameters (running on 1.52 beta and can confirm that parameter 50 does not influence the delay experienced between the initial press (up or down on paddle) and the moment that dimming initiates. To be clear I am not talking about on / off delay, but rather the long press action required to perform a dim.

Would be cool if I could also, similar to adjusting the ms delay (in increments of 100ms) for on/off action from single press, adjust the length between initial press (and hold) to when dimming (up or down) initiates!

Maybe seems minor, but for those times you turn on the light and it’s just a tad low in brightness and need to adjust about 10-20% the little delay feels somewhat unexpected in my opinion. Maybe I’m just old fashioned and used to the dedicated dials with instantaneous dimming response. I also recognize that we’re somewhat limited by the design of the paddle having essentially only up and down inputs. I swear I’m not trying to be hyper critical on this. More of a suggestion than anything.

1 Like

I agree. I was very excited to finally get the button delay parameter added after many of us had been requesting it for so long. But then was somewhat disappointed to find out it only sets the on/off delay and not the hold-to-dim delay.

I would be fine with the one parameter controlling both or a separate parameter is fine too. Whichever is easier to implement is ok with me as long as we can get some form of adjustable delay for the “hold to dim” reaction.

3 Likes

I actually completely agree. @EricM_Inovelli this seems like a feature request worth sharing.

Do you guys have a public github for tracking features like this?

3 Likes