Adding support for ColorTemperature items

Tags: #<Tag:0x00007fc8f6c44020> #<Tag:0x00007fc8f6c0be78>

@Kai, first of all, sorry in case I am reopening an existing discussion.

After some time using it, I really like OH, but I am a bit surprised that at OH3 we still do not have some some kind of support for specific color temperature items.

Would not it make sense from the user perspective to have UI specific interface and controls for it?

Some challenges I find with today’s implementation (using a dedicated Dimmer channel):

  • Not user friendly: going in the direction of user simplicity, not having a specific item type prevents the UI from having a color temperature picker.

  • No standard “units”: due to lack of definition, PercentType does not mean the same for all things having a color temperature item, as it depends on the underlying thing supported range (i.e. 45% means something different for different lights, while 2700K would mean the same).

  • Inconsistent with other item types: current approach (one channel for on / off brightness) and another for color temperature on things supporting it looks incosistent with the approach for color items (where color functionality is extended from the dimmer item).

On the other side, I only see one benefit on the current implementation (unless I am missing something), which is backwards compatibility.

I understand that adding it may be a bit of a breaking change, but also I see things complicating more and more to work with this, and the later this is done, the more difficult it will be. Maybe we could find a way to introduce this gradually without being disruptive?

Bindings might add support for it gradually once implemented, or even providing both channels during a transition period, letting the user choose the channel to link (old vs new), being less disruptive.

Happy to support on definition and implementation (probably not able to dedicate enough time to do everything on my own).

If moving forward with it, I can think of three approaches:

  • Extending a new Item type from Dimmer as done by Color.
  • Extending a new Item type from Color, as somehow Color Temperature is a kind of color.
  • Implementing it directly in the Color item.

Probably implementing it in the color item is the less disruptive, but the other two might seem cleaner when distinguishing item types, and also considering the “native” state would not be HSB but some new “color temperature” state.

Any thoughts on this? (and sorry again if this has been already discussed and I have not been able to find it)

Pedro

3 Likes

Some bindings such as zwave have backwards compatibility. The binding is designed for Z-Wave Plus devices but also works for the older Z-Wave devices.

Actually OH3 supports v1 bindings through the remoteopenhab binding. You can run an OH2 instance and have its Items in OH3.

@Bruce_Osborne, this has nothing to do with OH1-2-3 compatibility of current binding implementations.

It has to do with adding, at core level, a new item type for ColorTemperature.

OK I misread. I do not think the majority of homeowners adjust their lighting to specific color temperatures.

I do believe if you submit a PR to add that functionality it would be considered though. If you are not a developer the normal way to get assistance here is to commit to a bounty on bountysource hoping to attract a developer for your cause.

@Bruce_Osborne, yes, I can develop or help develop it myself, no need for a bounty here.

But this is a relevant enough change on core as to get first some feedback at least probably from @Kai, before even thinking of starting working on a PR.

1 Like

It’s true that many high-end (and even not so high-end) lighting systems are color temperature tunable now. Lutron’s semi-recent acquisition of Ketra and their ongoing integration of it in to HomeWorks demonstrates how serious the industry is about the trend.

I’m all for adding new types to openHAB where necessary, but I’m not sure it really in this case. Color temperature is usually expressed in degrees Kelvin, which denotes the temperature that a notional black body radiator would need to be heated to in order to radiate light of that color. So it may make sense to simply use a QuantityType for it (specified as degrees Kelvin) in bindings, with an item type of Number:Temperature.

A channel type definition for it might be something like the following:

	<channel-type id="colortemp-channel">
		<item-type>Number:Temperature</item-type>
		<label>Color Temperature</label>
		<state min="2400" max="6500" pattern="%d %unit%"/>
	</channel-type>

I don’t think creating a new type would be necessary unless you need it to automatically convert to HST or RGB color values.

It should be relatively simple to create an appropriate slider widget for it in MainUI. Maybe that’s what really needs to be added – a standard color temperature widget.

That should really have nothing to do with it - Items are abstract, so long as they hold a “colour” exactly how is internal business. It’s a binding’s job to present the abstract Item value as HSB or RGB or whatever the device likes.

The “color temp” dilemma is interesting, arguments both ways.

I’ll throw in that if considering adding on a new property to an existing Item type, Dimmer might be the one. This would allow dealing with a color temp controlled lamp as a “single unit”, analogous to a Color Item.
Note that I’d expect the full Color type to “inherit” this extra property, just as it does the other Dimmer features.
UI widgets would need some enhancement, to show or (default) hide the colour temp part.
Some magic would be needed to distinguish how to send a “colortemp” command or state update to a Dimmer that didn’t looklike an ordinary brightness command.
Perhaps that would be where the Temperature style quantity comes in?
myDimmer.sendCommand(99) = brightness only
myDimmer.sendCommand(1200K) = colour temperature only

