Wiznet makers

Thumbnail Image: AI-Generated Image

Overview

projectMM is an open-source lighting platform for constructing and running large addressable LED installations and DMX lighting systems through a modular pipeline.

A single source tree targets ESP32-family microcontrollers, Teensy, Raspberry Pi, Windows, macOS, and Linux. Users can assemble layouts, layers, effects, modifiers, and output drivers through a browser interface, preview the result in 3D, and deliver the generated frames to local LED hardware or network-lighting protocols.

projectMM combines the following capabilities within one runtime:

• 1D, 2D, and 3D LED layouts
• A visual pipeline combining effects and modifiers
• Addressable RGB and RGBW pixels
• Conventional DMX fixtures
• Bidirectional Art-Net, E1.31/sACN, and DDP
• I²S microphone input with sound level and 16-band FFT analysis
• Browser-based 3D preview
• MQTT and Homebridge integration
• An on-device file manager
• Firmware updates over the local network
• A browser firmware installer
• Runtime configuration of pins, protocols, strand lengths, microphones, and network interfaces

The project should not be understood as only an Art-Net receiver or a firmware image for one LED controller. Its central concept is a reusable lighting runtime that represents physical layout, visual generation, modification, and output through a shared module model that can run on both embedded and desktop platforms.

About the Maker

MoonModules

MoonModules is a volunteer open-source collective involving lighting artists, hardware developers, and software developers across Europe and North America.

According to its official description, the group develops ESP32-based lighting software and hardware for makers, artists, and engineers, with applications ranging from small hobby installations to large stage systems. It is more accurately described as a distributed open-source community than as a commercial company associated with one country.

MoonModules traces its origins to 2021, when Ewowi and Harry Baas began developing audio-reactive functionality and 2D effects for an Atuline WLED fork. Part of this work later contributed to the sound-reactive and 2D functionality included in upstream WLED 0.14.

The group subsequently developed WLED-MM to experiment with large LED installations, HUB75 matrices, Art-Net, and multi-instance synchronization. In 2023, it began MoonLight as a clean-room lighting platform. projectMM follows that work with a stronger focus on cross-platform parity, reusable modules, readable architecture, and separation between platform-specific code and the lighting domain.

-MoonModules Discord-

Publicly Introduced Contributors

MoonModules also describes collaboration or technology-sharing relationships with projects and hardware communities including Apollo Automation, Glorb, the Tarna art car, QuinLED, My Home Control, hpwit, srg74, and AnimARTrix.

These activities demonstrate experience across the wider MoonModules ecosystem. They should not automatically be interpreted as deployments of the current projectMM v2 runtime.

Development Model

projectMM publicly documents an AI-assisted development workflow.

Its README states that firmware, desktop code, the web installer, MoonDeck, documentation, tests, and UI assets are written by role-based agents. The product owner, however, defines the development process, architecture, and module specifications; decides what should be built; reviews the code and specifications; runs hardware tests; and controls commits, merges, and releases.

projectMM is therefore not presented as a system independently designed and released by autonomous AI. It is a human-directed engineering project in which agents support implementation, review, and testing while architectural authority and release control remain with the product owner.

From WLED-MM and MoonLight to projectMM

The relationship among MoonModules projects helps clarify the role of projectMM.

MoonLight v1.0.0 was announced as its final release in May 2026, with active development moving to projectMM. MoonLight can continue to support existing installations, but projectMM is now the principal runtime under development.

FastLED-MM also demonstrates that projectMM can serve as a reusable runtime layer inside another lighting firmware. FastLED provides pixel effects and hardware drivers, while projectMM supplies the browser control panel, REST API, persistent configuration, task distribution, networking, and supporting services.

What Is projectMM?

projectMM represents its major functions through a common MoonModule model.

Layout
   │
   ▼
Layers
   ├─ Effects
   └─ Modifiers
   │
   ▼
Drivers
   ├─ Addressable LED output
   ├─ DMX fixtures
   ├─ Network output
   └─ Browser preview

Layouts

A layout defines the physical or virtual coordinates of the lights.

Supported concepts include:

• 1D strips
• 2D matrices
• 3D cubes
• Wheels and rings
• Custom coordinate-based installations

projectMM does not treat 1D and 2D as separate effect modes. They are represented as special cases of a 3D coordinate system in which one or more dimensions have a size of one. As a result, the same effect model can be applied to a strip, panel, ring, cube, or irregular physical installation.

