Deconz-rest-plugin: Scene won't set `ct` for Color temperature light

Created on 16 Jul 2017 · 22Comments · Source: dresden-elektronik/deconz-rest-plugin

I have two OSRAM E14 Colour temperature lights (from the time before Philips released their E14 bulbs). I cannot set their colour temperature using a scene.

Here's the transcript of what I do (using my ph.sh bash script, which is just a wrapper around curl):

$ ph_put /groups/240/action '{"on":true,"bri":254,"ct":370}'
$ ph_put /groups/240/scenes/1/store '{"transitiontime":4}'
$ ph_get /groups/240/scenes/1
{
  "lights": [
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "id": "244",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "id": "241",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "id": "242",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "id": "243",
      "on": true,
      "transitiontime": 4
    }
  ],
  "name": "default",
  "state": 0
}
$ ph_put /groups/240/action '{"on":true,"bri":1,"ct":250}'
$ ph_put /groups/240/scenes/1/recall
$ ph_get /lights/243/state
{
  "alert": "none",
  "bri": 254,
  "colormode": "ct",
  "ct": 370,
  "on": true,
  "reachable": true
}

The scene seems to contain the correct light states. When recalling the scene, the API reports the issued values (from the scene). However, the OSRAM bulbs actually have a ct value of 153. After having polled the lights, deCONZ reflects this:

$ ph_get /lights/243/state
{
  "alert": "none",
  "bri": 254,
  "colormode": "ct",
  "ct": 153,
  "on": false,
  "reachable": true
}

Oddly this works, when using a similar setup for my Hue extended color lights. I'm not sure if this is caused by the OSRAM bulbs, or whether it's deCONZ issue with colour temperature lights. It might be related to issue #30 point 3: I see colorloop and xy are specified in the scenes table in the database (my formatting):

[
  {
    "bri": 254,
    "cl": false,
    "clTime": 0,
    "cm": "ct",
    "ct": 370,
    "lid": "244",
    "on": true,
    "tt": 4,
    "x": 30091,
    "y": 26912
  },
  {
    "bri": 254,
    "cm": "none",
    "lid": "241",
    "on": true,
    "tt": 4
  },
  {
    "bri": 254,
    "cm": "none",
    "lid": "242",
    "on": true,
    "tt": 4
  },
  {
    "bri": 254,
    "cl": false,
    "clTime": 0,
    "cm": "ct",
    "ct": 370,
    "lid": "243",
    "on": true,
    "tt": 4,
    "x": 30091,
    "y": 26912
  }
]

WONTFIX stale

Source

ebaauw

Most helpful comment

It’s a combination of a weird interpretation of the ZigBee standard on the IKEA side, and poor handling by deCONZ. I have good hopes it can be fixed at the deCONZ side, but it will take some time. I’m not too familiar with the code supporting lights and Manuel is traveling and will want to work on the stability issues first.

ebaauw on 6 Jan 2018

👍2

All 22 comments

I added the Ikea Trådfri to the group and scene, and the ct value for this bulb is set correctly. _However, it reports colormode xy after recalling the scene?!_ My guess would be that deCONZ translates the ct value to xy values (but why?!), which somehow results in out-of-range values for the OSRAM bulbs.

Here's the scene with the Trådfri added:

$ ph_get /groups/240/scenes/1
{
  "lights": [
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "id": "244",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "id": "241",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "id": "242",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 370,
      "id": "243",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 454,
      "id": "101",
      "on": true,
      "transitiontime": 4
    }
  ],
  "name": "default",
  "state": 0
}

The database now contains:

[
  {
    "bri": 254,
    "cl": false,
    "clTime": 0,
    "cm": "ct",
    "ct": 370,
    "lid": "244",
    "on": true,
    "tt": 4,
    "x": 30091,
    "y": 26912
  },
  {
    "bri": 254,
    "cm": "none",
    "lid": "241",
    "on": true,
    "tt": 4
  },
  {
    "bri": 254,
    "cm": "none",
    "lid": "242",
    "on": true,
    "tt": 4
  },
  {
    "bri": 254,
    "cl": false,
    "clTime": 0,
    "cm": "ct",
    "ct": 370,
    "lid": "243",
    "on": true,
    "tt": 4,
    "x": 30091,
    "y": 26912
  },
  {
    "bri": 254,
    "cl": false,
    "clTime": 25,
    "cm": "ct",
    "ct": 454,
    "lid": "101",
    "on": true,
    "tt": 4,
    "x": 33112,
    "y": 27216
  }
]

