[SOLVED] Brightness-Issue Philips-Hue

michaeljoos · September 23, 2018, 9:11am

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

cweitkamp · September 23, 2018, 4:07pm

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.

michaeljoos · September 23, 2018, 6:04pm

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

cweitkamp · September 23, 2018, 6:33pm

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

ysc · September 30, 2018, 3:21pm

@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

michaeljoos · September 30, 2018, 3:59pm

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.

cweitkamp · September 30, 2018, 7:30pm

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?

ysc · September 30, 2018, 7:51pm

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 ) 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.

cweitkamp · October 1, 2018, 8:28pm

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.

cweitkamp · October 1, 2018, 8:40pm

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?

chris · October 1, 2018, 9:20pm

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

cweitkamp · October 2, 2018, 10:00am

I filed an issue:

cweitkamp · October 3, 2018, 6:52pm

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

rubens · October 10, 2018, 2:12pm

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

cweitkamp · October 10, 2018, 9:11pm

Hi Daniel,

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

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

Now it is up to you.

rubens · October 10, 2018, 11:28pm

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

justjosh · February 2, 2019, 6:45am

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

cweitkamp · February 2, 2019, 9:48am

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.

Tobi-1234 · August 24, 2019, 8:36pm

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.