Command colorloop results in error 951

[danube]

Does the issue really belong here?

• I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

• I have searched the existing issues and there is none for the bug at hand

Describe the bug

Sending PUT .../lights/6/state with a payload {"effect":"colorloop"} results in

[
    {
        "error": {
            "address": "/lights/6/state/effect",
            "description": "Internal error, 951",
            "type": 901
        }
    }
]

where GET .../lights/6 results in

{
    "capabilities": {
        "alerts": [
            "none",
            "select",
            "lselect"
        ],
        "color": {
            "modes": []
        }
    },
    "colorcapabilities": 0,
    "config": {
        "groups": [
            "0",
            "26",
            "29"
        ]
    },
    "etag": "5410078df61c3d3126a8a0f13bd0c0a6",
    "hascolor": true,
    "lastannounced": null,
    "lastseen": "2024-10-21T09:04Z",
    "manufacturername": "Philips",
    "modelid": "LLC011",
    "name": "Tischlampe 2",
    "state": {
        "alert": "none",
        "bri": 0,
        "colormode": "hs",
        "effect": "none",
        "hue": 0,
        "on": true,
        "reachable": true,
        "sat": 0,
        "xy": [
            0,
            0
        ]
    },
    "swversion": "0x420067D5",
    "type": "Color light",
    "uniqueid": "00:17:88:01:00:1e:b3:25-0b"
}

I have some more color bulbs in the network. The same error occurs on each of them. So here's the API response for "Get all lights" call GET .../lights: https://pastebin.com/75Px7Gcs

I learned somewhere here, that error 951 means something like "bridge busy", but the network itself works quite fine.

Steps to reproduce the behavior

Sending PUT .../lights/6/state with a payload {"effect":"colorloop"}

Expected behavior

Colorloop starts

Screenshots

No response

Environment

• Host system: Raspberry Pi 4b
• Running method: Raspbian
• Firmware version: 26530900
• deCONZ version: 2.28.1
• Device: ConBee III
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? If so: USB storage

deCONZ Logs

No response

Additional context

No response

[ebaauw]

This is an old ZLL Gamut-A light, that should be handled by the light_zll_A.json DDF. But, by the looks of it, it's exposed through legacy code? Also, the Color Control attributes have never been read, as indicated by colorcapabilities being zero.

I can set colorloop on my Hue Boom, exposed by that DDF, in v2.28.1 without any issue.

951 means that the REST API plugin couldn't queue the Zigbee command, which could be because the bridge is busy, but also because of some internal error (like invalid command parameters). I think this might be caused by the value of colorcapabilities not being available, causing the logic queueing the command to think the light doesn't support colorloop.

Could you try and read the Color Control cluster attributes in the GUI, confirm that the API reports a non-zero colorcapabilities and retry?

[danube]

Hell yeah that worked! I figure I should do this with every single color bulb in my environment reporting 0 under colorcapabilities?

Is this a bug? Or have I done something wrong?

[ebaauw]

I figure I should do this with every single color bulb in my environment reporting 0 under colorcapabilities?

Indeed.

Is this a bug?

I would expect deCONZ to read this on pairing, and persist the value to the database. If you restart deCONZ too soon after pairing, the value might not yet be persisted in the database, and it needs to be re-read after restart. I suppose that, apparently, this doesn't happen, could be considered a bug in the legacy code, but we're not going to touch that.

Or have I done something wrong?

Not sure. I'm suspicious that the light isn't exposed by DDF (which would force the re-read). It could also be that the light runs on ancient firmware (the swversion value seems odd), that isn't supported by the DDF. You might try and update its firmware. The latest version is v67.116.3, but I haven't yet located the download location of this firmware. However, the semi-latest version linked on https://github.com/Koenkk/zigbee-OTA should cause the DDF to match.