Lights' color-temperature slider indicates brightness rather than color temperature when idle

[hivehand]

Checklist

• I have updated to the latest available Home Assistant version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.

Describe the issue you are experiencing

When I select a light entity that supports different color temperatures, and select the color-temperature control from the appearing popup, I am presented with a slider that allows me to control the color temperature. However, the value displayed above the slider itself is the brightness percentage rather than the current color temperature, i.e. "50%" rather than "4,003 K" . (Please see the attached image for an example.) The color temperature is displayed while I click/tap and hold the slider, but that display reverts to brightness percentage the moment I release the control.

I see this behavior on Mac Safari, Mac Chrome, and the Home Assistant iOS app.

Describe the behavior you expected

I expect to be shown the current color temperature when in color-temperature control mode.

Steps to reproduce the issue

1. Select, from the UI Overview, a lighting entity that supports variable color temperature.
2. From the ensuing pop-up, click/tap the rightmost member of the upper row of buttons to select color-temperature control.
3. Observe that the text field near the top of the pop-up shows a brightness percentage rather than the color temperature.

What version of Home Assistant Core has the issue?

2023.9.0

What was the last working version of Home Assistant Core?

2023.8

In which browser are you experiencing the issue with?

Apple Safari Version 16.6 (18615.3.12.11.2), Google Chrome Version 116.0.5845.179 (Official Build) (arm64)

Which operating system are you using to run this browser?

macOS Ventura Version 13.5.2 (22G91)

State of relevant entities

State:
on

Attributes:
min_color_temp_kelvin: 2202
max_color_temp_kelvin: 6535
min_mireds: 153
max_mireds: 454
supported_color_modes: color_temp
color_mode: color_temp
brightness: 128
color_temp_kelvin: 4016
color_temp: 249
hs_color: 26.805, 34.581
rgb_color: 255, 206, 166
xy_color: 0.42, 0.365
mode: normal
dynamics: none
icon: mdi:dome-light
friendly_name: Center
supported_features: 40

Problem-relevant frontend configuration

type: entities
entities:
  - entity: light.office_led_strips
  - entity: light.desktop_led_strip
  - entity: light.workbench_led_strip
  - entity: light.office_center
  - entity: light.hexagoon
title: Office
footer:
  type: buttons
  entities:
    - entity: scene.office_morning
      show_icon: true
      show_name: true
      name: Morning
    - entity: scene.office_daylight
      show_icon: true
      show_name: true
      name: Daylight
    - entity: scene.office_evening
      show_icon: true
      show_name: true
      name: Evening
    - entity: scene.office_chillout
      show_icon: true
      show_name: true
      name: Chillout
state_color: true
show_header_toggle: true

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

[spacegaier]

@matthiasdebaat Was this done on purpose from a UX perspective that always the brightness is shown, even when in color temp or color wheel mode?

I lean towards OP that this is weird because there is no easy way to see the current temperature value despite being in the mode/view.

[Mariusthvdb]

thanks for pinging me in the thread Philip!

yes agree, it is unexpected to see brightness as state when the color-temp mode is selected. as I posted in the release topic in the community.

Had not spotted this issue before that, sorry.
now +1'ed it ;-)

[matthiasdebaat]

@matthiasdebaat Was this done on purpose from a UX perspective that always the brightness is shown, even when in color temp or color wheel mode?

Yes, for a number of reasons:

• The dialogs layout pattern we created has the prominent value at the top. This keeps it consistent.
• The version before the redesign also showed Kelvin on drag. We didn't want to hide Kelvin, because Home Assistant has users that want a more advanced UI.
• Kelvin isn't a daily used number for most of the people, the brightness percentage is more common.
• The color selector and temp slider help you guide what you see in real life.
• If we always show Kelvin at color temp, we must also do so on the color wheel. But what numbers? And what does that tell you?

Hope this answers your questions. I'm closing this issue.

[Mariusthvdb]

The dialogs layout pattern we created has the prominent value at the top.

