Use supported_color_modes to determine what UI elements to show

[bramkragten]

Proposed change

TODO: CLEANUP!

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

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

• Documentation added/updated for www.home-assistant.io

[spacegaier]

Related #7956 and the linked issues/discussions. What do we do with those points?

[thecode]

Hi @bramkragten with this change how will the frontend show the white brightness? will it use 0-255 or 0-100%?
IMO all sliders should be in the range 0-100%.

The bellow are just suggestions or for better understanding, not mandatory:

• Does the UI reflect the mode of the entity? (Color mode or Color temperature mode)?
• When a user click on COLOR or TEMPERATURE will it sends an event for this?

Currently Shelly integration has two modes of operation for color bulbs/devices:

• When you change something in the RGB color picker or the white brightness we sends a mode change command to the bulb to switch to color mode and sends the updated RGB/W values
• When you change the color temperature value we sends a mode change for the bulb to switch to white mode (in Shelly white mode is a mode when you control only color temperature and brightness, not to mix with color mode which has RGBW and brightness)

As far as I know Deconz integration works in a similar way.

I am going to make a PR to adjust Shelly to support this changes.

[spacegaier]

I had a similar thought a few days ago: For a Kelvin based temperature value (from cold to warm) currently I get a weird value shown on the slider. It is neither from 0...100% nor is it Kelvin (2600K to 6000K in my case as defined in the used integration).

Haven't investigated yet, but might be related to this PR.

[bramkragten]

I had a similar thought a few days ago: For a Kelvin based temperature value (from cold to warm) currently I get a weird value shown on the slider. It is neither from 0...100% nor is it Kelvin (2600K to 6000K in my case as defined in the used integration).

Haven't investigated yet, but might be related to this PR.

It is mired, what is used inside HA https://en.wikipedia.org/wiki/Mired

I personally would prefer Kelvin, as it is more widely used.

[bramkragten]

Hi @bramkragten with this change how will the frontend show the white brightness? will it use 0-255 or 0-100%?
IMO all sliders should be in the range 0-100%.

It currently is 0-225, but yeah I kinda agree.

The bellow are just suggestions or for better understanding, not mandatory:

• Does the UI reflect the mode of the entity? (Color mode or Color temperature mode)?

Yes

• When a user click on COLOR or TEMPERATURE will it sends an event for this?

If the user chooses a color or a color temperature, that will be sent to the backend.

Currently Shelly integration has two modes of operation for color bulbs/devices:

• When you change something in the RGB color picker or the white brightness we sends a mode change command to the bulb to switch to color mode and sends the updated RGB/W values
• When you change the color temperature value we sends a mode change for the bulb to switch to white mode (in Shelly white mode is a mode when you control only color temperature and brightness, not to mix with color mode which has RGBW and brightness)

This will stay the same.

As far as I know Deconz integration works in a similar way.

I am going to make a PR to adjust Shelly to support this changes.

👍

[balloob]

observer 😱