WLED Cloud
One dashboard for every light, near or miles away
A multi-tenant platform for controlling architectural LED lighting at scale. Facilities teams and installers manage venues full of devices from a single dashboard — whether a fixture is on the local Wi-Fi or sitting on a distant monument with no internet at all, reached over long-range LoRaWAN.
The short version
- Problem
- Cities light gateway monuments, bridges and signage, and someone has to change the color, run a schedule, and switch it for a holiday or a home game. That someone is a facilities manager who needs the lights to just work, or an installer running dozens of sites for different clients. Many of those lights sit where there is no Wi-Fi at all.
- What I learned
- A Wi-Fi fixture and a long-range LoRaWAN fixture behave nothing alike underneath, but neither user should have to care which is which. An installer's clients must never see each other's venues. And an owner, an on-site operator and a view-only stakeholder need the same screen to mean different things.
- Decision
- One control surface where the transport disappears: pick a device, pick a color, and the platform decides whether the command goes over a live Wi-Fi connection or waits for the next LoRaWAN downlink. Devices are organized as organization, then venue, then device, so a "north bridge" is something you manage instead of a pile of MAC addresses. Roles remove controls rather than adding screens. Rejected: making the operator choose or even see the radio.
- Result
- A working prototype covering the fleet dashboard, venue management, device control, effects, scheduling, LoRaWAN onboarding, team roles, and a browser-based firmware installer that gets an installer from box to online in minutes. Tested end to end at a demo site, my house, with Wi-Fi WLED fixtures and a LoRa-DMX device running from the same dashboard.
- How I validated it
- I set up my house as a demo site with both kinds of device, Wi-Fi fixtures and a long-range LoRa-DMX device, and ran them side by side from one dashboard to check that the radio really disappeared for the person at the controls. Built as a directed AI-assisted build so the design could be tested on live devices instead of described in a spec.
The product idea
One control surface. The transport disappears.
The operator picks a device and picks a color. WLED Cloud decides — invisibly — whether that command rides a live Wi-Fi socket or gets queued for the next LoRaWAN downlink window. Same button, same result.
Wi-Fi devices — instant
An ESP32 running the wledcloud firmware holds an open Socket.IO connection to the cloud. Commands and state changes are real-time, both directions.
LoRaWAN devices — long range
For sites with no internet, the platform talks to a LoRaWAN Network Server and pushes commands as downlinks — miles of reach, no local network required. See the LoRa-DMX device →
Underneath, each device gets a Wi-Fi, LoRa or offline path, chosen by the platform so neither the rest of the system nor the operator ever has to branch on it. Long-range reach works through The Things Network, Chirpstack or Helium, so an installer is not locked to one network operator.
Platform
What it looks like.
Status
A working prototype, tested on a real demo site.
I tested it at a demo site, my house, with Wi-Fi WLED fixtures and a LoRa-DMX device controlled side by side from the same dashboard. WLED Cloud runs today as a prototype built under StructureSense. The target is the market of distributed, hard-to-reach architectural installs — city gateway monuments, bridges, and signage — where the lights matter but the network doesn't reach.
The platform stands on its own with ordinary Wi-Fi WLED devices; the long-range half is what makes the no-Wi-Fi sites possible, powered by the companion LoRa-DMX device.
Tech stack
Validated through an AI-assisted build I directed. I defined who it was for, designed the workflows, roles and screens, and tested it against real devices; the AI wrote the code.