Hue Entertainment bad performance

[nhmann]

Hey together, I am using 2 ws2812b strips with 300leds each. Every strip is connected to an esp8266. Everything works fine with the Hue App.

Today I wanted to connect it to the Windows Hue Sync App and use the Music Sync.

When I press "start sync" everything works for the first few seconds fine but the i can figure out a lag which gets worse with the time. After ~10 seconds the strips shut down nearly the same time and the esp8266 reboots (white flash and green flash). After that everything starts again.

The raspberry is connected to the router per LAN, the esp8266 are connected per WiFi but only ~ 2m from the router. My laptop is also ~ 2m from the router.

When i ping the esp8266 from my laptop, the average time is around 95ms.

[mariusmotea]

If wifi performance if not the issue, then the latency of the 300 leds can be the problem. Every led add some extra latency. I believe the frames are received too fast by ESP and it don't have time enough to apply the changes to all 300 leds. Try to decrease to 100 leds. My tests were made with 60leds divided into 3 virtual lights.

[mariusmotea]

Another thing you may try is to set the esp8266 cpu frequency to 160mhz from arduino ide before to complile and flash the code.

[nhmann]

Oh, i forgot to say that each 300led strip is divided into 3 virtual lights. Okay, I tested it with 160mhz. It is slightly better but not good. I used the ESP8266 for another project also with a 300 led strip. In this project every single LED changes up to 30 times a second. https://github.com/scottlawsonbc/audio-reactive-led-strip It worked fine and the ESP8266 had no problems...

Another thing: I checked the raspberrys workload but it is nearly idle

[mariusmotea]

I believe the problem is this: Raspberry forward udp bytes to esp, esp has a loop that read the bytes and apply the needed rgb to each led. This operation require a number of ms and without to have this operation completed there is a new udp package that is received in the buffer. After about 10 seconds (about 240 requests) the buffer is full and esp crash.

[mariusmotea]

Can you test by setting just 60leds on one strip to be sure the wifi performance is not the problem here?

[nhmann]

I want to make a few tests now. I got a better wifi router and I want to reduce the number of leds. I will report the results

[nhmann]

1. try: 1 Strip: 300LEDs a 3 lamps. Router: Belkin N300: ~5s lag, crashed after a while
2. try: 1 Strip: 60LEDs a 3 lamps. Router: Belkin N300: damn nice...

tests with a different network are coming later. the N300 is the old router

[mariusmotea]

Can you find the max led number that is workingfine? Base on that i can choose between some optimizations or refactor entire function.

[nhmann]

Okay, with the original setup (I didn`t test it with the other router yet) 150leds is still working fine but 200leds crashed. Is it fine enough for you or should it test more?

[mariusmotea]

If you can test with other router with better wifi performances it will be better because we can know exactly the router is not a factor.

[nhmann]

Okay, I'll test it. One small question: How can I reset the ESP so I can connect it to different wifi?

[mariusmotea]

Flashing will not delete the wifi credentials, you need to power on the esp with the router powered off. After this you have 2 minutes to connect on esp hotspot and setup new wifi network.

[shbatm]

If you're using the current version of the Arduino IDE and ESP8266 libraries there should be be a menu option to erase the wifi details when you flash.

[mariusmotea]

I'm currently in vacation and read the api from neopixel. There is hope with a new method but i cannot test.

void ClearTo(ColorObject color, uint16_t first, uint16_t last)

This will clear all pixels from first to last to the given color. color - a color object to use, RgbColor, HslColor, and HsbColor will all work and if the NeoPixelBus object was created with the NeoRgbwFeature the RgbwColor will also work. first - the index to the first pixel to start clearing last - the index to the last pixel that will be cleared

The entertainment function must look like this:

void entertainment() {
  int packetSize = Udp.parsePacket();
  if (packetSize) {
    Udp.read(packetBuffer, 4);
    int lightLedsCount = pixelCount / lightsCount;
    strip.ClearTo(RgbColor(packetBuffer[0], packetBuffer[1], packetBuffer[2]), packetBuffer[3] * lightLedsCount, packetBuffer[3] * lightLedsCount + lightLedsCount);
    strip.Show();
  }
}

[mariusmotea]

@nhmann i made a new commit, can you test now if there are problems with 300 leds?

[mariusmotea]

I push lot of changes to fix this issue. I test on my strip with 300 leds and i don't have any issues after these commits.

[nhmann]

Thank you very much! I sadly won't be able to test it before thursday but i will test it asap!

[sneak-thief]

FWIW I have the same issue with my longest SK6812 strip (268 leds). Hue Entertainment often crashes the Wemos D1 Mini - one time it crashed so hard that I had to login to it again over wifi to get it to reconnect to my network.

[mariusmotea]

I perform the fix also for SK6812. Please update HueEmulator3.py file and flash again the firmware on the strip with latest release.

[ghost]

@nhmann @sneak-thief Have you tested this fix?

[sneak-thief]

Not yet - tomorrow is the first chance I'll have to do it.

[sneak-thief]

I did a few quick tests and comparisons: Hue Entertainment via UDP is working much, much better.

Great work!

[ghost]

Thanks for testing, ill close this now