Light component - fix output min_power headaches by adding a minimum brightness control to lights

[ojwc]

Describe the problem you have/What new integration you would like

Add light control parameters to all PWM light components (e.g., monochromatic, CCT, RGBWW etc.) to allow minimum and maximum brightness values to be set - in the light component itself, rather than relying on setting min_power in the output component.

A minimum_brightness parameter would tell the light component the lowest value to pass to the output component for a set/constant brightness. When transitioning to or from off, the light component would behave as it currently does. It would also continue to represent the lowest possible brightness setting in Home Assistant/web server as 1% - that is, the brightness range should be automatically recalculated. Users could find the 'correct' value for minimum_brightness by finding the lowest brightness setting (percentage) at which the light with default settings is consistently on without flickering, then set minimum_brightness to that value.

A visual example:

light:
    - platform: rgbww
      id: lightbulb_rgbww
      name: "Lightbulb"

      warm_white: output_warmwhite
      cold_white: output_white
      red: output_red
      green: output_green
      blue: output_blue

      cold_white_color_temperature: 6500 K
      warm_white_color_temperature: 3000 K

      minimum_brightness: 14%

Please describe your use case for this integration and alternatives you've tried:

I have many RGBWW lightbulbs flashed with ESPHome. Without setting min_power in each colour channel's output component, when brightness is set to ~14% or lower, the light simply turns off. If I set min_power (and accompanying zero_means_zero to ensure the light can turn off), the light will not turn off at low brightness values as before, but between 0% and 14% the brightness simply doesn't change. In addition to this, when toggling the light, setting min_power leads to the light transition 'stuttering' around the minimum value. When turning on, the light will instantly turn on to the minimum and then transition as expected. When turning off the reverse happens; it will transition down to the minimum value then instantly turn off. When min_power isn't used, the light transitions smoothly on and off, as expected. I suspect this occurs because min_power is telling the device that no PWM output value below the set value is permitted (or, with zero_means_zero set to true, no value between 0 and the set value is ever permitted), and the light components aren't aware of this and do not account for it.

A different but related issue (more of an undesired or clunky behaviour) is that in either case, the brightness range of the light is never truly represented. Ideally that range would be from 0% (off) to 100% (maximum brightness), with 1% representing minimum brightness. In my case the range is from 14% (off) to 100% (maximum), whether min_power is configured or not, and around 15% represents minimum brightness.

If a minimum brightness could be configured in the light component, the output components could be left with default parameters. The light component logic could manage transitions across the minimum value, to or from zero. This could also solve the scaling issue mentioned above.

Additional context

I've tried to tackle this issue many times before. There are some examples on reddit and the home assistant community forum of people successfully using template output components to apply lambda filters to PWM values, but I've found this approach to be needlessly difficult as well as inconsistent. Besides these few examples, there are many more of people trying to address undesired light behaviour and being unsatisfied with simply setting min_power on the output component.

Setting gamma_correct to 1 solves the issue completely (which is fine for monochromatic or CCT lights) but doing this breaks any RGB features - colours just end up not reflecting what is set by the user. It's possible to create separate RGB and CCT light components and then set gamme_correct to 1 for the CCT light, but the RGB light will continue to have the issues outlined above. Setting a global minimum_brightness value for a light component would be a more straightforward approach.

[bmarien]

+1

I've been looking for the exact same thing.