//MAIN// | //GO BACK//

LED Network Display

In this first demo video, you can see the LED Network Display in action on a single LED strip. At the start of the video, there is very little network traffic. I then trigger a large upload and download so you can see the effect increased network traffic has on the display.

This second demo video shows the LED Network Display in action with two LED strips, one representing TX and the other RX. At the start of the video, there is moderate network traffic. I then trigger a large upload and download so you can see the effect increased network traffic has on the display.

Per my personal policy, I’m disclosing here that I “vibe-coded” the software for this project using AI. I understand people have feelings about this sort of thing, but in my opinion this is exactly the kind of project AI coding tools are useful for: a small, one-off project that you just want to get up and running.

Downloads (read below for history and instructions)

Download WLED Network Display v2.0.0-rc10

Download the RC10 Firmware Bundle - Dig2Go, Dig-Next-2, and Generic ESP32

Download the Complete RC10 Package - Application + Firmware

Download the Original Home Assistant / Node-RED Flow

Download the WLED Network Display RC10 Corresponding Firmware Source (also included in the firmware bundle; not needed to run the app)

UPDATE - 10/01/2026

The standalone version has changed quite a bit since my original update. The current build is v2.0.0-rc10, and the recommended configuration now uses a small custom WLED firmware build rather than streaming complete LED frames across the network.

The standalone application still runs on both Windows and Linux. I’ve tested it on Windows 11 and Debian 13, and am currently running it on a Pi 4 with the current version of Raspberry Pi OS. Both installers include the same interactive setup wizard for SNMP, WLED, traffic scaling, colors, layout, fallback behavior, display brightness, and particle highlight intensity. I can confirm that this version works with both pfSense and MikroTik switches running SwOS, but any device that exposes suitable standard IF-MIB interface counters over SNMP should be usable.

The biggest change is the addition of native local rendering. The Python application still polls the network device over SNMP and calculates the RX/TX traffic rates, but it no longer needs to generate and send 48 complete RGB frames per second. Instead, it sends a small traffic telemetry packet to WLED, and a custom WLED effect called Network Traffic Native generates the particle animation locally on the ESP32.

This change came out of testing the realtime frame-streaming approach. I could see occasional small pauses or jitter even when the Python renderer was holding essentially perfect frame timing. I tried both WLED’s DRGB realtime protocol and DDP, and the behavior was still visible. Meanwhile, WLED’s built-in effects remained smooth on the same hardware. Moving the animation itself onto the ESP32 removes network packet arrival timing from the animation clock, and in my testing the result has been much smoother.

I’ve tested the native firmware on a QuinLED Dig2Go with a single strip and a QuinLED Dig-Next-2 driving two physical LED outputs. I also built a generic firmware image for common classic 4 MB ESP32-WROOM / ESP32 DevKit-style boards, but that version remains untested.

RC9 added per-output WLED brightness selection to the setup wizard:


Low 64 / 255

Medium 160 / 255 (default)

Bright as possible 255 / 255

Manual 1 - 255

That value is applied when the Network Display effect starts. A fallback preset keeps its own stored brightness when the application stops.

RC10 adds a separate particle highlight-intensity control. The highlight color still determines the color of the bright head of each particle; the new setting determines how strongly that color is blended into the particle:


None 0%

Subtle 30%

Medium 60% (default for new configurations)

Strong / RC9 behavior 100%

Manual 0 - 100%

Existing RC9 and earlier configuration files that do not contain the new setting are treated as 100%, so upgrading the application does not silently change the appearance of an existing display. In native mode, adjustable highlight intensity requires the RC10 firmware. RC10 remains packet-compatible with RC9: the RC10 application can still drive RC9 firmware, but RC9 firmware will simply continue using the original 100% highlight behavior.

The original Home Assistant/Node-RED version described below is still available and still works. The standalone/native version is what I’ll be working on going forward.

Original Node-RED Version and Genesis of the Project

The project originally started as a Node-RED flow running under Home Assistant. The rest of this section describes that original implementation and how the project came together.

In my work office I have a couple of conduits that carry CAT6 and fiber cables to different spots in the room. When I installed the conduits, I spaced them roughly so I’d be able to fit an LED strip between them. I finally got around to actually adding the strip, and this is what I came up with:

The LEDs are a strip of WS2812B1 LEDs, which are individually addressable. Regular RGB LEDs won’t work for something like this because the individual LEDs need to be controlled independently.

I used a dig2go2 controller, which is essentially a pre-made ESP32-based controller running WLED firmware. It makes it quick and easy to get up and running.

After getting the LEDs mounted in an aluminum channel3, wired to the controller, and mounted to the wall, I started working on the effect I was looking for. At first I went with a generic pattern that sort of looked like “data flowing” through the strip. Then it occurred to me that, since the controller was already on the network and WLED supports realtime control, it might be possible to make the display react to actual network traffic.

I’m using a MikroTik switch running SwOS, but any network device that exposes suitable interface counters over SNMP should be usable for this sort of project.

In Node-RED, running under Home Assistant, I set up a flow that polls the selected switch interface over SNMP once per second. It reads the interface inbound and outbound byte counters, calculates the actual traffic rate from the difference between successive samples, maps those values to RX and TX for the display, and smooths them slightly so the animation isn’t overly erratic.

Those traffic rates are then used to generate two streams of particles. RX traffic is represented by cyan particles traveling in one direction, while TX traffic is represented by green particles traveling in the other. The amount of traffic primarily controls how frequently particles appear, while heavier traffic also makes them somewhat brighter and gives them slightly longer trails.

The original animation is rendered in Node-RED rather than by one of WLED’s built-in effects. Node-RED generates the RGB values for the entire strip at roughly 24 frames per second and sends them directly to WLED using its realtime DRGB UDP interface.

This particular strip is visible behind me on camera during video meetings, so I wanted the movement to look reasonably smooth at 24 fps. The renderer uses fractional pixel interpolation between adjacent LEDs, which helps make the particles appear to move more smoothly both on camera and in person.

As a fallback, if Node-RED stops sending realtime data, the WLED realtime timeout expires and the controller automatically returns to a normal WLED preset. That way the strip doesn’t freeze or go dark if Node-RED, SNMP, or the network connection fails.

Standalone Version

The standalone application packages the SNMP polling, traffic calculations, scaling, configuration, logging, and WLED control into a Python application that runs as a background service on Windows or Linux.

Version 2 uses named instances. One instance consists of:


one SNMP traffic source

        |

        +-- one or more WLED controllers

For example:


instance "office"

    office switch uplink

        -> one combined RX/TX WLED strip

instance "internet"

    firewall WAN interface

        -> RX strip

        -> TX strip

Different SNMP sources should normally be configured as separate instances. Multiple WLED outputs driven by the same source remain in the same instance, so the application only polls that SNMP interface once.

Each WLED output can display:


RX + TX

RX only

TX only

The application supports one strip, multiple WLED controllers, separate RX/TX strips, and multiple physical LED outputs on a single WLED controller.

Current Native Architecture

The recommended RC10 configuration looks like this:


Network switch / router / firewall

            |

            | SNMP interface counters

            v

WLED Network Display Python app

            |

            | small UDP telemetry packets

            | default: 10 updates/sec on UDP 21325

            v

WLED + Network Display usermod

            |

            | local "Network Traffic Native" effect

            v

LED strip(s)

Python still does the network-monitoring work:

  • polls the selected interface over SNMP

  • calculates RX/TX throughput from counter differences

  • handles 64-bit counters with 32-bit fallback

  • maps inbound/outbound counters to display RX/TX

  • applies logarithmic traffic scaling

  • handles colors, traffic scale, output regions, brightness, and fallback configuration

The ESP32 does the animation work:

  • particle spawning

  • particle movement

  • trails

  • fractional LED interpolation

  • brightness/highlight blending

  • continuous frame timing

That division of work is important: the traffic values still come from the monitored network device, but the movement of the LEDs is no longer dependent on a new network packet arriving for every animation frame.

How the Particle Animation Represents Traffic

The display is not trying to represent individual Ethernet packets. SNMP gives the application interface byte counters, so the Python side measures how quickly those counters are changing and turns the resulting throughput into a normalized visual activity value for RX and TX.

The traffic scaling is logarithmic rather than linear:


activity = log10(1 + Mbps) / log10(1 + configured scale Mbps)

The result is clamped between 0 and 100%. This makes lower traffic levels much more visible than they would be with a simple linear scale. With the default 1000 Mb/s scale, the approximate visual activity works out to:


1 Mb/s -> about 10%

10 Mb/s -> about 35%

100 Mb/s -> about 67%

500 Mb/s -> about 90%

1000 Mb/s -> 100%

The setup wizard asks for the throughput that should represent 100% visual activity. That value does not need to be the physical line rate. It should be whatever makes sense for the traffic source you are monitoring. If a link normally tops out around 100 Mb/s, setting the scale to 100 Mb/s will make 100 Mb/s produce the full visual effect. The wizard can also use separate RX and TX scales, which is useful for asymmetric Internet connections.

Very small background traffic is ignored by default below approximately 0.02 Mb/s, so ARP, keepalives, and other tiny amounts of network chatter do not constantly produce particles.

Particle Density - The Main Traffic Indicator

The primary indication of bandwidth is how many particles are being generated, not how fast they move.

At low activity, particles appear only occasionally. As traffic approaches the configured 100% scale, particles are spawned much more frequently.

The RC10 defaults are:


RX maximum spawn rate: 3.0 particles/second

TX maximum spawn rate: 2.4 particles/second

Once there is measurable activity, the spawn rate starts at a very low baseline and ramps toward those maximums as the visual activity value increases. This gives occasional visible motion even with light traffic without making an idle link look busy.

This was an intentional design choice. I found that using particle density as the main bandwidth cue is much easier to read than making particles race faster and faster as throughput increases.

Particle Speed

Particle speed is mostly independent of network traffic. The default speeds are:


RX: 15.0 LEDs/second

TX: 13.5 LEDs/second

Those are base speeds. Each new particle gets a small random variation of approximately +/-10%, which prevents several particles from moving in a perfectly synchronized, mechanical-looking group.

In other words, a large file transfer creates more particles, but it does not substantially make each individual particle move faster.

The speeds can be changed under the setup wizard’s advanced animation settings.

Trails

Each particle has a fading trail. The default base trail lengths are:


RX: 8 pixels

TX: 7 pixels

Traffic activity does influence trail length. At low activity the trail is roughly 75% of the configured base length, and at full activity it can grow to roughly 145% of the base length. Each particle also gets a small random trail-length variation so the animation does not look too uniform.

This means heavier traffic looks somewhat fuller even beyond the increase in particle count.

Particle Brightness vs. WLED Brightness

There are two separate brightness controls involved.

First, the renderer varies the particle strength with traffic activity. At low traffic, individual particles are somewhat dimmer. As activity approaches 100%, the particles become brighter. A small per-particle random variation is also added so every particle does not look exactly identical.

Second, the brightness selected in the setup wizard is the normal WLED master brightness for the Network Display effect:


Low 64 / 255

Medium 160 / 255

Bright as possible 255 / 255

Manual 1 - 255

That WLED value controls the overall output level. So heavier traffic can make the particles brighter within the animation, while the configured WLED brightness still acts as the master brightness for the entire display. WLED’s configured current/power limiter remains independent and can still reduce the actual LED output if necessary.

Colors and Highlights

RX and TX each have a base color and a highlight color.

The RC10 defaults are:


RX base: RGB 0,205,255 #00CDFF

RX highlight: RGB 210,255,255   #D2FFFF

TX base: RGB 0,255,100  #00FF64

TX highlight: RGB 70,255,220 #46FFDC

The bright head of the particle is blended toward the highlight color. Farther back in the trail, the color transitions toward the base color and then fades exponentially toward black.

When two particle trails overlap, their RGB values are added together, up to the maximum value for each color channel. This can make busy portions of the strip look brighter and more energetic without changing the basic RX/TX colors.

The setup wizard includes several color presets as well as manual RGB entry. If you enter a custom base color, the wizard automatically creates a related highlight by blending that color toward white, although the highlight can also be customized separately.

The color itself does not represent bandwidth. Color identifies RX versus TX; particle density, trail length, and particle strength represent the amount of traffic.

