[HUE] Hue bulbs with brightness of 1 shown as off

[tomekk20]

Hi,

I have following unexpected behavior in openHAB 2.3.0. When I move the slider for brightness of a Hue Bulb in the official Hue-App (IOS/Android) to the minimum, the brightness is set to 1 percent. The Hue bridge JSON response is as expected:

{"state":{"on":true,"bri":1,"hue":8372,"sat":140,"effect":"colorloop","xy":[0.4579,0.4096],"ct":366,"alert"....

So far so good. But the Hue-Binding says in the Logfile:
2018-12-02 21:44:58.309 [vent.ItemStateChangedEvent] - Light1_Switch changed from ON to OFF
2018-12-02 21:44:58.317 [vent.ItemStateChangedEvent] - Light1_Brightness changed from 36 to 0

Can someone confirm this behavior?

Best regards,
Tomekk

[kaikreuzer]

I didn't test it, but from the code, I would assume that your observation is correct. The brightness is calculated as an int with

        int percent = (int) Math.round(lightState.getBrightness() / BRIGHTNESS_FACTOR);

where BRIGHTNESS_FACTOR is 2.54 - so if the hue bridge returns a 1, the item state is set to 0 (as it is gets rounded).
I see two possibilities: Either treat the percentage as a float instead of an int (but this will probably give us ugly values most of the time) or make an exception for the value 1 and set the state to 1% in that case.

@cweitkamp Wdyt?

[cweitkamp]

First of all I am able to reproduce this issue for bulbs connected to the Hue binding.

One question in advance: The PercentType is capable of carrying a BigDecimal. What is the current behavior of the framework itself if we assign a floating point value to it? Can we handle it by defining a "%d %%" pattern for the state description of the channel type?

Second guess: We are doing something similar in the Tradfri binding but always round up instead of arithmetical rounding. What about that?
https://github.com/eclipse/smarthome/blob/36b3e3fe37aced8e018d5af7e6f0062c1f598116/extensions/binding/org.eclipse.smarthome.binding.tradfri/src/main/java/org/eclipse/smarthome/binding/tradfri/internal/TradfriColor.java#L179

[kaikreuzer]

Can we handle it by defining a "%d %%" pattern for the state description of the channel type?

The correct pattern would be "%.0f %%", but afair, we also covered %d to handle it nicely.
But still, you will have all the fractions always visible in your event log and at other places, which isn't really nice.

We are doing something similar in the Tradfri binding but always round up instead of arithmetical rounding. What about that?

Sounds good to me, with that we can avoid the exceptional flow for "1". What would need to be checked though is whether that might cause a "jump" in the state, if we send a certain value - if we e.g. send 33% as a command, which might set the value for hue to "84", which in turn would be translated to a state update of 34%, this would be an undesired side effect.

[cweitkamp]

I will take care of that and write a small unit test to cover the edge cases - or maybe for all of the valid values.

[cweitkamp]

I submitted a fix for it (see #6629).

[tomekk20]

Thanks a lot!