Here's the lights (after reading the attributes of the 0x0300 clusters in de deCONZ GUI):

$ ph_get /lights
{
  "101": {
    "etag": "33b16ad8423e361f0a926c5a756fd623",
    "hascolor": true,
    "manufacturer": "IKEA of Sweden",
    "modelid": "TRADFRI bulb E27 WS�opal 980lm",
    "name": "Trådfri",
    "state": {
      "alert": "none",
      "bri": 254,
      "colormode": "xy",
      "ct": 454,
      "on": true,
      "reachable": true
    },
    "swversion": "1.1.1.1-5.7.2.0",
    "type": "Color temperature light",
    "uniqueid": "00:0b:57:ff:fe:39:35:7f-01"
  },
  "241": {
    "etag": "919310d5ebeac0790c7ead7e0f5dd218",
    "hascolor": false,
    "manufacturer": "innr",
    "modelid": "UC 110",
    "name": "Kitchen Sink Left",
    "state": {
      "alert": "none",
      "bri": 254,
      "on": true,
      "reachable": true
    },
    "swversion": "0x10000c46",
    "type": "Dimmable light",
    "uniqueid": "00:15:8d:00:00:cd:d7:f7-01"
  },
  "242": {
    "etag": "919310d5ebeac0790c7ead7e0f5dd218",
    "hascolor": false,
    "manufacturer": "innr",
    "modelid": "UC 110",
    "name": "Kitchen Sink Right",
    "state": {
      "alert": "none",
      "bri": 254,
      "on": true,
      "reachable": true
    },
    "swversion": "0x10000c46",
    "type": "Dimmable light",
    "uniqueid": "00:15:8d:00:00:7e:2f:eb-01"
  },
  "243": {
    "etag": "d593ac7cdeaa0a6e2cb7aa96533b9865",
    "hascolor": true,
    "manufacturer": "OSRAM",
    "modelid": "Classic B40 TW - LIGHTIFY",
    "name": "Kitchen Stove Left",
    "state": {
      "alert": "none",
      "bri": 254,
      "colormode": "ct",
      "ct": 153,
      "on": true,
      "reachable": true
    },
    "swversion": "V1.04.12",
    "type": "Color temperature light",
    "uniqueid": "84:18:26:00:00:07:f8:12-03"
  },
  "244": {
    "etag": "182a1b395624560d46a7aaeca61f5083",
    "hascolor": true,
    "manufacturer": "OSRAM",
    "modelid": "Classic B40 TW - LIGHTIFY",
    "name": "Kitchen Stove Right",
    "state": {
      "alert": "none",
      "bri": 254,
      "colormode": "ct",
      "ct": 153,
      "on": true,
      "reachable": true
    },
    "swversion": "V1.04.12",
    "type": "Color temperature light",
    "uniqueid": "84:18:26:00:00:0a:56:4d-03"
  }
}

ebaauw on 16 Jul 2017

My guess would be that deCONZ translates the ct value to xy values.

Indeed. Here's what happens with the Hue Extended color lights.

$ ph_put /groups/230/action '{"on":true,"bri":254,"ct":463}'
$ ph_put /groups/230/scenes/1/store '{"transitiontime":4}'
$ ph_get /groups/230/scenes/1
{
  "lights": [
    {
      "bri": 254,
      "id": "234",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 463,
      "id": "232",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 463,
      "id": "233",
      "on": true,
      "transitiontime": 4
    },
    {
      "bri": 254,
      "colormode": "ct",
      "ct": 463,
      "id": "231",
      "on": true,
      "transitiontime": 4
    }
  ],
  "name": "default",
  "state": 0
}
$ ph_put /groups/230/scenes/1/recall
$ ph_get /lights/231/state
{
  "alert": "none",
  "bri": 254,
  "colormode": "ct",
  "ct": 463,
  "effect": "none",
  "hue": 13158,
  "on": true,
  "reachable": true,
  "sat": 208,
  "xy": [
    0.511007,
    0.416535
  ]
}
# read attributes of the 0x0300 cluster in deCONZ GUI
$ ph_get /lights/231/state
{
  "alert": "none",
  "bri": 254,
  "colormode": "xy",
  "ct": 459,
  "effect": "none",
  "hue": 13158,
  "on": true,
  "reachable": true,
  "sat": 209,
  "xy": [
    0.511589,
    0.41675
  ]
}