Particle Highlight Intensity - RC10

RC10 separates the highlight color from the highlight intensity. The highlight color determines what color the head of the particle is blended toward, while highlight intensity determines how strongly that color is applied.

The setup/edit wizard offers:


None 0%

Subtle 30%

Medium 60% (default for new configurations)

Strong / RC9 behavior 100%

Manual 0 - 100%

A setting of 0% does not turn the particle off or reduce the WLED master brightness. It only removes the highlight-color blend, leaving the normal base-colored particle and trail. Likewise, 60% does not mean that the LED is running at 60% brightness; it means the highlight contribution is 60% of the normal RC9 highlight strength.

The setting is global to an instance, so RX and TX use the same highlight-intensity percentage while retaining their independently configured base and highlight colors.

For backward compatibility, RC9 and earlier configuration files that do not contain highlight_intensity are loaded as 100%. New RC10 configurations default to 60%.

In native mode, the RC10 application sends the intensity value to the WLED usermod as part of the same 41-byte telemetry packet. RC10 firmware understands the new value, while RC9 firmware safely ignores it and continues using the original 100% highlight behavior.

Direction and Strip Orientation

On a combined RX/TX region, the two particle streams travel in opposite directions:


RX  -------------------->

TX  <--------------------

For a dedicated RX-only or TX-only region, the traffic moves from the logical beginning of that region toward its end. The setup wizard’s Reverse the physical animation orientation option flips the WLED segment, which is useful when two strips are physically mounted in opposite orientations.

Smoothing and Responsiveness

There are two different kinds of smoothing in the current design.

The Python application first applies light smoothing to the calculated SNMP throughput so a single noisy sample does not instantly change the display. The default smoothing factor is 0.45.

Native mode then eases the RX/TX activity value on the ESP32 over approximately 150 ms by default. This second stage only smooths changes in traffic activity. It does not pause or buffer particle movement.

The Python application sends native telemetry at 10 Hz by default, but the ESP32 continues rendering and moving particles locally between those updates. This is one of the main reasons the native version looks smoother than the earlier full-frame streaming versions.

Advanced Animation Defaults

For reference, the current RC10 native defaults are:


Traffic scale: 1000 Mb/s

Ignore traffic below: 0.02 Mb/s

Python traffic smoothing: 0.45

Native telemetry update rate: 10 Hz

Native traffic easing: 150 ms

Particle highlight intensity: 60% (new configurations)

RX speed: 15.0 LEDs/sec

TX speed: 13.5 LEDs/sec

RX max spawn rate:  3.0 particles/sec

TX max spawn rate: 2.4 particles/sec

RX base trail: 8 pixels

TX base trail: 7 pixels

Most users should not need to change the animation values. The settings that usually matter most are the traffic scale, which determines how easily the display reaches a busy-looking state; the WLED master brightness, which determines the overall light output; and the particle highlight intensity, which controls how strongly the bright particle head stands out from the base-colored trail.

Why the Custom WLED Firmware?

The first standalone versions rendered the complete animation in Python and streamed full RGB frames to stock WLED.

I eventually increased the sender to 48 fps and added high-resolution frame pacing and timing diagnostics. During a constant-motion test, the Python sender was effectively holding the requested 48 fps with extremely small timing variation, but I could still see occasional hiccups in the LEDs.

I tested both:


WLED DRGB realtime UDP

DDP realtime UDP

and the visible jitter remained. It was more noticeable on a larger two-output display than on a smaller single-strip display, while ordinary WLED effects running locally on both controllers looked smooth.

That narrowed the problem down to the realtime frame-streaming path rather than the SNMP calculations or the Python animation scheduler.

A traditional jitter buffer was one possible solution, but it would still leave the ESP32 consuming a stream of complete animation frames. Instead, I moved the actual particle effect into WLED.

The custom firmware is still WLED 16.0.1. The only project-specific addition is a usermod that:

  • listens for Network Display telemetry on UDP port 21325

  • registers a WLED effect named Network Traffic Native

  • receives RX/TX activity and animation parameters

  • renders the particles locally using WLED’s own effect timing

The Python side sends a very small telemetry packet instead of hundreds of RGB bytes 48 times per second.

