When change the color of a Philips HUE lamp using blockly, something strange happens:
The log shows the following:
2023-08-03 21:19:49.065 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'HUE_Schreibtisch_Strip_Farbe' received command 23,90,100
2023-08-03 21:19:49.069 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'HUE_Schreibtisch_Strip_Farbe' predicted to become 23,90,100
2023-08-03 21:19:49.071 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HUE_Schreibtisch_Strip_Farbe' changed from 23.033,90.16700,0 to 23,90,100
2023-08-03 21:19:50.195 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HUE_Schreibtisch_Strip_Farbe' changed from 23,90,100 to 22.976,89.95600,100
2023-08-03 21:20:10.370 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HUE_Schreibtisch_Strip_Farbe' changed from 22.976,89.95600,100 to 23.033,90.16700,100
Here something seems to be rounded strangely, or with too many decimal places. It works but it doesn’t look clean.
Disable autoupdate. Then the Item won’t change state until Hue reports that it’s changed state. With autoupdate enabled (the default) OH predicts what the new state of the Item will be.
As for the “too many decimal places”. Well that’s what Hue is reporting. There really isn’t anything you can do about it. Maybe file an issue on the binding to round the values returned by Hue?
During development of the API v2 version, we expressly increased the number of decimal places. At the request of another user. The reason is that OH uses the HSB color model whereas Hue v2 uses XY+Gamut and we found that round tripping HSB → XYG → HSB with integer values would lead to significant rounding errors. So we decided to use decimal values instead, in order to reduce such errors.
EDIT: PS (just so you know) different models of Hue lamps use different color Gamuts, so the round trip of color model changes can have different rounding errors on different models. Its complicated