Problem
When WLED is used with a relay-controlled LED power supply (relay on the AC side), addressable LED strips can briefly flash an unintended color when the relay switches the LED PSU on and the voltage rises/stabilizes.
My setup is:
- QuinLED Dig-Octa
- WLED 0.16.1 “Niji” - Dig-Octa
- Controller remains powered continuously
- LED power supply is switched using WLED’s relay functionality on the AC side
- Addressable COB LED strip (QuinLED COB LED Strip SK6812/WS2814)
The assumed current startup sequence is approximately:
As soon as brightness > 0 the relay is switched on an data is sent to the LEDs
During this startup period of the PSU, the strip can briefly flash.
Test result: power-up itself does not cause the flash
I tested the strip startup separately.
Applying power to the LED strip does not cause any flash as long as no LED data is transmitted during the PSU/strip power-up phase.
This includes the period while the PSU output voltage is still rising and has not yet fully stabilized.
The strip remains dark when:
Relay ON
↓
PSU starts
↓
Strip receives power
↓
No LED data transmitted
The unwanted flash occurs when LED data is transmitted during this startup period.
The required behavior is therefore:
Do not transmit LED data at all during the configurable relay power-on guard period.
Once the guard period has expired, normal LED output can start and the existing WLED transition can begin.
Related discussions
Similar startup-flash and power-up timing issues have been discussed in the WLED community for several years (as a new user I cannot link them all):
- Strong Light flash when powerup Ledstrips
- Power delay to WS2812
- Flashing on boot
- Green Flash on Startup
- How to Delay initializing LEDs at powerup
Proposed feature
Add a configurable minimum guard time after the relay switches ON before LED data transmission is allowed.
For example:
Relay power-on guard: 500 ms
When the relay changes from OFF → ON, WLED records the timestamp:
relayOnTimestamp = millis()
Until the configured guard time has elapsed, LED data output should remain inactive.
Afterwards, normal WLED output resumes and the requested transition starts.
Desired startup sequence
The desired behavior is:
LED ON command
↓
Relay ON
↓
Record relay-on timestamp
↓
Power-up guard period
↓
NO LED DATA transmitted
↓
Guard period expires
↓
Start normal WLED output / transition
For example:
Relay guard: 500 ms
Transition: 700 ms
0 ms Relay ON
0–500 ms No LED data transmitted
500 ms LED output becomes active
500 ms Normal WLED transition begins
500–1200 ms Fade from OFF to requested brightness/color
There should be no BLACK frames or other LED protocol frames sent during the first 500 ms.
Data-line behavior during the guard period
Based on my testing, the important requirement is that the LED strip must not receive LED protocol data during PSU startup.
Therefore:
During relay guard:
No LED frames transmitted
After relay guard:
Resume normal LED output
Start requested transition
How the underlying LED output driver achieves this internally is an implementation detail.
For example, it may mean suspending the relevant bus output, preventing show() calls from transmitting, or otherwise keeping the LED protocol inactive during the guard period.
The important functional requirement is that BLACK frames must not be continuously transmitted as a substitute, because my testing shows that the strip powers up cleanly when no data is transmitted.
Guard time should depend on actual relay-on time
The guard should only apply after a real relay OFF → ON event.
It should not simply add the configured delay to every ON command or transition.
For a 500 ms guard:
Relay just switched ON
→ wait 500 ms before transmitting LED data
Relay has already been ON for 120 ms
→ wait another 380 ms
Relay has already been ON for 450 ms
→ wait another 50 ms
Relay has been ON for >= 500 ms
→ transmit immediately
This makes the feature a minimum PSU/strip stabilization time rather than a generic transition delay.
Important behavior
The guard should NOT delay:
- brightness changes while the relay is already on
- preset changes while the relay is already on
- color changes while the relay is already on
- effect changes
- normal transitions while the LED PSU is already powered
Example:
Relay ON for 10 seconds
LEDs currently at 10%
User changes brightness to 100%
→ transition starts immediately
The PSU and strip are already powered and have been stable for much longer than the configured guard time.
Possible configuration
For example:
LED Preferences
Relay GPIO: [configured GPIO]
Relay power-on guard: 500 ms
or:
Relay startup guard:
0 ms = disabled
A millisecond value would be useful because typical PSU/LED-controller startup times are much shorter than whole seconds.
Why this could be useful beyond my setup
This could benefit WLED installations using:
- relay-switched LED power supplies
- QuinLED controllers with standby-powered ESP32
- large LED power supplies with non-zero startup time
- addressable COB strips
- WS281x-compatible strips
- other addressable LEDs that are sensitive to data received during power-up
It would also avoid the need for external timing circuitry or hardware-specific workarounds.
Summary
The requested behavior is:
Relay OFF → ON
↓
Start guard timer
↓
Power LED PSU / strip
↓
Transmit NO LED data during guard period
↓
Wait until relay has been ON for configured minimum time
↓
Enable normal LED output
↓
Start the existing WLED transition
The two key requirements are:
- The guard time is based on how long the relay has actually been ON, rather than being a fixed delay added to every transition.
- No LED protocol data should be transmitted during the guard period. Testing shows that powering the strip, including the PSU voltage-rise phase, does not cause the flash when data transmission is absent.
Difference towards Multi-Relay usermod
The multi relay usermod offers the exact opposite of the requested feature. It starts data transmission, but delays the relay trigger for the specified GPIOs.