Add color modes for light entities

[emontnemery]

Suggestion

Add attribute SUPPORTED_COLOR_MODES to light component with the following options:

• none: The light can be turned on or off
  • State: The state is only on or off
  • Set: The light can only be turned on or off
• white or monochrome: The light is in a simple dimmer mode.
  • State: The state is represented by the light's brightness
  • Set: Brightness can be set
• CCT: The light's color temperature and brightness can be adjusted
  • State: The state is represented by the light's color temperature and brightness
  • Set: Color temperature and brightness can be set
• hs: The light's color and brightness can be adjusted
  • State: The state is represented by the light's color (in hs format) and brightness
  • Set: Color and brightness can be set
• xy: The light's color and brightness can be adjusted
  • State: The state is represented by the light's color (in xy format) and brightness
  • Set: Color and brightness can be set
• rgb: The light's color and brightness can be adjusted
  Note: The color is normalized and does not include brightness information
  • State: The state is represented by the light's color (in rgb format) and brightness
  • Set: Color and brightness can be set
• rgbw: The light's color and brightness can be adjusted
  Note: The color is normalized and does not include brightness information
  • State: The state is represented by the light's color (in rgbw format) and brightness
  • Set: Color and brightness can be set
• rgbww: The light's color and brightness can be adjusted
  Note: The color is normalized and does not include brightness information
  • State: The state is represented by the light's color (in rgbww format) and brightness
  • Set: Color and brightness can be set

As an alternative, make the rgbx modes non-normalized, i.e. include brightness information.

Deprecate these features:

SUPPORT_BRIGHTNESS = 1
SUPPORT_COLOR_TEMP = 2
SUPPORT_COLOR = 16
SUPPORT_WHITE_VALUE = 128

Do not convert colors to hs before storing the state.

Store the light's actual state to make sure the light's color is correctly reset when activating scenes etc.

Enforce state according to color mode

If the state update from the light is ambiguous, e.g. the light is in hs mode, but also reports a color temperature, the color temperature will be removed from the state.

Backwards compatibility

For lights without SUPPORTED_COLOR_MODES, SUPPORTED_COLOR_MODES will be calculated from the deprecated features.

[frenck]

I honestly think we should add color_mode to the light entity, and a device in which color mode an entity is in (either fixed or selectable) and integration should provide supported modes by the device.

For example, RGB, RGBW, RGBWW, HS, XY, CCT.

This would not only solve the above problem, we can also stop calculating everything from Home Assistants general color format (HS) and keep it closer to the color spectrum of the source device. Additionally, we can actually add proper support for color + white channels (instead of calculating it from an HS->RGB-> simulated RGBW value)

I've been playing/thinking about this a couple of times now, since I have the same issue with WLED. WLED can support multiple types of LED strips, which Home Assistant can't support at this point. And resulting in these horrible constructs right now:

https://github.com/home-assistant/core/blob/c8ffac20b9b717b704c3c8a9d80e6fdc6b088a22/homeassistant/components/wled/light.py#L318-L337

[Koenkk]

+1 for the color_mode. I also believe this will make life easier on the integration side (at least for Zigbee2MQTT). This is similar how the Zigbee ZCL spec handles this.

[sjorge]

color_mode on the zigbee side changes base on what is the bulbs active mode.

If you set it via color_temp, color_mode returned by the bulb will indicate the mode is ct, if you then use a remote (e.g. tiny with color wheel) the color_mode will change to xy as that is now what the bulb is using. If you later set it using color: {hue: 120, saturation:100} color_mode will change when read to indicate hs is being used.

I have a branch somewhere that allows a getter for color_mode, I was using it to ignore either the returned color_temp or color.{x,y} or color.{hue,saturation}

Which was working pretty well for my case. It doesn’t solve the a set payload with both color_temp and color payloads though.

As the zigbee property is read only.

I’ll dig up the branch later tonight.

[rytilahti]

👍 for adding an indicator for active color mode with my retired yeelight&tplink integration maintainer hat on. This will not only relieve individual integration developers to add conversion boilerplate, but also avoids creating bugs/minor annoyances caused by inadvertently exposing multiple different types of values.