Layers, Effects, and Modifiers

A layer can contain one or more effects and modifiers.

Effects generate pixel colors, while modifiers transform the result through operations such as mirroring, rotation, multiplication, or coordinate remapping. Multiple layers can be combined into the final lighting frame.

Configuration changes such as pin maps, LED lengths, output protocols, and microphone settings are designed to apply at runtime where possible, often from the next frame without rebooting the device. Updating the firmware binary itself still requires the normal restart process.

Drivers

Drivers send the final frame to physical hardware, remote devices, or the browser preview.

Examples include:

• RMT LED output
• LCD_CAM or I²S i80 parallel output
• Parlio output
• DMX fixtures
• Art-Net
• E1.31/sACN
• DDP
• Browser-based 3D preview

RGB strips, RGBW pixels, PAR lights, moving heads, and remote network nodes can therefore participate in the same lighting model. Art-Net, E1.31, and DDP are supported in both sending and receiving roles.

Project at a Glance

Prebuilt releases currently focus on ESP32 firmware, macOS arm64, and Windows x64. Teensy, Raspberry Pi, and Linux are targets in the common source tree, but identical prebuilt release packages are not necessarily available for each platform.

System Architecture

AI-Generated Image

┌────────────────────────────────────────┐
│ Input and Control                      │
│                                        │
│ Browser UI / REST / MQTT               │
│ Art-Net / E1.31 / DDP input            │
│ I²S microphone / audio synchronization │
└──────────────────┬─────────────────────┘
                   │
                   ▼
┌────────────────────────────────────────┐
│ projectMM Runtime                      │
│                                        │
│ System Modules                         │
│ ├─ Network                             │
│ ├─ HTTP / WebSocket                    │
│ ├─ Filesystem / Firmware Update        │
│ └─ MQTT / Home Automation              │
│                                        │
│ Lighting Pipeline                      │
│ Layouts → Layers → Effects / Modifiers │
│                         ↓              │
│                    Shared Buffer       │
└──────────────────┬─────────────────────┘
                   │
                   ▼
┌────────────────────────────────────────┐
│ Drivers                                │
│                                        │
│ Local LEDs: RMT / i80 / Parlio         │
│ Network: Art-Net / E1.31 / DDP         │
│ Fixtures: DMX / Hue                    │
│ Preview: WebSocket 3D                  │
└───────────────┬────────────────────────┘
                │
        ┌───────┴────────┐
        ▼                ▼
 Local LED Output   Remote Lighting Nodes
 DMX Fixtures       Art-Net / sACN / DDP

Users construct the pipeline through the browser. Each module declares its own controls, allowing the UI to generate the relevant configuration interface without separate frontend code for every module type.

The 3D preview sends frames to the browser over WebSocket. In v2.0.0, preview transmission was redesigned around resumable chunking and backpressure so that it does not block the main render tick. On a slow connection, the system is designed to reduce frame rate before reducing preview resolution.

Role of the WIZnet W5500

External SPI Ethernet for ESP32-S3

ESP32-S3 does not contain the same integrated Ethernet MAC available on classic ESP32 devices. On supported ESP32-S3 boards, projectMM uses the W5500 as an external SPI Ethernet controller.

The ESP32 platform configuration identifies W5500-over-SPI as the S3 Ethernet path and includes W5500 as a runtime-selectable Ethernet type. The driver is compiled into applicable S3 firmware variants, while the physical SPI pins are supplied by each board profile.

The SPI Ethernet build fragment enables CONFIG_ETH_USE_SPI_ETHERNET, and idf_component.yml adds Espressif’s managed W5500 component for ESP32-S3 targets.

W5500 Network Path

AI-Generated Image

projectMM TCP / UDP Services
        │
        ▼
lwIP Socket Layer
        │
        ▼
ESP-IDF esp_netif
        │
        ▼
ESP-IDF esp_eth
        │
        ▼
W5500 MAC / PHY Driver
        │
        ▼
SPI
        │
        ▼
WIZnet W5500
        │
        ▼
Wired Ethernet

When the W5500 interface is active, the shared network layer can carry:

• Art-Net, E1.31, and DDP lighting frames
• HTTP and WebSocket traffic
• REST configuration
• MQTT and Homebridge traffic
• Device discovery
• File transfers
• Firmware updates

