Building a Network-Aware RGB LED Strip with Open Hardware and Python

Bright LEDs are one of them. Bright LEDs that blink are worse. Bright LEDs cycling endlessly through rainbow effects while illuminating the inside of a computer case rank somewhere near the bottom of his personal list. Unfortunately, colourful LEDs remain overwhelmingly popular, which left only one option: build an LED project anyway.

Rather than following the well-trodden path of addressable LEDs, ESP32 modules and pre-packaged firmware ecosystems, Clem took a completely different approach. Instead of building another Wi-Fi connected lighting project, he designed an Ethernet-controlled RGB LED strip controller from scratch, combining a Microchip ENC28J60 Ethernet controller with an ATtiny3226 microcontroller and exposing the entire system through a lightweight network API.

The result is not just a decorative lighting controller. It's a general-purpose network-controlled visualisation platform capable of acting as a notification system, a network activity monitor, a status indicator and potentially much more.

Hack the Visual Planet!

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Building a Network-Aware RGB LED Strip with Open Hardware and Python

Poster

Upload Preview

Ok

Cancel

Starting With Ordinary RGB Strips

One of the more unusual aspects of the build is what Clem chose not to use.

Rather than selecting modern addressable LED strips, the design uses inexpensive analogue RGB strips. These strips operate by independently driving red, green and blue channels and can typically be found in voltage variants ranging from roughly 12 V to 24 V. They lack per-pixel control but offer simplicity, low cost and broad availability.

As Clem explains:

"These are the cheapest ones that you can get. It's not any fancy new pixel stuff. These are just power on one end and you pull down the colour that you want to activate." 

This decision dramatically simplifies the hardware while still providing all the functionality required for network-controlled status indication and ambient lighting.

Designing Around Ethernet

The heart of the project consists of an ATtiny3226 paired with an ENC28J60 Ethernet controller. The choice is interesting because neither component is especially new or fashionable.

The ENC28J60 communicates over SPI, making it ideal for small 8-bit microcontrollers. While newer Ethernet devices are available, the chip benefits from years of community support, mature software libraries and a well-understood design process.

The firmware itself deliberately avoids complexity. Rather than embedding application-specific logic into the controller, the device simply accepts colour commands over the network.

This architectural decision is perhaps the most interesting engineering aspect of the build.

Instead of forcing integrations into individual applications, services or cloud ecosystems, the controller becomes a generic endpoint. Any application capable of sending a simple HTTP request can change the colour of the LEDs. The intelligence remains elsewhere while the hardware remains simple, reusable and easy to maintain.

Why an LDO Won the Design Review

Another notable design decision concerns power regulation.

Most modern projects would default to a switching power supply for efficiency reasons. Clem chose a linear regulator instead.

At first glance this appears inefficient, but his reasoning is grounded firmly in practical engineering considerations.

The controller must operate across the voltage range commonly found on RGB strips, reaching up to approximately 24 V input. Using an LDO allowed him to reduce this voltage to the 3.3 V required by both the microcontroller and Ethernet hardware with minimal design complexity.

More importantly, it eliminates another potential source of debugging headaches.

As Clem notes:

"It avoids having to debug any interference issues between the switching and my Ethernet lines. So those could couple in and I'm not ready to debug that yet." 

For a prototype that isn't intended to run continuously, the additional efficiency of a switching supply simply wasn't worth the additional cost, complexity or potential EMI concerns.

Ethernet Is More Than Just An RJ45 Socket

One of the lessons reinforced throughout the project is that Ethernet hardware demands attention to detail.

Connecting an Ethernet controller directly to an RJ45 connector is not sufficient. Ethernet requires isolation transformers, termination networks and supporting circuitry to meet signalling requirements and maintain reliability.

To reduce complexity, Clem selected a BEL MagJack, integrating the Ethernet magnetics directly into the connector assembly. This significantly reduced component count and simplified PCB layout. The MagJack used in the design appears in the BOM as part number P01-0002-01. 

During the PCB routing stage, the differential Ethernet pairs required careful handling:

"You have to route them as pairs in KiCad and tune their length to each other so the signals take the same time to travel the distance." 

Although the trace lengths on this design were relatively short, the project serves as a useful demonstration of real-world differential pair routing practices.

Community Review Prevents A PCB Mistake

Before manufacturing the final PCB revision, Clem shared the design publicly for review. What followed demonstrates exactly why community feedback is important.

A community member noticed that one of the Ethernet transmit pair connections had been reversed. Clem had been preparing to point out his missing ESD protection circuitry when another engineer spotted the far more serious wiring issue. 

As Clem explains:

"The viewer pointed out that I connected TPR and TPR backwards to my MagJack. I didn't realise until then." 

The boards were reordered before assembly, preventing what could otherwise have become a costly debugging exercise.

Turning LEDs Into Debugging Tools

One particularly elegant feature of the project is the diagnostic system.

Without a dedicated serial interface available, the LEDs themselves became the debugger.

The controller communicates its status entirely through colours:

• Red indicates communication failure with the Ethernet controller.
• Blue indicates Ethernet hardware is present but has not connected successfully to the network.
• Green indicates successful operation and network connectivity. 

When the board stubbornly remained blue, considerable effort went into investigating software, networking and protocol issues before the real problem emerged.

A bad solder joint.

After extensive experimentation, reheating and reflowing the board solved the issue completely. 

The experience serves as a familiar reminder that sophisticated faults often have surprisingly simple causes.

Software That Lives Outside The Device

A particularly clever architectural decision was keeping application logic away from the firmware. The project downloads listed in the support files include:

• color_control.py
• network_monitor.py
• notification_blink.py 

The browser-based colour controller provides a lightweight web interface for selecting colours and sending them directly to one or more EtheRGB devices. 

Beyond that, Clem created two more practical demonstrations.

The first monitors network traffic and visualises network activity through colour changes.

The second watches Ubuntu desktop notifications and causes the strip to blink whenever a notification appears.

"You don't have to log into your applications or have to use their weird API. You can just use a little function in Ubuntu itself." 

Because all application logic exists externally, additional uses become straightforward to develop. CPU utilisation, GPU activity, build completion alerts, server monitoring and workflow notifications become simple software exercises rather than firmware modifications. 

More Than Decorative Lighting

What begins as a reluctant LED project ultimately becomes an interesting lesson in embedded networking, PCB design and system architecture.

The hardware itself is intentionally simple. An ATtiny3226, an ENC28J60, a MagJack and a handful of supporting components create a network-connected endpoint capable of accepting colour commands and storing persistent settings. 

The real intelligence lives elsewhere.

That separation allows a single controller design to support an unlimited number of applications without requiring firmware changes. Whether displaying network traffic, signalling incoming messages, highlighting completed builds or simply providing ambient lighting, the same hardware serves every purpose.

In the end, Clem may still not like RGB lighting quite as much as the Internet does.

But he did build a surprisingly capable Ethernet-controlled RGB LED platform, and along the way delivered a practical lesson in Ethernet hardware design, community-driven debugging and the value of keeping embedded systems simple.

Supporting Files and Links

-  Episode 732 Resources - Building a Network-Aware RGB LED Strip with Open Hardware and Python  

Project Parts and Bill of Materials

Additional Parts