Hue lights misbehaving

Any ideas please folks?

/* Kitchen */

Group:Color KitchenLights “Kitchen Lights” (AllDownstairsLights) [“Lighting”]
Group:Color KitchenLights1 “Kitchen Lights 1” (KitchenLights)
Group:Color KitchenLights2 “Kitchen Lights 2” (KitchenLights)

Color Kitchen1_Color “Kitchen1” (KitchenLights1) {channel=“hue:0210:2:36:color”}
Color Kitchen2_Color “Kitchen2” (KitchenLights1) {channel=“hue:0210:2:37:color”}
Color Kitchen3_Color “Kitchen3” (KitchenLights1) {channel=“hue:0210:2:38:color”}
Color Kitchen4_Color “Kitchen4” (KitchenLights1) {channel=“hue:0210:2:39:color”}
Color Kitchen5_Color “Kitchen5” (KitchenLights1) {channel=“hue:0210:2:40:color”}
Color Kitchen6_Color “Kitchen6” (KitchenLights1) {channel=“hue:0210:2:41:color”}
Color Kitchen7_Color “Kitchen7” (KitchenLights1) {channel=“hue:0210:2:45:color”}

Color Kitchen8_Color “Kitchen8” (KitchenLights2) {channel=“hue:0210:2:46:color”}
Color Kitchen9_Color “Kitchen9” (KitchenLights2) {channel=“hue:0210:2:47:color”}
Color Kitchen10_Color “Kitchen10” (KitchenLights2) {channel=“hue:0210:2:48:color”}
Color Kitchen11_Color “Kitchen11” (KitchenLights2) {channel=“hue:0210:2:49:color”}
Color Kitchen12_Color “Kitchen12” (KitchenLights2) {channel=“hue:0210:2:50:color”}
Color Kitchen13_Color “Kitchen13” (KitchenLights2) {channel=“hue:0210:2:51:color”}
Color Kitchen14_Color “Kitchen14” (KitchenLights2) {channel=“hue:0210:2:52:color”}

Strangely, when I play this video back and my alexa hears it and carries out the commands it’s different bulbs that play up each time, there seems to be no logic to it.

No errors in openhab log either!

Seems to only happens when you go from OFF to a color.
I think ít´s an Alexa - Hue issue, where some bulbs doesnt receive the actual command from Alexa, and it seem to be random bulbs. It is strange however.

You may have to enable some debug or even trace logging to identify where things are going wrong

My understanding is the following:

(correct?)

Within OH2 (step (4)), you are actually have more intermediate steps:

One possible root-cause for some of the lights not going ON would be that you are “saturating” the communications in step (5) above (14 commands executed simultaneously). Maybe the Binding and/or the Bridge are having trouble handling this.

One workaround would be to test this by using a rule and introduce some small delay between the Commands towards the individual Color Items (use a dummy Item to be exposed to Alexa and then use this as a trigger)

By the way: the current response time is pretty good for such a long path (1-7)

Ps: I don’t use Alexa and/or Hue, so I am not sure if the “path” that I described above is correct
Ps2: Check the state of the individual Color Items which have not turned on after issuing a “Red” voice command to see if step (4) has been completed successfully.
Ps3: Is it possible to link Alexa directly to the Hue Bridge to see if this happens also with a shorter path? (without OH2 in the middle)

I am seeing the same issue occasionally (~20 hue’s), I cannot reproduce it as it appears to have a similar random effect than you show in your video. Other systems can show this effect too, e.g., 433mhz based plugs are notorious for this issue and show this effect very easily.

Coming from a similar train of thought:

I had implemented @Dim 's solution:

and it worked perfectly. A 10ms delay if memory serves me well, was sufficient for Hue lights. Maybe less works too, I never tried it. In the meanwhile, I moved and started with the group switching approach again (just laziness on my part) so I cannot show you my code anymore.

As always @rlkoshak has several good posts for this, here are some to get your started:


1 Like

Thanks guys, some things for me to think about. I think you are spot on about the path Dim.
I split the lights into 2 groups to see if it would make a difference. It does not seem to matter whether I use 1 group or 2. I get the same issue on a larger scale if I try to use the AllDownstairsLights group which has around 40 lights :slight_smile: (I have approx 75 lights across 2 bridges at the moment, 2 bridges is the reason I needed openhab)
I’ll have a read up on the scripting. I think it would be interesting to see if I could get the lights to switch on/off/colour in the order of my choosing, say in a zigzag or in a circle around the room, do you think this would be possible?

1 Like

Ναί (Yes) :slight_smile:

Markus has more experience than me on rules. He is typing up a response now and I am sure that he will give you more hints :+1:

most definitely…just a lot of coding…but if you use groups and naming schemes in the right way, it is not too difficult, these links may come in handy:



and even this

1 Like

Thank you so much for your hints (ευχαριστώ πολύ), it’s a lot to digest but I will take my time to read over everything and hopefully in a few days time I will post another video of my lights turning on/off and switching colour in a much cooler way, haha! :smile:

