aurora-smart-home

Aurora Smart Home

Describe what you want to build. Get back automations, firmware, integrations, and dashboards that already passed validation.

Aurora is a Claude Code plugin with 21 smart home specialists backed by verified reference data. Home Assistant automations and dashboards, ESPHome firmware, HACS-ready Python integrations, Node-RED flows: every request is routed to the right specialist, and every pin, entity ID, I2C address, and API pattern is checked before code is generated. Ask for something that cannot work, a reserved GPIO or an automation triggering on an entity that does not exist, and Aurora refuses, shows you why, and hands you the fix instead of code that fails silently.

---

⚠️ Use at your own risk. Aurora generates code and recommendations for educational purposes. Smart home projects involve mains electricity, batteries, and devices that control locks, water, heating, and gas. AI-generated configs can be plausible but wrong. The maintainers, contributors, and Anthropic accept no liability for property damage, personal injury, data loss, or any other harm. See DISCLAIMER.md for full terms.

---

Aurora in 10 seconds

/plugin marketplace add tonylofgren/aurora-smart-home
/plugin install aurora@aurora-smart-home
/aurora:aurora

Then just describe it. One request is enough for a complete build: Aurora delivers the ESPHome firmware, the Home Assistant automation, and the dashboard as one coherent project, wired together end to end so the entity the firmware creates is the entity the automation triggers on and the dashboard shows.

You: motion light for the hallway: sensor on ESP32, automation in Home Assistant, a tile on the dashboard

Aurora: plans three specialists working from one shared snapshot:

Volt (firmware)    validates board + pins before writing YAML,
                   creates  binary_sensor.hallway_motion
Sage (automation)  triggers on binary_sensor.hallway_motion,
                   modern triggers:/actions: syntax
Iris (dashboard)   places the same entity on the room view

Anything impossible is refused with a concrete fix instead of generated:

❌ Problem:  GPIO 19/20 are reserved for USB on the ESP32-S3 DevKit.
🔧 Fix:      Use GPIO 8 (SDA) and GPIO 9 (SCL), the board's default
             I2C pins.

If Sage's automation references an entity Volt never creates, Aurora raises the conflict to you instead of shipping broken YAML. Delivery is a project folder on disk, not a paste in chat:

hallway-motion/
├── README.md              ← BOM with prices, wiring table + diagram,
│                            install steps, troubleshooting, recovery
├── hallway-motion.yaml    ← ESPHome firmware (Volt)
├── automations.yaml       ← HA automation (Sage)
├── dashboard.yaml         ← Lovelace view (Iris)
└── secrets.yaml.example   ← WiFi + API key template

No hardware involved? Aurora works the same for pure software requests:

You: lights on at sunset, off at midnight

Aurora: a Home Assistant automation in modern triggers: / actions: syntax, where every entity it references is verified to exist.

You: Python integration for the Acme cloud API, HACS ready

Aurora: the full custom_components/ structure with config flow, coordinator, and the async pitfalls (datetime.now(), blocking I/O) already caught.

Plain AI codegen gives you plausible. Aurora gives you checked: 12 validators block bad pins, I2C address collisions, wrong voltages, missing entities, async bugs, and OTA-bricking configs before any code reaches you, whether the output is ESPHome YAML, a Home Assistant automation, Python, or a Node-RED flow.

---

What's new: OpenAI Codex support (v1.19.0, August 2026)

• OpenAI Codex CLI support: a two-command install via the codex plugin marketplace, with AGENTS.md routing so Codex users get the same specialist routing as Claude Code. Also works from a plain repository clone, no plugin install required.
• Model guidance refreshed to the Claude 5 family: Opus 5 recommended for complex design work (PCB layout, integration architecture), Sonnet 5 as the workhorse for everyday builds and automations.
• Build Principles baked into every specialist: simplest working config first, reuse existing patterns before adding new dependencies, and a validation step built into every delivery.

Earlier releases (ESPHome 2026.8.0, ESPHome 2026.7.0, XIAO boards, the recipe library, verified JLCPCB part numbers, fab-ready hardware delivery, and more): see CHANGELOG.md.

What's new: ESPHome 2026.8.0 support (v1.18.0, August 2026)

• Full ESPHome 2026.8.0 release guide: Bluetooth Low Energy now works across more chip families (Raspberry Pi Pico W, Beken BK72xx, LibreTiny LN882H), with a breaking-change migration checklist for the ble_hub_id rename, voc_index/nox_index sensor keys, and the new LED strip channel_colors key.
• New device support with ready-to-flash configs: 60 GHz presence radar (LD6002B), Hörmann garage door control, DS248x 1-Wire bridges, and ad-hoc Modbus read/write actions straight from YAML.
• Networking and reliability: dual Ethernet+WiFi with automatic failover on ESP32, and multi-key OTA signature verification for signing-key rotation.

What's new: ESPHome 2026.7.0 support (v1.17.0, July 2026)

