Color Conversion XY/RGB, Maintaining a predictable RGB value

[Kriegbaum]

Hi, I have a question about the way color is handled for a lot of smart lights in this system.
I've used the color control with both the HSV and XY schemes, and found that the HSV control doesn't produce very accurate results, but the XY control point is very good (and by extension the built-in RGB input option that translates the color to XY)

However, I've found that any sort of XY -> RGB and RGB -> XY conversion isn't very precise. If I set something with an RGB color, and then ask for its state, I never quite get back the same value. I've messed around with a lot of different gamma/whitepoint options, and there is always some point of the XY range that doesn't convert back to RGB exactly, its always a couple points off at one of the extremes.

This has presented as a minor annoyance for some features of automations I am working on.
I am envisioning something where I can ask for an RGB value over MQTT, and Zigbee2MQTT will do the XY conversion, set the color as it already does, but then stores the RGB value I asked for in its current state so that I get that same value back when the state is updated.

Is this something that is possible through configuration in the current Zigbee2MQTT framework, or would this require a feature add?

[sjorge]

I think if you set the following device options for your bulb it will do what you want:

optimistic: true
color_sync: false

You might also need to remove reporting for lightingCtrl.colorX, lightingCtrl.colorY, lightingCtrl.colorTemperature, lightingCtrl.Hue, and lightingCtrl.Saturation. But those are not configured by default.

Setting those 2 device options should skip all the color conversion to keep x/y/hue/saturation in sync. And optimistic will tell z2m to just store whatever you set to it in the state before the device reports the actual value.