ebaauw on 16 Jul 2017

which somehow results in out-of-range values for the OSRAM bulbs

Or the OSRAMs simply don't accept a change to xy. Using other values for ct doesn't work either.

ebaauw on 16 Jul 2017

I saw that the OSRAM lights do support attribute reporting in commit https://github.com/dresden-elektronik/deconz-rest-plugin/commit/887e6b121640109c1e1f7ef6f7f4743e69648b24. I'm still on 2.04.57, but I managed to configure attribute reporting manually for the 0x0300 cluster. I now receive multiple websocket notifications when recalling the scene:

Sat Jul 29 2017 19:37:08: {"e":"changed","id":"244","r":"lights","state":{"ct":370},"t":"event"}
Sat Jul 29 2017 19:37:08: {"e":"changed","id":"243","r":"lights","state":{"ct":370},"t":"event"}
Sat Jul 29 2017 19:37:08: {"e":"changed","id":"243","r":"lights","state":{"ct":153},"t":"event"}
Sat Jul 29 2017 19:37:09: {"e":"scene-called","gid":"240","r":"scenes","scid":"1","t":"event"}
Sat Jul 29 2017 19:37:09: {"e":"changed","id":"243","r":"lights","state":{"ct":370},"t":"event"}
Sat Jul 29 2017 19:37:09: {"e":"changed","id":"243","r":"lights","state":{"ct":153},"t":"event"}
Sat Jul 29 2017 19:37:11: {"e":"changed","id":"244","r":"lights","state":{"ct":153},"t":"event"}

