[SOLVED] Brightness-Issue Philips-Hue

Tags: #<Tag:0x00007f2fafdce098>

Hi

I did not use/check this for a long time now, but I have a very strange behaviour with Philips Hue Bulp Type 210 in the latest snapshot and as well in Milestone M3:

  • I’m not able to control anymore the brightness in BasicUI with Colorpicker-Slider --> Bulp doesn^t change anything
  • I can control the Brightness from Paper-UI Control-Panel but the value jumps back to 100 after next refresh (according refresh-interval) --> See video
  • REST-Interface does show the same --> Value jumps back to 100
  • In addition I do not get the same colors as in the past by sending a command out of my rules: Light_Sofa_Dimmer.sendCommand(“30,64,60”)

It seems that this bug is only related to the color-bulps and lightstrips.

Video:

The question is now if I’m the only one? Or is this really a bug? Does someone else have this setup and is able to check before I create an issue on Github?

Thx
Michael

Hi @michaeljoos,

No, not yet. We introduced a change in the way how color commands are send to the Hue API. The binding currently takes the colormode into account. See

Maybe you can activate TRACE logging and have a look what happens.

Mmmhhhh, switching off and disconnecting the bulps completely from power did solve this issue.
Sometimes it’s good to just “restart” the hardware :smiley:

Sounds good. I am glad that it is working again for you.

@cweitkamp
I have this problem too, and cycling power on the bulbs worked temporarily, but now it’s happening again.
Moreover updating the brightness through a Color item doesn’t work anymore.

17:16:08.093 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Hue_Bureau' received command 0,60,62
17:16:08.125 [DEBUG] [thome.binding.hue.internal.HttpClient] - Async sending put to address: http://192.168.1.xxx/api/yyy/lights/8/state delay: 40 body: {"xy":[0.5027254,0.32956395]}

Brightness is set to 62 from another value but doesn’t have any effect.
Then after a few seconds:

17:16:18.453 [DEBUG] [.binding.hue.handler.HueBridgeHandler] - Status update for Hue light 8 detected.
17:16:18.472 [DEBUG] [.binding.hue.handler.HueBridgeHandler] - Sending lightStateChanged for light 8
17:16:18.479 [DEBUG] [.binding.hue.handler.HueBridgeHandler] - Sending lightStateChanged for light 8
17:16:18.490 [TRACE] [e.binding.hue.handler.HueLightHandler] - onLightStateChanged() was called
17:16:18.500 [TRACE] [e.binding.hue.handler.HueLightHandler] - Received state change for another handler's light (8). Will be ignored.
17:16:18.504 [DEBUG] [.binding.hue.handler.HueBridgeHandler] - Sending lightStateChanged for light 8
17:16:18.520 [TRACE] [e.binding.hue.handler.HueLightHandler] - onLightStateChanged() was called
17:16:18.561 [DEBUG] [.binding.hue.handler.HueBridgeHandler] - Sending lightStateChanged for light 8
17:16:18.573 [INFO ] [smarthome.event.ItemStateChangedEvent] - Hue_Bureau changed from 0,60,62 to 0,60,100

Brightness is set back to 100 even though it doesn’t change at all.

modelId LCT007
uniqueId 00:17:88:01:10:…
vendor Philips

Current firmware version: 5.105.0.21536

I can confirm that disconnecting from power was just a temporary solution for me, but I did not have time this week to deeper analyse it. Will try to save a TRACE-Log as soon as it’s happening again.

Hi Yannick,
Hi Michael,

I am afraid I cannot reproduce your issue in my environment. One difference is that I own gen 3 colored bulbs (LCT010). Maybe they are handled differently in the Hue API. What can we do now? Any ideas? I could revert my changes and prepare a .jar file for you to test again. Does that help?

Hi Christoph,

My take from looking at the PR is that bulbs made by Philips (and I’m sure you’ll agree it’s important that the Hue binding supports them all properly :stuck_out_tongue: ) should continue be sent updates in the HS color mode only since they support it, and sending XY has the unfortunate effects @michaeljoos describes in the OP (hue/saturation is “adjusted” by 1 or 2% on update, and brightness doesn’t work).
I don’t have the newer gen models but have a Hue Go, Hue Bloom, a lightstrip and several gen-2 color bulbs I can test on.

I did some more tests today and I was able to reproduce the reported issue with my own bulbs. I have an idea why the problem occures. I will follow my trail and prepare a test version for you. Thanks again for reporting this behavior and for your patience.

1 Like

I wrote a small unit test:

@Test
public void testHSBtoXYequalsXYtoHSB() {
    HSBType hsb = new HSBType("0,60,62");
    PercentType[] xy = hsb.toXY();
    assertEquals(new PercentType("50.27254"), xy[0]);
    assertEquals(new PercentType("32.956394"), xy[1]);
    assertEquals(hsb, HSBType.fromXY(xy[0].floatValue() / 100.0f, xy[1].floatValue() / 100.0f));
}

And it failed:

Failed tests: 
  HSBTypeTest.testHSBtoXYequalsXYtoHSB:136 expected:<0,60,62> but was:<0,60,100>

@chris Do you see similar problems in the ZigBee binding?

It’s not something I’ve noticed, but I guess the test doesn’t lie :wink:

I filed an issue:

I prepared a test version which sends an XY color command followed by a brightness command to the Hue API (see https://github.com/eclipse/smarthome/issues/6299#issuecomment-426928066).

// EDIT: Uploaded new test version

I see the behavior discussed here and while the thread is flagged [solved] I’m not sure how to proceed to fix the issue at my site. As far as I can see the version of the binding on my system is 0.10.0.oh240M4
I uninstalled/reInstalled the Hue Binding but still cannot control the B of HSB from openhab.
Is there a known workaround other than using the Hue app on my phone whenever I step into a room?
Should I simply wait for the next milestone?
Thanks in advance

Hi Daniel,

The fix is not port of OH2 milestone 4 build. You have three possibilities:

  1. Wait for the next milestone / release build
  2. Install the fixed binding version manually - you can download it from my link above
  3. Switch to latest snapshot builds

Now it is up to you.

cordial thanks, Christoph, for the fast response!

I was busy already to mend a workaround based on executeCommandLine() and some curl magic like

curl -H “Accept: application/json” -X PUT --data ‘{“on”:true,“bri”:$BRIGHT255}’ http://$IP_OF_GATEWAY/api/$USERID/lights/$LIGHTID/state

But with your input now #2 really looks like the best way to proceed,
thanks again

Daniel

Hi Christoph,

I tried installing the snapshot from your link above but I couldn’t get the addon to activate. It was stuck at Installed. I tried bundle:resolve but got no output while bundle:requirements said that the bundle is not resolved.

Edit: I’ve reverted to the paperUI version 0.10.0.oh240 just to check which version I was originally on that gave the error

Thanks

Hi Josh,

If you are already on OH2.4 release you do not need my version anymore because it is part of it. Otherwise you should watch out for the upnp dependency. Have a look here for detailed instructions.

Hi guys,

even if the issue is closed I hope somebody read it… I have the same problem with the 210 lamps since I updated 1 week ago from OH 2.1 to 2.4.0-1. I removed the lamps, the binding and disconnecting the bulps from power - nothing did solve this issue - does somebody can help me?

Thanks in advance.