Example, yeelight was showing wrong frontend information due to this at some point, bulb being in one mode but the UI taking the hue for the icon from another, and I think I have seen some cases where users have done automations based on converted values causing unwanted results. Explicit > implicit.

[sjorge]

Koenkk/zigbee-herdsman-converters#2283 is open, works best with reporting for colorMode configured. But with that PR we can read it manually with /get too.

That is what I already had, a follow up PR could be to have the toZigbee convert also opportunistically set it.
e.g. write to the colorTemperature attribute, set color_mode=ct in the result, ...

[emontnemery]

color_mode is added to light in home-assistant/core#47720

[frenck]

As per comment above by @emontnemery:

color_mode is added to light in home-assistant/core#47720

[iMicknl]

Will color_mode and other changes be added to https://developers.home-assistant.io/docs/core/entity/light as well? I am not sure if I am looking in the wrong place..

[emontnemery]

Oops, that has been forgotten. Thanks for mentioning it 👍

[iMicknl]

@emontnemery no worries, I was looking to add the new color_modes support to a new integration, but was a bit struggling finding examples :-).

[townsmcp]

@frenck sorry to comment on an old thread, but I have been playing around with LIFX bulbs that I have added to HA via HomeKit Controller. When I perform a debug on an A19 light in NodeRed, the “supported_color_modes” only shows hs as an option (I’m guessing the other modes shown are a conversion of hue/saturation?).
I know I can use the official LIFX integration (which I was doing), however as the bulbs added in Homekit Controller support push rather than poll the performance difference is night and day so I have deleted the LIFX integration for the bulbs rather than having 2 entities for the same device in HA.

Will colour mode be added for HomeKit Controller? Or am I misreading the situation?

[Djelibeybi]

LIFX bulbs that support color only present color mode to HomeKit as per the requirements of the original HomeKit Accessory Protocol specification. Though, LIFX appears to be the only manufacturer that followed this specification, because everyone else just ignores it and presents both. I suspect this would have to be manually overridden by Home Assistant such that it presents both color modes for LIFX devices regardless of what the device actually states.

[icemanch]

I'm not sure if I should add a new topic or just comment on this one.

Why is the brightness information removed from RGB?

I'm asking because in RGB mode the front end offers a color selector and brightness slider. If the slider is moved it sends the change in brightness which can then be used by the integration to adjust the light. If an RGB is selected then it sends the normalized RGB data. The integration can use that in conjunction with the current brightness to set the light correctly.

Everything is fine but, this is where things get weird. At least to me.

The integration can send back brightness and it will show correctly on the slider. The integration can also send back a non-normalized RGB which will change the slider on the brightness (I didn't test to see if its' correct but, I think it is. I'll double check next time I'm testing). If you send BOTH the brightness and the non-normalized RGB it will move the slider to what I'm assuming is the brightness of the RGB scaled further down by the brightness level.

It seems like it would be better for the RGB to send a non-normalized and receive a non-normalized. Or, when a non-normalized RGB is sent from the integration convert it into a normalized RGB and depend on the brightness to dictate the slider lever.

As a side note, what is the purpose of having "supported color modes" and "color modes" The light can only be in one color mode so what is the need for the list? Also, if its RGBWW then it can be assumed that it can handle COLOR_TEMP, COLOR_RGB, COLOR_RGBW, and COLOR_RGBWW. It's all inherited unless I'm looking at it from the wrong point of view.

[emontnemery]

@icemanch

It seems like it would be better for the RGB to send a non-normalized and receive a non-normalized.

Home Assistant itself can both send and receive non-normalized colors. However, when color is changed from the frontend it will always send a normalized color.
Can you give some examples on how you propose that it should work instead, for example a sequence of user actions, service calls, state updates and UI updates?

what is the purpose of having "supported color modes"

The purposes are:

• Make it possible to translate a service call according to what the light supports
• Make it possible to show UI control to make it possible to switch between color modes, for example to switch between color and white with adjustable color temperature

[icemanch]