The W5500 does not calculate effects or generate WS2812 waveforms. It provides the physical wired Ethernet interface used by high-volume lighting traffic and device-management services.

W5500 Initialization

The ESP32 platform layer contains a dedicated W5500 initialization path.

The firmware performs the following sequence:

1. Reads the Ethernet type and SPI pins from the board profile.
2. Initializes the SPI2 bus.
3. Creates the W5500 SPI device configuration.
4. Uses interrupt-driven reception when an IRQ pin is configured.
5. Uses 10ms polling when no IRQ pin is available.
6. Creates the MAC object with esp_eth_mac_new_w5500().
7. Creates the PHY object with esp_eth_phy_new_w5500().
8. Installs the ESP-IDF Ethernet driver.
9. Derives the Ethernet MAC address from the ESP32 eFuse base MAC.
10. Attaches the interface to esp_netif.
11. Registers Ethernet and IP event handlers.
12. Starts the Ethernet driver.

If the required SPI pins are not configured, the W5500 is absent, or MAC and PHY creation fails, the initialization returns a failure result. The higher-level NetworkModule can then attempt another available network interface.

SPI Clock

The current implementation configures the W5500 SPI clock at 20MHz.

A source comment describes this as a stable W5500 limit, but the official W5500 specification supports SPI operation up to 80MHz. The 20MHz value should therefore be understood as projectMM’s current operating choice, not the maximum supported by the W5500 itself.

Confirmed W5500 Board Profiles

The current board catalog includes ESP32-S3 profiles with concrete W5500 SPI configurations.

LightCrafter 16

SE 16 V1

Both profiles list LEDs, Wi-Fi, and Ethernet among their supported capabilities and select the W5500 through ethType: 3.

The W5500 is therefore not merely a dormant driver or a proposed future feature. It is connected to board-specific SPI and interrupt configurations in the project’s device catalog.

v2.0.0 also added runtime configuration of Ethernet PHY type and pins. The W5500 interface can be stopped, uninstalled, and reinitialized with a new configuration without rebooting the complete device.

Connectivity Strategy

AI-Generated Image

projectMM’s NetworkModule manages available network interfaces in the following priority order:

Ethernet
   │ unavailable or disconnected
   ▼
Wi-Fi Station
   │ credentials unavailable or connection fails
   ▼
Wi-Fi Access Point

When Ethernet hardware and a valid link are available, Ethernet is preferred. If Ethernet cannot be initialized or used, the system attempts Wi-Fi station mode. If credentials are unavailable or the station connection fails, the device starts an access point for configuration and recovery.

If a higher-priority interface becomes available later, the system can promote that interface and shut down the lower-priority one to recover memory.

The firmware catalog contains ESP32 variants that include both Wi-Fi and Ethernet, an Ethernet-only classic ESP32 build with Wi-Fi compiled out, and ESP32-S3 variants containing both Wi-Fi and external W5500 SPI Ethernet.

This is not network bonding or bandwidth aggregation. It is an Ethernet-first connectivity policy with managed Wi-Fi fallback.

Performance and the 16K Claim

16,384 Logical Lights

projectMM’s headline scale is a 128 × 128 grid, equal to 16,384 logical lights.

The README performance table reports measurements taken through a full pipeline containing an effect, modifier, and Art-Net output. However, the number does not mean that every supported board physically drives 16,384 LEDs at the same frame rate through one output peripheral.

Depending on the benchmark, 16,384 may refer to:

• A logical render grid
• A full render-to-Art-Net pipeline
• A render-only effect test
• A parallel-output driver test
• A PSRAM-backed buffer configuration

At a 128 × 128 grid, the public headline results include:

The ESP32-S3 uses its 8MB PSRAM for large layer buffers and mapping tables. In the reported S3 benchmark, however, Wi-Fi Art-Net transmission consumed a substantial part of the complete frame time.

Measured Wi-Fi and Ethernet Difference

AI-Generated Image

The performance documentation publishes measurements for sending 97 UDP packets in a 16K Art-Net workload.

The project attributes this difference to Wi-Fi characteristics including CSMA/CA backoff, rate adaptation, and link-layer retries, and recommends Ethernet for 16K Art-Net workloads.

An important limitation is that the Ethernet side of this direct comparison used an Olimex classic ESP32 board with RMII Ethernet. The table is not a W5500-specific benchmark.

