Add Channel for color state

[AfromD]

Hue bulbs can operate in two color modes: Hue / Saturation / Brightness or Color Temperature / Brightness. To coordinate with other lights which onyl show white, it would be helpful to have a channel which reflects the operating mode, since this is not reflected in the available channels. The original Hue hub API seems to have a state.colormode [hs|ct] paramter for this, so it is probably transmitted somewhere.
I suggest to call it colormode with possible values ct or hs, for maximum compatibility with people who might have gotten this value from the hue hub.

[cdjackson]

I'll take a look at this soon - but I'm not sure I can guarantee the names or Hue compatibility (sorry). There are other bulbs on the market as well ;)

[cdjackson]

I'm not sure that this attribute is reportable :( Certainly in the Osram bulbs, its not - I've not tried a Hue yet. This may mean polling is needed which makes it a little less reliable (or higher latency at least).

[AfromD]

I have given it some thought. I have no idea how other bulbs do this, but I might have a concept that is more generic. I imagine there are bulbs that just do color temperature (because they have no color leds) and other bulbs that just do HSB. Hue does both, and it leads to an inconsistent state, where you can see the last set values for HSB and CT, but it is not apparent which one is active. They can be completely different.

Through experimenting I think the color temperature setting can be closely replicated by setting hue to a rich yellow and varying saturation between 0 and 50%.

My idea: Mimic this by reflecting a change in color temperature also in the position of the color sliders. This way, they are pretty much in accordance with each other. So whenever the color temperature is set (and the bulb would change mode to "ct"), that would also reflect in the hue slider as a rich yellow and the saturation slider would be about half the way of the ct slider from the coldest setting.

For my purpose, finding out whether we are producing color, I could just decide on the basis of saturation: lower half is still considered a white, upper half is considered a color. No need for an extra channel as long as HSB values approximate the actual CT setting. The Hue bulb can still be operated as CT or HSB, but OH would always report the HSB sliders according to the output of the bulb.

You might still need to poll, since the Hue bulbs always power on in ct mode after you take away power. So when they are powered off through mains power while producing color, they will turn on producing white.

Of course there is no way to reflect a color state in the CT slider. So rules should read the hsb values (and always have a pretty accurate state of the lamp), but control can still be CT based.

[cdjackson]

I suggest that we look at the original request first as the next suggestion is something different. I've already implemented the color_mode channel and will merge it in the next day or so. If you now want something different, we should open another request.

[AfromD]

This also solves my problem, which is to know which values are being currently used by the lamp. My second idea was just another way to solve the same problem which might be more generic. No need to put any more work into as far as I am concerned.

[cdjackson]

Ok, thanks. Let’s see how this works. I’ve set it up so that it will poll when there’s a change to other colour parameters which are reported, so this should give us reasonably instantaneous feedback even though this is not a reportable channel… Let’s see how it looks ;)

[kaikreuzer]

Sorry guys, but this looks awful to me 😞
We already have a Hue binding and thus Thing definitions for Hue bulbs and ideally, this should be exactly the same here. From the user perspective, he either wants to control color/saturation/brightness, then he uses the color channel. Or he wants to control the "warmth", then he uses the CT channel. The now introduced "color_mode" is imho far too technical and not at all needed. At least we do not have it for hue, LIFX, TRADFRI or any other color bulb support so far - so we should really try to do the same modelling here.

[cdjackson]

I’m not at all versed with Hue bulbs, but I’m trying to present the options from the ZigBee perspective. In ZigBee, there are 3 options (not 2) so if I now just follow the Hue “standard” then how does this work if it only has 2 (which is what I’m seeing here)? I’m not sure how we manage dependancies between bindings like this - if we’re not careful, we end up with the lowest possible option, or the first one wins, or something, and we don’t offer the features of all devices. I’m happy to standardise if there are standards, but for me the binding should present the features that the devices offer, and not the features that another binding offers? Sorry if that’s “awful” :(

[AfromD]

The problem is (I think also in other Hue bindings as I gather from the forums) that Philips offers control via ct as well as hsb, but then has no feedback as to what control it is currently adhering to. In OH, the sliders/values can show "blue, full saturation" and "warm white" AT THE SAME TIME, and then I don't know what is actually showing. The color mode tells me which of the two is active. It is not needed for control, but it is absolutely needed for knowing what the bulb is doing. The Philips Hue Hub hardware reports this value as well, other OH users (using the hue hub binding) are actually polling this via HTTP separately to solve this very problem. https://community.openhab.org/t/hue-how-to-detect-colormode/28974

Another way to solve it, as proposed above, would be to synchronize values for HSB in OH, even when the bulb is in the another control mode.

[kaikreuzer]

It is not about hue, as I mentioned we do it the same way for any color bulb that is supported in ESH.

What is important is that ESH comes with a certain abstraction already - so you must not be tempted to expose ZigBee as it is to the Thing model; rather the contrary: The Thing channels must be designed in a way that the user does not have to care whether there is Zigbee behind or anything else.

So my main point is that a "mode" simply does not bring you (the user) much value here: He should at any time be able to use the color channel or the ct channel, so this mode does not really make any sense.

[cdjackson]

What is important is that ESH comes with a certain abstraction already - so you must not be tempted to expose ZigBee as it is to the Thing model; rather the contrary: The Thing channels must be designed in a way that the user does not have to care whether there is Zigbee behind or anything else.

Sorry - I’m confused then. The bulb does (I think) expose the same color controls, UX as other bulbs I’ve seen (as far as I know).

So my main point is that a "mode" simply does not bring you (the user) much value here: He should at any time be able to use the color channel or the ct channel, so this mode does not really make any sense.

I'm happy to remove it - someone asked for it as it was apparently available in other bindings. If it brings no value then I’ll remove it again. Currently, you can use the color temperature, or color at any time you like so I’m not really sure about this comment?

[kaikreuzer]

Another way to solve it, as proposed above, would be to synchronize values for HSB in OH, even when the bulb is in the another control mode.

This would imho be the proper approach.

Currently, you can use the color temperature, or color at any time you like so I’m not really sure about this comment?

Yes, you can use it and if you follow the "sync values" approach, both channels will always have some valid value - hence there is no need to talk about "what mode" - you can always look at both.

[AfromD]

This is what controls are currently exposed in OH for a Hue white and color light. Is it Blue or White? 100% bright or 95% bright? ;)

