Setting color temp causes first color to change, is this by design?

Setup, Configuration and Use Scripts & Rules
, ,
1
  • Platform information:
    • Hardware: Raspberry Pi
    • OS: Rasbian latest release
    • Java Runtime Environment: buildt in in rasbpian
    • openHAB version: 2.3 stable (2.4 snapshot has a broken tellstick binding)
  • Issue of the topic: I’m using rules to set the color of a IKEA bulb, and it works, but when it changes from a either high to low brightness with a color change as well, it first changes the color, then half a second or so later it changes brightness.
TRADFRIGangnede1_Color.sendCommand(new HSBType("30,64,100")) 
TRADFRIGangnede1_Color.sendCommand(new HSBType("22,100,1"))

I also tried the same in karaf console, and it works the same way (but with string, which I also tried in the rules)

smarthome:send TRADFRIGangnede1_Color "30,64,100"
smarthome:send TRADFRIGangnede1_Color "22,100,1"

They all behave the same, first the color is changed, then half a second or so later the dimming level is changed.

I hoped and sort of expected it to be one smooth change from the one color+brightness to the next, not first set color, then set brightness.

Is this by design for all color bulbs, or just the implementation of the Trådfri binding? (If you do this from the ikea android app, it is one smooth fade from the one to the other) I don’t have a Phillips hue device, so I cannot test if this is the way openhab behaves for all color light bulbs or not.

Regards
Thorbjørn

2

This might be a bug in the newer version of something?
I have experienced this myself in my new installation, but can’t remember noticing it before!

3

Probably… I use onather binding for miLight bulbs and the changes are smooth…

4

I would ask the question on the github page for binding. Submit as an issue.

5

Hi Thorbjørn,

You are right. The TRADFRI binding splits up your color command to first send the color followed with a delay of 1 second by the brightness. I think this is not the supposed way to handle it because it should be possible to send both values at once to the TRADFRI gateway. I will try to fix it and submit a PR.

1 Like
6

I am afraid we cannot change very much. During my tests I found that the brightness value gets swallowed if I try to send them at the same time. The only change to make it a little bit smoother is to reduce the delay.

2 Likes
7

Thanks for a good answer and explanation to why this is so. A shorter delay would definitely give an impression of a smoother fade. How short can you set it before it doesn’t work properly? Or can one just remove the delay entirely?

Regards
Thorbjørn

8

The color bulb functionality in the Tradfri binding was initially implemented by me.
At least at the time of implementation this was the shortest possible delay, otherwise the brightness command will interrupt the fading to the color, and you end up with the wrong color.
Maybe this has changed since then, I didn’t checked it now.

9

Okay, then it’s just ‘by design’. I could wish for it to be different but, it works.

By the way, thank you very much for that binding! It’s made my smarthome so much cheaper to implement :wink:

10

Over time we optimized the necessary delay between two commands to 600ms. The color command was an exception. Today I did some further tests changing with it and for me it was fine reducing it to 600ms as well. I can prepare a test version for you if you like to test it.

11

Sure, I’ll give it a go. If you have a how-to, maybe I can compile it myself, and test different values.