The README separately states that ESP32-S3 supports W5500 SPI Ethernet and that this provides a way to avoid the Wi-Fi bottleneck on boards wired for it.

The most accurate interpretation is:

projectMM publishes measurements demonstrating the advantage of wired Ethernet over Wi-Fi for large Art-Net workloads, and implements W5500 SPI Ethernet as the wired path for supported ESP32-S3 boards.

Ethernet Does Not Eliminate Every Bottleneck

W5500 avoids radio transmission delays and part of Wi-Fi’s variability, but it does not eliminate CPU and memory costs associated with effect rendering, pixel encoding, or physical LED waveform generation.

The current performance documentation records an ESP32-S3 test in which long 16K parallel-output encoding work on the same CPU core delayed W5500 network processing and affected link and HTTP responsiveness.

This demonstrates that high-performance lighting systems must consider not only the network interface, but also how rendering, encoding, networking, DMA, and multicore work are scheduled.

Parallel LED Output

projectMM uses different hardware peripherals depending on the ESP32 family.

Multiple LED strands can be transmitted in parallel. Some drivers also support loopback self-tests that read the actual wire signal through an input pin and verify output bits.

Physical output capacity depends on the MCU, number of lanes, DMA-accessible memory, PSRAM support, and the output driver’s buffer structure. A logical 16K render grid should therefore be distinguished from the physical output ceiling of one board.

v2.0.0 standardized the per-chip RMT, LCD_CAM, and Parlio driver layer. The active development branch includes further work on parallel output and multicore processing.

DMX and Network Lighting

projectMM does not treat addressable pixels and conventional DMX fixtures as separate applications.

The same pipeline can contain:

• RGB strips
• RGBW pixels
• LED matrices
• PAR lights
• Moving heads
• LED bars
• Remote network receivers

The Network Send driver can transmit Art-Net, E1.31/sACN, and DDP frames. The Network Receive effect can accept those protocols as inputs.

v2.0.0 introduced bidirectional network I/O with automatic protocol detection by port. A device can drive part of a scene through local LEDs and transmit another section of the shared lighting frame to remote controllers.

Audio-Reactive Lighting

AI-Generated Image

The Audio service receives samples from an I²S microphone or a supported audio codec.

I²S Audio Input
       │
       ▼
DC Blocking and Windowing
       │
       ▼
RMS Sound Level
       │
       ▼
16-Band FFT
       │
       ▼
Audio-Reactive Effects

v2.0.0 added live RMS level measurement and a 16-band spectrum using a Hann window with configurable sample rate, gain, and noise floor.

AudioSpectrum and AudioVolume effects consume this information to generate lighting animation.

Installation and User Workflow

AI-Generated Image

Browser Installer

Supported ESP32 boards can be flashed through a browser using Chrome or Edge.

Select a board
   │
Choose a stable release or latest build
   │
Connect over USB
   │
Flash firmware
   │
Apply initial configuration through Improv
   │
Open the device browser interface

The installer presents supported device models and firmware variants, then guides the user through flashing and initial network setup.

It provides both stable releases and a latest build generated from newer changes on the active branch. Users preparing a permanent installation should distinguish between the tested stable release and an unreleased development image.

Desktop Runtime

Release binaries are available for macOS arm64 and Windows x64.

The desktop application exposes its configuration through a browser at localhost:8080, allowing users to build a pipeline, preview it in 3D, and transmit the result through Art-Net or another supported protocol.

The current binaries are unsigned, so macOS Gatekeeper or Windows SmartScreen may display a warning on first launch.

MoonDeck

Source developers can use MoonDeck, a browser-based development console included in the repository.

MoonDeck brings together:

• Desktop build, run, and test functions
• ESP32 build and flashing
• Live-device discovery
• Logs and device status

Validation and Test Strategy

projectMM does not store performance numbers only in prose documentation. It also defines target-specific performance contracts within scenario tests.

Scenario steps specify maximum tick time and minimum free heap for each target. Pull requests validate those contracts, and the project documents a process for updating both observed values and contractual limits when performance expectations are intentionally changed.

The reviewed revision reports:

• Warning-free GCC and Clang builds
• 778 tests passing
• Scenario and specification checks
• Boundary checks
• AddressSanitizer testing
• Successful builds for multiple ESP32 targets

