White flashes every 5 minutes - seems related to HA integration

[harueg]

What happened?

Leds flash white every about 5 minutes, hard to tell the exact time in between.

To Reproduce Bug

Setup with esp32E 4MB on AZ-delivery board.
8 outputs with 144 leds each. GPIO 2, 13, 14, 16, 25, 26, 27, 32
Each output is a segment.
Each segment is running different builtin effects.

Expected Behavior

Obviously no flashes

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.13.0-b6 (build 2112080)

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

How would I log that ?

Anything else?

Thank you

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

White flashes (across all leds) usually mean there was an interrupt while updating leds.
Try reducing number of outputs to see where flashes start occurring. If this is with only 1 output it may mean your ESP is having other work to do during led updates (wifi broadcasts, usermods, etc.) preventing it to properly update leds.

[harueg]

Hi blazoncek
Thanks for the answer !
Is there a way to estimate the max number of leds and the max number of outputs for a certain setup.
There is usually a 20ms pause between sending the led data. Wouldn't it possible to put the other "work" in this timeframe ?

[blazoncek]

interrupts occur at any time

[harueg]

Yep, I guess that's the idea of an interrupt.

[harueg]

so from your experience what would be the maximum configuration without having flashes ?
Setup either with ethernet ddp, data from PC or playing fseq files from sd card.

[blazoncek]

I am just explaining my experience. I would suspect a network traffic (mqtt, udp or some other polling your ESP) may be the cause but it may also not be. It may be other hardware in your set-up (sensors and such).
Another possibility is a faulty strip or noise on the data line.
You will need to diagnose your setup by compiling source yourself by adding debug output to various parts of the code. Still I am not sure this will help narrow down the problem.

[ghpk]

Hi,
Are you sure you have sufficient Amps to run 144x8 Setup ? from your post I am assuming you are using
WS2812b with 144Leds/Meter.
Can you please try injecting Power from other Side of each strip and see if that helps.
How long is the Data Line wire from ESP32 Output pins ?

Try running the same setup with 144x4 LEDs and see if that helps.

[thepilchers]

I was noticing a similar issue - an occasional inconsistent flash or "hiccup" while running my LED matrix.
Configuration: Dig-Quad (EPS32) with ethernet running 17 meters of 30 pixels/meter WS2811 in a matrix configuration (total 510 pixels) on 1 channel (pin). 5V 30A power supply set at 5.2V, power injection every 2 meters. Approx 3 meter, 18 gauge, 3 wire cable connecting Dig Quad to matrix.
I tried the following to correct:

• substituting 1 meter pixels at a time with a new pixel strip
• Adding a 2nd channel (pin) at 8m
• Introducing data boosters at each end of the signal wire (2 different types, Intermit.Tech and Holiday Coro)
• Using a different 5v 8A power supply
• Using a different output pin on Dig Quad
• Varying brightness

None of these made a noticeable difference. I then reverted WLED to v0.13.0-b5 (build 2111170) which fixed the problem.

[blazoncek]

None of these made a noticeable difference. I then reverted WLED to v0.13.0-b5 (build 2111170) which fixed the problem.

I don't think it did, it just made it latent. 🤷‍♂️
As I tried to explain above, if you see white flash across all LEDs it will most often mean signal timing issues (caused by interrupts or interfering code) and it may reappear.
Of course there is a possibility that WLED code is sub-optimal in places and optimizations in future will help.

[thepilchers]

You are absolutely correct - I left it running (color 1: RED, color 2 & 3:BLACK, Android effect) with b5 for about an hour and the "hiccups" are occurring again. Possibly interrupts from the ethernet interface on the Dig Quad?

[blazoncek]

Interrupts occur all of the time. Usually they are quickly processed including ethernet.
If they occur during LED update (which itself may need interrupts for timing) this timings may get skewed hence flash.
You may need to monitor network traffic using WireShark or something similar to see if network packets coincide with flashes.
If they do it may point to a sub-optimal code in WLED (what exactly will depend on the packet).
If they don't there may be other things that will interfere (I noticed that a poorly written usermod was a culprit of such flashes once).

[softhack007]

I also had white flashes on my setup (ESP32, 300LEDs SK6812, 15Amp power supply). I found that they were largely caused by electrical problems:

• 5V level shifter (TXS0102) was about to die, and stopped working the next day. Had to replace it.
• LED data cable was thin, long, and not shielded - so it acted like an antenna. Using a shorter cable reduced flashes and colour errors.
• I had the first power injection after 50 LEDs, however I didn't connect 5v and gnd lines at the beginning of the strip because I was afraid to toast my thin dupont wires... 💡 as it turned out, a full "power connection" at the first LED reduced flashing considerably.
• reducing the distances between power supply, controller, and LED strip helped - basically I nailed my ESP32 to the top of a wall, to be as close to the strip as possible 😜

See also: #230

.

If they occur during LED update (which itself may need interrupts for timing) this timings may get skewed hence flash.

Reminds me of something - Could there be some interferences with asynchronous wifi events during LED updates, maybe from AsyncWebServer? NEOPixelBus suggests a workaround for ESP32:
https://github.com/Makuna/NeoPixelBus/wiki/ESP32-and-RTOS-Tasks

Is WLED implementing something similar already?

[howardtopher]

I know I'm a few months late commenting on this one, but I've noticed a similar issue recently. I run my lights from sunset to sunrise every night, but just on solid white. I ran the built in "flow" effect with red, white, and blue for July 2-4. On the 3rd, I noticed a white flash happening randomly. Sometimes 30 seconds apart, sometimes a couple minutes apart. Tonight (the 4th), I sat outside and stared a the lights for a good 10 minutes with no flashes at all.

Christmas was the last holiday I ran a pattern other than solid white. The Christmas pattern was run for more than a month (thanksgiving to new years), with never noticing any flashes. In fact, I've never noticed any flashing in the year I've run WLED in this install until last night. In the time between Christmas and July 4th, I've done two things - 1) update from 0.12.0 to 0.13.1, and 2) start running Home Assistant and added the WLED into there. The solid white still runs perfectly.

At first I figured it was the update that did it assuming new code had a bug or something. However, I did a packet capture tonight and noticed that Home Assistant polls the WLED web ui for two different URIs (/json/si and /presets.json) and it polls both of those every 5 seconds constantly. Now I'm thinking that Home Assistant is just polling it too often and getting in the way of signal generation. Prior to Home Assistant I ran Hubitat which doesn't have an integration so all I did to control it was use the json API (no continuous polling). I'm considering deleting the Home Assistant integration and going back to using the json API directly and see if that helps.

My install is a Dig-Quad (esp32) with about 22 meters of 60 LED/meter WS2815 (12v). Running 2 separate data channels with one about 700 LEDs and the other about 600 LEDs, just over 1300 LEDs total. The flashes happen on both data channels at the same time, which would indicate a signal generation interruption.

[blazoncek]

Reminds me of something - Could there be some interferences with asynchronous wifi events during LED updates, maybe from AsyncWebServer? NEOPixelBus suggests a workaround for ESP32:

https://github.com/Makuna/NeoPixelBus/wiki/ESP32-and-RTOS-Tasks

Is WLED implementing something similar already?

Sorry to see this post so late. Thanks for the insight!

Indeed that could prevent "some" of the flickers related to web UI access or web API calls.
Still these are in minority and only happen when you interact with web interface (UDP has a simpler code and may be less prone).

Nevertheless it may be good to implement seggested approach at some point.