Skip to content
This repository has been archived by the owner on May 7, 2020. It is now read-only.

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

Closed
bredmich opened this issue Jan 4, 2019 · 8 comments
Closed

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

bredmich opened this issue Jan 4, 2019 · 8 comments

Comments

@bredmich
Copy link
Contributor

bredmich commented Jan 4, 2019

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:

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

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
Copy link
Contributor

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 😉

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 bredmich changed the title [Hue] Binding doesn´t accept 360 as Hue value openHAB doesn´t accept 360 as Hue value anymore Jan 4, 2019
@bredmich
Copy link
Contributor Author

bredmich commented Jan 4, 2019

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 bredmich changed the title openHAB doesn´t accept 360 as Hue value anymore [HSBType] openHAB doesn´t accept 360 as Hue value anymore Jan 4, 2019
@bredmich
Copy link
Contributor Author

bredmich commented Jan 4, 2019

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
Copy link
Contributor

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
Copy link
Contributor Author

bredmich commented Jan 4, 2019

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
Copy link
Contributor

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 - #6790 should fix this.

@maggu2810
Copy link
Contributor

@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
Copy link
Contributor Author

bredmich commented Jan 4, 2019

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants