Rate limit for Zigbee commands

I am trying to create a flow that switches multiple (4) Zigbee (Philips Hue, directly connected to Homey) lights on and to a specific temperature and dim level. So my flow consists of 12 actions: 4x on, 4x set dim level. 4x set temperature.
This works… not so well. Sometime this succeeds, most often at least one light does not receive it’s parameters or is not even switched on. I am aware that Zigbee is a bit on the light side in terms of command bursts – but how do you solve this dilemma with Homey? Homey does not seem to get or wait for Ok replies from the Zigbee devices (not sure if this is part of Zigbee), so I need to somehow limit the rate at which the commands are sent. Do I need to explicitely put sleep statements between my actions in my flows? Or is there some secret Zigbee configuration I haven’t found yet?

Have you tried to make use of the delay feature?

What I found works is setting a delay or separating the flows. I have a flow that turns on 15 lights for my hue party and they often don’t get triggered if I execute it in one flow.
Probably too much traffic.

What I found works was separating the flows with delay and execute that flow twice.

So you could have
Flow 1 turn on 4 lights
Flow 2 set dim level
Flow 3 set temperature

Main flow to run the 3 flows

Run flow 1 immediately
Run flow 2 after 1 Sec
Run flow 3 after 2 Sec
Run flow 2 after 3 Sec
Run flow 3 after 4 sec

You may not need to run the repeat if it works.
I do as some of my hues don’t receive the commands the first time so the repeat always solves it and it works great when I execute my hue party lights

The action cards all fire at once if you don’t use delay and the delay. Try adding 1 sec to card 2 for any bulb, 2 sec for next card for same bulb and so on to see if that helps.

An other solution is to add your bulbs to a zone and use the device card to light a zone.

A third solution is to add the devices to a virtual group and use that group in the action part.

Well, thanks, but unfortunately none of those really solve the problem:

  1. Adding local delays. This might fix this problem if only one flow ever controls Zigbee devices. I cannot think of a reasonable way to write multiple flows using some sort of mutex on the Zigbee interface, never forgetting the sleep command.

  2. Using zones. At first this seemed to fix the problem… but sooner or later some devices stayed on though switched off (and vice versa). I have no idea what Homey does behind the scenes, when I Device-switch-on a whole zone and if this even is different to switching them separately. Also this approach only allows to switch devices on or off, not set light temperature., dim level etc.

  3. I couldn’t find virtual groups – only apps for having virtual devices; and those only make writing flows nicer.

If there is nothing I can do to reliably lower the rate of Zigbee commands, can I somehow act on the replies of devices? This way I could only try to change the 2nd device, after the 1st device successfully replied.
I am trying hard to love Homey, but the WAF really drops rapidly if the Zigbee communication is this unreliable. :woozy_face: