Deconz-rest-plugin: Cannot set brightness when setting ct/xy in the same PUT request on Ikea lamps

Created on 25 Oct 2020  ·  3Comments  ·  Source: dresden-elektronik/deconz-rest-plugin

Describe the bug

When setting "bri" while also setting "ct" or "xy" on the light state, the light shortly changes it's brightness to the desired state and then changes back to the old state. Without "ct" or "xy" in the request the brightness is changed correctly.

When getting the current state of the light the API however returns the new brightness value.

I could reproduce the behaviour on "TRÅDFRI bulb E27 CWS opal 600lm" and "FLOALT panel WS 30x30".

Steps to reproduce the behavior

  1. Identify the light id for an above mentioned light (in my case it's 7)
  2. Initially set "ct", "bri" and "on": curl http://deconz:8080/api/${APIKEY}/lights/7/state -X PUT -H "application/json" -d '{"ct": 153, "bri": 1, "on": true}'
  3. Change "ct" and "bri". The lights color temperature will change, however the brightness becomes only briefly brighter and resets to the previous "bri" value: curl http://deconz:8080/api/${APIKEY}/lights/7/state -X PUT -H "application/json" -d '{"ct": 250, "bri": 255}'
  4. Get the current light state and notice that "bri" is set to 254: curl http://deconz:8080/api/${APIKEY}/lights/7

Expected behavior

Deconz should change "ct"/"xy" and "bri" in a single request for Ikea lamps.

Above mentioned steps work just fine with my "Philips Hue LightStrip Plus".

Environment

  • Host system: Raspberry Pi
  • Running method: Marthoc Docker container
  • Firmware version: 26660700
  • deCONZ version: 2.05.84
  • Device: ConBee II
  • Do you use an USB extension cable: no
  • Is there any other USB or serial devices connected to the host system? If so: Which?

    • I have a small OLED attached to the RPi GPIO SCL and SDA

deCONZ Logs

These logs are generated when triggering curl http://deconz:8080/api/${APIKEY}/lights/7/state -X PUT -H "application/json" -d '{"ct": 250, "bri": 255}'

engine_1  | 18:52:18:935 skip binding for attribute reporting of ep: 0x00 cluster 0x1000 (end-device might sleep)
engine_1  | 18:52:19:735 delay sending request 220 dt 0 ms to 0xCCCCCCFFFEE2EF4A, ep: 0x01 cluster: 0x0300 onAir: 1
engine_1  | 18:52:19:789        0xCCCCCCFFFEE2EF4A force poll (2)
engine_1  | 18:52:19:879        0xCCCCCCFFFEE2EF4A force poll (2)
engine_1  | 18:52:19:884 ZCL attribute report 0xCCCCCCFFFEE2EF4A for cluster: 0x0300, ep: 0x01, frame control: 0x08, mfcode: 0x0000

Additional context

Currently I have 24 devices in my zigbee network. 7 sensors (Xiaomi/Aqara, Ikea), 4 switches (Ikea), 13 lights (Ikea, Philips, Osram/Ledvance).

Bug report

All 3 comments

Hi there. Thank you for filing this issue. Unfortunately, we cannot help you, because the required information is missing. Please open a new issue, using the template to provide all information.

Hi there. Thank you for filing this issue. Unfortunately, we cannot help you, because the required information is missing. Please open a new issue, using the template to provide all information.

You don't want to remove headers - the bot chokes on that.

This is a known limitation of the IKEA firmware: it doesn't accept another command, when the previous command is still transitioning. With the default transitiontime of 0.4 seconds the second command simply arrives too quickly. Either add "transtiontime": 0 to the PUT body, or split it into two PUTs (one for on and bri vs one for ct or xy).

Was this page helpful?
0 / 5 - 0 ratings