[kaikreuzer]

Clearly blue as it has 100% saturation. What else? And the brightness is obviously at 95%. Where's the problem? The only one I see is that a color temp value is difficult to grasp for any "real" color, but as far as I know, this can be calculated in some way as well (although I do not consider it very relevant).

[AfromD]

It is actually warm white at 100%. It is using the color temperature value right now, but I can't see that in OH.

[kaikreuzer]

Oh, I only just saw that your light also has switch and dimmer channels besides the color channel. This is clearly a bug - how did you get them there?

[kaikreuzer]

It is using the color temperature value right now, but I can't see that in OH.

Well, this only shows that there is a bug as it does not correctly update the color channel state.

[AfromD]

As soon as I would move any slider in the HSB section, it would switch to a color.
The switch is also exposed by the binding. It does work, but is not always updated

[kaikreuzer]

The switch is also exposed by the binding.

@cdjackson Didn't we talk about that already that this is incorrect?

[AfromD]

[cdjackson]

Didn't we talk about that already that this is incorrect?

Not sure, but I agree it should be removed, and it will be when I get a chance. Currently the channel gets created as the device exposes a specific cluster (ie the ON_OFF cluster) as well as the dimmer cluster (ie the LEVEL_CONTROL cluster), so the binding creates a channel for both. When I get a chance I want to add a channel consolidation check to remove this duplication, but I've just not had the chance yet - sorry.

[AfromD]

Before you clean up too much: The switch is not needed, but the dimmer channel is, as the brightness slider in the color channel will switch the bulb to color mode. I have tagged the dimmer for alexa to use, it will dim both color and white. The dual control via either color temp or color is a feature of this lamp. people are also using this via the hue binding: https://community.openhab.org/t/hue-bulb-210-or-220-for-latest-color-lamps/31249/2

So ideally, the switch would go, and the color channel would reflect a color temperature setting, when it is set by that method.

[kaikreuzer]

the brightness slider in the color channel will switch the bulb to color mode

Again, I would consider this a bug. The "B" in HSB stands for brightness and when you send 0-100% commands to the color channel, it must only adapt the brightness. Please help fixing such behavior to be as expected rather than working around it and introduce new complexity.

Feel free to enter bug reports for the hue binding resp. the Paper UI at https://github.com/eclipse/smarthome/issues.

[AfromD]

It is not a workaround, it is intended. The bulb is marketed as "white and color" and is compatibe with either CT/brightness commands or HSB commands. When taking away the dimmer, you would also have to take away the color temperature, because CT/HSB, where HSB is only used for dimming is not a standard.

Generally though, the dual command possibility would be helpful for compatibility, in case something would support one, but not the other. Or in case users would like alexa to control via the color channel, but would also like a CT slider on another control interface.

The ambiguity introduced by the two parallel command standards, Philips tried to solve with an indicator for color mode. Another way of solving it would be to synchronize HSB. However, it seems (speculation) that Philips didn't bother reporting back correct HSB when in CT mode. So this would be a translation that the binding would have to keep track of.

So I plead to leave the Dimmer, Color Temperature and Color all exposed. This would be standards compliant, and would be true to the bulbs native functions. The "Bug" in this case would be the inaccurate HSB reported by the bulb, which the binding would then fix by an approximate translation.

Edit: Disregard my original Alexa comments, as alexa supports the color channel via the OH skill.

[kaikreuzer]

As I said: We have many different such bulbs supported in ESH and the modelling is all the same for them with a color and a ct channel. What you are probably missing is the fact that you can always choose to use a slider for the color channel, which will simply make it the brightness control, if all you are interested in is ct+brightness. But there must not be an additional dimmer or switch channel, because this is simply a duplicate without any additional value.