Feature Request: Dynamic on/off ramp rates

To me, it doesn’t make sense that the setting takes the same amount of time to ramp on to 10% as it does to ramp on to 100%. This is especially problematic if you have default dimmer settings set at very low levels for portions of the day.

I would much prefer if there was a dynamic setting, which allows you to set ramp rate to 100% (example 3 seconds) and if the switch is ramping to 50% it takes half as long to get to the set brightness and stops (1.5 seconds in the example), 25% would be 1/4 the length of full brightness ramp time, etc.

Which platform are you running?
Many have a way to set the transition time when turning a light on.

Here’s an example with Home Assistant. This instantly turns on the lights to 40%.

service: light.turn_on
  transition: 0
  brightness_pct: 40
  entity_id: light.bar_lights
alias: Turn on lights to night mode

Now if I were to take this same example, I could make that light turn on to 40% over 10s

service: light.turn_on
  transition: 10
  brightness_pct: 40
  entity_id: light.bar_lights
alias: Turn on lights to night mode over 10s

EDIT: I see from your profile you’re using SmartThings. I don’t know if defining transitions is supported there since I haven’t played with their new platform at all.

The new 800 series Red dimmer already does it that way unless you send both the level and transition time and then it takes the transition time to ramp to the level. It is way better than the fixed time method the older dimmers used.

I think this was also put into the new Blue dimmer firmware. If it isn’t, then the request would be to add it to the next firmware release.


I’m actually using hubitat now. I understand I can do this with manual commands, but that doesn’t affect situations where the bright ess level is manually adjusted. Plus for every switch and time you change brightness with any rule, you would have to manually calculate and adjust ramp rate at the same time. Having it done automatically would be better.

Ramp rate = programmed into switch firmware
Transition = set through your automation command.

For clarity here, you are not calculating or adjusting ramp rate at all. You simply use the transition command in your automations. And I know for certain Hubitat supports this.

So the way I do this, is I set the ramp rate that I desire when manually toggling the switch in the switch settings. For me I prefer as little ramp rate as possible when manually pressing the switch since that’s what everybody is used to. (instant on/off with dumb switches)

Then when using automations, that’s where transition comes into play. For me, I primarily use motion lighting so I want a transition of 0 (instant) when walking into the room because I don’t want that slow ramp up and people making it 4 or 5 steps in before they can see properly.

Then for my motion off, I use a much longer transition to off. Usually 10s so the light slowly fades off in the background.

For adaptive lighting that brightens and dims depending on time of day I also use long transitions here because I don’t want the effect to be visible to the eye as the lights slowly dim. I use 45s transitions for this one.

None of this changes the ramp rate that I set for manually controlling the switch. The transition command in the automation overrides it for that command only.

The newer models (Blue series and Red 800 series) do what you are asking. What model/firmware version are you testing it on?

This is from the release notes:

(1) when On/Off, duration =ramp rate * (target level -current level)/100.
For example, if the ramp rate is set to 3 seconds, that is the time it should take to get from 0 to 100%. So, if you are only going to 1% then the amount of time to get there should be 3seconds/100 * 1(%).

1 Like

I’m on Blue Series with 2.14 and it does not appear to work that way for me. When set to 100% or 10%, it still appears to take the same amount of time to reach that set level, and if set to 1%, there is a significant delay from pressing the button until turning on.

Is this a parameter? or it should just work that way by default?

1 Like

Checking in again, is this confirmed to be in the most recent Blue firmware? Mine is definitely not behaving that way. I can provide videos or logs, if necessary.

Sorry I spoke too soon. It’s not in the current released blue firmware but it is the intended behavior for blues and new reds (VZWXX but not LZWxx). Hopefully it makes it into the next blue firmware release