Spectra L/S is a physical control board for Home Assistant.
Think of it like a home DJ mixer for music + lights:
- turn a knob for volume,
- press a button for playback,
- switch rooms/targets quickly,
- see what’s happening on the OLED.
It exists to make home control feel instant and tactile, instead of app-heavy and slow.
- Control playback (play/pause, next, volume)
- Control room lighting
- Switch targets/rooms with physical controls
- See live context/status on the onboard OLED
- Route actions through Home Assistant services and automations
- You already run Home Assistant (or are comfortable learning it)
- You want a premium physical interface for audio + home control
- You’re okay with a beta product that still evolves quickly
- Not a mass-market plug-and-play consumer product yet
- Not frozen/stable enterprise software yet
- Not "no-maintenance forever" if you follow
main
- ESP32-S3 dev board (
esp32-s3-devkitc-1in active firmware) - RP2040 board for physical input capture (buttons/encoders/pots)
- I2C OLED display (SSD1306 128x64, SSD1309-compatible, address
0x3C)
- WiiM devices
- Arylic / LinkPlay-class devices (TCP control, port
8899)
- ESP32-S3 remote node
- Current target board: ESP32-S3-DEVKIT-LIPO
- Encoder + buttons (play/pause, next-track flow)
- When hardware changes, update this list in the same change set as the hardware/firmware change.
- Also add the hardware-list update note to
docs/CHANGELOG.mdin that same slice.
Home Assistant ties these hardware pieces together so physical actions map cleanly to your home.
Inspired by premium physical control products like Condesa Electronics — Carmen SE and Varia Instruments — RDM series, Spectra L/S brings that tactile philosophy to Home Assistant.
- Music Assistant players
- Home Assistant media players
- WiiM-based rooms
- Arylic/LinkPlay-class endpoints
- Sendspin-class endpoints (roadmap target)
- AirPlay / Apple TV style sources
- Plex sessions/players (optional)
- A polished in-app Home Assistant control center
- Metadata-first now-playing contract hardening so OLED prioritizes true title/artist payloads before source-only passthrough fallback labels
- Component-authoritative OLED blank contract so true idle/no-payload windows blank deterministically instead of flipping source/friendly labels
- Runtime guard so idle source-state churn does not auto-reopen source context overlays while blank-contract posture is active
- Runtime guard so idle no-track windows do not use friendly-name fallback (
Kitchen Speakers) as now-playing text - Component guard so source-only passthrough context cannot assert active playback without title/progress evidence (prevents stale no-track OLED leakage)
- Better onboarding/setup flow for real homes with different device layouts
- Stronger playback and metadata reliability across mixed audio ecosystems
- Faster and cleaner input-to-action response from physical controls
If you want the deep implementation/roadmap details, see:
docs/roadmap/v-next-NOTES.mddocs/roadmap/CUSTOM-COMPONENT-ROADMAP.mddocs/architecture/
This section reflects an evidence-first compatibility audit against current upstream release notes plus local code-surface checks. It is intentionally conservative:
-
Verified up to (audit baseline):
- Home Assistant Core: 2026.6.4
- Home Assistant OS: 18.0
- ESPHome: 2026.6.2
- ESPHome add-on: 2026.6.2
- ESPHome Device Builder backend: 1.0.12
- ESPHome Device Builder frontend: 0.1.174
-
What “verified” means in this context:
- Upstream changelog/release deltas were reviewed and compared to current Spectra runtime + component contract surfaces.
- No blocking incompatibilities were identified in the current static code/config surface.
-
Expected (pending live soak confirmation):
- Build/deploy/runtime behavior remains expected-compatible on the versions above, but should still be confirmed with live compile + runtime validation evidence for each environment.
-
Known watch items:
- BLE scanning default changes in HA/ESPHome may affect operational behavior on
bluetooth_proxynodes; treat as an operational tuning watchpoint. - Compatibility statements here are contract-surface/audit based, not a blanket guarantee for every custom deployment topology.
- BLE scanning default changes in HA/ESPHome may affect operational behavior on
- A new standalone ESPHome node (
spectra-ls-remote) is being introduced as a movable coffee-table control box. - Current input model is encoder-first: rotary volume step control + encoder center-press play/pause + dedicated momentary next-track button.
- Power direction is battery-aware by design (final target board: ESP32-S3-DEVKIT-LIPO with charging + deep-sleep + battery telemetry).
- Communication direction is BLE-bridge-primary for low wake overhead, with Wi-Fi retained as secondary OTA/service lane.
- Scope/progress source of truth:
docs/program/SPECTRA-LS-REMOTE-SCOPE-PROGRESS.md. - Separate local operations helpers:
- build:
bin/esphome_spectra_remote_build_local.sh - upload:
bin/esphome_spectra_remote_upload_local.sh
- build:
Start here for setup, operations, and development workflow:
Common entry points:
- Setup placeholders:
docs/setup/SPECTRA-HA-CONFIG-PLACEHOLDERS.md - Latest project changes:
docs/CHANGELOG.md - Parallel Amped integration entrypoint (additive, current runtime preserved):
esphome/spectra_ls_system_amped_combined.yaml - Developer onboarding/runbook:
docs/developer/DEVELOPER-INSTRUCTIONS.md - WLED palette room E2E test runbook:
docs/testing/raw/wled_palette_room_e2e_runbook.md
Need current execution status? Use docs/roadmap/v-next-NOTES.md.
Need migration mechanics and slice evidence? Use:
Need wiki navigation? Start at docs/wiki/Home.md.
- I want to install and run Spectra →
docs/wiki/Install-on-Your-Own-HA.md - I already installed and need setup/deploy verification →
docs/wiki/User-Setup-Deploy-and-HA-Integration.md - Something broke and I need the right bug path →
docs/wiki/Welcome-README-and-Bug-Workflow.md - I’m contributing code/docs →
docs/wiki/Contributing-Workflow.md