The important difference is:


Frame streaming:

network packet timing

        -> LED frame timing

Native rendering:

network packet timing

        -> traffic activity value

local ESP32 clock

        -> LED frame timing

A delayed telemetry packet might make the displayed traffic level update a few milliseconds later, but it no longer causes a moving particle to pause.

This still feels realtime in practice because the underlying SNMP traffic measurement is sampled much more slowly than the LED animation itself. The default native telemetry rate is 10 Hz, while the ESP32 continuously renders the animation locally between telemetry updates.

DDP and DRGB are still supported by the application for stock-WLED compatibility and diagnostics, but native mode is the recommended setup.

Custom Firmware Options

The RC10 firmware bundle contains three WLED 16.0.1 builds:


WLED_16.0.1_Dig2Go_NetworkDisplay_RC10.bin

WLED_16.0.1_Dig-Next-2_NetworkDisplay_RC10.bin

WLED_16.0.1_Generic-ESP32-4MB_NetworkDisplay_RC10.bin

QuinLED Dig2Go

Use the Dig2Go image on a QuinLED Dig2Go. The build retains the normal QuinLED Dig2Go board configuration and existing QuinLED usermods, with the Network Display usermod added.

QuinLED Dig-Next-2

Use the Dig-Next-2 image on a QuinLED Dig-Next-2. This keeps the board’s normal two-output, PSRAM, relay, sensor, and other QuinLED-specific build settings while adding the Network Display usermod.

Generic ESP32 4 MB

The generic image is based on WLED’s normal esp32dev build and is intended for common classic ESP32 boards such as many ESP32-WROOM and ESP32 DevKit-style boards with 4 MB of flash.

It is not the correct binary for:


ESP32-C3

ESP32-S2

ESP32-S3

Those devices need a build made for their specific WLED target.

On a generic ESP32, WLED does not know how your LED strip is wired. After installation, configure the LED data GPIO, LED type, LED count, and current/power limit in WLED before running the Network Display wizard.

Software Licensing and Firmware Source

The different parts of this project are distributed under separate software licenses:


Standalone Python application and project-authored installer/management scripts:
MIT License

Network Display WLED usermod and modified WLED firmware:
European Union Public Licence v1.2 or later (EUPL-1.2+)

QuinLED build configuration used for the QuinLED-specific firmware targets:
MIT License

The firmware bundle includes the corresponding source used to build the three RC10 firmware images. I also provide that source as a separate download near the top of this page so it is easy to find.

The source package contains the prepared WLED 16.0.1 source tree, the Network Display usermod, the build configuration used for the Dig2Go, Dig-Next-2, and generic ESP32 targets, the applicable license files, and notes identifying the upstream versions used for the release build.

The source archive is not required to install or run the project; it is provided with the firmware distribution so the source for the modified WLED build remains available.

Installing the Custom WLED Firmware

Back Up WLED First

Before installing custom firmware, I recommend downloading both the WLED configuration and presets backup.

In WLED, open:


Config

  -> Security & Updates

  -> Backup & Restore

The custom image is based on WLED 16.0.1 and an OTA update normally keeps the existing configuration, but having a backup is cheap insurance.

Existing WLED Installation

If the controller is already running WLED:

  1. Download the correct .bin for the controller.

  2. Open the WLED web interface.

  3. Go to Config -> Security & Updates.

  4. If OTA Lock is enabled, enter the OTA passphrase, disable the lock, save, and reboot.

  5. Open Update WLED / Manual OTA update.

  6. Upload the appropriate Network Display .bin.

  7. Let the controller reboot completely.

  8. Open the WLED Effects list and verify that Network Traffic Native is present.

  9. Re-enable OTA Lock if you normally use it.

WLED’s own OTA/update documentation is available here.

Blank Generic ESP32

For a completely blank classic ESP32, the easiest path is:

  1. Install ordinary WLED 16.0.1 using the official WLED web installer.

  2. Connect WLED to Wi-Fi and verify the web interface works.

  3. Use WLED’s Manual OTA update page to upload WLED_16.0.1_Generic-ESP32-4MB_NetworkDisplay_RC10.bin.

  4. Configure the LED hardware under Config -> LED Preferences.

  5. Verify that Network Traffic Native appears in the Effects list.

