Anyone volunteering for double checking our calculations from HSB to XY in the HSBType?
1 Like
@cweitkamp @BobMiles @couriersud
I did further investigatons: I’ve checked all results with the Hue API.
There are different color modes of the Hue Brigde: hs=HSB, xy=XY, ct=Color Temperature
I’ve checked all DEFAULT COLORS: RED, YELLOW, GREEN, CYAN, BLUE, MAGENTA
here are my results:
RED:
2019-08-24 08:22:26.527 [ome.event.ItemCommandEvent] - Item 'Innr_Light1_Color' received command 0,100,100
2019-08-24 08:22:26.529 [vent.ItemStateChangedEvent] - Innr_Light1_Color changed from 25,98,100 to 0,100,100
{
"state": {
"on": true,
"bri": 254,
"hue": 0,
"sat": 254,
"effect": "none",
"xy": [
0.6961,
0.3003
],
"ct": 500,
"alert": "select",
"colormode": "hs",
"mode": "homeautomation",
"reachable": true
}
“hue:” 0/182=0°
.
YELLOW:
2019-08-24 08:25:28.492 [ome.event.ItemCommandEvent] - Item 'Innr_Light1_Color' received command 60,100,100
2019-08-24 08:25:28.495 [vent.ItemStateChangedEvent] - Innr_Light1_Color changed from 0,100,100 to 60,100,100
{
"state": {
"on": true,
"bri": 254,
"hue": 10920,
"sat": 254,
"effect": "none",
"xy": [
0.472,
0.499
],
"ct": 388,
"alert": "select",
"colormode": "hs",
"mode": "homeautomation",
"reachable": true
},
“hue:” 10920/182=60°
.
GREEN:
2019-08-24 09:23:40.768 [ome.event.ItemCommandEvent] - Item 'Innr_Light1_Color' received command 120,100,100
2019-08-24 09:23:40.775 [vent.ItemStateChangedEvent] - Innr_Light1_Color changed from 60,100,100 to 120,100,100
{
"state": {
"on": true,
"bri": 254,
"hue": 21840,
"sat": 254,
"effect": "none",
"xy": [
0.1141,
0.8113
],
"ct": 500,
"alert": "select",
"colormode": "hs",
"mode": "homeautomation",
"reachable": true
}
“hue:” 21840/182=120°
.
CYAN:
2019-08-24 09:29:12.010 [ome.event.ItemCommandEvent] - Item 'Innr_Light1_Color' received command 180,100,100
2019-08-24 09:29:12.021 [vent.ItemStateChangedEvent] - Innr_Light1_Color changed from 300,100,100 to 180,100,100
{
"state": {
"on": true,
"bri": 254,
"hue": 32760,
"sat": 254,
"effect": "none",
"xy": [
0.1177,
0.3473
],
"ct": 500,
"alert": "select",
"colormode": "hs",
"mode": "homeautomation",
"reachable": true
}
“hue:” 32760/182=180°
.
BLUE:
2019-08-24 09:41:57.266 [ome.event.ItemCommandEvent] - Item 'Innr_Light1_Color' received command 240,100,100
2019-08-24 09:41:57.271 [vent.ItemStateChangedEvent] - Innr_Light1_Color changed from 180,100,100 to 240,100,100
{
"state": {
"on": true,
"bri": 254,
"hue": 43680,
"sat": 254,
"effect": "none",
"xy": [
0.122,
0.0828
],
"ct": 500,
"alert": "select",
"colormode": "hs",
"mode": "homeautomation",
"reachable": true
}
“hue:” 43680/182=240°
.
MAGENTA:
2019-08-24 09:46:58.030 [ome.event.ItemCommandEvent] - Item 'Innr_Light1_Color' received command 300,100,100
2019-08-24 09:46:58.032 [vent.ItemStateChangedEvent] - Innr_Light1_Color changed from 180,100,100 to 300,100,100
{
"state": {
"on": true,
"bri": 254,
"hue": 54600,
"sat": 254,
"effect": "none",
"xy": [
0.3948,
0.1851
],
"ct": 266,
"alert": "select",
"colormode": "hs",
"mode": "homeautomation",
"reachable": true
}
“hue:” 54600/182=300°
.
.
.
As you can see, everything seems to be OK. Saturation always=254 (!!!)
The xy values I don’t know if they are correct??
But I also had strange effects while testing. Sometimes the color temperature changed from 500 to 388 or 266, but I could not find the reason. Especially (388) when switching to “yellow”.
Sometimes saturation was not 254, it then was 243 or 238.
And sometimes the color mode changed to xy. EDIT: (I now found out) when official Hue APP is used for setting a color!
To get it back to “hs” I had to switch “color temperature” manually e.g. to 100% (=500), then the color mode switched to “ct”. After that, when I’ve changed the color, then it was “hs” again.
Here is a screenshot of HueApp when e.g. RED was set correct by openhab.
And here BLUE:
.
.
EDIT: SUMMARY of above:
| Color | hue | saturation | brightness | x | y | ct | comment |
|---|---|---|---|---|---|---|---|
| RED | 0 | 254 | 254 | 0.6961 | 0.3003 | 500 | OK |
| YELLOW | 10920 | 254 | 254 | 0.472 | 0.499 | 388 | ?? |
| GREEN | 21840 | 254 | 254 | 0.1141 | 0.8113 | 500 | OK |
| CYAN | 32760 | 254 | 254 | 0.1177 | 0.3473 | 500 | OK |
| BLUE | 43680 | 254 | 254 | 0.122 | 0.0828 | 500 | OK |
| MAGENTA | 54600 | 254 | 254 | 0.3948 | 0.1851 | 266 | ?? |
.
.
Why is color temperature (=ct) changed by switching to yellow or magenta?
Could anyone please calculate if x,y are OK? Thanks a lot! 
1 Like
Shouldn’t the D65 Norm white be: X0,312713 Y0,329016
When I look at the Rgb2Xy it says
Rgb2Xy[][] = { { 0.4124f, 0.3576f, 0.1805f }, { 0.2126f, 0.7152f, 0.0722f },
{ 0.0193f, 0.1192f, 0.9505f } };
Where Rgb2Xy[0][] is full D65 white if I understand correctly?
Edit: Sorry, now I see the conversion matrix. it’s correct in the code.
Basically what is needed is provided by the api for color lights:
"colorgamuttype": "C",
"colorgamut": [
[
0.6915,
0.3083
],
[
0.17,
0.7
],
[
0.1532,
0.0475
]
],
This are the maximum saturation red, green and blue color the light can display. What is missing is the white point (WP). With this information you can build a linear RGB to Yxy matrix needed for WP correction. Basically the following conversion have to done:
- HSB to sRGB - all colorpickers I have seen use sRGB values and convert them to HSB
- sRGB to linear RGB
- linear RGB to Yxy (based on sRGB triangle and WP)
- Yxy WP correction from sRGB WP to bulb WP
- convert Y to Brightness
- send x,y,B to bridge
This approach ensures that the bulb will have a color close to the color picker color. But the sRGB gamut is smaller than the Hue gammuts. This means you will never get fully saturated colors with this approach.
Philips recommends using Wide RGB instead of sRGB. The formulas given by Philips are most likely used by a lot of apps so may be a basis for consistent behaviour.
I am using DCI-P3 in my code since it comes close to the hue gammuts and thus avoids excessive clippings. But for both Wide RGB and DCI-P3 the color picker color may not be close to the illumination color.
2 Likes
OK, my bulbs from testing above have:
"colorgamuttype": "other",
"colorgamut": [
[
0.7,
0.3
],
[
0.11,
0.82
],
[
0.12,
0.08
]
]
If I compare these (red, green, blue) to my above table, the values are approximately accurate.
| Color | gamut(x) | x | gamut(y) | y |
|---|---|---|---|---|
| RED | 0.7 | 0.6961 | 0.3 | 0.3003 |
| GREEN | 0.11 | 0.1141 | 0.82 | 0.8113 |
| BLUE | 0.12 | 0.122 | 0.08 | 0.0828 |
Great job guys. Lots of information to work with. To wrap it up: If we want to support (nearly) similar colors than Philips Hue we have to improve our XY calculation. Different bulbs / luminaries have different gammuts. On the one hand we are lucky because the Hue API tells us which one is supported. On the other hand we currently use a fixed one in OHC (HSBType). Thus we need a way to do the new math.
It looks like the formulas given by Philips and our calculation of the gamma corrections are slightly different.
Philips’ formula:
float red = (red > 0.04045f) ? pow((red + 0.055f) / (1.0f + 0.055f), 2.4f) : (red / 12.92f);
Our formula:
return c <= 0.04045f ? c / 19.92f : (float) Math.pow((c + 0.055f) / (1.0f + 0.055f), 2.4f);
Do you see it (ignore the syntax)? 
It looks like a small typo introduced by the initial commit while the previous calculation was correct. I will provide a fix for it.
3 Likes
My fix has been merged yesterday. Can anyone test again?
1 Like
@cweitkamp
I’d rather like to test it, but unfortunately I cannot switch to the newest snapshots, (because AmazonDashButton binding is not running with npcap on Windows 10 with Wifi only connection.) Maybe I’ll find time on the weekend, setting up a test machine with latest snapshot.
Hi, when will the fix be available in openhab?
Thanks
I think it should already be in the Milestones of 2.5. But I can’t tell for sure since I’m on 2.4 stable…
Hi @Coder89,
Welcome to the community. The fix should be available in snapshot builds and the latest milestone build (OH2.5.M3).
ok, thank you
Hi,
I just installed openhab 2.5.0 stable and hue binding 2.5.0. However, I’m still seeing the issue described in this thread. When reading the color of a bulb (it’s a hue go) and then immediately setting the same exact value, the color is washed out:
var colorString = Simon_TV_Color.state.toString
Simon_TV_Color.sendCommand(colorString)
Shouldn’t that be fixed in the current build? Am I mising something? I’m happy to provide more info/ color readings if needed. Thanks in advance!
Regards,
Simon
Yes, please provide your findings. Thanks.
1 Like
Well, I just did some testing, but was not able to pinpoint the issue. However, I collected some test cases that may be helpful to you. If not please let me know.
What I did:
- Set the color via hue app
- Read the state via REST- API out of the bridge
- Read the HSB value with openhab
- Write the same value to the bulb via openhab
- Read the state via REST- API out of the bridge
- Read the HSB value with openhab
Here are some test cases:
Case 1:
BEFORE setting via openhab:
"state": {
"on": true,
"bri": 144,
"hue": 31773,
"sat": 223,
"effect": "none",
"xy": [
0.1923,
0.5271
],
"ct": 153,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
152,100,57
AFTER setting via openhab:
"state": {
"on": true,
"bri": 144,
"hue": 28884,
"sat": 131,
"effect": "none",
"xy": [
0.2706,
0.4921
],
"ct": 153,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
150,96,57
The difference between the two colors is huge in this case
Case 2:
BEFORE setting via openhab:
"state": {
"on": true,
"bri": 132,
"hue": 14154,
"sat": 27,
"effect": "none",
"xy": [
0.3687,
0.3816
],
"ct": 250,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
37,30,52
AFTER setting via openhab:
"state": {
"on": true,
"bri": 132,
"hue": 34359,
"sat": 15,
"effect": "none",
"xy": [
0.3676,
0.3802
],
"ct": 230,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
37,30,52
Difference is not noticeable in this case
Case 3:
BEFORE setting via openhab:
"state": {
"on": true,
"bri": 67,
"hue": 34359,
"sat": 15,
"effect": "none",
"xy": [
0.1469,
0.1474
],
"ct": 230,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
209,100,27
AFTER setting via openhab:
"state": {
"on": true,
"bri": 68,
"hue": 43821,
"sat": 254,
"effect": "none",
"xy": [
0.1778,
0.1601
],
"ct": 153,
"alert": "select",
"colormode": "xy",
"mode": "homeautomation",
"reachable": true
}
208,100,27
No big, but noticable difference in this case.
Those are the cases I tested, is there any more info I could provide you with?
Thanks in advance,
Simon
May I ask some of the experts of this post if they have any idea how to resolve my HSBType issue: HSBType automatically resets to 0
Hi,
I’m currently running OpenHAB 2.5.11 and have recently added a Hue Bridge with actually just one Osram Smart+ Color Bulb for testing.
I have the same Color Bulb connected to a zigbee2mqtt instance which is running with a Conbee II Zigbee Stick.
When I set the color of the two bulbs in OpenHAB to 0,100,100, I can clearly see a difference in the saturation of the two bulbs.
It seems that this issue with the Hue Bridge is still open…
@cweitkamp: has there been any progress on this issue? I just came upon the same problem, since moving all my Hue lights to Openhab 3.0 a few weeks ago. Even my family noticed, that when they say “Alexa, turn lamp to red” the red is now no more a vivid red but more a rosé or light red.
I have the same issue here. Especially as I want to animate the colors via OH it’s pretty annoying.