[HUE] Support for Tradfri RGB Bulb

[eiGelbGeek]

The Tradfri RGB Bulb supports no CIE Commands, only XY Commands! Please Add an Work A Round for this Bulb... perhaps transform the CIE Commands from Openhab to XY Commands. I don't look into the Code of the Tradfri Binding, but I think they do this Transformation to get it worked.

[kaikreuzer]

Not sure what you are trying to say here. The hue Binding does all accesses through the hue bridge, which comes with its own REST API. And afaik, this REST API does not differ whether you are controlling a hue, a lightify or a tradfri bulb through it.

Do you have any log files that show that something isn't working as expected?

[eiGelbGeek]

If I expected correct the Binding send the Commands in CIE Color Mode? Right? The Tradfri Bulbs don't support this Commands, they need Commands in XY Color Mode.

Here the link to the Thread

https://community.openhab.org/t/hue-colorpicker-not-working/38044/14

There are two Screenshots from me ... I hope you understand now the Problem :-)

There are no Error in Log Files.

[kaikreuzer]

So what you are saying is that the REST API of the hue bridge indeed requires different kinds of requests for bulbs from different vendors? The official docs (https://www.developers.meethue.com/documentation/lights-api#16_set_light_state) do not state anything like that. Maybe it would be worth to first discuss at their forum whether this is a bug or indeed intended that way?

[eiGelbGeek]

Yes that is what I want to explain.

I think Point: - 1.6.2. Body arguments - in the Documentation - makes the difference. I think the HUE Binding sends hue,sat,bri and the Tradfri RGB Bulb don't support this. The Tradfri RGB Bulb needs the xy coordinates.

[eiGelbGeek]

Controll the Tradfri RGB Bulb with the HUE App works perfectly.

[kaikreuzer]

My point is that the client cannot/shouldn't really know about the exact bulb type - the Philips REST API should do the conversion in such a case. If you find any discussion around that at the hue developer forum, it would be helpful.

[BasvanH]

I have two types of Ikea Tradfri lamps bound to the Hue bridge.

TRADFRI_bulb_GU10_WS_400lm / 0220 TRADFRI_bulb_E27_CWS_opal_600lm / 0200

I experience the same as @eiGelbGeek . Setting Color_temperature and Color doesnt work, only on/off and brightness.

[eiGelbGeek]

TRADFRI_bulb_E27_CWS_opal_600lm / 0200

I think there is the Bug .... it is a 210 and not 200 Bulb ....

@kaikreuzer I think this must be fixed by Phillips or Ikea .... or must this fixed in the Binding ? (Controll in Phillips App works)

[kaikreuzer]

@eiGelbGeek Good catch. This is indeed a bug in the Tradfri bulb firmware. Even the Tradfri gateway reaches this information through, so the Tradfri binding has a special check for the exact model in place in order to determine the correct thing type. I'm afraid, we do not have that model information available in the hue binding, though...

Did you try to configure your bulbs textually (where you can specifically assign them the 210 thing type)? Would be a good check whether it all works as expected in that case.

[eiGelbGeek]

I try now textually .... Bulb come up as 210. But Color Change not Work.

I think here is a PR that can fix the Problem... https://github.com/eclipse/smarthome/pull/4959

[BasvanH]

According to @kaikreuzer , https://github.com/eclipse/smarthome/pull/4959 has nothing to do with this issue. Question is then, who can make the necessary adjustments to the HUE binding so it can control the color of the Tradfri bulbs. (As the HUE app can control them fully, the issue should be solved in the binding.)

[eiGelbGeek]

@BasvanH are you sure that the PR #4959 has nothing to with this ?

The Ikea Tradfri RGB Bulb accept only CIE XY and no HSB Types .... and Openhab sends HSBTypes ....

The linked PR is a conversion from HSB to XY and from XY to HSB ...that exactly what we need for the Binding .... The PR is a global Implementation, so not every Binding who need the conversion, must implement this for its own ...

That the HUE App can controll fully, is that the HUE App can send CIE XY and HSB Types ....

Another Solution is Ikea fixed his crappy Firmware ;-)

Correct me if a wrong .....

