Sonoff RF Bridge R2

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 Sonoff RF Bridge R2 d'origine déjà configuré pour l'opération LAN sur mon réseau local, avec son device ID et son devicekey existants fournis via le stockage d'identifiants approuvé (aucune récupération de clé cloud ne fait partie de ce skill), et une cartographie canal→action privée, confirmée par l'utilisateur (canaux 0-15). Seules les actions 433 MHz à codes fixes approuvées par l'utilisateur sont capturées ou transmises : aucun code roulant et aucune extraction de clé ; la clé AES dérivée du devicekey ne quitte jamais ma machine et n'apparaît jamais dans les commandes ni les journaux. L'installation du fichier ne configure rien de tout ça. Installe-moi « Sonoff RF Bridge R2 ». Il capture ou transmet des actions 433 MHz à codes fixes approuvées par l'utilisateur via un Sonoff RF Bridge R2 d'origine en utilisant Muse Home Link, avec un firmware HTTP zeroconf compatible, des identifiants d'appareil existants et une cartographie de canaux confirmée ; ce ne sont pas des codes roulants. Il s'utilise quand une découverte fraîche identifie un Sonoff RF Bridge R2 d'origine compatible — _ewelink._tcp, modèle exact du pont et firmware appariés, service HTTP zeroconf couramment sur 8081 avec le point découvert utilisé, et HTTP zeroconf du firmware 3.x gardé distinct des anciennes recettes WebSocket, la compatibilité n'étant jamais inférée de la seule fréquence radio ou marque. Le pont a déjà l'opération LAN configurée et son device ID/devicekey sont fournis via le stockage d'identifiants approuvé ; aucune récupération de clé cloud ne fait partie de cette procédure. Je maintiens une cartographie canal→action privée, confirmée par l'utilisateur, sur les canaux 0-15 — le pont ne fournit pas d'inventaire local fiable des canaux appris — et la cible physique, le canal et l'effet sont confirmés avant capture ou transmission, particulièrement pour les portes, alarmes et prises de courant. Pour chaque commande, il bâtit une enveloppe de requête fraîche : il dérive la clé AES de 16 octets comme le digest MD5 brut du devicekey, utilise un IV aléatoire frais de 16 octets, AES-128-CBC, un padding PKCS#7 et le texte chiffré/IV en base64, chiffre le payload JSON de commande en UTF-8, puis fait un POST vers le point /zeroconf/<command> correspondant avec sequence (chaîne en millisecondes), deviceid, le littéral selfApikey:"123", data chiffré, encrypt:true et iv — en gardant tout le matériel de clé hors des commandes et des journaux, et la clé AES dérivée ne quitte jamais la machine. Pour un apprentissage que je demande sur un canal libre confirmé N, il envoie {"cmd":"capture","rfChl":N} à /zeroconf/capture, puis je presse la télécommande visée près du pont ; une cartographie existante n'est jamais écrasée sans mon autorisation explicite, et une assignation de canal confirmée est consignée en privé après un apprentissage réussi. Pour une action apprise connue, il envoie {"cmd":"transmit","rfChl":N} à /zeroconf/transmit une seule fois, inspecte la réponse applicative, erreurs de l'appareil incluses, et décode une réponse chiffrée selon son enveloppe. HTTP 200 n'est pas une preuve physique : l'action réelle de l'appareil visé est confirmée par un retour d'état indépendant ou par moi, l'état RF n'est jamais inféré de la cartographie ni d'une réponse de transmission incertaine, et une transmission RF incertaine n'est jamais répétée automatiquement, car certaines actions apprises basculent un état ou déplacent un appareil. Limites : codes fixes 433 MHz seulement dans ce périmètre — aucune rejeu de codes roulants, aucun infrarouge ni support de télécommande universelle ; aucun client compagnon n'est requis et l'agent peut implémenter l'enveloppe documentée ; et aucun firmware de remplacement n'est installé, aucune clé n'est extraite de comptes et aucun repli cloud n'est créé. Dépôt : https://github.com/facebookincubator/muse-gadget-sdk (le skill est tout le dossier skills/gadget-sonoff-rf-bridge/ 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-sonoff-rf-bridge/ 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 b6288e113e1fa652a748a727106f31c4d8ffe6d9f0e40f1393f57247f1101b69 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 (3 306 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 à mon Sonoff RF Bridge R2 d'origine local, par ses points HTTP zeroconf chiffrés : enveloppes de capture ou de transmission pour des actions à codes fixes approuvées par l'utilisateur sur des canaux de ma cartographie confirmée. Le devicekey vient du stockage d'identifiants approuvé, tout le matériel de clé reste hors des commandes et des journaux, et la clé AES dérivée ne quitte jamais ma machine — elle ne fait que chiffrer localement le payload pour mon propre pont. Aucun code roulant n'est capturé ni rejoué et aucune clé n'est extraite. - Le skill ne rejoue aucun code roulant, ne supporte ni l'infrarouge ni les télécommandes universelles, n'installe aucun firmware de remplacement, n'extrait aucune clé de comptes et ne crée aucun repli cloud, et il ne répète jamais automatiquement une transmission RF incertaine. - 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-sonoff-rf-bridge dans le répertoire des skills de l'agent, dans un dossier nommé exactement « gadget-sonoff-rf-bridge », 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-sonoff-rf-bridge), 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 RF Bridge R2 d'origine déjà configuré pour l'opération LAN et garder son device ID/devicekey existants en stockage d'identifiants approuvé ; maintenir ma cartographie canal→action privée et confirmée — seules mes actions à codes fixes approuvées sont capturées ou transmises, jamais de codes roulants, et la clé AES dérivée ne quitte jamais ma machine ni n'apparaît dans les commandes ou les journaux ; 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.