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

TRADFRI bulb E26 WS opal 980lm reports color mode as "xy" #1861

Closed
glward opened this issue Sep 14, 2019 · 30 comments
Closed

TRADFRI bulb E26 WS opal 980lm reports color mode as "xy" #1861

glward opened this issue Sep 14, 2019 · 30 comments
Labels

Comments

@glward
Copy link

glward commented Sep 14, 2019

The REST api seems to be reporting this bulb as color mode "xy" even though it's only a color temperature bulb:

{
    "ctmax": 454,
    "ctmin": 250,
    "etag": "da6d097ee7330bd24d91488002420aef",
    "hascolor": true,
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI bulb E26 WS opal 980lm",
    "name": "Writing Desk Lamp",
    "state": {
        "alert": "none",
        "bri": 254,
        "colormode": "xy",
        "ct": 250,
        "on": true,
        "reachable": true
    },
    "swversion": "1.2.217",
    "type": "Color temperature light",
    "uniqueid": "00:0b:57:ff:fe:dd:47:63-01"
}

Setting the color temperature still works correctly, both via the REST api and the webapp, but it seems odd. Attempting to change the color mode over the REST api does not return anything, no errors or success:

glward@ares:docker/ha$ curl -H "Content-Type: application/json" -X PUT "http://IP/api/KEY/lights/8/state" -d '{"colormode": "ct"}'
glward@ares:docker/ha$
@sub0ne
Copy link

sub0ne commented Sep 15, 2019