This indicates a structured regression-testing process. It does not mean that every board, Ethernet switch, LED quantity, and venue environment has been independently validated by a third party.

Public Activity and Community

projectMM Repository Activity

At the time of review, the repository displayed:

v2.0.0 is described as a major release containing 77 commits across eight pull requests. It introduced audio-reactive lighting, multi-protocol network I/O, ESP32-P4 support, runtime Ethernet configuration, LAN discovery, and improvements to the browser installer and preview system.

Community Channels

MoonModules communicates through Discord, Reddit, GitHub, YouTube, and contributor social channels.

Its community information describes Discord as the fastest route for support and development discussion, while Reddit is used for releases and project updates. GitHub hosts source code, issues, pull requests, and releases.

The official site also links installation videos, feature demonstrations, developer introductions, release content, and LED-effect demonstrations. During this review, no official video specifically presenting projectMM v2 W5500 performance was identified.

Previous Installation Experience

MoonModules publishes several installation examples from its broader software ecosystem:

• A MoonLight system controlling lighting across two stages at a small festival
• A human-scale interactive LED cube
• A 20 × 20 × 20 LED curtain cube
• Art-car and interactive-lighting collaborations

These examples demonstrate that MoonModules contributors have experience with Art-Net, DMX, stage systems, and large LED installations.

The public pages identify most of these as MoonLight or WLED-MM deployments. They should not be presented as confirmed projectMM v2 installations.

Related WIZnet Maker Projects

1. 4-Universe Art-Net LED Controller with W5500-EVB-Pico

This project uses an RP2040-based W5500-EVB-Pico to receive four Art-Net universes and drive four WS2812B outputs.

The 4-Universe controller focuses on a compact edge node. projectMM operates at a higher level, combining scene generation, effects, previews, protocol handling, and multiple output systems.

2. Open-Source Art-Net LED Controller — 2,700+ LEDs

This project uses ESP32 and W5500 to drive multiple WS281x outputs through wired Art-Net. It provides a Web UI, static IP configuration, firmware updates, and a Wi-Fi debugging mode.

3. ArtGateOne-DMX

ArtGateOne-DMX uses an Arduino Uno with a W5100 or W5500 Ethernet Shield to convert Art-Net into one RS-485 DMX512 output.

Comparison at a Glance

Why This Project Matters

W5500 as a Platform Capability

Many W5500 lighting projects are appliances designed around one board, output count, and protocol.

projectMM does not bind the W5500 to one Art-Net receiver. It integrates the W5500 as an ESP32 platform network interface so that Art-Net, E1.31, DDP, HTTP, WebSocket, MQTT, file transfer, and firmware updates can share the same wired connection.

This expands the W5500’s role from:

• An Ethernet module for one application
• An Art-Net input for one controller

to:

A platform-level wired-network capability shared by multiple lighting and management services

Separation of PSRAM, Processing, Networking, and Output

On ESP32-S3, the responsibilities are divided as follows:

ESP32-S3 PSRAM
→ Large render buffers and mapping data

ESP32-S3 CPU
→ Effects, modifiers, and packet generation

W5500 SPI Ethernet
→ Wired network transport

LCD_CAM / RMT
→ Physical LED waveform generation

PSRAM provides memory capacity for large pixel configurations. The W5500 provides a wired alternative to the latency and variability of large Wi-Fi packet bursts.

The public material does not include a same-board ESP32-S3 benchmark comparing Wi-Fi and W5500 under identical conditions. The W5500 should therefore not be presented as guaranteeing a specific frame rate.

Connecting Art and Engineering

projectMM may be relevant to:

• Lighting artists
• Festival and stage technicians
• Interactive-installation designers
• LED sculpture makers
• Lighting-protocol developers
• Controller-board manufacturers
• Museum and education programs
• Home-automation integrators

Its desktop runtime and browser preview allow layouts, mappings, and effects to be designed before the complete physical installation is available, while preserving the same conceptual module model for embedded deployment.

Potential Application Directions

Stage and Festival Lighting

• LED bars and pixel strips
• PAR and moving-head fixtures
• Stage backdrops
• Festival sculptures
• DJ booths and live visuals
• Art-Net and sACN distribution

Interactive Art and Public Installations

• 3D LED cubes
• Kinetic sculpture
• Museum installations
• Architectural lighting
• Art cars
• Audience-responsive artwork

Distributed Lighting Networks

