Deconz-rest-plugin: Deconz reporting CT parameter as invalid

[cree8]

Describe the bug

I am no longer able to view the color temperature slider in Phosconz for my LEDVANCE bulbs, nor am I able to send API calls through the Rest plugin as the API returns an error stating that CT parameter is not available

Steps to reproduce the behavior

Send color temperature command to API for node which corresponds to a Sylvania/Ledvance bulb. The command will not succeed.
Pick the Sylvania bulb and click the color temperature button in Phoscon. The button now does nothing.

Expected behavior

The expected behavior is for the bulb to switch to color temperature mode, as was the case before.

Screenshots

Environment

• Host system: Docker via Intel CPU
• Running method: Home assistant docker addon
• Firmware version: (26xxyy00)
• deCONZ version: (2.05.78)
• Device:ConBee II
• Do you use an USB extension cable:Yes

deCONZ Logs

Additional context

Error message: "Call-service API error. Error Message: /lights/9/state parameter, ct, not available"

[Mimiix]

Hi!

Do you have a screenshot of the device and the Color control cluster?

Thanks!

[cree8]

@Mimiix
Device Info

Color Temperature command within deCONZ VNC console

Color Control Atttributes:

I believe the last screenshot is the main one that you need.

[Mimiix]

interesting.

What is the output of the querying the rest api with:
GET /api/<apikey>/lights/9

[cree8]

@Mimiix

[ebaauw]

The light supports colour temperature, but state.ct is missing?! I only added a sanity check that state.ct needs to be exposed when setting ct, but haven’t changed the logic what attributes to expose. Was stare.ct previously exposed? If not, you would never get an update when ct is changed through a controller that supports colour temperature.

Are these ZHA lights or ZLL lights? I need to check the code, but I would think the API only looks at the _Device Type_, ignoring the _Color Capabilities_ when deciding what attributes to expose. Also note that the light doesn’t support color loop, but the API exposes state.effect nonetheless.

[cree8]

@ebaauw

The light supports colour temperature, but state.ct is missing?! I only added a sanity check that state.ct needs to be exposed when setting ct, but haven’t changed the logic what attributes to expose. Was stare.ct previously exposed? If not, you would never get an update when ct is changed through a controller that supports colour temperature.

Are these ZHA lights or ZLL lights? I need to check the code, but I would think the API only looks at the _Device Type_, ignoring the _Color Capabilities_ when deciding what attributes to expose. Also note that the light doesn’t support color loop, but the API exposes state.effect nonetheless.

I believe they are ZHA lights. I have two ZLL (Hue) bulbs that do have the state.ct var exposed and I can say with some certainty that this value was probably not there before, as I've played around with the HTTP calls quite a bit and dont recall seeing that value until recently.
If that is the case and the bulb doesnt expose the value, then it makes sense that the newly implemented sanity check would cause these ct change calls to no longer function.

Off topic:
Speaking of color loop, its funny that its possible to put the bulb into color looping mode via the manual command in deconz via vnc. These settings have color loop enabled on my test bulb here

[ebaauw]

Hm the light seems to report the corresponding attributes as not supported. Maybe I got the bitmap wrong. Could you double-click on _Color Capabilities_ and see which capabilities the light reports?

[cree8]

Here it is:

Its strange that the color loop is not reported to be supported, yet works just fine when the above commands are sent. Sounds like a firmware thing.
The screenshot does confirm the Color Temp capability though

[holdestmade]

I'm having the same issue, but with Hive Light Cool to Warm White smart E14 bulbs. They used to be recognised as INNR but since the latest HA deCONZ addon update they are now showing as Aurora TWCLBulb01UK. They work fine apart from the CT slider is not available in Phoscon or HA and, surprisingly, have a color slider and a saturation slider that do nothing.
I also have OSRAM and LEDVANCE GU10 and E27 bulbs and they have the CT slider.
Also, both the OSRAM and LEDVANCE bulbs both have a colorloop effect in HA.

[ebaauw]

I also have OSRAM and LEDVANCE GU10 and E27 bulbs and they have the CT slider.
Also, both the OSRAM and LEDVANCE bulbs both have a colorloop effect in HA.

