Lifx Commands delayed after latest update

I have a Python script that synced my Lifx lights to music. It worked better than I could have expected! However after the Lifx latest update there is a delay from when my computer sends the UDP light command and when the light actually changes.

I have the rapid command activated so the script runs without waiting for acknowledgments. It is really upsetting me.

Has this happened to anyone else?
Does anyone know why this is happening?
Is there a way to rollback the firmware on the bulbs?

@drewc89 Are you using broadcast or unicast when you are sending your messages? You will get better performance if you are using unicast instead of broadcast.

Hey Mark

I was using broadcast, but I switched it to Unicast per your suggestion and the issue persisted. I started a packet capture and I can see that the packets are being sent then about 3 seconds later the lights act on them. I can even stop the program and see all packets stop being sent, however the lights are still changing based on previously sent packets.

When I send them slowly it can keep up, however if I rapidly send packets the lights work on a delay. This just started after the last firmware update, it is super frustrating.

Is there a way to clear the “buffer” on the lights?
Is there a way I can roll back the firmware?
Do you have any other suggestions?

Thanks!

A 3 second delay is very high with LAN UDP packets. How many messages are you sending over what time period?

What speed to you have to slow your script down to, in order to get a normal update speed?

What model of lights are you using and what firmware version do you have on them?

There is no way to clear the buffer. It is possible to downgrade light firmware but we would prefer to help resolve the issue.

@drewc89 I am sending around 120 light zone change commands per second to LIFX Z lightstrip. Most of the time this works very well with less than 50 ms latency. After a while there is a noticeable jump in latency that can be fixed by limiting sending rate temporarily.

@superg thanks for the info, you are right after looking at the time stamps per @markh suggestion, I realized that I was sending out about 100 packet a seconds. This was because the python library I was using sent out 5 identical packets (besides the seq number of course) for each iteration of the loop when it should have been sending out one.

I fixed the issue by dumping the library and encoding my data into hex and sending them to my network’s broadcast address. When I did this only 1 packet was being sent out per iteration of the loop. I still had to slow down the speed a little from my original working script, but not enough to really effect the light show.

My best guess for what happened is that the lights handle packet overload differently in the latest update. Before the update the packets would simply get dropped and I didn’t notice it because as long as 1/5th of the packets got through the light show would not be effected. After the update it seems to buffer the packets it can’t process immediately. Personally I like the previous behavior but understand the value of buffering as well.

Here is the light show if anyone is interested. Video