Fix issue when setting cw/ww brightness via temperature

[patagonaa]

What does this implement/fix?

This fixes an issue when CW/WW lights are used via Home Assistant, after both CW and WW values have been set below 1 (which can happen with the random effect as that does call.set_publish(true); for some reason.

More details in the linked issue.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Related issue or feature (if applicable): fixes esphome/issues#5241

Pull request in esphome-docs with documentation (if applicable): -

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040
• BK72xx
• RTL87xx

Example entry for config.yaml:

output:
  - platform: template
    id: output_cw
    type: float
    write_action:
      - logger.log:
              format: "CW: %.1f"
              args: [ 'state' ]
  - platform: template
    id: output_ww
    type: float
    write_action:
      - logger.log:
              format: "WW: %.1f"
              args: [ 'state' ]

light:
  - platform: cwww
    name: "Test"
    cold_white: output_cw
    warm_white: output_ww
    cold_white_color_temperature: 6536 K
    warm_white_color_temperature: 2000 K
    default_transition_length: 0s
    gamma_correct: 1
    effects:
      - random:
          transition_length: 0s

After enabling and disabling the random effect once, it can be seen that there is no way (via Home Assistant) to go back to full brightness (before this PR).

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder). (there are currently no tests for the light component as far as I can tell)

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in esphome-docs.

[probot-esphome]

Hey there @esphome/core, mind taking a look at this pull request as it has been labeled with an integration (light) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[jesserockz]

Let me get this straight, you want to add new code to support an older HA version?

If you are happy to run an old HA version, why not just run an old ESPHome version to match?

[patagonaa]

Let me get this straight, you want to add new code to support an older HA version?

No, the code to support this old version is already there (and I'd be happy to remove this as it adds a bunch of additional complexity).

Currently (no matter the HA version), switching to the random effect on a CW/WW light and switching back causes the max brightness to be capped at the last value that was set by the effect.
This partly happens because the white value (which is never set in current HA versions) is calculated from the max of CW/WW (which should always be 1), and the random effect uses call.set_publish(true); (which is also not correct, in my opinion), which causes both CW/WW and color temperature to be in remote_values.

Ideally, when switching off the effect, the last color temperature would also be applied, however that isn't as simple as it may sound and also wouldn't be necessary if the random effect didn't overwrite the remote_values.

Example (can be reproduced with my yaml snippet):

• Light is set to brightness 100% and center color temperature
  • -> CW: 1.0, WW: 1.0
• Set effect to random
  • random values are not only set, but also published as remote_values
  • -> CW: 0.2, WW: 0.5
• Set effect to None
  • -> CW: 0.2, WW: 0.5
• Set color Temperature back to center (LightCall::transform_parameters_() uses max(CW, WW) as white value)
  • -> CW: 0.5, WW: 0.5
• now there is no way from HA to get back to full brightness, as the white value is never set in current HA versions and it's instead calculated from the current max CW/WW value (which will never be above 0.5)

[kbx81]

I just tested this with a CW/WW bulb I have and confirmed the original problem's existence (HA 2024.4.3 with current ESPHome dev) ; this PR resolves the issue.