esphome

Name: esphome
Author: tonylofgren

56installs3forks

How to install esphome?

tonylofgren/aurora-smart-home/esphome

$npx -y skills add tonylofgren/aurora-smart-home --skill esphome

Installs into the current project.

Summary

ESPHome device configuration, firmware, and IoT product development. Covers ESP32, ESP32-S3, ESP32-C3, ESP32-C6, ESP32-H2, ESP32-P4, ESP8266, RP2040, RP2350, nRF52, LibreTiny, Shelly, Sonoff, Tuya, BLE proxy, Matter firmware, Thread, Zigbee, GPIO, sensor YAML, LVGL displays, LED

Files · 1

View on GitHub

SKILL.md

1	# ESPHome Devices
2
3	Reference skill for ESPHome device configuration and firmware.
4
5	## Overview
6
7	Core principle: Never generate ESPHome configuration without knowing the exact hardware. Board selection determines GPIO mapping, flash size, available features, and component compatibility.
8
9	Context: This skill requires hardware confirmation before any YAML generation. Different ESP chips have vastly different capabilities - ESP32-S3 supports USB and cameras, ESP32-C6 supports Thread/Matter/WiFi 6, ESP32-H2 is BLE+Thread only (no WiFi), ESP32-P4 is high-performance with MIPI DSI displays, and ESP8266 has limited GPIO and memory. ESPHome also supports nRF52 (Zephyr), RP2040, and LibreTiny (BK72xx/RTL87xx) platforms.
10
11	## The Iron Law
12
13	```
14	CONFIRM BOARD BEFORE GENERATING ANY CONFIGURATION
15	```
16
17	ESP32 has 12+ variants with different GPIO mappings, strapping pins, and capabilities. Assuming `esp32dev` when the user has an S3, C3, or C6 produces configs that silently fail. Always get explicit board confirmation first.
18
19	## The Process
20
21	```
22	User request
23	│
24	▼
25	Ask: What board?
26	│
27	▼
28	Board confirmed? ──no──▶ Ask again
29	│ yes
30	▼
31	Battery/actuator/outdoor/>5V? ──yes──▶ Vera: Hardware Safety Review
32	│ no (or cleared by Vera) │ blocks if critical risk found
33	▼ ▼
34	Ask: Output method? ◀── safety cleared
35	│
36	▼
37	deep_sleep / battery / solar / power bank? ──yes──▶ Flag Watt for power budget
38	│ no (or after Watt)
39	▼
40	Read relevant references
41	│
42	▼
43	Generate YAML config
44	│
45	▼
46	Generate wiring diagram (every GPIO — no exceptions)
47	│
48	▼
49	Calibration procedure needed? ──yes──▶ Generate procedure with actual entity IDs
50	│ no
51	▼
52	Generate troubleshooting section (3 most likely failure points)
53	│
54	▼
55	Run pre-completion checklist
56	│
57	▼
58	Deliver config
59	```
60
61	## Common Pitfalls
62
63	Watch out for these assumptions:
64
65	\| Thought \| Reality \|
66	\|---------\|---------\|
67	\| "They probably mean ESP32" \| ASK. ESP32 has 12+ variants with different pinouts \|
68	\| "I'll use esp32dev as default" \| WRONG. Could be S3, C3, C6, or commercial device \|
69	\| "The GPIO numbers look standard" \| Strapping pins vary by chip. Confirm board first \|
70	\| "It's just a simple sensor" \| Simple configs still need correct board ID \|
71	\| "I can infer from the project" \| Never infer. Always confirm \|
72	\| "secrets.yaml is just a file" \| NEVER touch secrets.yaml. Use !secret references only \|
73
74	## Delivery Contract (read first, applies to every output)
75
76	Every output is a set of files in a project folder on disk. Chat output is not delivery. A described BOM is not a written BOM. A wiring diagram pasted in chat is not a wiring diagram in the project. Volt has not delivered until the files exist on disk.
77
78	Before generating anything for the user:
79
80	1. Create a project folder (`<device-name>/` for existing devices, `<product-slug>/` for new products).
81	2. Write every artifact as a file in that folder: the device YAML, `secrets.yaml.example`, and `README.md`. The README is the master document and carries (inline or via linked files): What this does, Bill of materials with estimated prices, Wiring with connection table and ASCII diagram, Installation, Calibration (if applicable), Troubleshooting, Recovery.
82	3. Place every artifact in the hierarchical project structure per the Project Structure Rule in `aurora/SKILL.md`. ESPHome firmware + `INSTALL.md` + `TROUBLESHOOTING.md` live under `<project>/esphome/`; the master `README.md` lives at the project root.
83	4. Write human-readable docs (`README.md`, `INSTALL.md`, `TROUBLESHOOTING.md`, `BOM.md`, `WIRING.md`) in the user's detected language per the Language Rule for Deliverables in `aurora/SKILL.md`. The install templates in `aurora/references/templates/install-*.md` are English by default and MUST be translated when the user wrote their request in any other language. Quoted commands, file paths, and identifiers stay English; the surrounding prose does not.
84	5. Run the pre-delivery disk check: every required file must exist before you declare the project complete. A described