on a dedicated page for the color-temp, brightness is Not the prominent value. not disagreeing the move to Kelvin was unfortunate (since as you say it isnt a daily used number compared to what we had before...) but showing a fixed brightness on the color_temp view is downright confusing to say the least.

so no, this doesnt answer the questions raised, and I sincerely hope you will reconsider, its a bad experience having to keep touching/holding the view to see what one expects / wants to see: the color temp on the color temp page..

its like being presented the kWh value of a sensor on a dedicated Power view, and being told to hold that for some popup to show the actual property of interest.

[matthiasdebaat]

so no, this doesn't answer the questions raised

Please start a discussion with questions I didn't answer yet.

[Mariusthvdb]

it's not about missing answers Matthias, its about counter intuitive frontend behavior that is 'issued' here.

if you don't want to, that's fine, there's no point really in keeping us busy in yet another discussion that will never be resolved.

yet, please feel free to move it there.

[matthiasdebaat]

I don't know why I deserve this kind of hostility, Marius? I'm giving multiple answers to the only question I'm seeing in this issue. If you don't like the answers, that's fine. Feel free to start a discussion.

But stop playing the victim here, blaming me for multiple unanswered questions. Then to say that it is not about the missing answers, but to insinuate that we do not listen to feedback. Again, I have given my design rationale. If you have any feedback on this, please feel free to open a discussion.

[Mariusthvdb]

I don't know why I deserve this kind of hostility, Marius? I'm giving multiple answers to the only question I'm seeing in this issue. If you don't like the answers, that's fine. Feel free to start a discussion.

But stop playing the victim here, blaming me for multiple unanswered questions. Then to say that it is not about the missing answers, but to insinuate that we do not listen to feedback. Again, I have given my design rationale. If you have any feedback on this, please feel free to open a discussion.

?? Huh, not sure what's going on here. 'Deserve hostility', 'playing victim' , 'blaming' ??

Somehow I must have triggered a completely unintended emotion. Not my intention at all!

All I am saying is this current behavior is experienced as a bug. Hence the issue here.
And not a FR/discussion in the other spot in the Repo.

It's as simple as can be: requiring a user to have to touch the slider to see the actual value of this dedicated color temp view or otherwise see brightness %.

Not much to add to that.

Again, please don't be defensive, not required at all, this is nothing personal.

Greetz, Marius

[plamenko]

Thank you for your detailed explanation regarding the UI design for Home Assistant's lights. I appreciate the thought that has gone into maintaining consistency and catering to a diverse user base. I'd like to share a few thoughts in the spirit of constructive feedback:

1. Prominent Value Display: I understand the intent to keep a consistent layout with a prominent value at the top. However, when in the "color temperature" tab, it might be more intuitive if the displayed value represents the color temperature (in Kelvin), rather than brightness. Initially, I interpreted the percentage value as a representation of color temperature, and it was quite puzzling. Aligning the displayed value with the tab's function could enhance user understanding and experience.

2. UI Efficiency: Regarding the separate tabs for brightness and color temperature, integrating these controls into a single dialog could streamline user interactions. This approach not only reduces the number of clicks to achieve a desired setting but also minimizes confusion. Typically, users interact with three main aspects of lighting: on/off, brightness, and color/temperature. A unified interface accommodating all three could be a significant usability improvement.

3. Standard Representation of Color Temperature: Kelvin is a widely accepted standard for color temperature measurement. When users adjust color temperature, showing the value in Kelvin would align with common expectations and practices. This approach would provide clarity, especially for users familiar with color temperature concepts.

4. Color Wheel and Color Temperature Display: I understand the challenge in representing Kelvin values on a color wheel. However, many lighting devices that support both RGB and color temperature modes use them exclusively—with separate LEDs for each mode. In such cases, the UI could reflect the mode in use: displaying (R,G,B) values in RGB mode and Kelvin in color temperature mode. Since Home Assistant is aware of the light's operating mode, this could be a feasible and user-friendly approach.

I hope these suggestions contribute positively to the ongoing development of Home Assistant's UI. Your work is greatly appreciated, and I look forward to seeing how it evolves.