Home Assistant itself can both send and receive non-normalized colors. However, when color is changed from the frontend it will always send a normalized color.

But it doesn't, unless I'm missing something or implementing the code incorrectly. I've double checked it three times now just to make sure.

There may be a bit of confusion on my part. Perhaps the current code has a bug.

The proposal above states that all three RGB modes are normalized. However, the documentation on the Light Entity for the color_modes states that they are not normalized. To add even more to the confusion the below statement is below the Color_modes table which suggests that it's normalized.

If the light is in mode COLOR_MODE_HS, COLOR_MODE_RGB or COLOR_MODE_XY, the light's state attribute will contain the light's color expressed in hs, rgb and xy color format. Note that information is lost when the light is in mode COLOR_MODE_RGB as hs and xy don't hold brightness information.

I guess I'm just looking for consistency. Either all three modes send data non-normalized or they send it normalized. It might be easier to send it non-normalized and let the integration decide what to do with it. In my case I can pass the values directly to the API for the bulb without any further work other then calculating the new brightness and storing it.

Further thought about. At low brightness levels the color information get's lost. It's better to send normalized and let the integration figure out how to deal with the data loss

Being able to decide to send back normalized or non-normalized really seems like the best way which is how it's currently implemented.

For clarity DEV currently works as outlined below:

Color_Mode_RGB -> Normalized RGB values out
Color_Mode_RGBW -> Non-Normalized RGB values out
Color_Mode_RGBWW -> Non-Normalized RGB values out

Is this unintentional and actually a bug?

[emontnemery]

The proposal above states that all three RGB modes are normalized. However, the documentation on the Light Entity for the color_modes states that they are not normalized.

We need to separate between what the frontend sends (normalized RGB) and how the light entity should interpret the colors (non normalized RGB).

To add even more to the confusion the below statement is below the Color_modes table which suggests that it's normalized.

Which table do you refer to?

Either all three modes send data non-normalized or they send it normalized.

Unlike RGB, HS and XY pairs don't hold any brightness information, it's just a color. Hence, this is not possible.
As explained in the documentation the light's state is defined by the brightness and RGB properties, hs and xy are there as a convenience.

Further thought about. At low brightness levels the color information get's lost.

Right, this is why RGB is combined with a master brightness.

For clarity DEV currently works as outlined below:
Color_Mode_RGB -> Normalized RGB values out
Color_Mode_RGBW -> Non-Normalized RGB values out
Color_Mode_RGBWW -> Non-Normalized RGB values out

What's DEV, are you referring to the frontend?

It's a bit hard to follow exactly what your concern is, can you give some concrete examples on how you propose that it should work instead, for example a sequence of user actions, service calls, state updates and UI updates?

[icemanch]

Sorry, I'm not trying to be hard to follow. We're definitely not syncing up.

Let me start over just a bit. I am working on an integration. When I refer to the data in and out I'm talking about the attributes and properties that the integration interfaces with.

Here is the link to the documentation on the Light Entity that I was referring to.

https://developers.home-assistant.io/docs/core/entity/light/

The color modes table in the above link is defining how the data flows for the modes Color_Mode_RGB, Color_Mode_RGBW, and Color_Mode_RGBWW. It states they are non-normalized. However, below that table is a statement specifically for the Color_Mode_RGB in which it states that data is lost in the RGB, HS, and XY. This seems conflicting as it is true for HS and HY, but the table specifically states that it's not lost when in RGB.

My comment about making them all consistent was in reference to RGB, RGBW, and RGBWW. Not HS and XY since, as you explained, it's not possible for them to have brightness included.

In regards to where I'm seeing the conflicting data. I am working with https://github.com/home-assistant/core . I have not checked to see if the same behavior is in the released Home Assistant. The integration I am working on currently receives data in the below forms from Home Assistant.

Color_Mode_RGB -> Normalized RGB values out
Color_Mode_RGBW -> Non-Normalized RGB values out
Color_Mode_RGBWW -> Non-Normalized RGB values out

Here is where I'm seeing the conflicting information.

