ESPHome Devices

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites — Muse Home Link and a compatible physical device are required to USE this skill, not to install it: installing the skill file itself needs no account, no key and no device, and this install does NOT set up Home Link, pair anything or ask for any credential. But the skill is instructions only. To use it I must read and follow ~/docs/devices/home_link.md in my Muse environment, have the compatible physical device named below already set up on my local network, and have a device confirmed to run ESPHome, already installed and commissioned with an enabled native API or web server, already set up on my local network (confirmed from the firmware's service metadata and API information — an Espressif manufacturer identifier alone is insufficient), with the existing native API encryption key/password or web authentication, if configured, plus a compatible client; enabling an absent API by reflashing is not part of this skill — and, for ratgdo garage controllers, I use the more specific ratgdo skill instead (gadget-ratgdo-v32-garage-door, lot 4 of this same vetting, a separate listing from the same repository). Installing the file configures none of that. Install "ESPHome Devices" for me. It reads and controls entities exposed by already-installed ESPHome firmware through Muse Home Link, using an enabled native TCP or HTTP API and its configured credentials; the ratgdo skill is preferred for ratgdo garage controllers. It is used when the device is confirmed to run ESPHome and already exposes a supported API (an Espressif manufacturer identifier alone is insufficient): the firmware's service metadata and API information confirm the device, firmware version and enabled interface, and live entities are enumerated with their stable identifiers, types and capabilities — for ratgdo garage controllers the more specific ratgdo skill (gadget-ratgdo-v32-garage-door, lot 4 of this same vetting, a separate listing from the same repository) is used instead, while this listing's tested install remains the copy of its own folder only. It connects to the native API using a compatible aioesphomeapi client and the current endpoint, or uses the installed firmware's documented HTTP API, preserving native session encryption and configured authentication. It lists entities, supported commands, ranges and current state, preferring the native API for structured enumeration when available (web entity IDs and URL conventions are firmware-version dependent), reads sensors or subscribes to state updates over the outbound native connection or HTTP SSE where supported, and for a requested change calls only the command advertised for that entity — for example a switch's on/off, a light's supported brightness or a cover's supported movement — converting units and ranges using that entity's metadata. It follows state updates and action errors, confirms the intended entity changed and reports whether the value is measured, inferred or optimistic, distinguishing optimistic target states from measured feedback when firmware lacks a physical sensor, and never retries a toggle, button action or movement command until an uncertain first outcome has been checked. Limits: no universal entity names or URL templates across firmware versions, and no firmware installation, OTA, arbitrary device services/scripts, generic Bluetooth proxy, network reconfiguration or safety bypasses; an entity's existence does not authorize its actuation, and the shared physical-action safety rules apply. Repository: https://github.com/facebookincubator/muse-gadget-sdk (the skill is the whole skills/gadget-esphome-devices/ folder at the pinned commit: SKILL.md only, 1 file) Pinned version: install the code at commit e6fe5174092702ffddae6f90759a38d55a4ebae1 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/facebookincubator/muse-gadget-sdk into a temporary folder, check out commit e6fe5174092702ffddae6f90759a38d55a4ebae1, and copy the skills/gadget-esphome-devices/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-22: [FINGERPRINTS] - SKILL.md: SHA-256 2b44f5d9240519453d27590ff6395b694ed973872b71e25fbc4f3b8f55d25522 If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, and tell me in plain words: what the skill does when used, what it connects to, whether it reads or sends any personal information or credentials, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the files: - The skill folder holds 1 file only: SKILL.md (2,785 bytes). There is no script, no code and no configuration in it; the procedure runs at use time through Muse Home Link against my own local device. Cross-reference disclosed by the skill itself: for ratgdo garage controllers, use the more specific ratgdo skill (gadget-ratgdo-v32-garage-door, lot 4 of this same vetting, a separate listing from the same repository). The tested install of this listing is still the copy of its own folder only. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit. No device is contacted, no pairing is started and no key is asked for during installation. - At use time, exchanges go only to my local ESPHome device over its enabled native API (aioesphomeapi client, current endpoint) or its documented HTTP API: entity enumeration, state reads/subscriptions and the per-entity commands the firmware advertises, with native session encryption and the existing API encryption key/password or web authentication, if configured, preserved. - The skill does not do firmware installation, OTA, arbitrary device services/scripts, a generic Bluetooth proxy, network reconfiguration or safety bypasses, and it does not reflash to enable an absent API. - Do not pair any device, do not ask for or set any credential, do not run any control, print, scan or playback action, and do not use the skill in any way during this install: Home Link setup, pairing and use are my decisions, later, when I actually ask for them. 3. When I say "yes, install", install it as a skill: copy the whole gadget-esphome-devices folder into the agent's skills directory, in a folder named exactly "gadget-esphome-devices", keeping its 1 file (SKILL.md at its root). The exact folder name matters: relative links between sibling gadget skills depend on these exact names. 4. Verify with no network calls: frontmatter valid (name: gadget-esphome-devices), the 1 file in place with matching fingerprint. Do not run anything and do not connect to any device to verify. 5. Report what was installed, where, and what I still need to do myself (for example: read ~/docs/devices/home_link.md in my Muse environment and follow its Home Link rules; have an ESPHome device already installed and commissioned on my local network with an enabled native API or web server, and keep its existing native API encryption key/password or web authentication, if configured, in place; for ratgdo garage controllers, use the ratgdo skill (gadget-ratgdo-v32-garage-door, lot 4, separate listing from the same repository) instead; using the skill is a separate step that only starts when I ask for it, and the use-time exchanges disclosed above happen only then). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.