• Full ESPHome 2026.7.0 release guide: native ESP-IDF and nRF Connect SDK toolchains are now the default build backend, with an upgrade checklist, a breaking-change table, and a "what did not change" reassurance section so upgrades do not surprise you.
• New device support with ready-to-flash configs: the QMI8658 IMU, Divoom Pixoo 64 LED matrix, IT8951 e-paper (M5Paper), and new touch controllers, plus a Modbus meter recipe and an animated, auto-rotating LVGL screen.
• Security recipes: opt-in NVS encryption, OTA downgrade protection, and the new provisioning window for products that ship unconfigured, all wired into a single hardened-node example.

What's new: XIAO boards, more air-quality sensors, current platform data (v1.16.0, July 2026)

• Seeed XIAO family in the catalog: board profiles for the XIAO ESP32-C3, ESP32-C6, and ESP32-S3 with verified pin maps, strapping pins, LiPo charging data, and the C6 antenna-switch GPIOs, so tiny battery builds get real pin validation.
• Air quality beyond CO2: PMS5003 particulate (PM1.0/PM2.5/PM10) and SGP40 VOC index sensor profiles join the catalog (now 16 parts), both with live-verified JLCPCB part numbers.
• Aurora routes on current releases: platform data now covers HA 2026.6/2026.7 and ESPHome 2026.5/2026.6, including the HA 2026.6 removal of legacy platform: template sensors, plus sharper routing keywords (mmWave/radar/presence, DLMS smart meters, SkyConnect).

What's new: ESPHome 2026.6.0 support (v1.15.0, June 2026)

• New ESPHome release reference: Aurora now knows ESPHome 2026.6.0, with an upgrade checklist, breaking changes, and copy-ready examples, so generated firmware matches the current release instead of older patterns.
• New hardware covered: the motion/IMU framework (BMI270 and LSM6DS tilt and orientation), the PCM5122 HiFi audio DAC, the router speaker for live SPDIF/analog switching, the XDB401 pressure sensor, and FTDI/Prolific USB-serial adapters, each with a worked config.
• Safer upgrades: Aurora warns that ESP8266 now defaults to WPA2 (legacy routers need a one-line opt-out) and shows how enable_on_boot: false now frees real RAM on WiFi and ethernet.

What's new: two new recipes and four more sensors (v1.14.0, June 2026)

• Two new recipes: daylight-lights dims or switches lights to match the measured ambient light in a room, and dc-power-monitor measures the current and power a DC device or circuit draws. The library is now 14 curated starting points.
• Four more verified sensors in the catalog (now 14 parts): SHT31 and AHT20 (higher-accuracy temperature/humidity), BH1750 (ambient light), and INA219 (DC current/power), each with a real, in-stock JLCPCB part number.
• Sharper existing recipes: weather-station can swap in SHT31/AHT20 for better accuracy, and motion-light now has a real light sensor (BH1750) behind its lux threshold.

What's new: out-of-stock warnings (v1.13.1, June 2026)

• No more checkout surprises: when a part you picked is out of stock or running low at JLCPCB, Aurora now flags it in the BOM and calls it out in the README, so you can swap to an alternative before you order instead of finding out at checkout.
• Live stock in the component catalog: the verified-parts catalog tracks JLCPCB stock status (in stock / low / out of stock), refreshed automatically each month.

What's new: stronger delivery and protocol checks (v1.13.0, June 2026)

Three additive upgrades that make Aurora's output more trustworthy.

• Conformance levels in the delivery check: check-delivery.py now reports whether a project reaches minimal, standard, or strict, and you can gate at the level you want. The language check is now definitive (every doc in a project must share one language) instead of a heuristic, and there is a drop-in CI workflow template so you can gate your own project repos.
• A worked DEEP-mode demo: a complete CO2 project shows three specialists (firmware, automation, dashboard) building through one shared snapshot, with a replay test that proves the hand-off protocol end to end.
• An eval regression gate: the routing and delivery eval scores are pinned to a golden baseline, so a future change cannot quietly weaken how Aurora routes requests or what it delivers.

What's new: recipe library (v1.12.0, June 2026)

Aurora can now start you from a curated recipe instead of a blank page.

• 12 ready-made starting points: CO2 monitor, motion light, weather station, fridge/freezer monitor, room presence, home/away routine, energy dashboard, notification hub, vacation mode, greenhouse, smart thermostat, and a button scene controller.
• Describe a goal, get suggestions: say something broad like "I want to do something about air quality" and Aurora offers the closest recipes, always with "start from scratch" as an option.
• Pick one and Aurora builds it: the full project folder is generated from the recipe (hardware with verified part numbers where applicable, automation pattern, and dashboard), then you customise the handful of parameters that matter (thresholds, rooms, schedules).
• Across the board: recipes span sensor builds and pure Home Assistant automations that need no new hardware, and each links the full worked example when one exists.

What's new: verified part numbers + validated netlists (v1.11.0, June 2026)

The fab-ready pipeline from v1.10.0 is now complete and verified end to end.