The generic project binary is an application firmware image; starting with the normal WLED installer is the easiest way to ensure a blank ESP32 also has the expected bootloader and partition layout.

Important Future-Update Note

If you later flash an ordinary stock WLED firmware image, WLED itself will still work, but the Network Traffic Native usermod/effect will no longer be present.

To continue using native mode after a WLED upgrade, install a Network Display custom build based on the newer WLED version. The Python application can still use DDP or DRGB with stock WLED if necessary.

Before You Install the Application

Have these ready:

  • A WLED controller reachable from the computer running the application

  • The custom Network Display WLED firmware installed if you want native mode

  • SNMP enabled on the switch, router, or firewall you want to monitor

  • Your SNMP v2c community string

  • The interface you want to monitor

  • the wizard can normally discover this for you

  • Python 3.11 or newer

For a normal display, the defaults are:


RX = cyan

TX = green

The colors are configurable in the wizard.

For native mode, the application needs:


HTTP access to WLED

UDP 21325 from the application host to WLED

You do not need to enable WLED’s Receive UDP realtime option for native mode.

If the application host and WLED controller are on different VLANs, make sure your firewall allows the required HTTP access and UDP 21325 traffic between them.

WLED Output Modes

RC10 supports three WLED output modes.

1. Native Local Render - Recommended

Requires the custom Network Display WLED firmware.


UDP port: 21325

Default telemetry rate: 10 Hz

WLED renders every animation frame locally.

2. DDP

Works with stock WLED.


UDP port: 4048

Python sends complete RGB frames to WLED.

3. WLED DRGB Realtime

Legacy stock-WLED compatibility mode.


UDP port: 21324

This mode uses WLED’s Receive UDP realtime setting.

DDP and DRGB are useful compatibility and diagnostic options, but I recommend native mode where the custom firmware is available.

Linux Installation

Tested on Debian 13.

Prerequisites


sudo apt update

sudo apt install -y python3 python3-venv

A globally installed pip is not required.

Extract the package:


unzip WLED-Network-Display-v2.0.0-RC10.zip

cd wled-netdisplay-v2.0.0-rc10

Install:


sudo ./install-linux.sh

The installer:

  • creates a dedicated wled-netdisplay system account

  • copies the application to /opt/wled-netdisplay

  • creates a private Python virtual environment

  • installs the Python dependencies

  • installs the wled-netdisplay management command

  • installs a systemd service template

  • optionally launches the setup wizard

When asked:


Configure a display instance now? [Y/n]

choose:


y

Linux Setup Wizard

The wizard prompts for information including:


Instance name

SNMP host/IP

SNMP community

SNMP interface

RX/TX direction

SNMP polling interval

Traffic scale

WLED host/IP

Output mode

LED layout / regions

Fallback preset

RX/TX colors

Particle highlight intensity

WLED brightness

When the custom firmware is installed, choose:


Native local WLED render

For brightness, the choices are:


1) Low 64 / 255

2) Medium 160 / 255 default

3) Bright as possible 255 / 255

4) Manual value 1 - 255

For particle highlight intensity, the choices are:


1) None 0%

2) Subtle 30%

3) Medium 60% default

4) Strong / RC9 behavior 100%

5) Manual value 0 - 100%

Highlight intensity is separate from WLED master brightness. It controls only how strongly the configured highlight color appears at the head of each particle.

Use SNMP interface discovery when offered. This is generally easier than manually looking up an interface ifIndex.

For a normal one-strip display choose:


RX + TX on same strip

For a controller driving separate RX and TX strips, configure separate regions for each direction. The regions may be on the same physical data output or on different WLED physical outputs; WLED exposes them as logical LED ranges.

Native Setup / Validation

The running service automatically activates the native effect when it has valid SNMP data, but the explicit setup command is useful for validating the custom firmware and programming the configured WLED segments:


sudo wled-netdisplay native-setup OfficeSwitch

You should see:


Network Traffic Native

reported as the active custom effect.

Then run the native diagnostic:


sudo wled-netdisplay test-native OfficeSwitch 60