A desktop renderer or central controller could send Art-Net, E1.31, or DDP to multiple remote nodes, with each node responsible for local LED outputs or DMX fixtures.

Hardware-Vendor Integration

A board manufacturer can add pin mappings, Ethernet PHY configuration, microphone settings, and LED-output capabilities to deviceModels.json, then expose the board through the browser installer.

The LightCrafter 16 and SE 16 V1 profiles demonstrate how generic W5500 support is connected to concrete hardware configurations.

Education and Prototyping

projectMM can combine the following subjects in one practical environment:

• 1D, 2D, and 3D coordinate mapping
• LED effect composition
• DMX and network-lighting protocols
• ESP32 peripherals
• Ethernet and Wi-Fi behavior
• FFT-based audio visualization
• Cross-platform C++
• Regression and performance testing

Future Wiring Research

Large installations with many distributed lighting and sensor nodes may provide a useful context for studying Single Pair Ethernet or integrated power-and-data wiring.

No SPE PHY, 10BASE-T1L/T1S interface, SPE connector, or PoDL implementation is present in the current projectMM repository.

The W5500’s integrated PHY is intended for conventional 10/100BASE-T Ethernet, so projectMM cannot be converted to SPE through firmware configuration alone. An additional SPE PHY or bridge would be required.

This should be considered a future design-study direction, not a current feature.

Open Source and Limitations

License and Public Material

projectMM is released under GNU GPL v3.

The repository includes:

• A cross-platform C++ runtime
• ESP-IDF firmware
• Desktop platform implementations
• The browser UI
• The browser installer
• MoonDeck development tools
• A board-model catalog
• Unit and scenario tests
• Performance documentation
• Module specifications

Anyone modifying and distributing projectMM, or incorporating it into a commercial product, should review the GPL requirements concerning source availability and licensing notices.

Scope of the 16K Claim

16,384 lights can refer to several different test contexts:

• A 128 × 128 logical render grid
• An Art-Net output benchmark
• A specific parallel-output test
• A PSRAM-backed render buffer

It is not a universal guarantee that every ESP32 target can directly drive 16,384 physical LEDs with every effect, protocol, and frame rate.

Scope of the W5500 Performance Evidence

The public sources establish:

• A measured performance difference between Ethernet and Wi-Fi in a large Art-Net workload
• An implemented ESP32-S3 W5500 SPI Ethernet path
• W5500 MAC, PHY, SPI, interrupt, polling, and ESP-IDF driver initialization
• Concrete W5500 board profiles
• A README statement that W5500 can avoid the S3 Wi-Fi bottleneck

They do not provide a same-board ESP32-S3 table directly comparing Wi-Fi and W5500 under identical conditions.

The accurate statement is therefore that W5500 is implemented as a wired path capable of avoiding the identified Wi-Fi bottleneck—not that it guarantees a particular 16K frame rate.

W5500 Is Not Used by Every Target

• Desktop targets use their operating system’s network interface.
• Raspberry Pi uses the Linux networking stack.
• Classic ESP32 Ethernet boards generally use the integrated EMAC with an RMII PHY.
• ESP32-P4 follows a separate EMAC and PHY path.
• W5500 is used on supported ESP32-S3 boards.

projectMM should not be described as a W5500-only platform.

Network Security

The NetworkModule documentation assumes operation on a local network and notes the following limitations:

• The fallback access point is open and has no password.
• HTTPS is not provided.
• The embedded device is expected to operate within a local network.

For stage, exhibition, or public-network deployment, an isolated VLAN, firewall, or separate trusted control network would be appropriate.

Direct Deployment Evidence

MoonModules publishes previous experience involving festival stages, large LED cubes, and art vehicles, but detailed public case studies clearly identifying projectMM v2 as the deployed runtime remain limited.

The number of active projectMM installations, long-duration uptime, packet loss, failover behavior, and venue commissioning results would be valuable topics for a future maker interview.

Connecting with the Maker

MoonModules communicates through Discord, Reddit, GitHub, YouTube, and contributor social channels. It accepts contributions in code, documentation, hardware testing, and issue reporting.

A technical interview could explore:

