search

eclipse-archived / smarthome

Eclipse SmartHome™ project
https://www.eclipse.org/smarthome/
Eclipse Public License 2.0
862 stars 787 forks source link

[HSBType] openHAB doesn´t accept 360 as Hue value anymore #6788

Closed bredmich closed 5 years ago

bredmich commented 5 years ago

Hi there,

i just migrated from oH 2.3.0 to 2.4.0 and so did my Hue binding. With 2.3.0 i was able to send a command with a Hue value of 360 to the binding. This doesn´t work anymore as the binding says 360 is not a valid value, the value needs to be between 0 and 360 :-) I already opened a thread in the oH community but figured out this was a bug and not a configuration mistake.

Hardware: Raspberry Pi 3 B+ OS: Raspbian 9 (stretch) with openhabian oH: 2.4.0-1 (Release Build) Binding: 2.4.0

Things:

Bridge hue:bridge:1 [ipAddress="192.168.x.x", userName="<username>"]
{
    0210 hueFlur [lightId="9"]
}

Items:

Switch hueFlur "Flur" (Lights) {channel="hue:0210:1:hueFlur:color"}
Dimmer hueFlur_Dimmer {channel="hue:0210:1:hueFlur:color"}
Color hueFlur_Color {channel="hue:0210:1:hueFlur:color"}
Dimmer hueFlur_Temp {channel="hue:0210:1:hueFlur:color_temperature"}
String hueFlur_Alarm {channel="hue:0210:1:hueFlur:alert"}
Switch hueFlur_Effect {channel="hue:0210:1:hueFlur:effect"}

A simple rule:

rule "Flur Licht morgens"
when
    Item itmFIBmotion2 changed to 1
then
    hueFlur_Color.sendCommand("360,80,30")
end

Log entry when rule triggers: 2019-01-03 23:54:42.320 [WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert '360,80,30' to a command type which item 'hueFlur_Color' accepts: [HSBType, PercentType, OnOffType, IncreaseDecreaseType, RefreshType].

Log entry when changing the bulb manually with the hue app:

2019-01-04 00:14:18.300 [ERROR] [ue.internal.handler.HueBridgeHandler] - An exception occurred while calling the BridgeHeartbeatListener
java.lang.IllegalArgumentException: Hue must be between 0 and 360
    at org.eclipse.smarthome.core.library.types.HSBType.validateValue(HSBType.java:106) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
    at org.eclipse.smarthome.core.library.types.HSBType.<init>(HSBType.java:81) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.LightStateConverter.fromHSBtoHSBType(LightStateConverter.java:234) ~[268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.LightStateConverter.toHSBType(LightStateConverter.java:222) ~[268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueLightHandler.onLightStateChanged(HueLightHandler.java:414) ~[268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler.notifyLightStatusListeners(HueBridgeHandler.java:651) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler.access$7(HueBridgeHandler.java:636) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler$2.doConnectedRun(HueBridgeHandler.java:238) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler$PollingRunnable.run(HueBridgeHandler.java:101) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]

Current workaround:

Why i was using 360? I used the hue app to choose my color and then had a look at the openHAB log for the value :-)

kind regards Michael

cweitkamp commented 5 years ago

It is not Hue specific. Validation for HSBType has been added in the meantime (see #6033).

Current workaround:

  • Changing the Hue to 0 instead of 360 (same color)

Your workaround is the solution :wink:

Why i was using 360? I used the hue app to choose my color and then had a look at the openHAB log for the value :-)

What happens now if you set the same color via Hue App? Does it work or does it result in an error too?

bredmich commented 5 years ago

Validation for HSBType has been added in the meantime (see #6033).

But why does the error message tell me a value between 0 and 360 is fine? The message should tell that a value between 0 and 359 is fine. I don´t understand why the first mentioned value "0" is valid but the last mentioned value "360" isn´t. Sorry but this is clearly a matter of understanding.

What happens now if you set the same color via Hue App? Does it work or does it result in an error too? Currently it works because i wasn´t lucky enought to hit the 360 again...

I had a look at the Philips Hue API and the maximum allowed value for is "65535". If you´re using the buildin http:///debug/clip.html and set this value on one of the bulbs, openHAB throws an error again.

{ "on":true, "bri": 254, "sat": 254, "hue": 65535 }

2019-01-04 11:26:18.862 [ERROR] [ue.internal.handler.HueBridgeHandler] - An exception occurred while calling the BridgeHeartbeatListener
java.lang.IllegalArgumentException: Hue must be between 0 and 360
    at org.eclipse.smarthome.core.library.types.HSBType.validateValue(HSBType.java:106) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
    at org.eclipse.smarthome.core.library.types.HSBType.<init>(HSBType.java:81) ~[102:org.eclipse.smarthome.core:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.LightStateConverter.fromHSBtoHSBType(LightStateConverter.java:234) ~[268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.LightStateConverter.toHSBType(LightStateConverter.java:222) ~[268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueLightHandler.onLightStateChanged(HueLightHandler.java:414) ~[268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler.notifyLightStatusListeners(HueBridgeHandler.java:651) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler.access$7(HueBridgeHandler.java:636) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler$2.doConnectedRun(HueBridgeHandler.java:238) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at org.eclipse.smarthome.binding.hue.internal.handler.HueBridgeHandler$PollingRunnable.run(HueBridgeHandler.java:101) [268:org.eclipse.smarthome.binding.hue:0.10.0.oh240]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
    at java.lang.Thread.run(Thread.java:748) [?:?]

So this seems to be a bug in your validation as "360" is an valid value for hue in HSBType.

kind regards Michael

bredmich commented 5 years ago

I had a look at the release notes of openHAB 2.3 and 2.4 but there´s no information about a change at the validation of HSBType and the sideeffects for the Hue Binding...

kaikreuzer commented 5 years ago

But why does the error message tell me a value between 0 and 360 is fine?

Because prosa language is not as precise as maths. What it means to say is that the value should comply to 0 <= hue < 360.

bredmich commented 5 years ago

Understand. But it´s still something that´s inside the Hue API but not recognized by openHAB. As openHAB isn´t alone in a smarthome a change from other systems to hue bulbs causes error(s) in openHAB.

So this subject is done and it will stay like this?

kind regards Michael

kaikreuzer commented 5 years ago

It stays that 360 is an invalid value for HSBTypes. But what I see from your exception above is that the hue binding has indeed a bug as it creates such a value in its code - https://github.com/eclipse/smarthome/pull/6790 should fix this.

maggu2810 commented 5 years ago

@bredmich You could change the message to e.g. "a value between 0 (inclusive) and 360 (exclusive)" so it should be understandable (perhaps more than "in range of [0;360)").

bredmich commented 5 years ago

@maggu2810 i´ll have a look and maybe create an PR to make the message more understandable. But as i understand #6790 this shouldn´t be a problem anymore.