Osram Bulb on hue bridge no longer working with OH2

Hi there!

So I have an OSRAM LIGHTIFY Classic A LED-Glühlampe, 10 Watt, E27, klar.
This bulb works with the Hue binding in OH 1.8.0 by simply addressing it like this:

Dimmer MyDimmer {hue=“7”}

However, since the Hue binding was replaced by the ESH binding in OH2, where bulbs are detected as things and I bind my items to channels on these things, this no longer works.
The bulb does not show up as a thing in the paper ui configuration of OH2. Manually adding doesn’t work, since my specific type is not shown as an option. Trying the other Osram bulbs or a generic ZLL bulb doesn’t seem to work either.

What should I do?
Thanks for any help!

You do not need to discover your devices through the Paper UI. Simply define your Thing (and the bulbs) yourself through the textual configuration, see https://www.eclipse.org/smarthome/documentation/features/bindings/hue/readme.html#full-example

1 Like

Thank you, that clears that up!

So I actually had a go at it and tried to get the Osram bulb to work, but so far with no success.

There a few concepts that are still confusing to me.
There are the automatically discovered devices in the paper UI, which include my Hue bridge and the associated bulbs, and then there is whatever I define in my hue.items file.
Now from the documentation that you linked me, it seems that I would add any bulb that is attached to a hue bridge by adding the bulb in the braces after the definition of the hue bridge thing. Now I did that, but that apparently then defines a new bridge which stands in conflict with the one that was already discovered in the paper ui.
I then deleted the bridge that was already discovered and now I only have the one that I explicitly defined in the .items file.
Now all the other bulbs were discovered in the paper UI, but the Osram bulb that I am trying to add as a thing is not showing up there.
When looking closer at the documentation for defining hue bulbs I can see that the bulb expects two string values(“LCT001” and “bulb1”):

LCT001 bulb1 [ lightId=“1” ]

The first string appears to be what is called the modelid in the hue API. I can see the following there: “modelid”: “LCT001”.
The Osram bulb however has an empty modelid:
“modelid”: “”,

Can this even work, when the modelid is empty?

The other thing that is confusing to me is the second string. In the example in the documentation the items seem to reference this string:
Color Light { channel=“hue:LCT001:1:bulb1:color” }
However, all the automatically discovered bulbs in the paper ui dont have a special string there, but rather the lightId.
Example from a discovered bulb:
hue:LWB004:xxxxxxxxxxx:1
So what is the right thing to do here?

This seems to have been buried. I don’t think it can actually be that difficult, can it?
Anyone have an idea?

So what happens if you define your bulb as

LCT001 bulb1 [ lightId="1" ]

and the item as

Color Light { channel="hue:LCT001:1:bulb1:color" }

? I would expect this to work. (using “LCT001” as the thing type as there is no specific thing type for the Osram bulb available).

Fantastic, that worked. It even worked for the Osram plug switch that I have, even though it is just an On/Off switch, using a LWB004 modelid for the thing and defining a switch item did the trick. Just mentioning it here for anyone who might want to try this in the future.
Thanks a lot Kai!

1 Like

Hi Jaykay,

Were you able to get the Osram Plug working with Openhab2 or 1.7/1.8?
Could you post your binding for Osram Lightify Plug?

Both, if I recall.

Let me check…

Ok for Openhab2 this is my openhab.things file:

Bridge hue:bridge:xxxxxxxx[ ipAddress=“xxx.xxx.xxx.xxx”, userName=“xxxxxxxxxxx”] { LWB004 bulb7 [ lightId=“7” ] LWB004 Plug3 [ lightId=“3” ] }

where the xxx… represent certain values. (first xxxx = the id of the bridge, which you can find in the paper configuration website for the items, second xxxx = IP address of the bridge, third xxxx = shared secret for the hue bridge)
The lightId can be found in the API website of your bridge. Google for how to access it and find the IDs of your devices.

In this example you can see that I am using an Osram lightbulb and an Osram Plug.

The item binding looks like this:

Switch MoodLighting “moodlighting” (Switching, MainArea) {channel=“hue:LWB004:0017881c9395:Plug3:brightness”}

for OH 1.8 I did this by using the http commands:

Item file:
Switch MoodLighting “moodlighting” (Switching, MainArea)

Rules file:

rule moodlightingruleOn
when
Item MoodLighting changed from OFF to ON
then
sendHttpPutRequest(“http://192.168.2.72/api/xxxxxxxxxx/lights/3/state”, “application/json”, “{“on”:true}”)
end

rule moodlightingruleOff
when
Item MoodLighting changed from ON to OFF
then
sendHttpPutRequest(“http://xxx.xxx.xxx.xxx/api/xxxxxxxxxxx/lights/3/state”, “application/json”, “{“on”:false}”)
end:

Where xxx.xxx.xxx.xxx = ip address of the hue bridge and xxxxxxxxxx is the shared secret for accessing the hue bridge (should be configured in the config file for hue)

Hope this helps!

1 Like

Thanks a lot! With your tips, we got it working in openhab 1.7 in no time.

Sorry to bring this thread up after it being inactive for a while, but the issue I’m having seems to apply here.

How do I go about getting the Osram Lightify username? I have a single bulb and the Lightify Gateway. I’m not using any hubs. I have a new openHAB2 installation.

Thanks for the help!

This thread is about using Osram bulbs on the hue gateway. There is no support for the Lightify gateway afaik.

I know this is an old post, but wanted to circle back and ask the question…

And really for users in the USA… How are you controlling Osram Bulbs with OH2 in the USA? From my experience, I have yet to get an osram bulb (or osram light strip) to pair with the Hue Bridge. All my readings seem to point to this being a Hue issue in the USA only and that they due pair ok in Europe.

If anyone in the USA has had success in paring an Osram Bulb to a Hue Bridge or another way of controlling in OH2, can you share how you did it?

Again, what I have read is that Hue has not updated its bridge to Zigbee 3.0 and that is the main reason?