People who liked this also viewed

6 picks

Type

esphome

56installs3forks

View on GitHub

How to install esphome?

tonylofgren/aurora-smart-home/esphome

$npx -y skills add tonylofgren/aurora-smart-home --skill esphome

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ESPHome Devices
2
3	Reference skill for ESPHome device configuration and firmware.
4
5	## Overview
6
7	Core principle: Never generate ESPHome configuration without knowing the exact hardware. Board selection determines GPIO mapping, flash size, available features, and component compatibility.
8
9	Context: This skill requires hardware confirmation before any YAML generation. Different ESP chips have vastly different capabilities - ESP32-S3 supports USB and cameras, ESP32-C6 supports Thread/Matter/WiFi 6, ESP32-H2 is BLE+Thread only (no WiFi), ESP32-P4 is high-performance with MIPI DSI displays, and ESP8266 has limited GPIO and memory. ESPHome also supports nRF52 (Zephyr), RP2040, and LibreTiny (BK72xx/RTL87xx) platforms.
10
11	## The Iron Law
12
13	```
14	CONFIRM BOARD BEFORE GENERATING ANY CONFIGURATION
15	```
16
17	ESP32 has 12+ variants with different GPIO mappings, strapping pins, and capabilities. Assuming `esp32dev` when the user has an S3, C3, or C6 produces configs that silently fail. Always get explicit board confirmation first.
18
19	## The Process
20
21	```
22	User request
23	│
24	▼
25	Ask: What board?
26	│
27	▼
28	Board confirmed? ──no──▶ Ask again
29	│ yes
30	▼
31	Battery/actuator/outdoor/>5V? ──yes──▶ Vera: Hardware Safety Review
32	│ no (or cleared by Vera) │ blocks if critical risk found
33	▼ ▼
34	Ask: Output method? ◀── safety cleared
35	│
36	▼
37	deep_sleep / battery / solar / power bank? ──yes──▶ Flag Watt for power budget
38	│ no (or after Watt)
39	▼
40	Read relevant references
41	│
42	▼
43	Generate YAML config
44	│
45	▼
46	Generate wiring diagram (every GPIO — no exceptions)
47	│
48	▼
49	Calibration procedure needed? ──yes──▶ Generate procedure with actual entity IDs
50	│ no
51	▼
52	Generate troubleshooting section (3 most likely failure points)
53	│
54	▼
55	Run pre-completion checklist
56	│
57	▼
58	Deliver config
59	```
60
61	## Common Pitfalls
62
63	Watch out for these assumptions:
64
65	\| Thought \| Reality \|
66	\|---------\|---------\|
67	\| "They probably mean ESP32" \| ASK. ESP32 has 12+ variants with different pinouts \|
68	\| "I'll use esp32dev as default" \| WRONG. Could be S3, C3, C6, or commercial device \|
69	\| "The GPIO numbers look standard" \| Strapping pins vary by chip. Confirm board first \|
70	\| "It's just a simple sensor" \| Simple configs still need correct board ID \|
71	\| "I can infer from the project" \| Never infer. Always confirm \|
72	\| "secrets.yaml is just a file" \| NEVER touch secrets.yaml. Use !secret references only \|
73
74	## Delivery Contract (read first, applies to every output)
75
76	Every output is a set of files in a project folder on disk. Chat output is not delivery. A described BOM is not a written BOM. A wiring diagram pasted in chat is not a wiring diagram in the project. Volt has not delivered until the files exist on disk.
77
78	Before generating anything for the user:
79
80	1. Create a project folder (`<device-name>/` for existing devices, `<product-slug>/` for new products).
81	2. Write every artifact as a file in that folder: the device YAML, `secrets.yaml.example`, and `README.md`. The README is the master document and carries (inline or via linked files): What this does, Bill of materials with estimated prices, Wiring with connection table and ASCII diagram, Installation, Calibration (if applicable), Troubleshooting, Recovery.
82	3. Place every artifact in the hierarchical project structure per the Project Structure Rule in `aurora/SKILL.md`. ESPHome firmware + `INSTALL.md` + `TROUBLESHOOTING.md` live under `<project>/esphome/`; the master `README.md` lives at the project root.
83	4. Write human-readable docs (`README.md`, `INSTALL.md`, `TROUBLESHOOTING.md`, `BOM.md`, `WIRING.md`) in the user's detected language per the Language Rule for Deliverables in `aurora/SKILL.md`. The install templates in `aurora/references/templates/install-*.md` are English by default and MUST be translated when the user wrote their request in any other language. Quoted commands, file paths, and identifiers stay English; the surrounding prose does not.
84	5. Run the pre-delivery disk check: every required file must exist before you declare the project complete. A described

People who liked this also viewed

6 picks

Type