Allow HUE binding to switch groups of lights

[GoogleCodeExporter]

Allow HUE binding to switch groups of lights this wil speed up switching a lot.

Original issue reported on code.google.com by SJo...@gmail.com on 12 Jul 2013 at 1:17

[GoogleCodeExporter]

a possible solution would be to implement Hues' Group-Feature (see 
http://developers.meethue.com/2_groupsapi.html#25_set_group_state). But i have 
no good idea how that would fit best into the binding configuration.

Original comment by teichsta on 12 Jul 2013 at 1:20

[GoogleCodeExporter]

Maybe a g for group? like:

Switch Toggle_1         "Group 1 switch"     (Switching)     {hue="g1"}
Dimmer Dimm_1           "Group 1 dim"     (WhiteDimmer)                   
{hue="g1;brightness;30"}

Original comment by SJo...@gmail.com on 13 Jul 2013 at 8:08

[GoogleCodeExporter]

You may already do this. First of all define the group of bulbs in the *.item 
file like this:

Group                   Example

Group:Switch:OR(ON, OFF) GroupSwitch            "All Lights [(%d)]" (Example)

/* Lights */
Switch Toggle_1         "Bulb 1"        (GroupSwitch)           {hue="1"}
Switch Toggle_2         "Bulb 2"        (GroupSwitch)           {hue="2"}
Switch Toggle_3         "Bulb 3"        (GroupSwitch)           {hue="3"}

Then you may implement the *.sitemap like this:

sitemap hue label="Main Menu"
{
    Frame { 
        Switch item=GroupSwitch mappings=[OFF="All Off", ON="All On"]
    }
}

This should switch all three bulbs at once...

Does this solve your problem?

Original comment by roman.ha...@gmail.com on 20 Aug 2013 at 7:38

[GoogleCodeExporter]

Hello, 

I tested this. 
It still switches the bulbs one by one with a few seconds between:

2013-08-20 23:06:18 - GroupSwitch received command OFF
2013-08-20 23:06:23 - Toggle_1 received command OFF
2013-08-20 23:06:26 - Toggle_3 received command OFF
2013-08-20 23:06:29 - Toggle_11 received command OFF
2013-08-20 23:06:32 - Toggle_10 received command OFF
2013-08-20 23:06:36 - Toggle_5 received command OFF
2013-08-20 23:06:39 - Toggle_7 received command OFF

Original comment by SJo...@gmail.com on 20 Aug 2013 at 9:14

[GoogleCodeExporter]

It is clear to me that it does it sequentially, but I really wonder why there 
are several seconds inbetween.

Roman, do you have any explanation for this? It should simply do a single REST 
call to the bridge for each bulb, which should be just a matter of 
milliseconds...

Original comment by kai.openhab on 20 Aug 2013 at 9:17

[GoogleCodeExporter]

Sorry, but I cannot reproduce this behaviour. This is my log... Maybe your 
bulbs are not as close together as my bulbs, or something else is preventing a 
fast reachablility of your bulbs. I think the switch request to every bulb 
waits for a response by the bridge before the next is executed. Perhaps your 
bulbs or bridge is just responding slower than mine.

20:02:47.334 INFO  runtime.busevents[:42] - GroupSwitch received command ON
20:02:47.340 INFO  runtime.busevents[:42] - Toggle_3 received command ON
20:02:47.340 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_3'
20:02:47.856 DEBUG o.o.b.h.i.hardware.HueBulb[:253] - Sent message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/3/state
20:02:47.860 INFO  runtime.busevents[:42] - Toggle_1 received command ON
20:02:47.860 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_1'
20:02:48.191 DEBUG o.o.b.h.i.hardware.HueBulb[:253] - Sent message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/1/state
20:02:48.194 INFO  runtime.busevents[:42] - Toggle_2 received command ON
20:02:48.194 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_2'
20:02:48.498 DEBUG o.o.b.h.i.hardware.HueBulb[:253] - Sent message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/2/state

Original comment by roman.ha...@gmail.com on 21 Aug 2013 at 6:10

[GoogleCodeExporter]

The phillips app on the iphone is really switching the bulb synchronously. 
That's really nice. I will try to find out how they do this and how we could 
implement that in openHAB. But I can't promise anything. ;)

Original comment by roman.ha...@gmail.com on 21 Aug 2013 at 6:13

[GoogleCodeExporter]

Ok, I see the point. The app is defining a group of bulbs _on the bridge_. That 
is what you mentioned above ;) This makes it possible to switch them at once.

I think the workaround I described will be ok until I implemented a better 
solution ;)

Kai, could you please assign that task to me?

