If you’re responding to my comment above, my point was that @GroovyAlpaca had already turned off the delay,
What I was trying to get across is that the issue is seems to be with BINDING, not a wired load. (I don’t notice any discernible delay with wired loads.) So if it is a binding-only issue, then the issue could be on the switch side or it could be on the bulb side. So simply adding a parameter to reduce a binding delay may not be a solution if the delay is on the bulb end. I don’t use binding, so my statement is theoretical.
As @danielscottjames said “the button delay parameter DOES NOT affect what we are complaining about”. We’re talking about how long it takes for dimming to start.
@Bry, what exactly do you do to dim your lights locally, and how long does it take? For example, my experience is:
At time 0s: start pressing the down paddle
Wait 1 second: this delay appears to be hard coded into the firmware
At time 1s: dimming begins
From this point the speed of dimming is affected by the local dimming speed parameters (as documented here).
When I press a paddle to change a dim level on a wired load, I don’t see a discernible delay. But TBH, pressing a paddle and observing a light change could possibly be subjective. I might say I don’t see a delay and you standing next to me might see a big delay. In any event, I don’t see a large delay like what you are describing.
Inovelli is going to have to comment because this really goes to firmware code.
Bench testing to observe a voltage change vis a vis a paddle press might be more telling.
I think the commenters are right that there is a separate delay here and it makes sense from thinking about how the firmware works. The button delay parameter is intended to control the ability of the switch to detect multiple presses in rapid succession. It doesn’t seem like it’s intended to control the ability of the switch to detect a held down switch.
Unlike with multiple button presses, there has to be some delay, because otherwise it’s impossible to distinguish between dimming and a button press. This is just like eliminating the button delay takes away the ability to detect multiple button switches, except that the consequences are different and likely almost never wanted (unless you wanted a dimming only switch). It’s not really possible to do completely (0 millisecond) instant dimming as doing so would disable the ability to do button presses. Every button press would count as a brief dimming period. As a result, I think it’s certain that this is not controlled by the button delay parameter, but is likely hard coded.
I don’t know if it’s possible, but it might be nice if this were configurable. I too find that it sometimes takes too long for dimming to start — maybe some people linger on the button when holding it down and so reducing the delay would result in accidental dimming rather than switching? I’m not sure, but I suspect that I might be happier with the ability to decrease the delay in recognizing a held down switch as it seems longer than I would expect