Wiznet makers

What Is WLED?

WLED is one of the most popular open-source firmware projects for controlling addressable LEDs like WS2812B strips. With over 17,000 GitHub stars, it provides a web-based UI, mobile app support, and dozens of lighting effects, all running on an ESP32 or ESP8266. Most WLED setups rely on WiFi for everything: configuration, remote control, and real-time pixel streaming.

That works well for small installations. But when you're pushing pixel data to hundreds or thousands of LEDs at high frame rates, WiFi's shared-medium nature starts to show its limits: dropped frames, latency spikes, and interference from other devices on the network.

TheBreeze: Wired Pixel Data, Wireless Control

Turkish maker HIVKorn's project, TheBreeze, tackles this by adding a WIZnet W5500 Ethernet interface to WLED through a custom usermod. The W5500 handles all high-bandwidth pixel data over wired Ethernet using DDP (Distributed Display Protocol), while WiFi remains available for lightweight tasks like relay power control.

One reason W5500 was chosen here is that the ESP32 WROOM module does not expose an RMII Ethernet interface. Only specific ESP32 variants like WROVER or WT32-ETH01 support native Ethernet. For a standard ESP32 DevKit, the W5500 via SPI is the simplest way to add wired Ethernet.

This makes it a genuine hybrid network project: the code initializes and actively uses both WiFiUDP (for relay control commands to the master ESP) and EthernetUDP (for DDP pixel data from the W5500) simultaneously, with each interface handling a distinct function.

The master ESP sends chunked DDP packets over Ethernet to the TheBreeze node at 192.168.10.2:4048. The node receives the pixel data through the W5500 and feeds it directly into WLED's realtime rendering pipeline. When LEDs turn on or off, the node sends a simple RELAY_ON / RELAY_OFF UDP command back to the master over WiFi, keeping the LED power supply in sync with actual usage.

Inside the Repository

The project is intentionally minimal. The entire repository contains just three files on top of the standard WLED codebase:

The usermod itself is a single C++ class that handles W5500 SPI initialization, DDP packet parsing, and relay state management. The SPI pins are mapped to non-default GPIOs (MOSI=23, MISO=17, SCK=22, CS=19) to avoid conflicts with WLED's four LED data outputs (GPIO 32, 33, 25, 26) and the INMP441 I2S microphone.

platformio_override.ini shows the project is currently in test mode with 10 LEDs, with a production target of 4x480 = 1,920 LEDs noted in the comments.

W5500 and TOE

The Arduino Ethernet library used here communicates directly with the W5500's hardware TCP/IP core. DDP reception runs on the W5500's built-in UDP socket, so the ESP32 doesn't need to handle any network stack processing for incoming pixel data. This is WIZnet's TCP/IP Offload Engine (TOE) at work: the chip handles the protocol layer in hardware, and the microcontroller just reads the application data.

For a high-throughput use case like real-time LED streaming, this matters. At 3 bytes per LED, 1,920 LEDs produce just 5,760 bytes per frame, which is only ~2.8 Mbps at 60 fps. That is well within the W5500's 100 Mbps capacity. The practical bottleneck would be SPI throughput and WLED's rendering loop, not the network.

Early Stage, Clear Direction

This is an early-stage project with a single commit, no README, and Turkish-language code comments. But the architecture is sound and the code works. It demonstrates a real use case where wired Ethernet solves a genuine problem that WiFi can't reliably handle at scale.

For the full implementation details, see the original repository.

FAQ

Q: What is DDP and why use it instead of Art-Net or E1.31?
A: DDP (Distributed Display Protocol) is a lightweight UDP-based protocol designed specifically for streaming pixel data to LED controllers. Compared to Art-Net or E1.31, DDP has no universe size limitation (512 channels) and supports arbitrary pixel counts per packet, making it simpler for large LED installations.

Q: How many LEDs can a single W5500 handle over DDP?
A: At 3 bytes per LED and 60 fps, 1,920 LEDs require only ~2.8 Mbps. The W5500's 100 Mbps Ethernet link has plenty of headroom. The practical limit comes from SPI bus speed and the ESP32's rendering loop, not the network bandwidth.

Q: Can I add W5500 Ethernet to my existing WLED setup?
A: Yes. This project is built as a standard WLED usermod. You need an ESP32 DevKit, a W5500 SPI module, and six GPIO connections. The usermod registers through WLED's module system, so it works alongside other usermods like AudioReactive.

Q: Does this replace WiFi entirely?
A: No. WiFi remains active for WLED's web UI, OTA updates, and in this project, relay power control. The W5500 only handles the high-bandwidth DDP pixel data path.