Shelly Plugs

Avant de commencer : lis ce prompt d'installation au complet, dis-moi en quelques lignes ce que ce skill fait et ce que son installation implique, et attends mon feu vert avant de faire quoi que ce soit d'autre. Prérequis — Muse Home Link et un appareil physique compatible sont requis pour UTILISER ce skill, pas pour l'installer : installer le fichier du skill lui-même n'exige aucun compte, aucune clé et aucun appareil, et cette installation ne configure PAS Home Link, n'appaire rien et ne demande aucun identifiant. Mais le skill n'est que des instructions. Pour l'utiliser, je dois lire et suivre ~/docs/devices/home_link.md dans mon environnement Muse, avoir l'appareil physique compatible nommé ci-dessous déjà configuré sur mon réseau local, et avoir une prise Shelly Gen 4 déjà configurée sur mon réseau local, identifiée par découverte fraîche (métadonnées de modèle/nom d'hôte _http._tcp comme ShellyPlugUSG4-<device-id>, confirmées par /rpc/Shelly.GetDeviceInfo : model, app, gen, firmware et auth_en, avec l'IPv4/port découverts courants et jamais une adresse DHCP mémorisée), savoir quelle charge est branchée avant toute commutation — surtout les charges réseau, de chauffage, médicales ou autrement conséquentes — et, quand auth_en est vrai, avoir les identifiants digest HTTP/RPC documentés en stockage approuvé (le nom d'utilisateur de l'appareil est admin ; le mot de passe n'est jamais placé dans une commande). L'installation du fichier ne configure rien de tout ça. Installe-moi « Shelly Plugs ». Il commute les prises Shelly Gen 4 et lit les mesures de puissance ou d'énergie supportées via Muse Home Link, en utilisant l'API RPC locale Shelly ; ce n'est pas le protocole Gen 1. Il s'utilise quand une découverte fraîche identifie une prise Gen 4 : les métadonnées de modèle/nom d'hôte _http._tcp sont appariées (les préfixes et noms seuls ne suffisent pas) et /rpc/Shelly.GetDeviceInfo confirme model, app, gen, firmware et auth_en, avec l'IPv4/port découverts courants. Il confirme l'identité, puis lit /rpc/Shelly.GetStatus et le composant switch visé (la Shelly Plug US Gen 4 utilise l'ID de switch 0 ; les ID de composants se confirment sur tout autre matériel compatible) et lit /rpc/Switch.GetStatus?id=0 avant d'agir, en retenant output, apower et les drapeaux de faute pertinents. Un changement demandé part comme /rpc/Switch.Set?id=0&on=true ou on=false — une écriture reste un changement d'état même quand le vendeur utilise un endpoint HTTP GET — et pour une action temporaire explicitement demandée, Switch.Set accepte toggle_after=<secondes> pour que le retour s'exécute sur la prise, avec la minuterie et ses conséquences expliquées avant de la régler. Il relit ensuite Switch.GetStatus : le was_on de la réponse Switch.Set est l'état précédent, pas l'état résultant. Il vérifie output pour l'état du relais et apower pour les watts mesurés (relais allumé à zéro watt peut signifier une charge au repos ou débranchée, pas un échec de contrôle), rapporte les champs réels de tension/courant/énergie et leurs unités quand ils sont exposés (les totaux aenergy sont en wattheures), et sur une réponse incertaine, il lit l'état courant avant de réessayer, sans jamais utiliser toggle comme réessai d'une demande on/off explicite. Limites : pas d'horaires, pas d'installation de scripts, pas de réinitialisation ni de mise à jour du firmware et pas de modification des seuils de protection sous couvert d'une demande de commutation ; la Gen 4 peut exposer illuminance, MQTT, BLE ou Matter, mais ce ne sont pas des voies d'exécution alternatives présumées ; l'on/off explicite est préféré à /rpc/Switch.Toggle, et les changements persistants Switch.SetConfig exigent leur propre périmètre demandé. Dépôt : https://github.com/facebookincubator/muse-gadget-sdk (le skill est tout le dossier skills/gadget-shelly-plugs/ au commit épinglé : SKILL.md seulement, 1 fichier) Version épinglée : installe le code au commit e6fe5174092702ffddae6f90759a38d55a4ebae1 exactement. Ne substitue pas une version plus récente. Si ce commit est inaccessible, arrête-toi et dis-le-moi. 1. Clone https://github.com/facebookincubator/muse-gadget-sdk dans un dossier temporaire, place-toi au commit e6fe5174092702ffddae6f90759a38d55a4ebae1, et copie le dossier skills/gadget-shelly-plugs/ de ce checkout. Compare ensuite chaque fichier du dossier aux empreintes enregistrées pour cette fiche le 2026-10-22 : [FINGERPRINTS] - SKILL.md: SHA-256 1952f4eee8bab6fd30fc5f1bd5211a37dfa750efaee9766e39245dd89e9fa41c Si un fichier ne correspond pas, il a changé depuis la préparation de la fiche : ne l'installe pas encore, dis-moi ce que tu as trouvé et laisse-moi décider. 2. Lis SKILL.md au complet, et dis-moi en mots simples : ce que le skill fait quand on l'utilise, à quoi il se connecte, s'il lit ou envoie des informations personnelles ou des identifiants, et tout ce qui semble inhabituel. Arrête-toi sur tout signal d'alerte et dis-le-moi avant d'aller plus loin. Confirme ces points à partir des fichiers : - Le dossier du skill contient 1 fichier seulement : SKILL.md (2 994 octets). Il n'y a aucun script, aucun code et aucune configuration dedans ; la procédure roule à l'usage via Muse Home Link contre mon propre appareil local. Il ne dépend d'aucun autre skill gadget de ce lot. - Rien n'est envoyé nulle part pendant l'installation elle-même ; le seul téléchargement à l'installation est le dossier du skill depuis GitHub au commit épinglé. Aucun appareil n'est contacté, aucun appairage n'est lancé et aucune clé n'est demandée pendant l'installation. - À l'usage, les échanges vont uniquement à ma prise Shelly Gen 4 locale, par l'API RPC locale Shelly (HTTP) : Shelly.GetDeviceInfo, Shelly.GetStatus, Switch.GetStatus et Switch.Set sur le point découvert courant. Quand auth_en est vrai, l'authentification digest HTTP/RPC documentée utilise des identifiants stockés approuvés (nom d'utilisateur de l'appareil : admin) et le mot de passe n'est jamais placé dans une commande. - Le skill ne crée pas d'horaires, n'installe pas de scripts, ne réinitialise pas et ne met pas à jour le firmware, et ne modifie pas les seuils de protection sous couvert d'une demande de commutation ; il ne couvre pas le protocole Gen 1, et illuminance, MQTT, BLE ou Matter ne sont pas des voies d'exécution alternatives présumées. - N'appaire aucun appareil, ne demande et ne règle aucun identifiant, n'exécute aucun contrôle, aucune impression, aucune numérisation ni aucune lecture média, et n'utilise le skill d'aucune façon pendant cette installation : la configuration de Home Link, l'appairage et l'usage sont mes décisions, plus tard, quand je les demande vraiment. 3. Quand je dis « yes, install », installe-le comme skill : copie tout le dossier gadget-shelly-plugs dans le répertoire des skills de l'agent, dans un dossier nommé exactement « gadget-shelly-plugs », en gardant son 1 fichier (SKILL.md à sa racine). Le nom de dossier exact compte : les liens relatifs entre skills gadget frères dépendent de ces noms exacts. 4. Vérifie sans appels réseau : frontmatter valide (name: gadget-shelly-plugs), le 1 fichier en place avec une empreinte concordante. N'exécute rien et ne te connecte à aucun appareil pour vérifier. 5. Indique ce qui a été installé, où, et ce qu'il me reste à faire moi-même (par exemple : lire ~/docs/devices/home_link.md dans mon environnement Muse et suivre ses règles Home Link ; avoir une prise Shelly Gen 4 déjà configurée sur mon réseau local et identifiée par découverte fraîche ; savoir quelle charge y est branchée avant toute commutation, surtout les charges réseau, de chauffage, médicales ou autrement conséquentes ; et, quand auth_en est vrai, garder les identifiants digest en stockage approuvé (nom d'utilisateur de l'appareil : admin, mot de passe jamais placé dans une commande) ; utiliser le skill est une étape séparée qui ne commence que quand je le demande, et les échanges à l'usage divulgués ci-dessus arrivent seulement à ce moment-là). GitHub est optionnel : si j'ai un compte GitHub ou la CLI gh, tu peux l'utiliser ; sinon l'accès public suffit. Ne jamais l'exiger sauf s'il figure dans les prérequis ci-dessus. Règles : ne touche à rien en dehors du dossier temporaire et de la cible d'installation. Si quelque chose semble anormal, arrête-toi et demande-moi.