Closed bechte closed 1 year ago
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"
}
}
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
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.
I would add two channels to every Hue color light bulb to address this issue.
@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.
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)
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.
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.
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.
Yes, I think we can close it, @cweitkamp explained there is a limit with API.
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:
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