ESPHome Devices

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 un appareil confirmé comme roulant ESPHome, déjà installé et mis en service avec une API native ou un serveur web activés, déjà configuré sur mon réseau local (confirmé depuis les métadonnées de service du firmware et les informations d'API — un identifiant fabricant Espressif seul ne suffit pas), avec la clé de chiffrement/mot de passe de l'API native existants ou l'authentification web, si configurés, plus un client compatible ; activer une API absente en reflashant ne fait pas partie de ce skill — et, pour les contrôleurs de garage ratgdo, c'est le skill ratgdo plus spécifique que j'utilise à la place (gadget-ratgdo-v32-garage-door, lot 4 de ce même vetting, fiche séparée du même repo). L'installation du fichier ne configure rien de tout ça. Installe-moi « ESPHome Devices ». Il lit et contrôle les entités exposées par un firmware ESPHome déjà installé via Muse Home Link, en utilisant une API TCP native ou HTTP activée et ses identifiants configurés ; le skill ratgdo est préféré pour les contrôleurs de garage ratgdo. Il s'utilise quand l'appareil est confirmé comme roulant ESPHome et expose déjà une API supportée (un identifiant fabricant Espressif seul ne suffit pas) : les métadonnées de service du firmware et les informations d'API confirment l'appareil, la version du firmware et l'interface activée, et les entités actives sont énumérées avec leurs identifiants stables, leurs types et leurs capacités — pour les contrôleurs de garage ratgdo, le skill ratgdo plus spécifique (gadget-ratgdo-v32-garage-door, lot 4 de ce même vetting, fiche séparée du même repo) est utilisé à la place, tandis que l'installation testée de cette fiche reste la copie de son seul dossier. Il se connecte à l'API native avec un client aioesphomeapi compatible et le point courant, ou utilise l'API HTTP documentée du firmware installé, en préservant le chiffrement de session natif et l'authentification configurée. Il liste les entités, les commandes supportées, les plages et l'état courant, en préférant l'API native pour l'énumération structurée quand elle est disponible (les ID d'entités web et les conventions d'URL dépendent de la version du firmware), lit les capteurs ou s'abonne aux mises à jour d'état via la connexion native sortante ou le SSE HTTP là où c'est supporté, et pour un changement demandé, il appelle seulement la commande annoncée pour cette entité — par exemple l'on/off d'un switch, la luminosité supportée d'une lumière ou le mouvement supporté d'un couvre-fenêtre — en convertissant les unités et plages selon les métadonnées de cette entité. Il suit les mises à jour d'état et les erreurs d'action, confirme que l'entité visée a changé et rapporte si la valeur est mesurée, inférée ou optimiste, en distinguant les états cibles optimistes des retours mesurés quand le firmware n'a pas de capteur physique, et ne réessaie jamais un toggle, une action bouton ou une commande de mouvement avant d'avoir vérifié un premier résultat incertain. Limites : pas de noms d'entités ni de gabarits d'URL universels entre versions de firmware, et pas d'installation de firmware, d'OTA, de services/scripts d'appareil arbitraires, de proxy Bluetooth générique, de reconfiguration réseau ni de contournements de sécurité ; l'existence d'une entité n'autorise pas son actionnement, et les règles de sécurité des actions physiques partagées s'appliquent. Dépôt : https://github.com/facebookincubator/muse-gadget-sdk (le skill est tout le dossier skills/gadget-esphome-devices/ 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-esphome-devices/ 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 2b44f5d9240519453d27590ff6395b694ed973872b71e25fbc4f3b8f55d25522 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 785 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. Référence croisée divulguée par le skill lui-même : pour les contrôleurs de garage ratgdo, utiliser le skill ratgdo plus spécifique (gadget-ratgdo-v32-garage-door, lot 4 de ce même vetting, fiche séparée du même repo). L'installation testée de cette fiche reste la copie de son seul dossier. - 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 à mon appareil ESPHome local, par son API native activée (client aioesphomeapi, point courant) ou son API HTTP documentée : énumération des entités, lectures/abonnements d'état et les commandes par entité que le firmware annonce, avec le chiffrement de session natif et la clé de chiffrement/mot de passe d'API existants ou l'authentification web, si configurés, préservés. - Le skill ne fait ni installation de firmware, ni OTA, ni services/scripts d'appareil arbitraires, ni proxy Bluetooth générique, ni reconfiguration réseau, ni contournements de sécurité, et il ne reflash pas pour activer une API absente. - 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-esphome-devices dans le répertoire des skills de l'agent, dans un dossier nommé exactement « gadget-esphome-devices », 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-esphome-devices), 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 un appareil ESPHome déjà installé et mis en service sur mon réseau local avec une API native ou un serveur web activés, et garder sa clé de chiffrement/mot de passe d'API native existants ou son authentification web, si configurés, en place ; pour les contrôleurs de garage ratgdo, utiliser le skill ratgdo (gadget-ratgdo-v32-garage-door, lot 4, fiche séparée du même repo) à la place ; 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.