Yes, understood. It’s that cosmetic adjustment that I would like. That template looks like a good idea and the formula seems logical and correct. However, I just tried it out and with it, 1% is much brighter than the 4% without it. Just to clarify, state is either 0 if switched off or a value in [0.01, 1] corresponding to the brightness percentage in the UI?
If you set 1% on light component, it should give 0.03+0.0097 = 4% on ledc output.
Did you remove the min_power from your code?
Well, 0,0397 to be precise. But I agree, it should work.
Yes, I removed the min_power. Should I not have done that? Here’s the yaml for reference.
output:
- platform: ledc
pin: GPIO0
id: gpio_cw
- platform: ledc
pin: GPIO21
id: gpio_ww
- platform: template
id: cw_calibrated
type: float
write_action:
- if:
condition:
lambda: return state > 0;
then:
- output.set_level:
id: gpio_cw
level: !lambda |-
return 0.03 + 0.97 * state;
else:
- output.set_level:
id: gpio_cw
level: 0
- platform: template
id: ww_calibrated
type: float
write_action:
- if:
condition:
lambda: return state > 0;
then:
- output.set_level:
id: gpio_ww
level: !lambda |-
return 0.03 + 0.97 * state;
else:
- output.set_level:
id: gpio_ww
level: 0
light:
- platform: cwww
name: "Lampe"
cold_white: cw_calibrated
warm_white: ww_calibrated
cold_white_color_temperature: 6000 K
warm_white_color_temperature: 3000 K
constant_brightness: true
restore_mode: RESTORE_DEFAULT_OFF
Looks correct to me, don’t know what that constant brightness does though.
What are you getting on esphome log?
- constant_brightness (Optional, boolean): When enabled, this will keep the overall brightness of the cold and warm white channels constant by limiting the combined output to 100% of a single channel. This reduces the possible overall brightness but is necessary for some power supplies that are not able to run both channels at full brightness at once. Defaults to
false.
It should not cause an issue as I tested with single channel (only warm white).
It’s just reporting the values that I set on the UI, like so:
[12:53:56][D][light:036]: 'Lampe' Setting:
[12:53:56][D][light:051]: Brightness: 10%
[12:53:56][D][light:085]: Transition length: 1.0s
Esp32-c3, right?
Use some other Gpio (0-10), not 21.
Because it’s bad practice to use TX/RX or because it could actually have something to do with the issue? Will change it to 10 in the evening, but I think the issue is rather software related
Because it’s bad practice and especially because esphome documentation leaves room for doubts.
According to docs for C3 logger component is using USB-CDC port on arduino framework, but on same doc it’s telling that on C3 USB-CDC is not implemented. So at the end I have no idea if it’s logging to UART or something else.
Or I’m just not able to read the docs.
It’s not clear to me how it’s exactly behaving. Works like expected but brighter than it should?
Yes, with the template, 1% should equal 4% without the template. However, the 1% with template are much brighter than the 4% without it.
Alright, will fix that in the evening
But the brightness control is working and it gradually change the brightness from 0 to 100?
Without template, there’s a perfect gradient change, yes.
With the template, 1% corresponds to ~20% of the brightness without template.
With the template, from 1-20%, there’s no real change, above 20%, brightness is changing visibly - might also be hard to see as it’s bright day out at the moment. Can check that again in the evening.
Interesting.
Set your logger severity level to see what ledc component outputs.
I know that light brightness doesn’t have straight correlation with pwm duty cycle, but I didn’t expect that much difference.
So then you need to adjust the formula with testing other values like 0.01 + 0.99 * state
I have the following in my yaml:
logger:
That should mean DEBUG, right? With that, no ledc outputs are logged
so try:
logger:
level: VERBOSE # or VERY_VERBOSE
Alright, here are my findings:
-
without template:
- 100% = duty cycle 16383
- 5% = duty cycle 3
- 4% = duty cycle 2
- 3% = duty cycle 1
- 1-2% = duty cycle 0
-
with template:
- 1% = duty cycle 492
- 10% = duty cycle 518
- 20% = duty cycle 657
- 100% = duty cycle 16383
so, there is a gradient in both cases. It was just not very visible in the second case because of the high start value.
I don’t remember the resolution, maybe 12. What’s the max value at 100% ? 4096?
It’s 14 bit resolution. I added the 100% duty cycles above
That makes sense.
The relationship between brightness and duty cycle is far far from linear!
So the code should be 0.0001 + 0.9999 * state
Hopefully 4 decimals are accepted/considered here.
Ahh, after some looking around and trying to find the formula, I finally got it! It’s gamma scaling. Default value is gamma: 2.8.
Example:
3%: 0.03 ^ 2.8 * 16383 = 0.89 duty cycle
5%: 0.05 ^ 2.8 * 16383 = 3.7 duty cycle
20%: 0.2 ^ 2.8 * 16383 = 180.8 duty cycle
So, one would need to adjust the formula such that
f(x) = x ^ 2.8 with x being a combination of state and some other constants,
f(0.01) = 1, f(0.02) = 2, f(1) = 16383
I thought about adjusting gamma to e.g. 2, but that would give too low a resolution in the lower number areas. I think, 2.8 is actually a good value. I’m just trying to fit that function above 
Yep, don’t mess with gamma, it’s changing the whole range.
Did you try that 0.0001 + 0.9999 * state ?