[kaikreuzer]

Guys, #4959 is only about being able to convert the HSBType to XY values - these are merely helper methods. The hue binding isn't touched in that PR, so why would you expect that it suddenly behaves differently? The question still remains: How is the hue binding supposed to know how to use the Philips hue REST API, if the correct use depends on the model of the bulb?

[eiGelbGeek]

Okay, so the hue binding would have to resort to this helper method. The manufacturer of a lamp can be queried via the HUE REST Api. Probably it would be easier and better if Ikea would offer decent firmware.

[BasvanH]

Probably it would be easier and better if Ikea would offer decent firmware.

I do not agree, since the HUE app and Bridge are able to control the Ikea bulbs fully.

How is the hue binding supposed to know how to use the Philips hue REST API, if the correct use depends on the model of the bulb?

The hue binding can be changed to include an check on the modelid, if TRADFRI then use appropriate code to change it's color the the hueREST API.

Would that make sense @kaikreuzer ?

[kaikreuzer]

the HUE app and Bridge are able to control the Ikea bulbs fully. The hue binding can be changed to include an check on the modelid

So are you saying: "The hue app contains a list of all IKEA TRADFRI models on the market and thus is regularly updated to not miss any new IKEA device"? What about all OSRAM lightify bulbs? Does Philips do the same for those? And what about any other Zigbee Lightlink compatible bulbs that users might add to their hue gateway? As already mentioned above, this cannot be the solution that EVERY app that accesses the hue bridge should implement. This question is not at all specific to Eclipse SmartHome, so I would really recommend that you check the hue developer forum for an answer first.

[BasvanH]

Ok, understood. I have created an post on the Hue develepors forum.

[lopez1de]

I found this on the hue dev forums:

The best way to get the XY support for the bulb you are sending the lightstates to is doing the RGB to XY calculation via the SDK. It will calculate the correct XY depending on the modelid. More information can be found here: http://www.developers.meethue.com/documentation/color-conversions-rgb-xy.

Hue Developers Support - Niek

https://developers.meethue.com/content/final-xy-values

[BasvanH]

@kaikreuzer , have you seen the post above. Does it make sense?

[kaikreuzer]

No, it doesn't. See my response here.

[BasvanH]

Okay, so the HUE API shows the 'colormode' in it's JSON reply, but your're asking the HUE developers to implement the color conversion in their API? Why not look at the 'colormode' key per light/bulp and do the conversion in OH?

This is my JSON of some TRADFRI lights in my network. { "lights":{ "3":{ "state":{ "on":true, "bri":123, "hue":0, "sat":0, "effect":"none", "xy":[ 0.4541, 0.3990 ], "alert":"none", "colormode":"xy", "mode":"homeautomation", "reachable":true }, "swupdate":{ "state":"notupdatable", "lastinstall":null }, "type":"Color light", "name":"Lees lamp", "modelid":"TRADFRI bulb E27 CWS opal 600lm", "manufacturername":"IKEA of Sweden", "capabilities":{ "streaming":{ "renderer":false, "proxy":false } }, "uniqueid":"00:0b:57:ff:fe:ae:62:79-01", "swversion":"1.3.002" }, "4":{ "state":{ "on":true, "bri":123, "ct":357, "alert":"none", "colormode":"ct", "mode":"homeautomation", "reachable":true }, "swupdate":{ "state":"notupdatable", "lastinstall":null }, "type":"Color temperature light", "name":"Woonkamer spot 3", "modelid":"TRADFRI bulb GU10 WS 400lm", "manufacturername":"IKEA of Sweden", "capabilities":{ "streaming":{ "renderer":false, "proxy":false } }, "uniqueid":"00:0b:57:ff:fe:c3:d1:85-01", "swversion":"1.2.217" }, "5":{ "state":{ "on":true, "bri":123, "ct":357, "alert":"none", "colormode":"ct", "mode":"homeautomation", "reachable":true }, "swupdate":{ "state":"notupdatable", "lastinstall":null }, "type":"Color temperature light", "name":"Woonkamer spot 2", "modelid":"TRADFRI bulb GU10 WS 400lm", "manufacturername":"IKEA of Sweden", "capabilities":{ "streaming":{ "renderer":false, "proxy":false } }, "uniqueid":"00:0b:57:ff:fe:c5:3f:d4-01", "swversion":"1.2.217" } } }