Color Mode	Proposal	Documentation	How it's currently working
Color_Mode_RGB	Normalized	Not Normalized	Normalized
Color_Mode_RGBW	Normalized	Not Normalized	Not Normalized
Color_Mode_RGBWW	Normalized	Not Normalized	Not Normalized

The proposal I'm referencing is #519 (comment)
The Documentation I'm referencing is https://developers.home-assistant.io/docs/core/entity/light/
The system I'm currently working in and seeing the behavior is https://github.com/home-assistant/core

The Question I'm asking is now two parts:

1. Is the way it's currently working a bug?
2. If it's not a bug can all three be changed to have consistent values either Normalized, or Non-Normalized? I think the preference after thinking about it would be Normalized since you lose color information otherwise when dimming to low values.

[emontnemery]

below that table is a statement specifically for the Color_Mode_RGB in which it states that data is lost in the RGB, HS, and XY. This seems conflicting as it is true for HS and HY, but the table specifically states that it's not lost when in RGB.

OK, now I get it, thanks for the patience. What we try to convey is that the hs and xy representations of the RGB color do not have the full information of the RGB tuple. As an example, RGB = (255,0,0) and RGB = (1,0,0) will both be represented as hs = (0,100).

Can you suggest a clearer way to explain it? Maybe something like:

Note that when the light is in mode COLOR_MODE_RGB, the hs and xy properties only hold the color, not the brightness of the RGB tuple.

I'm still unsure what you mean when you say:

Color_Mode_RGB -> Normalized RGB values out

Is your concern that the frontend will always send normalized RGB values, for example, if the light is currently in state: `{"brightness": 100, "rgb_color": (128,0,0)}"
If the user picks a new color in the frontend's color picker, the frontend will now send a normalized color, is this behavior your concern?

[icemanch]

OK, now I get it, thanks for the patience.

No thank you for taking time to look at this. I'm not always the best at explaining things.

What we try to convey is that the hs and xy representations of the RGB color do not have the full information of the RGB tuple. As an example, RGB = (255,0,0) and RGB = (1,0,0) will both be represented as hs = (0,100).

Can you suggest a clearer way to explain it? Maybe something like:

Note that when the light is in mode COLOR_MODE_RGB, the hs and xy properties only hold the color, not the brightness of the RGB tuple.

Well... that depends on what the actual behavior is supposed to be. If the COLOR_MODE_RGB is working as intended then You could just delete the statement and fix the description of COLOR_MODE_RGB to the below.

The light can be dimmed and its color can be adjusted. The light's brightness can be set using the brightness parameter and read through the brightness property. The light's color and brightness can be set using the rgb_color parameter. The lights normalized color can be read through the rgb_color parameter. *rgb_color parameter is normalized

I'm still unsure what you mean when you say:

Color_Mode_RGB -> Normalized RGB values out

Is your concern that the frontend will always send normalized RGB values, for example, if the light is currently in state: `{"brightness": 100, "rgb_color": (128,0,0)}"
If the user picks a new color in the frontend's color picker, the frontend will now send a normalized color, is this behavior your concern?

Very close. My concern is that it currently DOES NOT always send a normalized RGB.

USER CHANGES BRIGHTNESS COLOR_MODE = COLOR_RGB
Current State = {"brightness": 100, "rgb_color": (255,0,0)},
User Change = {"brightness": **50**, "rgb_color": (255,0,0)},
Data sent to Integration = {"brightness": 50}

USER CHANGES COLOR PICKER COLOR_MODE = COLOR_RGB
Current State = {"brightness": 50, "rgb_color": (255,0,0)},
User Change = {"brightness": 50, "rgb_color": (255,**30**,0)}
Data sent to Integration= {"rgb_color": (255,30,0)} <--- This is normalized and does not include brightness information.

USER CHANGES BRIGHTNESS COLOR_MODE = COLOR_RGBW
Current State = {"brightness": 100, "rgbw_color": (255,0,0,50)}
User Change = {"brightness": **50**, "rgbw_color": (255,0,0,50)}
Data sent to Integration = {"brightness": 50}