Original comment by roman.ha...@gmail.com on 21 Aug 2013 at 6:17

[GoogleCodeExporter]

done :-)

Original comment by teichsta on 21 Aug 2013 at 6:54

• Changed state: Accepted

[GoogleCodeExporter]

> I think the switch request to every bulb waits for a response by the bridge 
before the next is executed

Do we actually use any return value from the request (such as a new status)? If 
not, how about firing the REST requests asynchronously to speed up things? 
There were some users on a RaspPi, who also said that the Hue binding felt a 
bit slow. Async calls might improve this.

Original comment by kai.openhab on 21 Aug 2013 at 8:27

[GoogleCodeExporter]

No we don't. I will give that a try. But if I remember correct, the frequence 
of requests to the bridge was limited. But I am not sure. I will test that.

Original comment by roman.ha...@gmail.com on 23 Aug 2013 at 7:06

[GoogleCodeExporter]

Regarding latency in the hue binding, please also have a look at 
https://code.google.com/p/openhab/issues/detail?id=138#c30

Original comment by kai.openhab on 23 Aug 2013 at 8:04

[GoogleCodeExporter]

I just tried to multithread the problem. This does not really help. Two bulbs 
are nearly synchronous. The third one is late. I think the only solution is to 
use the grouping functionality of the bridge itself.

20:58:27.414 INFO  runtime.busevents[:42] - Toggle_3 received command ON
20:58:27.414 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_3'
20:58:27.417 INFO  runtime.busevents[:42] - Toggle_2 received command ON
20:58:27.418 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_2'
20:58:27.421 INFO  runtime.busevents[:42] - Toggle_1 received command ON
20:58:27.421 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_1'
20:58:27.422 INFO  runtime.busevents[:42] - GroupSwitch received command ON
20:58:27.981 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:34] - Sent message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/3/state
20:58:27.997 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:34] - Sent message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/2/state
20:58:29.500 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:34] - Sent message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/1/state

Original comment by roman.ha...@gmail.com on 25 Aug 2013 at 7:13

[GoogleCodeExporter]

hmmm...

see https://code.google.com/p/openhab/issues/detail?id=138#c32 - I wrote a 
small plain .py-script which takes approx .08 secs per set-request... Feels 
like there is something else...

Original comment by frank.pa...@mobiles-arbeiten.de on 25 Aug 2013 at 8:07

[GoogleCodeExporter]

I just added some additional logging and the request are sent to the bridge 
immediately. The bridge does not react in the same pace as the requests are 
coming in. See the log:

22:32:50.779 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_1'
22:32:50.782 INFO  runtime.busevents[:42] - Toggle_1 received command ON
22:32:50.782 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_2'
22:32:50.789 INFO  runtime.busevents[:42] - Toggle_2 received command ON
22:32:50.789 DEBUG o.o.b.hue.internal.HueBinding[:88] - Hue binding received 
command 'ON' for item 'Toggle_3'
22:32:50.794 INFO  runtime.busevents[:42] - Toggle_3 received command ON
22:32:50.795 INFO  runtime.busevents[:42] - GroupSwitch received command ON
22:32:50.992 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:77] - Sending message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/2/state
22:32:50.993 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:77] - Sending message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/1/state
22:32:50.997 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:77] - Sending message: 
'{"bri":255,"on":true}' to 
http://192.168.178.28/api/crqtgh924n8z57vtrncquihdjXAB/lights/3/state
22:32:51.058 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:82] - Received response for 
message: '{"bri":255,"on":true}' was 200
22:32:51.073 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:82] - Received response for 
message: '{"bri":255,"on":true}' was 200
22:32:52.598 DEBUG o.o.b.h.i.h.AsyncBridgeMessage[:82] - Received response for 
message: '{"bri":255,"on":true}' was 200

Original comment by roman.ha...@gmail.com on 25 Aug 2013 at 8:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ah, sounds like getting closer... ;-)

So, it could of course be the case that the bridge has (for whatever reason) 
significantly variable response times. This would probably call for some sort 
of "asynchronous message firing", right?

But why, then, is the phue-lib from 
https://github.com/studioimaginaire/phue/blob/master/phue.py so much faster 
even when I add status requests to my small script (.12 secs per bulb for a 
set-request and an additional read-status request)? And how would this explain 
the 7secs of >90% cpu-load experienced on the RasPi with openhab and the fact 
that openhab is completely blocked throughout these 7 (or, in the combined case 
with 3 bulbs, 21) secs? Weird...

Just fyi, here is the quick'n'dirty script I used:

#!/usr/bin/python
from phue import Bridge
import time
import random

