Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
masonevans opened this issue May 19, 2019 · 5 comments
Labels

Comments

@masonevans
Copy link

@masonevans masonevans commented May 19, 2019

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:

image

Node info:

image

@ebaauw

This comment has been minimized.

Copy link
Contributor

@ebaauw ebaauw commented May 19, 2019

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

This comment has been minimized.

Copy link
Author

@masonevans masonevans commented May 19, 2019

@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 comment has been minimized.

Copy link
Contributor

@ebaauw ebaauw commented May 20, 2019

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

This comment has been minimized.

Copy link
Contributor

@ebaauw ebaauw commented May 20, 2019

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).

manup added a commit that referenced this issue May 21, 2019
Fix GLEDOPTO lights not reporting the correct value for _Enhanced Color Mode_, see #1526.

I no longer have the old RGB+CCT model, so I cannot test whether it actually has the same issue, but I don't think the change will do any harm (as long as _Color Mode_ is supported).  They use manufacturer code 0x0000, so I whitelist the manufacturer name instead.
@stale

This comment has been minimized.

Copy link

@stale stale bot commented Sep 17, 2019

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.

@stale stale bot added the stale label Sep 17, 2019
@stale stale bot closed this Sep 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.