USER CHANGES COLOR PICKER COLOR_MODE = COLOR_RGBW
Current State = {"brightness": 50, "rgb_color": (255,0,0,20)}
User Change = {"brightness": 50, "rgb_color": (255,**30**,0,20)}
Data sent to Integration= {"rgbw_color": (128,15,128,50)} <--- This is not normalized and includes brightness information in the RGB colors.

The problem I'm trying to highlight is that your proposal (that was implemented) states the RGB data will be normalized and loose the brightness information in all three color modes. However, the documentation says the opposite. Further the actual implementation matches the documentation except for COLOR_MODE_RGB which matches your proposal instead.

My original question was. Is the behavior in the RGBW and RGBWW modes unintentional and should it match the behavior of RGB.

[emontnemery]

the RGB data will be normalized and loose the brightness information in all three color modes.

This is absolutely not the case, if color_mode is rgb, the brightness information of the RGB tuple is retained.
As I explained, what the documentation is trying to convey is that the hs and xy representations of the rgb color only contain the color information, not the brightness.

Please note that in color modes rgb, rgbw and rgbww the state is define by the color tuple AND the brightness.
It means these states are equal: {"brightness": 50, "rgb_color": (255,0,0,20)} == {"brightness": 100, "rgb_color": (128,0,0,10)}

In the RGB example:

USER CHANGES COLOR PICKER COLOR_MODE = COLOR_RGB
Current State = {"brightness": 50, "rgb_color": (255,0,0)},
User Change = {"brightness": 50, "rgb_color": (255,30,0)}
Data sent to Integration= {"rgb_color": (255,30,0)} <--- This is normalized and does not include brightness information.

Why do you say the data sent to integration is normalized? The user change (255,30,0) is already at full brightness so the value before and after normalization would be the same.

In the RGBW example:

USER CHANGES COLOR PICKER COLOR_MODE = COLOR_RGBW
Current State = {"brightness": 50, "rgb_color": (255,0,0,20)}
User Change = {"brightness": 50, "rgb_color": (255,30,0,20)}
Data sent to Integration= {"rgbw_color": (128,15,128,50)} <--- This is not normalized and includes brightness information in the RGB colors.

This looks very strange, can you double check please, you're mixing "rgb_color" and "rgbw_color"?

Also, let me ask again: Are you talking about the behavior of the frontend (the Web UI) or are you talking about service calls?

[icemanch]

Why do you say the data sent to integration is normalized? The user change (255,30,0) is already at full brightness so the value before and after normalization would be the same.

The brightness is 50 or 19.6%. The RGB is normalized because it does not have brightness taken into account. The physical light would have an output of color light with an RGB value of {128, 15, 0} which is equal to {255,30,0} at 19.6% brightness.

This looks very strange, can you double check please, you're mixing "rgb_color" and "rgbw_color"?

Yes, I can double check and I've included images from the debugger below to hopefully make it clear. No, I am not mixing colors. The controller can be put into various color_modes including RGB, RGBW, and RGBWW.

Also, let me ask again: Are you talking about the behavior of the frontend (the Web UI) or are you talking about service calls?

Maybe we're talking two different things. I'm referring to what the light entity is sending to integrations. Now, if that's something wrong with the front end or the entity I don't know. I didn't dig into the light entity code to see if I could find it.

This is the starting image. Nothing has been sent to the integration yet.

Here, I moved to a different color. You can see that I'm getting RGBWW sent to the integrations with non-normalized values for the RGB channels. R = 49, G = 35 , B = 92. If this were normalized it would be R = 136, G = 97, B = 255.

Now I've switched the physical controller to RGB mode. This is the starting point nothing has been sent to the integration yet.

Now, I've moved the slider. This is what I get back from the integration. The RGB channels are normalized R=175, G=96, B=255. I did not move the brightness so It is still at 36.1%. If the RGB was not normalized it would have the value of R=63, G=35, B=92.

[thecode]

@icemanch what @emontnemery means is: Try to do the same test using a service call and not from the frontend:

This will help understanding if there is an issue with the frontend or the light entity

[icemanch]

Oh I see.

RGBWW

RGB

So if you use a service call they both get sent as non-normalized.

