[hue] HueBinding does not recognize or update the color mode when updating bulb color

[bechte]

When sending a HSB color to a bulb it sometimes occurs that the color is not set correctly, e.g. instead of a warm white tone, the bulb turns into a fireplace-red color. From my tests and a deep dive into the code, I am sure that it happens, whenever the HUE app on the smartphone is used to set up a color temperature. Then the color mode of the bulb is not updated/used correctly within OpenHab.

Steps to reproduce the issue:

• Go to HUE App and modify the color of the bulb with the color picker circle to any color
• Wait approx. 30 seconds until OH has received/recognized the new color from the HUE bridge
• Send the Command (31,67,70) to the bulb => warm white color
• Go to HUE App and modify the color of the bulb with the color temperature widget to any color
• Wait approx. 30 seconds until OH has received/recognized the new color from the HUE bridge
• Resend the Command (31,67,70) to the bulb => fireplace red color

I think the binding should handle the color mode correctly and update the color mode on the bulb in regard to the channel that is used for the update.

For more information, please see also the discussion on the community forum:
https://community.openhab.org/t/send-string-command-to-color-item-results-in-differnt-colors/113311/8

[cweitkamp]

I can confirm your issue and it may be annoying. Unfortunately the Hue API does not allow to set the expected colormode. When I try to do it I get an error message:

curl --location --request PUT 'http://{{ip}}/api/{{username}}/lights/2/state' \
--header 'Content-Type: text/plain' \
--data-raw '{
   "colormode": "hs"
}'

    {
        "error": {
            "type": 6,
            "address": "/lights/2/state/colormode",
            "description": "parameter, colormode, not available"
        }
    }

[bechte]

Is it possible to you to paste the two different payloads of the request that are sent to the light for the different channels provided within openhab (color, color_temperature)?

I would like to see if it is limited to the values required. If so, I would post this issue on the Philips side as a bug for handling the commands "wrong".

Thanks in advance. Bechte

[cweitkamp]

Yes, it is. We have to distinguish commands for setting the color between color modes "XY" and "HS". Replace {{ip}}, {{username}}and{{id}}` respectively.

Color (XY):

curl --location --request PUT 'http://{{ip}}/api/{{username}}/lights/{{id}}/state' \
--header 'Content-Type: text/plain' \
--data-raw '{
   "xy": [0..1, 0..1]
}'

Color (HS):

curl --location --request PUT 'http://{{ip}}/api/{{username}}/lights/{{id}}/state' \
--header 'Content-Type: text/plain' \
--data-raw '{
   "hue": [0..65535],
   "sat": [0..254]
}'

Color Temperature - The value expected by Hue API is in mired (calculation: mired = 1000000 / Kelvin) and depends on the technical specs of the bulb (default: [153..500], 2200K - 6500K):

curl --location --request PUT 'http://{{ip}}/api/{{username}}/lights/{{id}}/state' \
--header 'Content-Type: text/plain' \
--data-raw '{
   "ct": 153
}'

One more thing. I the same problem occures when applying a scene from openHAB on a Hue group. AFAIK the scenes should change the color mode as well. At least it happens when recalling them via Hue App.

[mechalas]

I would add two channels to every Hue color light bulb to address this issue.

• "Currently showing color" as a read-only channel that reflects the color actually being shown on the bulb. The color mode of a color light is part of the queryable state. Detect the color mode, and convert XY and CT modes to HSB. Obviously, this would need a better name.
• Provide the "Brightness" channel. Currently, only white lights get a brightness channel. This limits the UI options. For example, the state-aware "light" icon can't be used to reflect the brightness of a color bulb (not easily, anyway). It's also counter to the Hue API, which lets you control brightness independently of the color. (The workaround for this is to make Light Groups for every individual lamp, since Light Groups are given a brightness channel. This is unnecessarily verbose, and problematic since there are limits on the number of resources that can be created on a Hue bridge.)

[kaikreuzer]

@mechalas Both those features are covered in the color channel. Note that the Things are an abstraction layer that is not meant to exactly mimick the manufacturers modelling, but rather make it easily exchangeable.

[mechalas]

The lack of a brightness channel on color bulbs creates a very specific problem which I listed, and which I will repeat again: Currently, only white lights get a brightness channel. This limits the UI options. For example, the state-aware "light" icon can't be used to reflect the brightness of a color bulb (not easily, anyway).

Many color bulbs, such as downlights and lamps, are run in a white/color temperature mode most of the time. In white mode, a simple "brightness" channel that doesn't have to be extracted from a triplet would be more than just helpful. As it is, you can't use "oh:light" as a state-aware icon with Hue bulbs that don't have a brightness channel. Instead, you have to set the icon explicitly using an exrpession like this:

='oh:light-'+Math.round(items.DiningLampL_Color.state.split(',')[2]/10)*10

This should probably be its own issue.

As for the other issue, maybe I am just not waiting long enough for changes to get reflected. It does seem to take longer than 30 seconds, but I've probably been too impatient.

(Edited to fix copy/paste error)

[mechalas]

I can confirm your issue and it may be annoying. Unfortunately the Hue API does not allow to set the expected colormode. When I try to do it I get an error message

Actually, you can. You send a color parameter increment of 0 to change the color mode. For example:

curl --location --request PUT 'http://{{ip}}/api/{{username}}/lights/2/state' \
--header 'Content-Type: text/plain' \
--data-raw '{
   "hue_inc": 0
}'

This will change the color mode to hs without changing the color itself.

[kaikreuzer]

only white lights get a brightness channel. This limits the UI options.

No, that's a misunderstanding. You can link a Dimmer item to a color channel, which will behave exactly the same way as a Dimmer item against a brightness channel, that's why I said this feature is covered by the color channel already. Adding yet another channel to do the very same would be redundant.

[lsiepel]

As this issue has the won’t fix label and see some related discussion and PR, I wonder if there is still something to fix or do with this issue, otherwise I suggest to close it.

[lolodomo]

Yes, I think we can close it, @cweitkamp explained there is a limit with API.