Without really commenting on whether color temperature really needs it’s own item ‘type’, I’d like to say it may be hard for the binding developers to get their particular brand of bulbs to conform to the kelvin light scale. What I’ve noticed with different brands of bulbs is that the actual color they produce at different warmth levels wildly varies. A Lifx bulb I own is supposed to have a color temperature range of 2700K-9000K. The Hue white bulbs (not white ambiance or white & color ambiance) are supposed to be 2700K. I can tell you for a fact, they are not even close to the same color

And for background, as a young man I painted cars and was considered an expert matching color.
Fun fact: One out of every six people is fully or partially color blind

Introducing new item types is hardly possible as all existing UIs, IO-addons such as Alexa and others would have to be adapted to correctly deal with it.
You should therefore consider item types to be similar to a primitive type system. The semantics then come with the tags and “color temp” is clearly a semantic on a discrete number.

The foremost goal of item types is to be an analogy for physical controls you also find on devices or remote controls. For this, a dimmer item is the most natural fit. All you really want to do is to make the color temp colder or warmer, but the average user won’t ask to have 5420 K, please.
And as @Andrew_Rowe correctly states: With that stuff being produced with lowest prices in China, you should not assume that setting the color temp to a Kelvin value actually works.

Note that volume controls are also naturally using a dimmer item and not a dB number. Same for the brightness of the light that is controlled from 0-100% instead of 0-470 lumens. There are many more such examples.

So in order to be a good abstraction, any bulb that supports color temp can offer a dimmer channel.
For the ones that offer settings in Kelvin, we also have the advanced system channel in place, which bindings can optionally support additionally.

Speaking as a user, not a developer, a Dimmer with color control capabillities is the most natural fit. Considerig UIs and remotes, the natural fit is a single control for both (as for the current color control, or the IKEA remote you linked), where the item accepts on, off, brightness, and color (in this case color temperature)

Correct, but, as a user, I do want to set all my home (or a room) to 2700K or 4000K, or whatever absolute point in between a slider can provide for all of them together, and with just Dimmers it is not possible.

Well, using K for light color temperature units, even if having its physical reasoning, is a mere convention: you would never treat it as a temperature (convert it to C or F?). You can also express it as Mireds (so 1e6 times the inverse of K temperature), Hue and Saturation, RGB, XY… It is a color, not a temperature.

This would solve the user experience part, if a widget is something that can just appear seamlessly in all UIs (including the mobile app) by just naming an item in the sitemap. Today we have, anyway, two independent items, not one.

I understand this is the real hard issue of the topic (more to this later).

Agreed, but a volume control is still something that can be turned off, on, and its value is representative of the level. ColorTemperture is just a color, a property like Hue and Saturation, together with On, Off, and Brightness (as with the Color Item) that is part of the item…

I understand that, from the user experience perspective, the same way a user would expect a color picker in the UI to select color, he would expect a white tone picker for a color temperature item, still being able to control its brightness from it.

Maybe I am not a standard user, but all commercial implementations of home automation UIs I have seen (I have not tested other non-commercial ones :slight_smile: ) do have a CT dedicated control and picker, and there is probably a reason for it.

This is nice! But only solves half of the problem (the programmatical one, not the user experience one).

And, as commented before, CT is not a temperature, it is a color, so not really a dimensonless number or a number with temperature units. It is something that can be expressed as K, but also as Mireds, Hue and Sat, …

So I think we are probably mixing three different discussions:

  • Is it needed or good to have: From a user experience perspective I think it is. A CT light should be treated the same way as RGB light. A non-technical user (so, a user) does not care of channels, widgets, abstractions, etc. He probably just cares about having a CT picker for his lights, without having to code, link channels, and do some rule / sitemap magic with it.

  • Does it fit the architecture: This is a conceptual / arquitecture discussion, not a user experience one. In any case, the Color item exists, so it is not like this is something totally out of the current model.

  • How to implement it (including the discussion on how difficult it can be): If we stick to this as the only driver, regardless of the above, we are assuming that something that should be probably out of the box, with more and more CT lights in the market, will never be implemented in OH.

From the above, and understanding the backwards compatibility issue (which I refer to in the original post), would it make sense from the user experience perspective, to have a dedicated CT item, in first intance?

If we want OH to be user friendly and UX driven some day, we should probably be having the discussion on how to implement this in a non-disruptive way that fits the architecture only after the user experience needs discussion.

Behind the scenes do these color temperature bulbs have a standard API for setting a specific kelvin or do they just have two opposing dimmers controlling the 2700k and 6500k LEDs where sliding from one extreme to the other turns up or down the related LEDs?

Some of the Wifi bulbs I’ve seen with proprietary apps use a slider with yellow on one end and blue on the other, without specifying the number of kelvin.

Again that wouldn’t really matter, supposing some Item had an abstract ‘color temp’ parameter it would be the binding’s business to turn it into whatever unique encoding the device wanted.