[emontnemery]

Thanks @thecode 👍

@icemanch It was really helpful with the screenshots, thanks again for your patience.

I think I understand the problem now:
The problem is that when the user changes color of an RGB light from the frontend, the frontend will send a normalized color. This has the effect of changing the light's brightness if the light's previous color was not normalized.
The frontend needs to either a) send a non-normalized color, or b) also send an updated brightness together with the color to compensate.
Is it right?

You write:

Now I've switched the physical controller to RGB mode. This is the starting point nothing has been sent to the integration yet.

At this point, what is the light's state?
You can check it in developer tools -> state?

[icemanch]

I think I understand the problem now:
The problem is that when the user changes color of an RGB light from the frontend, the frontend will send a normalized color. This has the effect of changing the light's brightness if the light's previous color was not normalized.
The frontend needs to either a) send a non-normalized color, or b) also send an updated brightness together with the color to compensate.
Is it right?

Yes. I think non-normalized is the preferred to avoid losing color information.

I didn't realize that the form of the data had to be determined by the front end. I assumed that the frontend just reported how things were moved/changed and then the entity determined the "shape" of the data.

At this point, what is the light's state?
You can check it in developer tools -> state?

Below is the state but, this is determined by what the integration sends back. It's what made me realize there was even an issue. If I send back a non-normalized number it adjusts the brightness.

Here is what it looks like when I have not changed anything.

And here is what happens if I change my integration to send a non-normalized instead of a normalized. My integration is calculating a brightness and sending that back along with a non-normalized color. The frontend combines the brightness from the RGB and the brightness I send back. The bar should be at 79% but, it's actually sitting at 63%.

[emontnemery]

Yes. I think non-normalized is the preferred to avoid losing color information.

No, it's precisely the opposite.
If the light is set to an RGB color with extremely low brightness, lets's say rgb = (1,0,0), that would mean there would be very poor precision if the user selects another colour and the relative brightness of the old colour was retained.

My integration is calculating a brightness and sending that back along with a non-normalized color. The frontend combines the brightness from the RGB and the brightness I send back. The bar should be at 79% but, it's actually sitting at 63%.

No, this is a misunderstanding on your side. The light's brightness property is the master brightness, and the color also holds brightness information. Hence, the overall brightness is: 202/255 * (max(202,61,92)/255 = 0.63, and this is what's displayed in the frontend.

This is explained in the documentation:

Note that in color modes COLOR_MODE_RGB, COLOR_MODE_RGBW and COLOR_MODE_RGBWW there is brightness information both in the light's brightness property and in the color.

PR on the documentation to make it clearer: home-assistant/developers.home-assistant#960

If your underlying light hardware does not support both setting an RGB color and a master brightness, you need to manage that in the integration.

[icemanch]

Yes. I think non-normalized is the preferred to avoid losing color information.

No, it's precisely the opposite.
If the light is set to an RGB color with extremely low brightness, lets's say rgb = (1,0,0), that would mean there would be very poor precision if the user selects another color and the relative brightness of the old color was retained.

I said one thing out loud and typed something completely different. The normalized would be the best to send back to avoid color loss. That's how most UIs work for color bulbs. You should be able to select a color, dim the bulb to the lowest and then un-dim the light to the brightest and have the same color as the beginning. Sending the non-normalized would mean that you could end up with a different color when you when from the lowest brightness to the highest.

My integration is calculating a brightness and sending that back along with a non-normalized color. The frontend combines the brightness from the RGB and the brightness I send back. The bar should be at 79% but, it's actually sitting at 63%.

No, this is a misunderstanding on your side. The light's brightness property is the master brightness, and the color also holds brightness information. Hence, the overall brightness is: 202/255 * (max(202,61,92)/255 = 0.63, and this is what's displayed in the frontend.

I understand it now. It just seems weird when you're only looking at the RGB mode because there is no "color brightness" in the front end for RGB only. It also explains why the front end is sending a normalized RGB value. It's because there isn't a way to adjust it since only the master brightness is available.