1 Like

Hi all,

Yes, that is exactly the root-cause.

As a general guideline we always recommend to our developers to stay at roughly 10 commands per second to the /lights resource with a 100ms gap between each API call. For /groups commands you should keep to a maximum of 1 per second.

Table 1: Average latency for various hue API messages

#ZigBee messages per hue API command parameters used in body of hue API command (example) average latency
1 brightness 55 ms
2 brightness + color 95 ms
3 brightness + color + on 125 ms

See Hue System Performance (login required).

Thanks Christoph, this is exactly what I needed!

rule "AllKitchenLights"
when 
	Item AllKitchenLights_dummyitem received command
 then
    var i = 0
	AllKitchenLights.allMembers.forEach [ item | 
        item.sendCommand(receivedCommand)
        i = i+1
        
      
            Thread::sleep(100)
        
	]	
end

This is what I have used and now ALL the bulbs now switch on/off/colour, great! :slight_smile:

Now I just need to figure out why they seem to be working in the following order rather than the order they appear in the items file.

2018-12-09 16:38:49.712 [ome.event.ItemCommandEvent] - Item 'Kitchen1_Color' received command 120,100,100

2018-12-09 16:38:49.820 [ome.event.ItemCommandEvent] - Item 'Kitchen7_Color' received command 120,100,100

2018-12-09 16:38:49.919 [ome.event.ItemCommandEvent] - Item 'Kitchen11_Color' received command 120,100,100

2018-12-09 16:38:50.028 [ome.event.ItemCommandEvent] - Item 'Kitchen12_Color' received command 120,100,100

2018-12-09 16:38:50.132 [ome.event.ItemCommandEvent] - Item 'Kitchen2_Color' received command 120,100,100

2018-12-09 16:38:50.239 [ome.event.ItemCommandEvent] - Item 'Kitchen10_Color' received command 120,100,100

2018-12-09 16:38:50.349 [ome.event.ItemCommandEvent] - Item 'Kitchen8_Color' received command 120,100,100

2018-12-09 16:38:50.455 [ome.event.ItemCommandEvent] - Item 'Kitchen3_Color' received command 120,100,100

2018-12-09 16:38:50.559 [ome.event.ItemCommandEvent] - Item 'Kitchen4_Color' received command 120,100,100

2018-12-09 16:38:50.668 [ome.event.ItemCommandEvent] - Item 'Kitchen14_Color' received command 120,100,100

2018-12-09 16:38:50.787 [ome.event.ItemCommandEvent] - Item 'Kitchen6_Color' received command 120,100,100

2018-12-09 16:38:50.908 [ome.event.ItemCommandEvent] - Item 'Kitchen9_Color' received command 120,100,100

2018-12-09 16:38:51.031 [ome.event.ItemCommandEvent] - Item 'Kitchen13_Color' received command 120,100,100

2018-12-09 16:38:51.121 [ome.event.ItemCommandEvent] - Item 'Kitchen5_Color' received command 120,100,100

I have tried changing the order in the items file but this makes no difference.

Could someone tell me how is the order determined please? :slight_smile:

From the above linked topic:

OMG, it works! :sunglasses: Amazing!

rule "AllKitchenLights"
when 
	Item AllKitchenLights_dummy received command
 then
    var i = 0
	AllKitchenLights.allMembers.sortBy[name].forEach [ item | 
        item.sendCommand(receivedCommand)
        i = i+1
        
      
            Thread::sleep(100)
        
	]	
end

I’m going to have some fun now! Hopefully post another video later, stay tuned! LOL :grin:

Thanks to everybody for all the help, I feel I made some really good progress with OH today!

I have the sleep set to 300ms currently for this video (set once as a val in the rules rather than in each individual rule)
I like the snake effect of each bulb switching in turn, although if I set the delay to 50ms it also creates a nice effect of the colour change sweeping across the room which I can’t really show properly you on an iphone video :slight_smile:
It’s definitely worth spending the time renumbering your bulbs so they are in order like this!

In any case, thanks to the delay they are working much more reliably now, with the exception of a couple of GU10s which disobey occasionally (like the one in my hallway that was off in the video), although I’m suspecting it might be the bulbs themselves (no bridge errors in OH log). I will give them a few days to see how well they work in normal use and if still giving me problems I will swap them out and see if the problems go away.

2 Likes

Just an idea that this could be caused by RF not being reliable from the bridge to the globes. If you only have a few commands they may send the RF out the the globes multiple times to ensure the message is received, but if 20+ globes are controlled they may skip the extra sending (or may skip waiting for an ACKnowledgement to be returned) to reduce latency and to clear out the queue. This is only a guess as some devices work that way.

No, the hue bridges were simply overloaded.
Slowing down the rate at which the commands are sent to it has cured the issues.

Are you using the new (square) bridges ?

Gert