• The product owner and individual module contributors
• The architectural transition from MoonLight to projectMM
• The exact scene and network topology used in the 16K benchmarks
• Why W5500 was selected for ESP32-S3 boards
• Plans for a same-board Wi-Fi and W5500 benchmark
• Real deployments of LightCrafter and SE16
• The reason for the current 20MHz W5500 SPI setting
• CPU-core allocation between W5500 networking and parallel LED encoding
• Field use of runtime W5500 reconfiguration
• Packet-loss and recovery behavior in live performances
• The process for hardware vendors contributing device profiles
• Future ports to WIZnet reference boards or modules

Because MoonModules brings together artists, controller designers, and software developers, a combined interview with a lighting artist, hardware contributor, and core developer would be more informative than a conventional product-focused presentation.

Conclusion

projectMM is a cross-platform lighting engine in which addressable LEDs and DMX fixtures are assembled through layouts, layers, effects, modifiers, and drivers.

A single source tree targets ESP32 devices, Teensy, Raspberry Pi, and desktop systems. It provides a browser UI, 3D preview, Art-Net, E1.31, DDP, audio-reactive effects, MQTT, file management, and firmware updates.

On supported ESP32-S3 boards, W5500 is implemented as an external SPI Ethernet interface. The public source includes its SPI bus, interrupt or polling mode, MAC and PHY creation, ESP-IDF Ethernet driver, esp_netif integration, board profiles, and runtime reconfiguration.

The project’s published measurements show that wired Ethernet can deliver substantially lower transmission time than Wi-Fi in a 16K Art-Net workload. W5500 gives PSRAM-equipped ESP32-S3 controllers a wired path for transporting large lighting frames without relying on the Wi-Fi radio.

The most accurate description is:

projectMM is an open-source lighting engine combining a 16K-scale LED and DMX rendering pipeline, a multi-platform runtime, and visual configuration tools, while integrating W5500 Ethernet as a wired network path for large lighting workloads on supported ESP32-S3 boards.

FAQ

Q. Is projectMM an LED controller or desktop software?
A. It is a cross-platform runtime covering both areas. The same module model can run on ESP32, Raspberry Pi, Teensy, and desktop systems, with support for local LED output and network-lighting output.

Q. Does the 16,384-light claim mean one device physically drove 16,384 LEDs?
A. Not in every test. The number describes a 128 × 128 logical benchmark grid. Some measurements cover the full render-to-Art-Net pipeline, while others isolate rendering or physical output drivers. It is not a universal physical-output guarantee for every target.

Q. Is the W5500 actually implemented in the source code?
A. Yes. ESP32-S3 builds include the W5500 component, and the platform source initializes the SPI bus, W5500 MAC and PHY, interrupt or polling mode, ESP-IDF Ethernet driver, and esp_netif connection.

Q. Why does projectMM support the W5500?
A. ESP32-S3 can use PSRAM for large pixel buffers, but transmitting a 16K Art-Net frame over Wi-Fi can consume a major part of the frame time. W5500 provides a wired Ethernet path for transporting that traffic.

Q. Is there a direct benchmark proving W5500 is faster than Wi-Fi?
A. The project publishes a large difference between Ethernet and Wi-Fi for the same 16K Art-Net workload. However, the directly compared Ethernet board used RMII Ethernet. A separate same-board ESP32-S3 Wi-Fi-versus-W5500 comparison has not been published.

Q. Which W5500 board profiles are included?
A. The current catalog contains ESP32-S3 profiles for LightCrafter 16 and SE 16 V1, each with concrete W5500 SPI, interrupt, and reset settings.

Q. Does projectMM support only Art-Net?
A. No. It can send and receive Art-Net, E1.31/sACN, and DDP, while combining addressable LEDs and DMX fixtures within the same pipeline.

Q. Can a general user install it?
A. Supported ESP32 boards can be flashed through the browser installer, and macOS and Windows releases are available. However, projectMM is an advanced lighting platform, so practical knowledge of board wiring, power distribution, network lighting, and DMX remains useful.

Source Snapshot

At the time of review, the GitHub repository displayed 352 commits, 11 stars, two forks, and three releases. Its latest stable release was v2.0.0, published on June 24, 2026. These values are a point-in-time snapshot and may change as the project develops.

The reviewed main revision contains changes made after v2.0.0. Its commit record describes fixes for Windows builds and buffer-bound verification, together with successful GCC and Clang builds, 778 tests, scenario and boundary checks, and AddressSanitizer testing. This article therefore distinguishes stable-release functionality from later work present on the active development branch.