Does a proposal need to be made to split out the brightness from all RGB values and only send normalized? That way color information can be maintained and the integration can handle dimming and scale based on a new brightness value called "color brightness" ?

[emontnemery]

I said one thing out loud and typed something completely different. The normalized would be the best to send back to avoid color loss. That's how most UIs work for color bulbs. You should be able to select a color, dim the bulb to the lowest and then un-dim the light to the brightest and have the same color as the beginning. Sending the non-normalized would mean that you could end up with a different color when you when from the lowest brightness to the highest.

Exactly, and this is why the frontend always sends a normalized color.

I understand it now. It just seems weird when you're only looking at the RGB mode because there is no "color brightness" in the front end for RGB only. It also explains why the front end is sending a normalized RGB value. It's because there isn't a way to adjust it since only the master brightness is available.

Yes, that's right!

Does a proposal need to be made to split out the brightness from all RGB values and only send normalized? That way color information can be maintained and the integration can handle dimming and scale based on a new brightness value called "color brightness" ?

I don't see the benefit of such a change, can you explain the use case?

[icemanch]

I don't see the benefit of such a change, can you explain the use case?

Unless I'm implementing something incorrectly it goes back to the first statement. I'll outline by color mode to hopefully illustrate what I was thinking.

COLOR_MODE_RGB
No benefit I don't recommend any change. The RGB value sent is sent as normalized because there's no way to adjust just the color brightness since only the master slider is available. The ability to maintain the users color selection is easily implemented.

COLOR_MODE_RGBW
Right now you can change the color brightness, white level, and the overall brightness. These are sent to the integration in the below attributes (actual names might be wrong but, you should get the idea) below.

Brightness: This is tied to the master brightness slider.
RGBW: This is tied to the color selector, color brightness, and the white level.

If you change the brightness the integration receives just a number for the brightness level that the integration can then implement however the programmer wants to.

If you change the white level the integration receives the RGBW with the W changed to the new white level. Integration can typically pass this directly to the API if the programmer chooses to.

If you change the color brightness level or the color selection the integration receives the RGBW with the RGB values scaled to the new brightness. This typically can be passed directly to the API. However, unless the programmer implements methods to store the normalized RGB value and only change it when there is an actual change in the color selection (which is not always detectable) the color information can get lost when going to extreme dim and then back to full brightness. There really is no easy way to keep track of the users RGB selection because you can't always tell if the change came from the Color Brightness slider or the RGB selection in the color wheel.

It would be better to send a normalized RGB value, and a Color_Brightness. This way the integration has much more control over how the control of the light is implemented. Some potential options on implementation would be

1. Prioritizing color accuracy and limiting the dimming range
2. Scale for brightness, send to the light and disregard any color loss.
3. Scale the RGB values in away that keeps the ratio accurate and prevents one of the channels from going to 0 just because of the dimming level. This actually gives you somewhat the best of both worlds. Color will seem more accurate through the dimming range even those essentially everything is always dimming to (0,0,0) but nothing changes to 0 until they all change to 0.

Here is a color slider between HSV and RGB to maybe help explain. I'm not sure how everyone does it but, to calculate brightness I'm typically converting to HSV and then taking the V as the brightness. There are better way and I'm looking into them but, I think this is the common method.

https://www.peko-step.com/en/tool/hsvrgb_en.html

Enter in RGB=(255,182,104)
This converts to HSV=(30,59,100)
I store 100% as the Color_Brightness and then send the light the RGB value (255,182,104)

Now if the user dims to 1% we change the V to 1.
HSV = (30,59,1)
This converts to RGB = (2,1,1)
I store brightness as 1% and send the light the RGB values (2,1,1)

The next time I poll the light I get back that it's set to (2,1,1).

Refresh the web page I sent and then type in (2,1,1) as the RGB.

If the user changes the brightness to 100% you'll end up with an RGB value of (255,127,127) which is not the original color.

I'm sure you know this I'm just going through to make sure I've highlighted the issue. And, again I may be missing something in how I'm writing my integration. I just don't see an easy way to determine the original selection of the user with any accuracy. Especially if the user is making a color selection when the light is dimmed.