I can confirm this. When I query my bulbs state (httpI got this in return:

{
"ctmax":65535,
"ctmin":0,
"etag":"1fccf86c78b24a8414433d4f4468960e",
"hascolor":true,
"manufacturername":"IKEA of Sweden",
"modelid":"TRADFRI bulb E27 WS opal 1000lm",
"name":"Kellerleuchte 1",
"state":{
"alert":"none",
"bri":254,
"colormode":"xy",
"ct":100,
"on":true,
"reachable":true
},
"swversion":"2.0.022",
"type":"Color temperature light",
"uniqueid":"00:0d:6f:ff:fe:03:b1:1d-01"
}

but not always...sometimes it seems to be correct:

{
"ctmax": 65535,
"ctmin": 0,
"etag": "ae2fb86af907f0be12ea8e3458e57724",
"hascolor": true,
"manufacturername": "IKEA of Sweden",
"modelid": "TRADFRI bulb E27 WS opal 1000lm",
"name": "Kellerleuchte 1",
"state": {
"alert": "none",
"bri": 254,
"colormode": "ct",
"ct": 182,
"on": true,
"reachable": true
},
"swversion": "2.0.022",
"type": "Color temperature light",
"uniqueid": "00:0d:6f:ff:fe:03:b1:1d-01"
}

@Kane610
Copy link

Kane610 commented Sep 23, 2019

@manup can we get a comment on this?

@manup
Copy link
Member

manup commented Sep 23, 2019

I think since these are are plain color temperature lights we can fix the color mode to ct.
It's similar to the LEDVANCE bulbs issue b30f4f8

Looking forward to get this fixed for 2.05.70.

@Kane610
Copy link

Kane610 commented Sep 23, 2019

Great!

It would be nice if we could separate what "hascolor": true, means to actually color and add something like a haswhitespectrum or similar while we're at it :)

@Seraphis411
Copy link

Same issue with the IKEA/TRADFRI "LEPTITER Recessed spot light" (which isn't officially listed as supported but working well besides):

"etag": "1be33fbb2d1b027fe7c7959c28e16942",
"hascolor": true,
"id": "2",
"manufacturername": "IKEA of Sweden",
"modelid": "LEPTITER Recessed spot light",
"swversion": "2.1.022",
"type": "Color temperature light",
"uniqueid": "00:0d:6f:ff:fe:19:48:17-01"

@YAMLcase
Copy link

Does anyone have a workaround until 2.05.70 comes out? My home automation's principal investor is getting upset that the closest I can come with the color slider has a green tint XD

@Flurkmark
Copy link

@manup I also would very much appreciate at least a commit to fix this. I am stuck in a project and can't write anything more until I can reliably pull ct from the light. I understand that you guys are busy, but for many people this is a major issue. Danke.

@YAMLcase
Copy link

@Flurkmark I think the fix is in for 2.05.70, we just have to wait for the build. I think this weekend I will try a manual build from the source and report back on if it works or not.

Is there a nightly available @manup ?

@Flurkmark
Copy link

@YAMLcase Have you tried a build? Version is bumped to 2.05.70, no release. I can't find anything in the commits that seems to fix this, then again I might have missed it.

@Flurkmark
Copy link

This is not fixed as of now, version 2.05.70, tried a build. Pretty bad bug for me, since I can't change color temp, kind of the reason for buying color temp lights..

@bedaes
Copy link

bedaes commented Nov 8, 2019

The same thing happens for all sizes of IKEA Floalt panels, I'm already on deCONZ 2.05.70:

{
      "ctmax":454,
      "ctmin":250,
      "etag":"0916428f1bd5fd7c6ded911b7f6047e9",
      "hascolor":true,
      "manufacturername":"IKEA of Sweden",
      "modelid":"FLOALT panel WS 30x30",
      "name":"Warehouse Panel",
      "state":{
         "alert":"none",
         "bri":10,
         "colormode":"xy",
         "ct":454,
         "on":true,
         "reachable":false
      },
      "swversion":"1.2.217",
      "type":"Color temperature light",
      "uniqueid":"00:0d:6f:ff:fe:1b:c3:61-01"
   },

@Flurkmark
Copy link

@manup
zcl_tasks.cpp line 384
If I comment
useXy = useXy || task.lightNode->manufacturerCode() == VENDOR_IKEA;
they work as expected, at least so far as I have tested.

@sverleysen
Copy link

I'm having the same issue

@Nicxe
Copy link

Nicxe commented Nov 23, 2019

I have the same issue

@Jpsy
Copy link

Jpsy commented Dec 30, 2019

Same issue here.
In Home Assistant this results in CT lamps not reporting back any color temperature at all.
I just migrated a group of lamps from a Hue bridge to a Conbee stick, just to find that all my automations are broken (because they rely on the bulbs reporting back their current color temp). Very annoying.
I am using latest HA (0.103.5) and latest HA deCONZ add-on (5.0).

@guennikasse
Copy link

Same issue here.
If I change the color_temp using a TRADFRI Switch the color is displayed as attributes in Home Assistant. If I use the slider in HA color_temp attributes disappears.
I am using latest HA (0.103.5) and latest HA deCONZ add-on (5.0).

@jensflorian
Copy link

jensflorian commented Jan 7, 2020

Same issue here with IKEA Floalt 30x30 panels using deCONZ 2.05.72. In phoscon app, color temperature slider works as expected, but after connecting TRADFRI or Hue Dimming switches, setting color temperature to cooler on switches is unresponsive and results in mismatch of bulbs reporting back their current color temp and actual color state.

EDIT: I think issue 2068 is related.

@jdeluyck
Copy link

jdeluyck commented Jan 16, 2020

Same issue with TRÅDFRI bulb E14 opal 400lm lamps...
@manup is there any update on this?

@alexlopezcifuentes
Copy link

Same issue here with an Ikea Bulb. When Home Assistant is restarted the attribute "color_temp" is enabled. However, every time I use it in automation it disappears...

@sverleysen
Copy link

@manup
zcl_tasks.cpp line 384
If I comment
useXy = useXy || task.lightNode->manufacturerCode() == VENDOR_IKEA;
they work as expected, at least so far as I have tested.

Does this still fixes this issue? Or did you encounter some other issues with this change?
How can I implement this in my own setup?

@Flurkmark
Copy link

Flurkmark commented Feb 7, 2020

@sverleysen

It fixes it, I'm still on .69 since it's stable for me.
Follow the docs on how to compile the plugin, first installing the .deb
Just delete the mentioned line.

It was supposed to be a fix for deconz build in scenes afaik. I don't use them, but I guess they will missbehave with IKEA light after the fix.

@sverleysen
Copy link

@manup, any update?
This would be fixed in 2.05.70, I installed 2.05.74 today but it's still not fixed.

@llonca13
Copy link

llonca13 commented Feb 28, 2020

@Kane610 @manup any plans on fixing this? Just some feedback would be great to know is this being worked on, or we should start looking for alternatives (new bulbs etc)...
thanks

home-assistant/core#14554 (comment)
does this fix solves this problem?

@sverleysen
Copy link

I have made a PR for this fix. Hopefully they will merge it.
#2507

@Flurkmark
Copy link

I have made a PR for this fix. Hopefully they will merge it.
#2507

I didn’t do it initially, since I thought it would be fixed quickly after I found it. Hopefully it will get attention now. They should just back out the commit that introduced it and redo the scene fix in my opinion. Fingers crossed...

@miki9987
Copy link

miki9987 commented Mar 2, 2020

Even with this fix I still don't get color_temp reported back..
home-assistant/core#26424
home-assistant/core#24143

@straaat
Copy link

straaat commented Apr 4, 2020

I have this issue as well. Very annoying. If I VNC into deCONZ I can set the color temperature using the color control cluster of the light. It then also shows the correct value in Home Assistant/OpenHAB.

But it seems the Phoscon interface as well as the connected Home Assistant do not set a color temperature value but a XY value instead...

@ebaauw
Copy link
Collaborator

ebaauw commented Apr 4, 2020

See #2507

@DerOetzi
Copy link
Contributor

Same issue with all my GU10 WS TRADFRI lamps. Investigated on this and found following behavior:

  1. Deconz started: all lamps send correct => colormode: ct, ct value reported correctly via REST API
  2. Phoscon app change color temperature of group => colormode:ct, ct value reported correctly
  3. Phoscon app or Postman request to single lamp => colormode: xy, ct not changing in report
    Can repeat 3 as often as I want colormode stays for this lamp at xy and not reporting ct value changes
  4. Phoscon app change color temperature of group => all lamps in group switch back to colormode: ct and reporting correct ct value

Hope this helps for finding a solution

@stale
Copy link

stale bot commented Jun 8, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests