Osram PAR16 50 TW OnOffState not managed correctly?

Hi everyone,

I got the same behavior in OpenHAB-1.
I am using Osram PAR16 bulbs being managed over an Philips HUE bridge.

If I switch off a bulb it just get’s dimmed down but never powered off really. If then I try to switch it back to ON nothing happens and the bulb stays dimmed down.
In OpenHAB-1 I fixed this by myself by changing the switchOn method in org.openhab.binding.hue.internal.hardware.HueBulb to the following:

if(powerOn) {
} else {

Is anyone facing the same problem using openHAB-2 and got a fix or workaround for that behaviour?

Thanks and best wishes


I found an working solution (at least for me :smile: ).
I changed the the function toOnOffLightState in org.eclipse.smarthome.binding.hue.handler.LightStateConverter to

public static StateUpdate toOnOffLightState(OnOffType onOffType) {
StateUpdate stateUpdate = new StateUpdate();
if (OnOffType.ON.equals(onOffType)) {
} else {
// StateUpdate stateUpdate = new StateUpdate().setOn(OnOffType.ON.equals(onOffType));
return stateUpdate;

Could you possibly report this problem at https://bugs.eclipse.org/bugs/buglist.cgi?product=SmartHome&list_id=13143238?


iam running openhab 1.7.1 on Linux. Since the last “updates” of the Hue Bridge Firmware the “on off” isnt working for my par16 Lightify Bulbs.

my Item config looks like this

Dimmer Light_gCZ_Bed_Ceiling "Decke" <lights> (gCZ, Lights) {hue="19;brightness;30"}

Do i have to set now a transmission time? I looked the latest changes and found some code pieces which let me think that its possible to identify par16 Osram lights by its DeviceID?

Hi Clemens,

there was a Firmware Update of the Bridge which excluded all Non-Philips bulbs. After some contrary wind :wink: Philips rolled back that update to further support Non-Philips bulbs.
Which firmware version your bridge is currently running with?

I’ve done some changes for the Eclipse Smarthome project because the Par16 50 Osram bulbs having an issue with there firmware regarding turning off/on the light. These changes are not commited for OpenHab 1.X as far as I know.

Iam aware of this firmware changes from philips, but since they rolled it back there should be normaly no problem anymore and everything working as it did before?
Before those updates my Par16 worked perfect, even with the standard Hue App. Now only the “OnSwitch” App is able to turn them off.

Bridge software 01030262 (newest available)

Maybe you can give me some advice what i have to change to get the Binding 1.7.1 working with those bulbes?

I would expect the same.

The openHAB 1.X workaround I implemented for myself assumes that you are not using any other bulb but Osram. What I’ve done is “documented” in my first post in this topic. If needed I can create a Fork of the openHAB 1.X Github project, apply the changes to my personal fork and give you some information how you can build the needed Jar file out from this.
But be aware that this workaround applies to all bulb types and not only for Osram ones.

What bulb are you exactly using. As far as I know the On/Off bug affects Osram Par16 50 TW bulbs but I saw that you configured “hue” and the Par16 50 TW bulbs are not capable for hue.

Mhm i use a wide bunsh of different lights. I have the Osram Par16 Gu10 Lightify Bulbs, a Dresden FLS-PP LP, Osram Lightify Flex Rgbw. Everything works only those G10 dont work as they should. What do you mean with

As far as I know the On/Off bug affects Osram Par16 50 TW bulbs but I saw that you configured “hue” and the Par16 50 TW bulbs are not capable for hue.

You mentioned that your item configuration looks like

That hue parameter is for setting the color light, as far as I understand. The Osram bulb PAR16 50 TW which I know is affected by this bug is not capable for changing color it is only a tunable white one.

Can you try to control your Osram light using the Philips Clip Api Debugger frontend:

If you “PUT”-send a body like
I expect that the light will be just dimmed down instead of turned off.

If this is the case try to “PUT”-send a body like
{"on":false, "transitiontime":0}
The latter body should turn off the light completely.

For turning it back on the body have to look like
{"on":true, "bri":254}

jap its only turnable white. i check this debug clip right now. So what is the username openhab uses to control the bridge?

That is the value of ‘hue:secret’ in your openhab configuration file.

1 Like

okay jap no surprise thats it. Okay now i have to change my Openhab Binding to let it use transmissiontime 0 with the posts above.

i hope i manage that somehow

Argh. I jumbled up that openHAB specific Hue binding configuration with the Hue API :slight_smile:
With hue=XYZ you reference your light :smile:

I think that the actual binding implementation will not support setting transition time but I am looking forward for your test outcome

mhm the perfect solution would be, that the Hue Binding asks the Hue Bridge after its “Modell ID”. Like GET http://<bridgeipaddress>/api/............................/lights/1

and if its Modell ID is "modelid": "PAR16 50 TW", Transmissiontime should be 0

i have never made a binding or read one of the tutorials about it, since iam new to Openhab. But i will look over it

Yap. That is exactly the way we implemented the workaround in Eclipse Smarthome.
Take a look at my current pull request:

If you implement that workaround for openHAB 1.X I am sure that @Kai will think about a merge :wink:

puh i dont think i can do that, my java is not the best. As far as i can see (and you already mentioned) the parameter “transmissiontime” has to be created in the Binding. So the Openhab2 Binding has this code already in it?

Yes and no :wink:
The Hue binding is no longer a direct part of openHAB 2. It was moved to the Eclipse Smarthome project which acts as the base of openHAB 2.
You can download the Alpha-2 release of openHAB 2 here but I think that the workaround code is not included there. You can try it with an snapshot which you can get from here but be aware that openHAB 2 is in an alpha state :smile:

I will take a look to find a way to implement that workaround in openHAB 1 in a way that the workaround will only affect the PAR16 50 bulbs. If I found the time to do that I will provide you with some information how you can get the needed binding jar so that you can test it.

that would be awesome, due to my exams in the nexttime i dont know how much time i will find to get into this topic.

I think Openhab2 misses some keyfunctions/bindings due to its alpha state

I am done with my changes and it seems to work but I cannot test it to see if other bulbs are handled correctly further on because I just own Par16 50 TW bulbs.

@Arsur: I commited the changes into my own branch. For testing you have to build the jue-Jar file. Are you able to build it or do you need some more information about the process?
I tested the changes in my local environment and it worked, for me.

Would really appreciate if you can test the changes in your environment even with other bulbs. If possible it would be nice if you can do some dimming tests to see if the bulbs will be switched off correctly in case of dimming to 0 and switched back on in case of dimming to > 0.

There is still some debug logging included. I will remove them if you test gone well.

1 Like

Sry i was away. I will check it tomorrow. Realy thanks in advance for help!

edit: I got the stuff from git, now copy everything in eclipse, than i enable openhab to accept new bindings. I hope i did not miss a step but i think i will see it soon by my own