During test-native, Python only sends slowly changing synthetic traffic activity. Every particle position and LED frame is generated on the ESP32. The manager temporarily stops the normal instance during the test and restores it afterward.

#### Configuration Location

Linux instance configuration files are stored under:


/etc/wled-netdisplay/instances/

For example:


/etc/wled-netdisplay/instances/OfficeSwitch.json

Application files are installed under:


/opt/wled-netdisplay/

The config directory is restricted because SNMP community strings should be treated as credentials.

Linux Management Commands


sudo wled-netdisplay list

sudo wled-netdisplay status OfficeSwitch

sudo wled-netdisplay start OfficeSwitch

sudo wled-netdisplay stop OfficeSwitch

sudo wled-netdisplay restart OfficeSwitch

sudo wled-netdisplay test OfficeSwitch

sudo wled-netdisplay test-leds OfficeSwitch

sudo wled-netdisplay native-setup OfficeSwitch

sudo wled-netdisplay test-native OfficeSwitch 60

sudo wled-netdisplay logs OfficeSwitch

sudo wled-netdisplay add

sudo wled-netdisplay edit OfficeSwitch

sudo wled-netdisplay remove OfficeSwitch

Windows Installation

Tested on Windows 11.

Prerequisites

Install Python 3.11 or newer.

Verify Python from PowerShell:


py -3 --version

or:


python --version

Run PowerShell as Administrator.

Extract the RC10 ZIP and enter the application directory:


cd C:\Path\To\wled-netdisplay-v2.0.0-rc10

If necessary, temporarily allow PowerShell scripts for the current session:


Set-ExecutionPolicy -Scope Process Bypass

Install


.\install-windows.ps1

The application is installed under:


C:\ProgramData\WLEDNetDisplay

Instance configuration files are stored under:


C:\ProgramData\WLEDNetDisplay\instances

Per-instance logs are stored under:


C:\ProgramData\WLEDNetDisplay\logs

Each configured instance gets its own Windows Task Scheduler task, for example:


WLED Network Display - OfficeSwitch

The task starts automatically with Windows and is configured to restart if the application fails.

Windows Setup Wizard

The Windows installer uses the same Python setup wizard as Linux, so the configuration questions are essentially identical:


Instance name

SNMP device

SNMP community

SNMP interface

RX/TX direction

Traffic scale

WLED controller

Native / DDP / DRGB output mode

LED layout / regions

Fallback preset

RX/TX colors

Particle highlight intensity

WLED brightness

For the recommended configuration select:


Native local WLED render

and choose the desired brightness preset plus the particle highlight intensity you want. New configurations default to 60% highlight intensity.

Native Setup / Validation

Set the manager path in an elevated PowerShell window:


$Manager = "$env:ProgramData\WLEDNetDisplay\manage-windows.ps1"

Validate/configure the native WLED effect:


& $Manager native-setup OfficeSwitch

Run the local-render diagnostic:


& $Manager test-native OfficeSwitch 60

Windows Management Commands


$Manager = "$env:ProgramData\WLEDNetDisplay\manage-windows.ps1"

& $Manager list

& $Manager status OfficeSwitch

& $Manager start OfficeSwitch

& $Manager stop OfficeSwitch

& $Manager restart OfficeSwitch

& $Manager test OfficeSwitch

& $Manager test-leds OfficeSwitch

& $Manager native-setup OfficeSwitch

& $Manager test-native OfficeSwitch 60

& $Manager logs OfficeSwitch

& $Manager add

& $Manager edit OfficeSwitch

& $Manager remove OfficeSwitch

Multiple Displays

The standalone version is designed so one SNMP source can drive multiple WLED outputs while polling the network device only once.

For example:


One SNMP source

    |

    +-- WLED output 1

    +-- WLED output 2

    +-- WLED output 3

Each WLED output can be configured as:


RX + TX

RX only

TX only

For example:


Switch A

    |

    +-- WLED #1 - RX + TX

    +-- WLED #2 - RX only

    +-- WLED #3 - TX only

Different SNMP traffic sources should normally use separate instances:


Office switch  -> instance "office"

WAN interface  -> instance "internet"

Server switch  -> instance "servers"