b = Bridge('<hue-ip>', '<secret>')

lights = b.get_light_objects()
start = time.clock()
current = start
total = 0.0
num_iterations = 64

for iteration in range(num_iterations):
    on = iteration % 2
    if on:
        print "switching high"
    else:
        print "switching low"
    for light in lights:
        light.brightness = 255 * on
        light.xy = [1.0, 0.5]
        #print light.brightness
    old = current
    current = time.clock()
    total = current - start
    last = current - old
    print "done. Last iteration took ", last, "secs, ", iteration, "overall iterations took ", total, "secs."
print "average: ", total/num_iterations, "secs per iteration or ", 
total/num_iterations/3, " secs per bulb"

The final output on my (wifi-connected) RasPi was:

average:  0.36375 secs per iteration or  0.12125  secs per bulb

Ok, weird enough for me to go to sleep...

Original comment by frank.pa...@mobiles-arbeiten.de on 25 Aug 2013 at 9:13

[GoogleCodeExporter]

Just to bring up this issue again (I hoped for 1.3 a little bit):

I now dived a little bit deeper into it. Would it probably make a difference in 
matters os RasPi-Hue-performance to *not* create a new 
com.sun.jersey.api.client.Client and a new 
com.sun.jersey.api.client.WebResource *every time* a Command is to be sent to a 
Hue Bulb in HueBulb.executeMessage ?

Just wondering. Don't know if this might massively eat up processor cycles or 
so...

Best,

Frank

Original comment by frank.pa...@mobiles-arbeiten.de on 29 Sep 2013 at 1:40

[GoogleCodeExporter]

I will take a look at that. But I do not have a chance to test that on a RasPi.

Original comment by roman.ha...@gmail.com on 30 Sep 2013 at 10:59

[GoogleCodeExporter]

Great, thanks!

In the meantime, I stumbled over this one at 
https://jersey.java.net/apidocs/latest/jersey/index.html:
"Clients are heavy-weight objects that manage the client-side communication 
infrastructure. Initialization as well as disposal of a Client instance may be 
a rather expensive operation."

Maybe one Client per hue bridge? Oh, and if you like me to, i could do some 
test by copying a .jar to my regular 1.3-installation. And if openHAB is in 
need for a RasPi, just let me know ;-)

Best,

Frank

Original comment by frank.pa...@mobiles-arbeiten.de on 30 Sep 2013 at 11:33

[GoogleCodeExporter]

Thanks a lot. I'll come back to this ;)

Original comment by roman.ha...@gmail.com on 11 Oct 2013 at 2:37

[GoogleCodeExporter]

Frank, thanks for the info about the Client instantiaton. To improve this 
behaviour, I have just merged a small fix, see 
https://github.com/openhab/openhab/pull/58
I hope that the performance issues with Hue are solved by this as well - at 
least it worked pretty well in my tests.

Original comment by kai.openhab on 27 Oct 2013 at 10:32

[GoogleCodeExporter]

Ah, looks highly promising, indeed :-) 

Can't wait for 1.4 to be released - with a usable Hue binding, it makes sense 
to go deeper into openHAB on the RasPi at all. Please, god, let it be before 
christmas-tinker-time ;-) 

Thanks a lot for these few lines!

Best

Frank

Original comment by frank.pa...@mobiles-arbeiten.de on 27 Oct 2013 at 4:22

[GoogleCodeExporter]

I actually expect the 1.4 version of the binding to be compatible with the 
1.3.x runtime. So if you like and have a try with the hue binding of tomorrows 
CI build from https://openhab.ci.cloudbees.com/job/openHAB/.

Original comment by kai.openhab on 27 Oct 2013 at 5:42

[GoogleCodeExporter]

Now I found the time to do a first check. Binding is indeed compatible with 1.3 
installation. While the first switch after startup still causes some delay for 
each bulb (probably the bulb is instantiated then, might be adressable with 
some startup rules in the sitemap, will have to check) further switches work 
*immediately*.

So great, thanks a lot!

Best

Frank

Original comment by frank.pa...@mobiles-arbeiten.de on 31 Oct 2013 at 7:05

[GoogleCodeExporter]

Perfect, thanks for the feedback!
P.S.: I unassign this issue for the moment as Roman mentioned that he won't 
have time for it in the near future. So if anybody else wants to pick it up, 
speak up :-)

Original comment by kai.openhab on 31 Oct 2013 at 2:38

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:53

• Added labels: To-Github

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

see above!

Issue has been migrated to Github and should be discussed there.

Original comment by teichsta on 21 Nov 2013 at 1:51

• Changed state: Invalid