Those are probably the ZLL bulbs?

I'm having the same issue, but with Hive Light Cool to Warm White smart E14 bulbs.

Please post the GUI screenshots and the API resource.

They used to be recognised as INNR but since the latest HA deCONZ addon update they are now showing as Aurora TWCLBulb01UK.

Is this reported by deCONZ or by HA? Did you upgrade the bulb firmware? What was the model before the HA update?

[ebaauw]

Its strange that the color loop is not reported to be supported, yet works just fine when the above commands are sent. Sounds like a firmware thing.

Yes. Not conform the standard, but, unfortunately, not uncommon. I guess that's why the API plugin ignores the _Color Capabilities_ and uses the _Device Type_ instead.

[holdestmade]

I also have OSRAM and LEDVANCE GU10 and E27 bulbs and they have the CT slider.
Also, both the OSRAM and LEDVANCE bulbs both have a colorloop effect in HA.

Those are probably the ZLL bulbs?

Yes

I'm having the same issue, but with Hive Light Cool to Warm White smart E14 bulbs.

Please post the GUI screenshots and the API resource.

API:

33: {
    "etag": "6bcb9443f53246d7a1ecd3406352****",
    "hascolor": true,
    "lastannounced": "2020-07-06T11:40:24Z",
    "lastseen": "2020-07-09T16:21:31Z",
    "manufacturername": "Aurora",
    "modelid": "TWCLBulb01UK",
    "name": "Simon_s_Lamp",
    "state": {
        "alert": "none",
        "bri": 64,
        "colormode": "ct",
        "effect": "none",
        "hue": 0,
        "on": false,
        "reachable": true,
        "sat": 0,
        "xy": [
            0.4578,
            0.4101
        ],
    },
    "swversion": "2.1",
    "type": "Color dimmable light",
    "uniqueid": "00:15:8d:00:02:5a:**:**-01"
},

Screenshots will not work if the VNC GUI is open - any reason why ?

They used to be recognised as INNR but since the latest HA deCONZ addon update they are now showing as Aurora TWCLBulb01UK.

Is this reported by deCONZ or by HA? Did you upgrade the bulb firmware? What was the model before the HA update?

Reported in GUI and Phoscon, not updated any firmware and can't remember the model sorry

[holdestmade]

For comparison this is a working LEDVANCE and and OSRAM:

34: {
    "ctmax": 526,
    "ctmin": 153,
    "etag": "c3c7dc8613306f621541fce19bf3****",
    "hascolor": true,
    "lastannounced": null,
    "lastseen": "2020-07-09T16:20:59Z",
    "manufacturername": "LEDVANCE",
    "modelid": "PAR16 RGBW Z3",
    "name": "Front Garden T3",
    "state": {
        "alert": "none",
        "bri": 50,
        "colormode": "ct",
        "ct": 400,
        "effect": "none",
        "hue": 43520,
        "on": false,
        "reachable": true,
        "sat": 254,
        "xy": [
            0.701,
            0.299
        ],
    },
    "swversion": "00103101",
    "type": "Extended color light",
    "uniqueid": "f0:d1:b8:00:00:12:**-**-01"
},

50: {
    "ctmax": 666,
    "ctmin": 125,
    "etag": "d36c385de4829ab82dd3899a9f43****",
    "hascolor": true,
    "lastannounced": "2020-07-08T08:24:26Z",
    "lastseen": "2020-07-09T16:21:22Z",
    "manufacturername": "OSRAM",
    "modelid": "PAR 16 50 RGBW - LIGHTIFY",
    "name": "Back Garden T3",
    "state": {
        "alert": "none",
        "bri": 254,
        "colormode": "ct",
        "ct": 500,
        "effect": "none",
        "hue": 512,
        "on": false,
        "reachable": true,
        "sat": 253,
        "xy": [
            0.701,
            0.2911
        ],
    },
    "swversion": "V1.05.10",
    "type": "Extended color light",
    "uniqueid": "84:18:26:00:00:08:**:**-03"
}

[ebaauw]

For comparison this is a working LEDVANCE and and OSRAM:

ZLL device type _Extended color light_.

The Aurora and the US LEDVANCE are ZHA _Color dimmable light_.

