LED Network Display
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.
Per my personal policy, I’m disclosing here that I “vibe-coded” parts of this setup 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 SwitchOS, 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 RX and TX byte counters, calculates the actual traffic rate from the difference between successive samples, and smooths the values slightly so the display 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 the full Node-RED flow below. You can import it and modify the switch address, SNMP community, interface, LED count, WLED address, colors, traffic scaling, and animation parameters as needed.