RGBWW Bulb is using RGB and CW/WW channels to reproduce color temperature instead of using only CW/WW.

[Seba-VT]

The problem

I flashed a bulb (https://kaufha.com/blf10/) with ESPHome using the RGBWW platform. The bulb works and is showing up on HA.

The issue is when I try to set the bulb to any temperature from an automation or node-red, it uses a mix of the RGB and the CW/WW LEDs to achieve the requested temperature instead of using only the CW/WW channels (see the video below).

https://user-images.githubusercontent.com/67033534/136714248-6a42b5d4-9722-4e3d-8075-194ad2557f6e.mp4

This causes an inaccurate color temperature produced by the bulb and an overheat of the hardware.

Now if I set the color_interlock to true, the color picker now shows the CT and COLOR mode (as shown in the next image). When the bulb is on CT or COLOR and transitions from one to another mode, the bulb gradually turns off and then turns on in the corresponding mode instead of smoothly transitioning between them.

The desired transition behavior is a smooth transition from, let's say, Orange light to Warm White. (I'm trying to make a wake up routine).

Which version of ESPHome has the issue?

2021.9.3

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2021.10.2

What platform are you using?

ESP8266

Board

No response

Component causing the issue

light:RGBWW

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[bkaufx]

ESPHome is pretty hard coded to have to go through the "off" state when transitioning between different color modes. I'm working on an update for that bulb with a forked ESPHome code base that will transition smoothly between RGB and CT without going through off. Once it's done I'll try to contribute it back to ESPHome if the devs are amenable. It may just be that no one has decided to tackle it yet since it's kind of a big change to the way lights work in ESPHome.

[Seba-VT]

@bkaufx

ESPHome is pretty hard coded to have to go through the "off" state when transitioning between different color modes. I'm working on an update for that bulb with a forked ESPHome code base that will transition smoothly between RGB and CT without going through off. Once it's done I'll try to contribute it back to ESPHome if the devs are amenable. It may just be that no one has decided to tackle it yet since it's kind of a big change to the way lights work in ESPHome.

That would be awesome! beside your website, where can I follow the progress of your work?

and Thank you for the contributions you have made to the community.

[bkaufx]

Probably youtube since that is the only place I have really posted updates so far. I'm going to try to do a blog on my website with RSS so that would be easier, and probably Twitter but I just haven't gotten around to it yet.

[oxan]

The issue is when I try to set the bulb to any temperature from an automation or node-red, it uses a mix of the RGB and the CW/WW LEDs to achieve the requested temperature instead of using only the CW/WW channels (see the video below).

Are you sure about that? What I think is happening is that it sets the requested color temperature using the CW/WW channels, but leaves the RGB lights alone on whatever it was before. Hard to say for sure without logs though. Can you try setting the color to off at the same time? (i.e. add "rgb_color":[0, 0, 0] or something like that to the action).

Now if I set the color_interlock to true, the color picker now shows the CT and COLOR mode (as shown in the next image). When the bulb is on CT or COLOR and transitions from one to another mode, the bulb gradually turns off and then turns on in the corresponding mode instead of smoothly transitioning between them.

Yes, this happens because one of the constraints of interlocked mode is that the RGB and CW/WW channels can never be on at the same time (there's hardware out there that doesn't support mixing them at all). I've seen some more requests like this, so I suppose we could accept an soft_interlock option or something like that.

[probot-esphome[bot]]

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

[bkaufx]

The reason that transitions go through off isn't because of color interlock. Transitions between color modes always go through off no matter what. The reason is because the light color values object will only return one type of value at any given time, and I think changing light color values to allow transitions between color modes would break a lot of other code so a careful review would be necessary. Maybe there's a better way to do it without breaking present functionality but I haven't thought of it. It looks like when the color modes were refactored or whatever, transformers.h was changed to go through off as an intermediate value instead of changing the way the light color values object works.

As for the first issue, I think we need to see some yaml for the config. It seems like ESPHome isn't adjusting the CW lights at all, and only changing RGB when color temp is set. Both cold white and warm white stay maxed in the video. The transition from warm to cold only modifies RGB and color brightness.

[bkaufx]

I guess in this case I am wrong about the transition since he's not changing color modes.

Edit: Even though in the video he isn't changing color modes, I think in his second example that we don't have a video of he might be.

[oxan]

The reason that transitions go through off isn't because of color interlock. Transitions between color modes always go through off no matter what. [..] It looks like when the color modes were refactored or whatever, transformers.h was changed to go through off as an intermediate value instead of changing the way the light color values object works.

I wrote the color mode code and that transformers.h change ;-)

