08.27.2026

LED Network Display

UPDATE - 09/08/2026

I now have a standalone Python version of the LED Network Display that does not require Home Assistant or Node-RED. I’ve linked it below along with the original Node-RED flow.

The standalone version runs on both Windows and Linux. I’ve tested it on Windows 11 and Debian 13, and both installers include an interactive setup wizard that handles the basic SNMP and WLED configuration.

It also supports multiple named instances. Each instance monitors one SNMP traffic source and can control one or more WLED outputs. This makes it possible to run several independent displays from one computer, or to use one SNMP source to drive multiple LED strips without polling the network device multiple times.

An output can display RX and TX together, RX only, or TX only. For example, you can use one strip for both directions, separate strips for RX and TX, or multiple WLED controllers driven from the same traffic source.

The standalone version is currently at v2.0.0-rc3. The normal single-strip configuration has been tested on both Windows and Linux. At the time of this update, the multi-output / separate RX and TX strip configuration still needs additional hardware testing, which is the primary reason the current build is labeled a “release candidate.”

I’m primarily working the standalone version going forward. The original Home Assistant/Node-RED flow described below remains available, however, and is still perfectly usable if you prefer that approach.

Original Node-RED Version

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 WS2812B¹ 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 dig2go² 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 channel³, 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.

Per my personal policy, I’m disclosing here that I “vibe-coded” portions of 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.

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 animation itself 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.

I’ve linked both versions below. The original Node-RED flow can be imported and modified directly, while the standalone version includes installers and a setup wizard for Windows and Linux.

Downloads

Download the Standalone Python Version

Download the Original Home Assistant / Node-RED Flow

Standalone Version

The standalone app does essentially the same thing as the original Node-RED flow, but packages everything into a Python app that can run as a background service on Windows or Linux.

Each configured instance monitors one SNMP interface. The app polls the interface counters, calculates and smooths the RX/TX traffic rates, renders the LED animation at roughly 24 fps (my display is visible on camera so I wnated it to look nice), and sends the resulting DRGB frames directly to WLED over UDP.

An instance can have one or more WLED outputs. This allows one SNMP source to drive a normal combined RX/TX strip, separate RX and TX strips, or multiple controllers without duplicating the SNMP polling.

On Linux, each instance runs as its own systemd service. On Windows, each instance runs as its own scheduled task.

For purposes of the app, an instance consists of one SNMP traffic source and one or more WLED outputs.

For example:

instance "office"
    MikroTik office uplink
        -> office WLED strip

instance "wan"
    pfSense WAN interface
        -> RX strip
        -> TX strip

Different SNMP sources should nominally be configured as separate instances.

Before You Install

Have these ready:

A WLED controller reachable from the computer running the application
SNMP enabled on the switch, router, or firewall you want to monitor
Your SNMP v2c community string
The interface you want to monitor
- Interface name or ifIndex
Python 3 installed

For the normal single-strip setup:

RX = cyan
TX = green

The application polls SNMP interface counters, calculates RX/TX traffic rates, renders the animation locally, and sends complete DRGB frames to WLED over UDP.

WLED Requirements

On each WLED controller:

Open Config
Open Sync Interfaces
Enable Receive UDP realtime
Set the UDP/Broadcast port to:

Configure a fallback preset

The examples and setup wizard default to:

Preset 22

Preset 22 is not required specifically; it is simply the default used by this project. You can select a different fallback preset during setup.

If the standalone application stops sending realtime frames, WLED’s realtime timeout expires and the controller automatically returns to the configured fallback preset.

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-netdisplay-v2.0.0-rc3.zip
cd wled-netdisplay

Install

sudo ./install-linux.sh

The installer:

Copies the application to /opt/wled-netdisplay
Creates a Python virtual environment
Installs Python dependencies
Installs the wled-netdisplay management command
Installs the systemd service template
Optionally launches the setup wizard

When asked:

Configure a display instance now? [Y/n]

choose:

Setup Wizard

The wizard will prompt for information including:

Instance name
SNMP host/IP
SNMP community
SNMP interface
WLED host/IP
LED layout
Fallback preset
Traffic scale

Use SNMP interface discovery when offered. This is generally easier than manually determining the interface ifIndex.

For a normal single-strip display, choose:

RX + TX on same strip

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/

Linux Management Commands

List configured instances:

sudo wled-netdisplay list

Check status:

sudo wled-netdisplay status OfficeSwitch

Restart an instance:

sudo wled-netdisplay restart OfficeSwitch

Test the configuration:

sudo wled-netdisplay test OfficeSwitch

Test the LED output:

sudo wled-netdisplay test-leds OfficeSwitch

View logs:

sudo wled-netdisplay logs OfficeSwitch

Add another display instance:

sudo wled-netdisplay add

Edit an existing instance:

sudo wled-netdisplay edit OfficeSwitch

Windows Installation

Prerequisites

Install a current version of Python 3.

Verify Python from PowerShell:

py -3 --version

or:

python --version

Run PowerShell as Administrator.

Extract the ZIP and enter the application directory:

cd C:\Path\To\wled-netdisplay

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

Each configured instance gets its own Windows Task Scheduler task.

For example:

WLED Network Display - OfficeSwitch

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

Setup Wizard

The Windows wizard prompts for the same basic information:

Instance name
SNMP device
SNMP community
SNMP interface
WLED controller
LED layout
Fallback preset
Traffic scaling

For the basic setup:

1 SNMP source
1 WLED controller
RX + TX on the same strip

Windows Management Commands

Set the manager path:

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

List instances:

& $Manager list

Check status:

& $Manager status OfficeSwitch

Restart an instance:

& $Manager restart OfficeSwitch

Test the configuration:

& $Manager test OfficeSwitch

Test the LED output:

& $Manager test-leds OfficeSwitch

View logs:

& $Manager logs OfficeSwitch

Add another instance:

& $Manager add

Edit an instance:

& $Manager edit OfficeSwitch

Multiple Displays

The standalone version is designed so a single 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 output can be configured to display:

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:

OfficeSwitch -> instance "office"
pfSense ix0  -> instance "wan"
ServerSwitch -> instance "servers"

For two strips showing separate traffic directions from the same source:

RX strip -> RX only
TX strip -> TX only

This allows one SNMP source to drive multiple LED displays without polling the network device multiple times.

If multiple physical LED strips are connected to a single WLED controller, they should be configured as regions of that controller rather than as separate outputs targeting the same WLED IP and UDP port.

Quick Post-Install Validation

After installation, verify:

The application/service is running
SNMP traffic rates are updating
WLED enters realtime mode
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 can depend 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.

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.

Affiliate link, but that is the exact strip I used.
No affiliation, but it’s a great little controller for the price.
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!