Two Strips on One WLED Controller

If one WLED controller drives two physical strips, do not define the same WLED controller as two independent outputs in the application.

Instead, configure the controller’s total logical LED space and create separate regions:


WLED controller

    |

    +-- region 1 -> RX only

    +-- region 2 -> TX only

In native mode, the application turns those regions into WLED segments and assigns the custom effect to each segment.

This works whether the physical strips are daisy-chained on one output or connected to separate data outputs on a multi-output WLED controller, as long as WLED gives each strip its own logical LED range.

Two strips wired in parallel to the exact same data signal will mirror each other and cannot independently display RX and TX.

Fallback Behavior

Each WLED output has a configurable fallback preset.

When the Python service is running and valid SNMP data is available, the Network Display effect is active.

If SNMP goes stale or the service shuts down normally, the application reapplies the configured fallback preset.

In native mode, if telemetry unexpectedly disappears, the usermod also eases the traffic activity toward zero instead of freezing the last traffic level.

The fallback preset retains its own brightness, so it does not have to use the brightness selected for the Network Display effect.

Quick Post-Install Validation

After installation, verify:

  1. The application/service is running.

  2. SNMP traffic rates are updating.

  3. native-setup can find Network Traffic Native.

  4. The configured RX/TX regions move in the correct directions.

  5. test-native produces smooth motion.

  6. Real network traffic changes the particle density.

  7. Stopping the application causes WLED to return to the configured fallback preset.

You can generate obvious test traffic using iperf3.

TX / Upload Test


iperf3 -c <SERVER-IP> -t 15

RX / Download Test


iperf3 -c <SERVER-IP> -R -t 15

Bidirectional Test

Using a current version of iperf3:


iperf3 -c <SERVER-IP> --bidir -t 30

You should see something roughly like:


Normal test -> TX traffic dominates

Reverse test -> RX traffic dominates

Bidirectional -> both RX and TX active

The exact RX/TX mapping depends on which side of the monitored network interface you consider to be “receive” and “transmit.” The setup wizard includes an option to swap the directions if necessary.

Troubleshooting

Custom Effect Is Missing

If Network Traffic Native does not appear in WLED’s Effects list, the controller is probably running stock WLED or the wrong firmware image.

Verify that you flashed the correct RC10 Network Display firmware for the controller.

Native Setup Cannot Reach WLED

Verify:

  • the WLED web interface is reachable from the application computer

  • there is no firewall rule blocking HTTP between the systems

  • UDP 21325 is allowed from the application computer to the WLED controller

Animation Is Backwards

Use the setup wizard’s RX/TX swap option if the monitored interface’s inbound/outbound interpretation is opposite what you want.

For physical strip orientation, edit the instance and reverse the appropriate output region.

Brightness Is Too High or Too Low

Edit the instance:


sudo wled-netdisplay edit OfficeSwitch

or on Windows:


& $Manager edit OfficeSwitch

Then choose Low, Medium, Bright as possible, or a manual 1-255 brightness value.

WLED’s configured power/current limiter still applies independently of this setting.

Particle Head / Highlight Is Too Strong

If the highlight color makes the head of the particle stand out more than you want, edit the instance:


sudo wled-netdisplay edit OfficeSwitch

or on Windows:


& $Manager edit OfficeSwitch

Then adjust Particle highlight intensity. Subtle (30%) is a good starting point when using a high-contrast highlight such as white. None (0%) removes the highlight-color blend entirely while leaving the base-colored particle and trail intact.

If you upgraded an existing RC9 configuration, seeing 100% here is expected; RC10 deliberately preserves the old highlight appearance until you choose a new value.

SNMP Security

SNMP v2c community strings should be treated like credentials.

Avoid exposing SNMP UDP/161 broadly. Restrict SNMP access to the computer or management network running WLED Network Display whenever possible.

The Linux and Windows installers restrict access to the instance configuration directory because those files contain the SNMP community string.

  1. Affiliate link, but that is the exact strip I used.

  2. No affiliation, but it’s a great little controller for the price.

  3. I have very strong opinions on how LED strips should be installed and consider it a mortal sin to just stick them to a surface sans a proper substrate!