Shelly Plugs

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 Shelly Gen 4 plug already set up on my local network, identified by fresh discovery (_http._tcp model/hostname metadata such as ShellyPlugUSG4-<device-id>, confirmed by /rpc/Shelly.GetDeviceInfo: model, app, gen, firmware and auth_en, using the current discovered IPv4/port and never a remembered DHCP address), know what load is plugged in before any switching — especially networking, heating, medical or other consequential loads — and, when auth_en is true, have the documented HTTP/RPC digest credentials in approved storage (the device username is admin; the password is never placed in a command). Installing the file configures none of that. Install "Shelly Plugs" for me. It switches Shelly Gen 4 plugs and reads supported power or energy measurements through Muse Home Link, using the local Shelly RPC API; it is not the Gen 1 protocol. It is used when fresh discovery identifies a Gen 4 plug: _http._tcp model/hostname metadata is matched (prefixes and names alone are insufficient) and /rpc/Shelly.GetDeviceInfo confirms model, app, gen, firmware and auth_en, using the current discovered IPv4/port. It confirms identity, then reads /rpc/Shelly.GetStatus and the intended switch component (the Shelly Plug US Gen 4 uses switch ID 0; component IDs are confirmed on other compatible hardware) and reads /rpc/Switch.GetStatus?id=0 before acting, retaining output, apower and relevant fault flags. A requested change is sent as /rpc/Switch.Set?id=0&on=true or on=false — a write remains a state-changing action even when the vendor uses an HTTP GET endpoint — and for an explicitly requested temporary action Switch.Set accepts toggle_after=<seconds> so reversal runs on the plug, with the timer and its consequences explained before it is set. It then reads Switch.GetStatus again: the Switch.Set reply's was_on is the previous state, not the resulting state. It verifies output for relay state and apower for measured watts (relay-on with zero watts may mean an idle or disconnected load, not failed control), reports actual voltage/current/energy fields and units when exposed (aenergy totals are in watt-hours), and on an uncertain response reads current state before retrying, never using toggle as a retry of an explicit on/off request. Limits: no schedules, no script installation, no reset or firmware update and no protection-threshold changes under a switching request; Gen 4 may expose illuminance, MQTT, BLE or Matter, but those are not assumed alternative runtime paths; explicit on/off is preferred to /rpc/Switch.Toggle, and persistent Switch.SetConfig changes need their own requested scope. Repository: https://github.com/facebookincubator/muse-gadget-sdk (the skill is the whole skills/gadget-shelly-plugs/ 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-shelly-plugs/ 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 1952f4eee8bab6fd30fc5f1bd5211a37dfa750efaee9766e39245dd89e9fa41c 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,994 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. It has no dependency on any other gadget skill in this lot. - 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 Shelly Gen 4 plug over the local Shelly RPC API (HTTP): Shelly.GetDeviceInfo, Shelly.GetStatus, Switch.GetStatus and Switch.Set on the current discovered endpoint. When auth_en is true, the documented HTTP/RPC digest authentication uses approved stored credentials (device username admin) and the password is never placed in a command. - The skill does not create schedules, install scripts, reset or update firmware, or modify protection thresholds under a switching request; it does not cover the Gen 1 protocol, and illuminance, MQTT, BLE or Matter are not assumed alternative runtime paths. - 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-shelly-plugs folder into the agent's skills directory, in a folder named exactly "gadget-shelly-plugs", 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-shelly-plugs), 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 a Shelly Gen 4 plug already set up on my local network and identified by fresh discovery; know what load is plugged into it before any switching, especially networking, heating, medical or other consequential loads; and, when auth_en is true, keep the digest credentials in approved storage (device username admin, password never placed in a command); 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.