Why do my Philips hue lights sometimes fall behind in animations?

Philips has a great lighting ecosystem, but one of the weaknesses of the product is the ability to keep up with rapid light changes, or even average-paced animations distributed across a larger quantity of lights.

Here's some background information:

The Philips bridge requires a "rest time" of about 0.1 seconds after each light command and 0.7 seconds per group command. (Philips officially recommends 1 second, but I find you can usually shave off a little time with most bridges.) This means that if you have 40 lights and want them all to change to a different random color, it will take at least 4 seconds (40 lights x 0.1s per light) to complete the change, even if fade times are set to zero. On the other hand, you can change all 40 lights to the same color (nearly) all at once with a group command, and the bridge will be ready for more less than one second later.

Where do Lightbow animations come in? Well, each animated preset is a series of light and/or group commands. If you take "Code Red" for example, all assigned lights fade back and forth between red and black. The loop takes two seconds, with one second for the fade-to-red and one second for the fade-to-black. If you have 14 lights individually checked in the assigned lights list, there's a problem, since 14 x 0.1 = 1.4 seconds which is obviously more than 1 second! The easiest fix is to go into the preset editor and assign "All Lights" (or a group of your choosing) instead of individual lights. This way each fade command will only need about 0.7 seconds (the "resting time" for group commands) and you'll have a little time to spare. In this example, individual light commands would quickly pile up and cause delays or even an error from the bridge, while assigning a group instead should be able to run indefinitely.

Was this article helpful?
1 out of 2 found this helpful
Have more questions? Submit a request