Deconz-rest-plugin: API doesn't update colour for Hue Bloom

[ebaauw]

Describe the bug

The colour of the Hue Bloom isn't updated in the API.

Steps to reproduce the behavior

Set the colour to {"xy": [0, 0]}. The bloom sets itself to its blue point, [0.138, 0.08], but the API continues to report [0, 0], until the _Color Control_ cluster attributes are read manually in the GUI.

Expected behavior

API should update the xy value.

Additional context

Sniffer log confirms that API plugin isn't polling the colour attributes. It is polling the _Color Control_ cluster alright, but for attributes 0x0008, 0x4001, 0x400a, 0x400b, 0x400c; even when the light is off. Looks like the API is stuck trying to initialise ctmin (0x400b) and ctmax (0x400c), but these attributes are unsupported for type Color Light.

See also https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1209, where this issue was discovered.

[ebaauw]

I'm pretty sure this used to work in the (distant) past. When creating ph probe, I did test it on the Bloom, and it worked. But now ph probe times out, because the API doesn't update the colour.

[ebaauw]

The issue is that for a _Color Light_, the RConfigColorCapabilities resource item isn't added, so the response to reading the _Color Capabilities_ isn't stored, causing the poll manager to think the light hasn't yet been initialised.

[ebaauw]

Haven't tested yet with the Tint remote, but ph probe now works again.

[Mimiix]

@ebaauw Thanks for making me smile this morning Erik :)

[thedannymullen]

The issue is that for a _Color Light_, the RConfigColorCapabilities resource item isn't added, so the response to reading the _Color Capabilities_ isn't stored, causing the poll manager to think the light hasn't yet been initialised.

Would this problem exist in other color lights possibly? My tradfri color lights have developed some issues since I updated. I am looking through the issues before I start debug.

[ebaauw]

Yes, all lights of type _Color light_.

[ebaauw]

Note that RConfigColorCapabilities was suppressed from the response to a GET of a /lights resource, but included in the web socket notification. It's now exposed as colorcapabilities top-level attribute on a GET as well (so the value can be checked with access to the GUI).

[klada]

I just wanted to confirm that this is working now. Even if the color is changed directly with a ZigBee remote (such as the tint remote), the colors reported through the API are updated after a few seconds. :+1:

Thanks for your efforts and the quick fix @ebaauw