deCONZ reporting xy mode & sending updates every ~10 seconds for GLEDOPTO RGB-CCT (GL-C-008) when in color temp mode

[masonevans]

I recently migrated a GELDOPTO RGB-CCT LED Strip controller to deCONZ (GL-C-008). Things are working mostly fine however there's one small issue that I've noticed. When the controller is in color temp mode deCONZ is sending an update notification every 10 seconds even though nothing is changing. deCONZ is also reporting that the light is in xy mode in these updates, although the color of the light doesn't change.

I noticed this because Home Assistant/pydeconz was showing a device update every 10 seconds over the web socket although the output of the device state didn't actually change. I was able to verify by hitting the REST API and seeing that the etag for the light resource was changing every 10 seconds but, again, nothing in the actual REST response is different.

This behavior stops when putting the controller into RGB mode and starts again when I put the controller back into color temp mode.

This is what I get back from the REST API if I query it right after putting the light into ct mode:

{
    "ctmax": 65535,
    "ctmin": 0,
    "etag": "6bc65e820b7c97c087b6f4cacd8ecf8c",
    "hascolor": true,
    "manufacturername": "GLEDOPTO",
    "modelid": "GL-C-008",
    "name": "Living Room LED",
    "state": {
        "alert": "none",
        "bri": 231,
        "colormode": "ct",
        "ct": 457,
        "effect": "none",
        "hue": 10240,
        "on": true,
        "reachable": true,
        "sat": 243,
        "xy": [
            0.432,
            0.497
        ]
    },
    "swversion": "1.0.6",
    "type": "Extended color light",
    "uniqueid": "00:12:4b:00:1b:92:33:f3-0b"
}

And this is what came back a few seconds later, without me changing anything and without the light changing colors (notice color mode switched to xy):

{
    "ctmax": 65535,
    "ctmin": 0,
    "etag": "56a125aeb0c4337f30996daa9e32979f",
    "hascolor": true,
    "manufacturername": "GLEDOPTO",
    "modelid": "GL-C-008",
    "name": "Living Room LED",
    "state": {
        "alert": "none",
        "bri": 231,
        "colormode": "xy",
        "ct": 457,
        "effect": "none",
        "hue": 10240,
        "on": true,
        "reachable": true,
        "sat": 243,
        "xy": [
            0.432,
            0.497
        ]
    },
    "swversion": "1.0.6",
    "type": "Extended color light",
    "uniqueid": "00:12:4b:00:1b:92:33:f3-0b"
}

And from the REST API a few seconds later, again with nothing changing, but a new etag:

{
    "ctmax": 65535,
    "ctmin": 0,
    "etag": "7121a42b4aefb027dbc5078f5e32b617",
    "hascolor": true,
    "manufacturername": "GLEDOPTO",
    "modelid": "GL-C-008",
    "name": "Living Room LED",
    "state": {
        "alert": "none",
        "bri": 231,
        "colormode": "xy",
        "ct": 457,
        "effect": "none",
        "hue": 10240,
        "on": true,
        "reachable": true,
        "sat": 243,
        "xy": [
            0.432,
            0.497
        ]
    },
    "swversion": "1.0.6",
    "type": "Extended color light",
    "uniqueid": "00:12:4b:00:1b:92:33:f3-0b"
}

Basic device info:

Node info:

[ebaauw]

I suspect an issue with deCONZ checking both the Color Mode and Enhanced Color Mode attributes, where the light exposes both, but only updates one. I need to do some testing to confirm, but it might be a couple of days before I’ll have the time. What attributes are included in the notifications after you set websocketnotifyall to false?

[masonevans]

@ebaauw Here's what I get in my Home Assistant logs after setting websocketnotifyall to false. The first entry is me putting it into ct mode, then the rest fire on their own.

2019-05-19 16:04:11 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"6","r":"lights","state":{"colormode":"ct","ct":442},"t":"event","uniqueid":"00:12:4b:00:1b:92:33:f3-0b"}
2019-05-19 16:04:15 DEBUG (MainThread) [pydeconz.deconzdevice] LED: update colormode with xy
2019-05-19 16:04:15 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"6","r":"lights","state":{"colormode":"xy"},"t":"event","uniqueid":"00:12:4b:00:1b:92:33:f3-0b"}
2019-05-19 16:04:22 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"6","r":"lights","state":{"colormode":"xy"},"t":"event","uniqueid":"00:12:4b:00:1b:92:33:f3-0b"}
2019-05-19 16:04:31 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"6","r":"lights","state":{"colormode":"xy"},"t":"event","uniqueid":"00:12:4b:00:1b:92:33:f3-0b"}

[ebaauw]

This confirms my suspicion. The first entry is the REST API plugin updating its cache when sending the command to set the colour temperature; the other entries are the REST API plugin reading the value while polling the light. On checking the first Color Mode attribute, the plugin changes colormode to ct; on checking the second attribute, it changes it back to xy. The event publising routine uses the last (current) value, and filters out one of the changes, because it’s already included the attribute (there’s probably a message in the deCONZ log for that, with the right debug settings).

If you check the Color control cluster in the deCONZ GUI, you should see a discrepancy between attributes 0x0008 and 0x4001: one reflecting ct and the other xy.

[ebaauw]

I can reproduce the issue. Enhanced Color Mode continues to report xy, where Color Mode correctly reports ct. Unfortunately, Color Capabilities includes enhanced hue and saturation, so there's no clue that Enhanced Color Mode wouldn't work. I see no other option than to whitelist GLEDOPTO lights, ignoring Enhanced Color Mode, (like Color Mode is ignored for IKEA lights).

[stale]

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.