[cobii]

Hey , I'am using a RasPi with the RaspBee modul from Dresden Elektronik as ZigBee Gateway. In the newest software version from Dresden Elektronik (deCONZ 2.04.99 / 15.12.2017) the gateway is emulating a hue bride. Connecting the gateway via the hue-binding works fine so far. But there is the same problem with the color mode and the color tradfri bulb. Changing the color with the gateway software direct is not a problem.
May be this helps a bit.

[BasvanH]

@kaikreuzer, seen my last post?

[DutchTaurus]

@BasvanH Heard anything?

[BasvanH]

@DutchTaurus, no nothing. @kaikreuzer, kindly requesting you to look at my comment.

[kaikreuzer]

Sorry for my late response. Ok, if we have the colormode at hand from the JSON response within the binding, this can probably be used to automatically decide whether we need to send HSV or CIE values to it. I'll thus happily accept an according PR from a Tradfri RGB bulb owner.

[ElliotSmith91]

I've been having similar issues with a different bulb and the hue binding seems to be returning a colour temperature value to the bulb even if it is not in colour temperature 'mode'. I believe this is happening in the getCurrentColorTemp function in the HueLightHandler. I'm not sure whether I am understanding the code correctly as I have never really done any Java programming and have no way of testing.

    private @Nullable Integer getCurrentColorTemp(@Nullable State lightState) {
        Integer colorTemp = lastSentColorTemp;
        if (colorTemp == null && lightState != null) {
            colorTemp = lightState.getColorTemperature();
        }
        return colorTemp;
    }

As a test and to be sure it wasn't the bulb I was using, I tried using the same bulb with another smarthome software and it worked flawlessly. Digging in to their code a bit I found that they are only returning a colour temperature value if the bulb is in colour temperature mode. They are also doing checks of which colour mode the bulb is in and doing the necessary conversions then.

Maybe this problem is related?

I can try implementing a fix, but it will probably take me quite a while. I have never done any real Java programming as I say and would have to get a working test set up, but hopefully this information may help someone.

[nesys]

same issue here. via Philips Hue app I'm able to manage the Tradfri colour bulb and all the Hue environment, changing color/brightness without any issue.

In openhab I'm not able to change the color for the Tradfri bulb (TRADFRI_bulb_E27_CWS_opal_600lm)

I'm not a software developer, but I can test if necessary, as I've the Tradfri colour bulb, and a Hue strip. Let me know

[cweitkamp]

Dear all, I have implemented a first version to support changing the color for the TRADFRI bulb E27 CWS opal 600lm. See PR #5946.

I did not touch the discovery so far which means it still will be discovered as 200 thing type.

[cweitkamp]

I have added the TRADFRI bulb as 210 thing type manually. I have linked a Dimmer item to the color_temperature channel and tried to send a command to the Philips interface. This results in an exception:

2018-07-21 12:24:22.972 [WARN ] [binding.hue.handler.HueBridgeHandler] - Error while accessing light: parameter, ct, not available
org.eclipse.smarthome.binding.hue.internal.exceptions.ApiException: parameter, ct, not available
    at org.eclipse.smarthome.binding.hue.internal.HueBridge.handleErrors(HueBridge.java:900) ~[?:?]
    at org.eclipse.smarthome.binding.hue.handler.HueBridgeHandler.lambda$0(HueBridgeHandler.java:204) ~[?:?]
    at java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:656) ~[?:?]
    at java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:632) ~[?:?]
    at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) ~[?:?]
    at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) ~[?:?]
    at org.eclipse.smarthome.binding.hue.internal.HttpClient.lambda$0(HttpClient.java:63) ~[?:?]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]

Imho this leads to the conclusion that there is an issue inside the Philips API itself as it doesn't recognize the IKEA bulb correctly.

[kaikreuzer]

Thanks @cweitkamp, #5946 is merged, so I suggest to close this issue as in general (with your workaround) these bulbs are now supported by the binding.