The scene actually contains "ct": 370 and deCONZ sets the state to that value upon recalling the scene (so it actually thinks it's sending 370 to the light?). However, the lights turn to ct 153, which deCONZ now sees through the attribute reporting.

ebaauw on 29 Jul 2017

We have seen various problems with OSRAM scenes and ct, also when switching between xy and ct. Maybe the reporting can help here to reduce the issues.

manup on 30 Jul 2017

These are colour temperature lights, which don't support xy. Reporting helps showing the actual value, after recalling the scene, but the lights still have the wrong value after recalling the scene.

The issue isn't with recalling the scene, though; it's with storing it. When I store the scene per light from the deCONZ GUI, the correct ct value is set, even when subsequently recalling the scene from the REST API.

ebaauw on 30 Jul 2017

This also happens with the IKEA GU 10 Color Temperature lights.

{
    "ctmax": 454,
    "ctmin": 250,
    "manufacturername": "IKEA of Sweden",
    "modelid": "TRADFRI bulb GU10 WS 400lm",
    "state": {
        "alert": "none",
        "bri": 1,
        "colormode": "ct",
        "ct": 454,
        "on": true,
        "reachable": true
    },
    "swversion": "1.2.217",
    "type": "Color temperature light"
...
}

Recalling a saved scene doesn't restore the color temperature. Probably because the color temperature isn't stored. When I set the light to state:

{
    "on": true,
    "bri": 1,
    "ct": 454,
    "transitiontime": 0
}

only 4 of the leds in the bulb are on. After that I store the light state in a scene. After changing the light color and recalling the stored scene all leds in the bulb are on and the REST API shows the following state:

    "state": {
        "alert": "none",
        "bri": 1,
        "colormode": "xy",
        "ct": 370,
        "on": true,
        "reachable": true
    }

snozzlebert on 23 Oct 2017

Odd, I wouldn’t expect different IKEA lights to behave differently, but maybe it’s the newer firmware. I’ll retest my E27 white spectrum.

ebaauw on 24 Oct 2017

I can verify this exact same behaviour for "TRADFRI bulb E27 WS opal 980lm" (Version 1.2.217) bulbs, meaning that I cannot use scenes with deconz if I ever want to have different color than ct 370.

What is the current state on this? Is it a bug on IKEAs side or can this be fixed in deconz?

tpetri on 6 Jan 2018

ebaauw on 6 Jan 2018

👍2

I'm seeing the opposite behavior with the TRADFRI bulb E27 WS opal 980lm bulbs. If I change color temperature and brightness in the same REST API call, then only the color temperature changes (querying state over the REST API indicates that deCONZ believes the brightness did change though). Changing the parameters separately works. I'm not familiar with the Zigbee protocol but the intuition I get is that one of the two updates is being lost before it is sent across the Zigbee network. I don't see why deCONZ would need to query the bulb state between setting the two parameters.

Edit: It seems the rabbit hole goes a bit deeper than just being a deCONZ issue? https://community.home-assistant.io/t/ikea-light-on-hue-hub-scene-doesnt-change-brightness/32755

mattiasflodin on 11 Mar 2018

Scenes in the IKEA bulbs have indeed a bug for some reason the color temperature is not restored to the value stored in the scene. I'm not sure if the issue can be fixed on deCONZ side, needs more testing. Scenes can be created and stored in various ways maybe IKEA does support one of them.

manup on 11 Mar 2018

I have been able to setup the scenes for me and they are working as intended as far as I can tell.
If you define the color temperature manually through the REST API by setting x,y color (needs some experimenting to get the temperature that you want) and the brightness manually and then store the scene manually by using the REST API, you get the correct expected behaviour when recalling the scenes (e.g. also the transition at the same time of brightness and color).

Edit: I'm referring to the IKEA E27 WS opal 980lm bulbs

tpetri on 12 Mar 2018

👍1

I can confirm the observation of @tpetri for the IKEA TRADFRI bulb GU10 WS 400lm lights. See my comment in December: https://github.com/dresden-elektronik/deconz-rest-plugin/commit/e0513b14bb956e3199572653c5b324c6bf3eb23f#commitcomment-26187674
While it is a color temperature light, only x,y values seems to be stored for scenes.

snozzlebert on 12 Mar 2018

Good find, we can build a workaround on top of that.

manup on 12 Mar 2018

I apologize if I'm simply being ignorant of how the protocol works, but I don't have any issues setting the color temperature of the Tradfri bulb — _as long as I don't set the brightness in the same API call_. I.e. sending:

{"on": true, "ct": 400}

to the state endpoint works just fine. But if I send

{"on": true, "ct": 400, "bri": 200}

then it misbehaves.

mattiasflodin on 12 Mar 2018

If I click on my ikea remote group via the web interface and change temperature not with the temperature slide but with the color slide then I get the temperature stored in the scene with my ikea bulbs

bootstrapbats on 12 Mar 2018

@mattiasflodin that is correct, setting the temperature with ct works, but if you want to store it as a scene, this will fail. Maybe the same reason why setting ct and bri at once does not work, I haven't actually tried setting xy together with bri, if that works, this would be the solution for a workaround indeed.

tpetri on 13 Mar 2018

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[bot] on 23 Nov 2018

This topic actually diverted into two issues, neither of which as been solved:

The original issue that scenes for OSRAM lights don't set ct, because deCONZ stores the xy values instead of the ct values. One of my OSRAM bulbs actually broke, and I replaced both by Hue bulbs. I still have the working one, though, if we need some more testing.
_Not the same issue_ of a bug in the IKEA firmware, that the light doesn't accept new commands when a transition is still underway. Combined with a default transition time of 0.4 sec added by the deCONZ REST API, this causes the light to ignore the ct in a PUT of both bri and ct. As workaround, specify a transitiontime of 0, or issue two separate request (causing the ct to arrive just late enough at the light. See also #894, #384,

ebaauw on 24 Nov 2018

In my case the issue with IKEA bulbs was that when storing a scene, the bulbs would store the color if and only if it was set with xy. If the ct value was used the temperature was not (or wrongly) stored. No connection to transition times, at least for me and as far as I understand/see. I haven't been checking if something has changed to this end (never touch a running system ;)).

tpetri on 24 Nov 2018

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[bot] on 24 Mar 2019

Was this page helpful?

0 / 5 - 0 ratings