The reasoning behind it was that color modes would be orthogonal, so when you transition between them, all the values of one would go to zero, and the values of the other would go from zero to a non-zero value. This could be done simultaneously, but to satisfy the pre-existing constraint that lights with color interlock enabled (which now are two different color modes) never output RGB and CW/WW together, that was not possible.

Note also that it's actually observable that transitions only go through off because of color interlock. If you disable color interlock on a RGBWW light, RGB_COLD_WARM_WHITE is the only supported color mode, and you'll never get transitions between color modes that go through off.

The reason is because the light color values object will only return one type of value at any given time

That's not true, LightColorValues (currently, this might change in the future) always holds all possible values. There's features (the color temp emulation for CW/WW lights) that actually rely on that.

I think changing light color values to allow transitions between color modes would break a lot of other code so a careful review would be necessary. Maybe there's a better way to do it without breaking present functionality but I haven't thought of it.

I guess (but I haven't thought too much about it) the proper way to implement this is by implementing another transformer, and using that as the default transformer (see LightOutput::create_default_transformer()) based on a soft_interlock/soft_transition/something like that option.

[Seba-VT]

@oxan, Thank you for your comments on this matter, and also Thank you for your contributions to the community. You have done an amazing job here.

Are you sure about that? What I think is happening is that it sets the requested color temperature using the CW/WW channels, but leaves the RGB lights alone on whatever it was before. Hard to say for sure without logs though. Can you try setting the color to off at the same time? (i.e. add "rgb_color":[0, 0, 0] or something like that to the action).

So I did another test with the following sequence:

And this are the logs from ESPHome for that sequence:

As you can see, ESPHome is setting the CW/WW channels to 100% when requesting "color_temp":370 or "color_temp":150 and using the RGB channels to reproduce the temperature. Even after requesting "rgb_color":[0, 0, 0]

I've seen similar behavior on RGBW lights where ESPHome mixes RGB colors with the white to reproduce different color temperatures. but in a RGBWW light this is not necessary since the CW/WW channels are for this purpose.

Yes, this happens because one of the constraints of interlocked mode is that the RGB and CW/WW channels can never be on at the same time (there's hardware out there that doesn't support mixing them at all). I've seen some more requests like this, so I suppose we could accept an soft_interlock option or something like that.

That would be fantastic. because even if some bulbs don't have the adequate hardware to have all channels turned on at the same time, during a transition this should never happen.

Note also that it's actually observable that transitions only go through off because of color interlock. If you disable color interlock on a RGBWW light, RGB_COLD_WARM_WHITE is the only supported color mode, and you'll never get transitions between color modes that go through off.

Correct, I noticed that. But here is when I discover that the RGB and CW/WW channels are being used at the same time to reproduce the temperature.

[bkaufx]

Interesting oxan, so in the default firmware RGBWW never changes color mode with interlock off so that is how you can transition from and to anything without going through off. Now I feel doubly like an idiot but thanks for the clarification. It's been so long since I've used the default light in ESPHome that I didn't catch that. I don't really like having four brightness sliders like in the video above so that is why I am partial to using separate RGB and CT color modes.

[bdr99]

I don't really like having four brightness sliders like in the video above so that is why I am partial to using separate RGB and CT color modes.

I agree. I use color_interlock not because my lights don't support RGB and white simultaneously, but rather because I prefer the separate RGB and color temperature controls over the color brightness, warm white brightness, and cold white brightness sliders.

[oxan]

As you can see, ESPHome is setting the CW/WW channels to 100% when requesting "color_temp":370 or "color_temp":150 and using the RGB channels to reproduce the temperature. Even after requesting "rgb_color":[0, 0, 0]

I've seen similar behavior on RGBW lights where ESPHome mixes RGB colors with the white to reproduce different color temperatures. but in a RGBWW light this is not necessary since the CW/WW channels are for this purpose.

Ah, I see now. It's not ESPHome that does this, but Home Assistant. See home-assistant/core#54216.

I don't really like having four brightness sliders like in the video above so that is why I am partial to using separate RGB and CT color modes.

You're not the only one. I personally also don't really understand the choices HA made here, but ESPHome can't do much about that. The color_interlock option wasn't made to give you a color temperature slider, so it's to be expected that it doesn't behave as you want when you use it for that.

[Seba-VT]

I also have WiZ bulbs and they control the RGB and CT just right, and they even transition smoothly between them. The only backdraw of those bulbs is the fact that you can't set a transition time.

So I don't know how they made to work with HA and not having the same issues as regular RGBWW lights.

[oxan]

Ah, I see now. It's not ESPHome that does this, but Home Assistant. See home-assistant/core#54216.

Since this is an issue in HA and there's nothing ESPHome can do about this, I'll close this issue now.