May 4, 2026 · omarchy-wled
Most desktop lighting projects look great in a demo and then quietly break in real life.
omarchy-wled started as a weekend experiment to sync Omarchy theme colors to WLED, but the useful part wasn’t the color effect. The useful part was building it so it can run unattended on a Linux desktop without turning into another fragile hobby service.
Repository: https://github.com/ericdahl-dev/omarchy-wled
The problem
If you want your room lighting to track your desktop theme, the hard part is not finding an RGB value. The hard part is operational reliability:
- where the color signal comes from
- how frequently updates happen
- what fails when wallpaper/theme state is weird
- how you make startup and recovery boring
That’s the gap this tool tries to close.
Why this matters
Ambient automation is only good when it disappears into the background.
If it needs babysitting, random restarts, or a wiki page to remember startup steps, most people abandon it. So the real target was not “looks cool once.” The target was “works every day with sane defaults.”
What omarchy-wled does
Core behavior:
- Reads color from Omarchy theme signals:
- accent
- foreground
- wallpaper-derived average
- Optional wallpaper gradient mode with LED resampling
- Brightness and saturation controls
- One-shot mode (
-once) and watch mode - TUI bootstrap for setup
- systemd user service template for autostart
- Release binaries and AUR packaging
Minimal usage:
omarchy-wled 192.168.1.50
omarchy-wled 192.168.1.50 -source fg
omarchy-wled 192.168.1.50 -source bg -gradient
How this compares to alternatives
1) Hyperion-style screen capture pipelines
(For context: Hyperion Project)
Great when your goal is reactive bias lighting from video content.
Tradeoffs:
- extra moving parts
- more resource overhead
- less aligned with theme-driven workflows
For this use case (theme color sync, not frame-by-frame capture), that stack is usually overkill.
2) Home Assistant automations
(For context: Home Assistant)
Excellent for full-home orchestration and cross-device rules.
Tradeoffs:
- more integration/config overhead for a single desktop-to-light bridge
- more places for drift when your desktop state is the primary source of truth
If you already run deep HA automations, it can still be a strong option. But for a local Linux-first loop, a focused binary is often simpler.
3) Ad-hoc shell/python scripts
Fast to prototype, often painful to operate long-term.
Tradeoffs:
- dependency drift
- brittle startup behavior
- no clean packaging/distribution story
That path is fine for proving an idea. It is usually not fine for a tool you want to keep running for months.
Engineering decisions that actually mattered
Go + single binary
This was mostly a packaging decision.
Benefits:
- no runtime stack to manage
- easier distribution via release artifacts and AUR
- fewer “works on my machine” failures
Tight scope
What I intentionally did not build first:
- cloud sync
- auth
- dashboard
- plugin system
Shipping a stable local loop beats shipping an unstable platform.
Operator ergonomics from day one
Reliability includes UX for the operator:
- clear flags
- config file support
- guided TUI setup
- systemd user template
That is not polish. That is the difference between “installed once” and “still running next month.”
Practical setup pattern (Linux)
The setup model I’d recommend for most people:
- Install release binary (or AUR)
- Run TUI/bootstrap once
- Validate color source + brightness in one-shot mode
- Enable user-level systemd service
- Let it run and only touch it when you want behavior changes
In short: configure once, then treat it like infrastructure.
Known tradeoffs and gotchas
No hype here—there are real limitations:
- Wallpaper sampling quality depends on source image characteristics
- Rapid theme transitions may need smoothing/debounce tuning
- WLED segmentation edge cases can produce output surprises
- Network-local device assumptions still apply for default transport mode
If your environment is chaotic, deterministic output is harder than the demo suggests.
What I’d improve next
Likely next iterations:
- stronger sampling for difficult wallpapers
- optional smoothing/debounce controls
- clearer docs for segment edge cases
- better diagnostics when expected and actual output diverge
Grounded takeaway
The interesting part is not “desktop RGB in the room.”
The interesting part is converting a tiny personal automation into something you can install, restart, and trust. That’s the pattern I care about: small scope, boring reliability, explicit tradeoffs.
If that’s your style too, try it: https://github.com/ericdahl-dev/omarchy-wled