I have flashed a Tuya LED light bulb with ESPHome. Using original Tuya FW I can dim down to 1% without any problem but with ESPHome and the light/output/sm2135 components I can only dim to 20% until it turns of.
With gamma_correct at 1 it works like the original FW but 2.8 is default so I guess there’s a good reason for that
Any suggestions what I need to do to be able to dim the whole span from 0 to 1.
I have tried it but it doesn’t work as I expected (or more precise as I would like to work). If I set min_power to e.g. 0.2 it will never go beyond 20%, i.e. not even turn of.
Yes I can also add the zero_means_zero: true so that it will turn of when I decrease to 0%.
But having this configuration, dimming works as expected between 20 and 100% but between 1% and 20% the dimming effect will be stuck at it’s min value, i.e. a none linear behavior.
So what I’m looking for is a config that keeps the adjustment linear from the light component (0-100%) from the min level I define and the formula 0.2+x*0.8 will do that but I can’t see how I would be able to implement that
I think that I’m in a similar boat: LED strips, controlled via MOSFETs, that go completely dark at 5% or lower. Setting min_power to 0.05 got me… something much brighter than I wanted.
On a hunch, I divided min_power by 10. Hmm. Better, maybe, but still way too bright.
OK. Divide by 100? Bingo. Setting min_power to 0.0005 leads to a value of 1% in the UI producing an eminently reasonable minimum brightness. (100% still gets me maximum brightness. Yay!)
Searching the ESPHome source code on GitHub for min_power sheds, uh, some light on things. In particular, note how both max_power and min_power are multiplied by 100.0. The behavior looks to be deliberate, even though it’s not immediately obvious to me why the two extra orders of magnitude are used. But hey, I’m now getting the behavior I want, so I’m happy.
I’d be curious to know if this works for you, too.
Actually, on closer (read: slightly more awake) inspection, the code I pointed to seems to be specific to logging. In any case, expressing min_power as a percentage of a percentage solves, for me at least, the problem we were both having.
This way I get a linear adjustment the whole range as below with a minimum of 10%.
Yes… It’s the 1% value (not 0%) that shall match the min value of 10% since the dimmer only goes from 1% to 100%
But it would be better if the light component could have this built-in as I guess this is something that everyone would like to do.
And… The light component generates a none linear value so doing this with y=kx+m is probably not the best way but… I’t works quite good for now until some smart person implements min and max in the light component
Yes… Since some smart person have done the calibration between pwm value and lumens (or whatever), I could also see that 1% represents 0.0004 (0.04%), and 50% represents 0.14 (14%).
So it’s not as easy as checking at what value the led starts to light and then taking that value as the min value for the output component. Bin there, done that…
I’ve been wrestling with this same issue: I have a light that turns off below a certain PWM threshold (~5% PWM). With the default gamma correction, the light is off at brightness values below about 33%.
Put another way: you can set the output min_power: 0.04 but that leaves the UI light brightness ineffective below ~33% due to the gamma correction. i.e. any brightness of 1-33% makes no difference, the output’s going to be 0.04. It takes a brightness value above 33% to kick the output above 0.04.
It’s likely that the same thing happens at the other end of the scale - that the lamp hits full brightness at some PWM output less than 1.0 - but that’s less noticeable/objectionable. The solution below accommodates this, if needed (via max_power).
(aside: my lamp, an Arlec ELGD11HA Batten Light, behaves a little oddly in that it will dim down to about 3% duty cycle, but won’t start back up again; i.e. I have to set the minimum to 5% before it’ll reliably operate)
My goals are to:
have the light be adjustable over its full range of operation: a PWM output range of 0.05 to 1.0
have that range be presented in the UI as the full range 1-100%
have the mapping be gamma corrected so that incremental changes have the same visual impact no matter the absolute brightness level (i.e. 10-20% should look as much of a change as 80-90%)
I don’t see how you can do those three things in ESPHome “natively”. The gamma correction needs to target not a (0.0-1.0) range, but the output’s (min_power, max_power).
Based on @erapade’s approach above, the following config does achieve all three goals by remapping the light’s level to the output’s (min_power, max_power). The UI now is responsive across its entire range, and gamma corrected.
esphome:
name: arlec-elgd11ha
friendly_name: Arlec ELGD11HA Batten Light
# TYWE3L
esp8266:
board: esp01_1m
logger:
level: DEBUG
output:
- platform: esp8266_pwm
pin: GPIO5
id: pwm_out
# the lamp is off at a PWM below about .05
min_power: 0.04
zero_means_zero: true
# map output to range (min_power, max_power)
- platform: template
id: pwm_out_mapped
type: float
write_action:
- if:
condition:
lambda: return state > 0;
then:
- output.set_level:
id: pwm_out
level: !lambda |-
float min=id(pwm_out).get_min_power(), max=id(pwm_out).get_max_power();
ESP_LOGD("cal", "state: %.2f -> %.2f", state, state * (max - min) + min);
return state * (max - min) + min;
else: # "zero means zero"
- output.set_level:
id: pwm_out
level: 0
light:
- platform: monochromatic
output: pwm_out_mapped
#output: pwm_out
id: light1
name: Light
#gamma_correct: 1.0
