Color Temperature Min/Max, Units, and UI

I recently submitted my first pull request, a feature to add color temperature support to MQTT lights. I’d like to start on a follow-up to add a couple of nuances my initial feature missed, but I need community feedback on the best way to go.

Min and Max Color Temp Values

The Problem

The lights I’m driving with this feature, Osram Lightify, accept color temp in mireds. HA uses mired internally, too – the slider control in the UI emits values in the range from 154-500 (defined in homeassistant/util/color.py as HASS_COLOR_MIN and HASS_COLOR_MAX). Some hardware, however, like the zigbee Osram Lightify bulbs I’m using (through MQTT via a rooted Wink hub) ignore mired values outside the range they support. This leads to problems where only a fraction of the UI slider does anything – releasing the slider outside of that range results in no reaction.

Proposed Solutions

One option is to clamp the range of values in the component – ie: allow the user to specify in their config “this endpoint only supports values from 200-350 mired; if you ask for 154 it’ll just clamp to 200, and if you ask for 500 it’ll clamp to 350.” Pros: no modification to web UI required. Cons: The full range of the slider still isn’t used, but at least dragging the slider outside the supported range still gets you a response from your lights.

Another option is to specify min/max color temp in the component, but normalize the range of input color temperature values (ie from 0 to 1), where 0 = the lowest value in mired and 1 = the highest value in mired. Pros: Minimal extra complexity in the web UI; full slider range is used. Cons: This would require changing the web UI and a bunch of existing components. This would also mean that the same position on the slider could mean different things to different lights.

Another option is to pass the min/max values through to the web UI. Pros: More info for the web UI. Cons: Lots of changes required (though the implementation could pass HASS_COLOR_MIN and HASS_COLOR_MAX by default, minimizing impact on existing color temp lights).

I’m open to other alternatives too, and happy to do implementation – just want to avoid a situation where to get a solution I like, I end up making PR with a bunch of changes and then nobody else is happy with them.

Color Temp Units (and slider direction)

[edit]Removed some incorrect info here – I misread something in the Lightify implementation. The fault is mine![/edit]

A lot of US color temp light UI (eg: Wink) expose color temp in kelvin, and at least the film/video/photography industry in the US talks about color temp in terms of kelvin. The big deal is that in mired, lower values are blue-er, while in kelvin, higher values are blue-er. I was initially confused by the HASS slider, because I expected “drag it to the left = redder light!”

One potential solution: Make kelvin/mired in the UI a configuration option. Probably best to keep things mired internally since it seems like zigbee lights, at least, like it that way. But it should be possible to configure the UI to display things in either mired or kelvin, consistently. It would be possible to add a function to utils/color.py to do the conversion. Bad news: more web UI complexity. Good news: configurability and everyone can get what they want.

Any input?

Again, not asking anyone else to write code for this – totally happy to start hacking and submitting PRs; just don’t want to start doing work in a direction that folks aren’t happy with, and ends up un-merge-able.

1 Like

Have you thought about implementing this with value templates? For example:

color_temp_value_template: "{{ 1000000.0 / value_json }}"

Obviously, there are a number of ways this doesn’t (yet) address the issues you brought up, namely:

  1. Slider Direction
  2. Converting back from Mired to Kelvin when sending commands to the light (this will require a small code change to the mqtt light component)
  3. Min/Max (though I think the template framework can manage this, I just haven’t tested yet)

It seems like if (2) and (3) above can be addressed with a simple fix that doesn’t involve UI changes, that could be a good path…

I hacked my way to getting color temperature to work on my Osram bulbs, I was able to use the template suggestion (maybe I was implimenting it incorrectly). I posted my solution to another topic that was more recently active regarding this topic.