LEDmesh is a minimalistic, broadcast-based LED synchronization system for OpenWrt-compatible devices (e.g. Google Wi-Fi, IPQ40xx-based routers) with controllable multicolor LEDs. It enables control of LED clusters using a single UDP packet, with zero cloud, zero middleware, and near-zero latency.
This project demonstrates a bare-metal approach to LED orchestration in local wired networks using standard Linux facilities and OpenWrtβs sysfs interface.
Repurposed routers and IoT hardware (such as Google Wi-Fi units) are often equipped with three-color LEDs and robust hardware specs (RAM, CPU, networking). This project showcases how such devices can be clustered and visually coordinated β turning a roomful of idle devices into a dynamic LED wall, notification system, or network visualization tool.
- No cloud: everything works over LAN via UDP broadcast
- No daemon dependencies: pure POSIX C, tiny binary
- Real-time: LED updates take effect on all devices almost instantly
- Uniform: all devices react in perfect sync to the same network packet
- Runs on OpenWrt (ARMv7, musl).
- Listens on a UDP port (default:
9999). - Parses simple 4-byte packets:
0x4Cβ magic byte- 3 bytes for Red, Green, Blue (0β255)
It applies brightness values via:
/sys/class/leds/LED0_Red/brightness
/sys/class/leds/LED0_Green/brightness
/sys/class/leds/LED0_Blue/brightness
- A command-line tool for sending demo sequences (rainbow, blinking, single-color pulses).
- Runs on macOS or Linux.
- Sends broadcast packets to
255.255.255.255:9999.
arm-openwrt-linux-muslgnueabi-gcc led_daemon.c -o led_daemon
scp led_daemon root@192.168.1.1:/tmp/chmod +x /tmp/led_daemon
/tmp/led_daemongcc led_benchmark.c -o led_benchmark -lm
./led_benchmark- LED cycling: each LED blinks sequentially
- RGB blinking: all channels flash in sync
- Rainbow gradient: smooth HSV-to-RGB transition, synchronized across all devices
.
βββ led_daemon.c # C daemon for OpenWrt that listens for LED control packets
βββ led_send.c # Minimal packet sender
βββ led_benchmark.c # Broadcast-controlled rainbow & blinking test
βββ README.md # This file
This project is meant for trusted local networks. No encryption/authentication is included by design.
- OpenWrt 23.05+ (musl, ARMv7 target)
LED0_Red,LED0_Green,LED0_Blueexposed via/sys/class/leds/- UDP broadcast allowed on the LAN
- MQTT gateway for home automation
- GUI controller (macOS app, web app)
- Per-device addressability via extended packets
- LED animations, music sync, notifications, etc.
Created under the seasoned guidance of a network engineer, with the questionable help of GPT, countless software versions, frustrated swearing, low-level debugging, and stubborn experimentation. A testament to perseverance and slightly unhinged curiosity.
MIT
Made with π», π οΈ, and β‘ by repurposing Google Wi-Fi hardware.
To compile the led_daemon for Google Wi-Fi or other OpenWrt-compatible IPQ40xx hardware, use the official OpenWrt SDK:
wget https://downloads.openwrt.org/releases/23.05.5/targets/ipq40xx/chromium/openwrt-sdk-23.05.5-ipq40xx-chromium_gcc-12.3.0_musl_eabi.Linux-x86_64.tar.xz
tar xf openwrt-sdk-23.05.5-ipq40xx-chromium_gcc-12.3.0_musl_eabi.Linux-x86_64.tar.xz
cd openwrt-sdk-23.05.5-ipq40xx-chromium_gcc-12.3.0_musl_eabi.Linux-x86_64export STAGING_DIR="$PWD/staging_dir"
export TOOLCHAIN="$STAGING_DIR/toolchain-arm_cortex-a7+neon-vfpv4_gcc-12.3.0_musl_eabi"
export PATH="$TOOLCHAIN/bin:$PATH"arm-openwrt-linux-muslgnueabi-gcc led_daemon.c -o led_daemonYou can then transfer the binary to your OpenWrt device via scp and run it.
OpenWrt SDK used: openwrt-sdk-23.05.5-ipq40xx-chromium_gcc-12.3.0_musl_eabi
Download:
https://downloads.openwrt.org/releases/23.05.5/targets/ipq40xx/chromium/
If you know the public IP and subnet mask of a remote device or network, and it accepts UDP broadcasts (rare, but possible in lab setups or custom firewalls), then you can emulate the same behavior remotely.
For example:
- A public IP
203.0.113.10with subnet mask/29(255.255.255.248) gives broadcast:203.0.113.15. - A message to
203.0.113.15will be received by any devices listening on port within that subnet.
β Requirements:
- The remote device must not block incoming broadcast packets.
- Routers must allow directed broadcasts (disabled by default in most production routers).
- This method can work in controlled environments, lab setups, or trusted mesh deployments.
β οΈ Important Note:
Public internet-wide broadcasting is generally discouraged and filtered by ISPs.
However, within known routed IPv4 segments, especially under your own control (VPS mesh, VPN, etc.), this technique can allow for multi-device coordination across geographic locations using a singlesend.
A new utility control_hsv has been added to the project. This is a standalone CLI tool for sending LED color control packets using HSV (Hue, Saturation, Brightness) input parameters.
- Accepts HSV values from the command line:
--hue(0β360 degrees)--sat(0β100 percent)--brightness(0β100 percent)
- Internally converts HSV to RGB and sends the appropriate UDP broadcast packet to the LED controller.
- Includes
--demomode, which runs a continuous HSV hue sweep (rainbow effect) for testing or demonstration purposes.
gcc control_hsv.c -o control_hsv -lm
./control_hsv --hue 120 --sat 80 --brightness 60
./control_hsv --demoThis repository includes two shell scripts designed to simulate the effect of a sunrise using controllable RGB LEDs on Google Wi-Fi devices.
This script is meant to be launched at system boot or via a cron job. It reacts to real-world time and simulates the early morning sky colors:
- 05:35 β 05:45: LEDs gradually increase brightness from 0% to 70% with a cool blue hue (
hue = 210,saturation = 100%). - 05:45 β 05:55: The color transitions from bluish white to full white by:
- Decreasing hue from 210Β° to ~60Β°
- Reducing saturation from 100% to 10%
- Increasing brightness from 70% to 100%
The result is a smooth fade from pre-dawn blue into a bright white, mimicking sunrise light conditions.
π‘ This visual effect is designed to work in synergy with subtle auditory cues.
The author uses short beep patterns (1, 2, and 3 beeps) at 05:35, 05:45, and 05:55, respectively, on a MikroTik router:
/system scheduler
add interval=1d name=alarm5am35 on-event="for i from=1 to=1 step=1 do={beep frequency=2000 length=.01s; delay .2s;}" start-time=05:35:00
add interval=1d name=alarm5am45 on-event="for i from=1 to=2 step=1 do={beep frequency=2000 length=.01s; delay .2s;}" start-time=05:45:00
add interval=1d name=alarm5am55 on-event="for i from=1 to=3 step=1 do={beep frequency=2000 length=.01s; delay .2s;}" start-time=05:55:00
These short beeps do not forcibly wake you, but gently stimulate the brain, especially in combination with ambient light.
This approach allows for natural awakening during REM or light sleep stages β a gentler alternative to harsh alarm clocks.
To enable it automatically at boot or every minute, you can set up a cron job on OpenWrt:
# Edit crontab
crontab -eAdd the following line:
* * * * * /root/sunrise.shOr run manually in loop
while true; do bash sunrise.sh ; sleep 60; done
Make sure the script is executable:
chmod +x /root/sunrise.shThis is a demo version of the above logic.
Instead of using the current time, it emulates the full 20-minute sunrise cycle in real time β every minute is played back in 1 second.
This script is ideal for testing the lighting behavior without needing to wait for early morning hours.
./sunrise_demo.shEach second it prints the emulated time and sends corresponding HSV values to the control_hsv binary.
Both scripts require the control_hsv utility to be compiled and available in the same folder or in your $PATH.