Hue lights misbehaving

[PanGalactic]

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!

[Kim_Andersen]

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.

[Dim (Angelos)]

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

My understanding is the following:

Alexa (1) → Amazon Cloud (2) → myopenhab.org Cloud (3) → OH2 (4) → Hue Binding (5) → Hue Bridge (6) → Lights (7)

(correct?)

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

4.1: Command received for the exposed Group KitchenLights, which triggers 4.2
4.2 : Command received for each of the 2 Group Members (KitchenLights1 & KitchenLights2), which triggers 4.3
4.3: Command to each individual Color Item which is a member of the 2 subgroups.

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)

[lipp_markus]

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:

@Dim

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.

I had implemented @Dim 's solution:

@Dim

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)

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:

Whole house lighting

There’s also a 230/110VAC dimmer actuator available if you want to stick with that voltage (but it only has 1 channel). And quite often you can get snap-in replacement fittings to replace or adapter to move from GU10 to a low voltage fitting like G4 or GU5.3.

Design Pattern: Working with Groups in Rules

Please see Design Pattern: What is a Design Pattern and How Do I Use Them for how to read and use DPs. Problem Statement Often one finds a number of Rules that are very similar and that all work on similar Items resulting in a lot of duplicated code. One way to solve this problem is through the use of Groups. Concept [image] This DP is not a standard DP in that it provides a single concrete template to follow to solve a specific problem. Instead this DP is more of a grand exploration of some …

[PanGalactic]

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 (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?

[Dim (Angelos)]

@PanGalactic

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?

Ναί (Yes)

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

[lipp_markus]

@PanGalactic

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?

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:

Design Pattern: Human Readable Names in Messages

Please see Design Pattern: What is a Design Pattern and How Do I Use Them for details on what a DP is and how to use them. Problem Statement Sometimes one wants to create a message or log statement that references certain Items. A clear example of this is to generate an alert message to be sent when one or more sensors change state. We have a nice way to provide a human readable version of an Item’s name on the UIs (i.e. the label) but from a rule this becomes more difficult. Concept [image] …

Design Pattern: Encoding and Accessing Values in Rules

Edit: Added link to item_init library. Please see Design Pattern: What is a Design Pattern and How Do I Use Them for how to read and use a DP. Problem Statement Often a user has the desire to be able to store and retrieve a series of constants or other values in a Rule. For example, a user may have an RFID reader and want to store the list of authorized and disallowed IDs in a flexible manner. As another example, one may be sending commands to a gateway and need to include the ID of the target…

and even this

Setting item to a previous state based on different item

This doesn’t directly address your specific problem, but if you separated your rules by function rather than room you will have a lot more opportunities for creating generic rules and reuse of variables in code. It also lets you apply DRY (Don’t Repeat Yourself). But regardless, you can do this with two events (one event that starts the heating mode) and two very simple rules. var previousStates = null rule "Start BR Nursery Heating" when // whatever triggers this mode then // store …

[PanGalactic]

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!

[cweitkamp (Christoph Weitkamp)]

Hi all,

@Dim

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.

Yes, that is exactly the root-cause.

Hue binding - mass update not always working

Hi Dennis, A quote from the Hue API documentation: We can’t send commands to the lights too fast. If you stick to around 10 commands per second to the /lights resource as maximum you should be fine. We have to wait for the group feature to be implemented in the binding or use a workaround till then.

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

[PanGalactic]

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!

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?

[cweitkamp (Christoph Weitkamp)]

@PanGalactic

Could someone tell me how is the order determined please?

From the above linked topic:

@rlkoshak

MyGroup.members.sortBy[ <method> ] : Return a List of the members sorted by the value returned by <method> (e.g. using name will sort the Items alphabetically by Item name, lastUpdate by the last time they received an update which requires persistence)

[PanGalactic]

OMG, it works! 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

[PanGalactic]

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

[matt1 (Skinah)]

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.

[PanGalactic]

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

[gert_konemann]

Are you using the new (square) bridges ?

Gert