ESPSomfy-RTS Gateways

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 an existing ESPSomfy-RTS gateway already installed on my local network with its motors and groups already configured, plus any authentication required by the installed firmware, and give my approval for the named shade or group and its movement, confirming an awning or window covering can move safely. Reported positions are estimates, because RTS is one-way radio. Installing the file configures none of that. Install "ESPSomfy-RTS Gateways" for me. It controls commissioned Somfy RTS shades and existing groups through an installed ESPSomfy-RTS gateway using Muse Home Link, using its local HTTP API for supported movement and positioning; reported positions are estimates. It is used when an already-installed ESPSomfy-RTS gateway controls my commissioned Somfy RTS shades: firmware identity and version are confirmed through the discovered service and /controller — an Espressif MAC prefix is not proof of ESPSomfy-RTS — and the installed API listener is used (documentation commonly uses port 8081, but the actual advertised/configured endpoint takes precedence). The gateway exists with its motors and groups already configured, plus any authentication required by the installed firmware, and I approve the named shade or group and its movement, confirming an awning or window covering can move safely. It reads /controller, /shades and /groups using the documented API, matches stable shade/group IDs and determines supported tilt, positioning and configured movement direction, then reads the target's current tracked state — RTS is one-way radio, so position is a timed estimate rather than feedback from the motor. For a requested open/close action it calls the firmware's /shadeCommand with its actual shadeId and documented up or down command, treating an HTTP GET used for a state-changing command as a write; it uses my only after checking its context, since it can stop a moving motor or send an idle motor to its favorite position, and never presents it as an unconditional stop. For an existing group it uses /groupCommand with that group's ID, and position and tilt requests use the exact installed firmware's documented parameters and calibrated capabilities, never guessing parameter names or position orientation. It inspects returned controller/shade state and errors but labels position as estimated, and asks for physical confirmation when actual position or successful radio delivery matters, because a successful HTTP response cannot prove the motor received the transmission; before retrying it inspects current movement and lets it settle, since repeated radio commands can change the outcome. Limits: no motor pairing/programming, rolling-code manipulation, flashing or new gateway deployment; /shadeCommand?get=shades is not used for enumeration (/shades is the documented inventory path); and rain/wind controls are never bypassed nor is support inferred for every Somfy motor. Repository: https://github.com/facebookincubator/muse-gadget-sdk (the skill is the whole skills/gadget-espsomfy-rts/ 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-espsomfy-rts/ 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 cdc86a5da589839d70786d13560ca7e707b1a68b45ffa577cf182f56e5026251 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 823 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 installed local ESPSomfy-RTS gateway over its local HTTP API: /controller, /shades and /groups reads and the documented /shadeCommand or /groupCommand for the movement I approved, with the installed firmware's authentication if configured. No motor pairing or rolling-code manipulation happens at use time. - The skill does not do motor pairing/programming, rolling-code manipulation, flashing or new gateway deployment, does not use /shadeCommand?get=shades for enumeration, and never bypasses rain/wind controls. - 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-espsomfy-rts folder into the agent's skills directory, in a folder named exactly "gadget-espsomfy-rts", 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-espsomfy-rts), 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 ESPSomfy-RTS gateway already installed with motors and groups already configured, plus any authentication the installed firmware requires; shade or group movement always needs my approval for the named target, and reported positions are estimates; 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.