Maybe the API plugin set the manufacturername to innr based on the mac address prefix, but changed it after the corresponding Zigbee attribute was read.

[holdestmade]

Not the best quality sorry, all seem to be ZLL ?

Hive (Aurora)

OSRAM:

LEDVANCE (UK)

[holdestmade]

For comparison this is a working LEDVANCE and and OSRAM:

ZLL device type _Extended color light_.

The Aurora and the US LEDVANCE are ZHA _Color dimmable light_.

Maybe the API plugin set the manufacturername to innr based on the mac address prefix, but changed it after the corresponding Zigbee attribute was read.

It has been showing as INNR for about a year and only changed after latest update

[cree8]

Its strange that the color loop is not reported to be supported, yet works just fine when the above commands are sent. Sounds like a firmware thing.

Yes. Not conform the standard, but, unfortunately, not uncommon. I guess that's why the API plugin ignores the _Color Capabilities_ and uses the _Device Type_ instead.

Roger that. No ability to send the command to start color loop on multiple bulbs sucks but it isnt the end of the world.

The color temp is much more important as I have many automations that set the color of the bulbs based on the current positioning of the sun.
So is there any chance the sanity check logic could be edited so that my CT change calls work as before?
Thanks for your help on this once again.

[ebaauw]

So is there any chance the sanity check logic could be edited so that my CT change calls work as before?
Thanks for your help on this once again.

I need to have a look, but I'd rather expose ct for the light properly.

[cree8]

So is there any chance the sanity check logic could be edited so that my CT change calls work as before?
Thanks for your help on this once again.

I need to have a look, but I'd rather expose ct for the light properly.

By that, do you mean only allowing the temperature change call based on whether or not the bulb reports the current CT value? If so, that'd likely cut out the feature from a lot of bulbs in use. I can definitely understand the urge to have the feature properly implemented, because as you stated before the error reporting in deconz leaves a lot to be desired.

Maybe there could be some type of override setting available? Such as 'yes we know this bulb does not conform to the standard, click here to force the calls (CT or Color Loop or any other feature) to be sent anyway'.

I'm aware only the API section is open source so I do not fully know if this is feasible.

[djryan012]

Also confirming same issue with no ct control as of latest update using Sylvania Smart+ "Adjustable White and Full Color Flex LED"
pydeconz.errors.RequestError: /lights/12/state parameter, ct, not available using Home assistant api integration

[ebaauw]

Looking at the code, we would need to whitelist each (ZHA) color light that supports colour temperature. That's too much work for now, so we need to defer that to API v2. For now, I'll skip the ct sanity check for all lights.

Note that the bug is that the API doesn't expose state.ct.

[cree8]

Looking at the code, we would need to whitelist each (ZHA) color light that supports colour temperature. That's too much work for now, so we need to defer that to API v2. For now, I'll skip the ct sanity check for all lights.

Note that the bug is that the API doesn't expose state.ct.

Roger that.
So its less a bug with the firmware and more a bug where certain bulbs state.ct is not exposed due to them not fully being compliant with the Zigbee standard?
Also, with that in mind, is the appropriate next step to leave the issue open?

[ebaauw]

So its less a bug with the firmware and more a bug where certain bulbs state.ct is not exposed due to them not fully being compliant with the Zigbee standard?

It's a bit of both really.

• Colour temperature is a bit of a step child to Zigbee. It wasn't defined in the original ZHA spec, was added to ZLL, but without scene support (under the wrong assumption that you could translate ct to xy and store that in the scene - this doesn't hold for 5-channel RGB+CCT lights). Consequently, different vendors handle it differently;
• Not all vendors expose _Color Capabilities_ correctly (a.o. the LEDVANCE light above with value 0x0019, but still accepting _Color Loop_ commands). Consequently, the API looks at the device type to derive what capabilities the light supports. This goes well for ZLL lights, with types _Color temperature light_, _Color light_, and _Extended color light_. This goes wrong for ZHA / ZB3 lights using ZHA device types that don't take colour temperature into account, like _Color dimmable light_.
• Then, of course, there are also lights that advertise the wrong device type.

I think it's best to close this issue. We won't be working on it separately.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.