Why Your ESP8266 LED Strip Flickers When WiFi Is On
Source: Hackster.io / WiFi Controlled Desk Lamp project
You build a fire effect. It works perfectly when WiFi is off.
Then you enable WiFi and the last 20 LEDs start flickering. Or worse — the whole strip goes chaotic every 10 minutes.
You did everything right. The code looks correct. But your project feels unreliable.
The Problem Is Invisible
Here is what is happening inside the ESP8266:
The WS2812B protocol requires a continuous stream of bits. There is no buffer. If the stream is interrupted for even a few microseconds, the LED gets confused and shows the wrong color.
When WiFi is active, the ESP8266 needs to handle radio interrupts. These interrupts pause the LED data stream. The data gets cut off mid-frame.
The result: flickering at the end of the strip, wrong colors, or random flashes.
This is not a bug in your code. It is a hardware conflict between two things that both need continuous timing.
The Three Fixes
There is no perfect solution. You choose your tradeoff.
Fix 1: Disable Interrupts
Add this before you include FastLED:
#define FASTLED_ALLOW_INTERRUPTS 0
#include <FastLED.h>
The flickering stops. But you now get watchdog resets every 5 to 10 minutes because WiFi cannot respond in time. For a ceiling light, occasional resets are acceptable. For a museum installation that needs to run for days, this is not viable.
Fix 2: Reduce Retry Count
If disabling interrupts causes resets, try this instead:
#define FASTLED_INTERRUPT_RETRY_COUNT 0
#include <FastLED.h>
Some users report this removes the flicker without causing resets. Your mileage depends on your LED count and strip length.
Fix 3: Use Hardware Serial Instead of Bit-Banging
Switch from bit-banging to the ESP8266 UART hardware module. This uses DMA to send LED data in the background while WiFi continues to work.
You need to switch libraries to NeoPixelBus:
#include <NeoPixelBus.h>
NeoPixelBus<Ws2812bFeature, Uart1Pin<Gpio2>> strip(LED_COUNT, pixelCount);
This requires rewriting your LED code. But it runs reliably with WiFi active. The tradeoffs: you give up FastLED features and parallel output support.
Source: Hackster.io / WiFi Controlled Desk Lamp project
What Most Makers Actually Do
After spending hours on this, many makers do one of three things:
They give up on ESP8266 and switch to the ESP32, which has dedicated RMT hardware that handles this properly.
They run the LED strip without WiFi and use a wired serial connection instead.
Or they accept the occasional flicker and use FASTLED_ALLOW_INTERRUPTS 0 as a compromise.
The Real Answer
If you need WiFi and reliable LEDs together, use ESP32.
The ESP32 has dedicated LED driver hardware (RMT) that works independently of CPU interrupts. WiFi and LEDs do not fight each other.
If you are locked into ESP8266 and need WiFi, budget the time to switch to NeoPixelBus with UART1 or I2S hardware output. It works, but it is not a 10-minute fix.
If your project can run without WiFi, turn it off. Your LEDs will be rock solid.
The conflict is not your fault. The hardware was designed for one thing at a time.
