LoRa-DMX
WLED for lights the internet can't reach
An ESP32 device that runs a custom build of WLED and takes its orders over LoRaWAN instead of Wi-Fi. It listens continuously for commands from a network server and turns them into live lighting — putting a controllable fixture on a monument, bridge, or roadside sign that has no network of its own.
How a command reaches the light
TTN] end subgraph "Air" GW[LoRa Gateway] end subgraph "Device (Heltec ESP32-S3)" SX[SX1262 Radio] UM[lorawled usermod] WLED[WLED Engine] LEDs[LED Fixture] end Dash -->|Command| LNS LNS -.->|Class C Downlink| GW GW -.->|Long-Range RF| SX SX -->|Decode| UM UM -->|Lighting command| WLED WLED --> LEDs UM -.->|Status Uplink| GW
The hardware
A Heltec WiFi LoRa 32 V3 — an ESP32-S3 paired with a Semtech SX1262 radio. One compact board handles both the LED engine and the long-range link.
The usermod
A WLED usermod (lorawled) bolts a LoRaWAN stack onto WLED without touching its core, decoding downlinks into the lighting commands WLED already understands.
Class C, always listening
Running in Class C keeps the receive window open continuously, so the network server can push a command at any instant — the difference between a sensor and a controllable light.
The hard part
Making sure the command actually arrives.
The demo is easy; the field is not. Most of the real work was in the invisible layer of radio regulation and regional quirks that decide whether a light a mile away lights up — or silently ignores you with no error to explain why.
Landing on the channels the gateway is actually watching
In the US, a device can technically transmit across dozens of frequencies, but a typical gateway only listens to eight of them. Get the sub-band configuration subtly wrong and every status message vanishes into channels no one is monitoring — while the initial join still succeeds, so nothing looks broken. The firmware writes the correct channel mask itself, before and after joining, so the device and the gateway are always talking on the same eight frequencies.
Playing by each region's legal airtime rules
Europe and Asia cap how often a device may transmit; the US and Australia cap how long each transmission may last. These aren't preferences — they're law (ETSI, ARIB, FCC). The device derives the right behavior from its configured region automatically, with no switch that can put it out of compliance in a place where that matters.
Configurable per region, without footguns
The same setting means different things in different parts of the world — a data rate that's fast and legal in one region is invalid in another. Region, sub-band, and data rate are set from WLED's own settings page and validated against each other, so only combinations that will actually work are even representable.
Where it fits
A device that stands on its own.
Today the LoRa-DMX device is managed through WLED Cloud, where it appears next to ordinary Wi-Fi fixtures and answers to the same controls. That's the pairing it was built for — long-range lights and local lights on one dashboard.
But because it speaks standard LoRaWAN to a standard network server, the device isn't locked to any one platform. Anything that can send a downlink through the network could, in principle, drive it — an openness I'd like to lean into next.
Validated through an AI-assisted build I directed. I defined what the device had to do and tested it in the field; the firmware was AI-written under my direction.