FrankenSonos MCP : des agents IA pilotent vos enceintes Sonos sur votre LAN

À qui cela s'adresse

Vous possédez déjà des enceintes Sonos et voulez confier l'audio de toute la maison à un terminal, une API HTTP ou un agent IA qui parle MCP : FrankenSonos est un contrôleur et démon en Rust décrit officiellement comme memory-safe (sûr pour la mémoire) — un seul binaire fait tourner toute la maison. Chacune des trois entrées vise un public différent : les amateurs de ligne de commande prendront le CLI fsonos, les intégrateurs l'API HTTP documentée en OpenAPI, et ceux qui délèguent à l'IA passeront par le serveur MCP. Les adeptes de la domotique par ligne de commande et scripts s'y sentiront particulièrement bien ; l'outil ne sert que les enceintes que vous possédez déjà, sans achat de matériel.

Les prérequis d'abord : le projet est en pré-version, sans binaire officiel téléchargeable, donc la première utilisation commence par une compilation depuis les sources (la toolchain Rust est figée dans rust-toolchain.toml). Le démon doit tourner sur une machine du même LAN que vos enceintes ; pour y accéder de partout, cette machine doit aussi rejoindre votre tailnet Tailscale. Si vous attendez une installation en une commande, prête à l'emploi, attendez la version officielle. Ces deux conditions en font plutôt une infrastructure auto-hébergée qu'une application prête à l'emploi ; si vous les acceptez, passons au premier essai.

Peu adapté, ou à surveiller : sans enceintes Sonos, sans envie d'installer une toolchain Rust, ou sans machine qui reste en permanence sur le LAN des enceintes, ces prérequis sont difficiles à réunir. La compatibilité avec d'autres marques d'enceintes n'est pas documentée dans les preuves — ne la présumez pas.

Premier essai en 3 minutes

Le chemin principal recommandé est la procédure officielle : compiler depuis les sources, terminer la configuration initiale, puis pointer un agent vers le démon. Pourquoi pas un téléchargement : la CI produit bien des artefacts Apple Silicon et x86_64 Linux à chaque push sur main, mais ils expirent avec le pipeline ; officiellement, les téléchargements commenceront avec 0.1.0. Rien n'est installé sur les enceintes pendant toute la procédure.

Prérequis : une machine sur le même LAN que vos enceintes, avec la toolchain Rust en place.

Première étape, cloner et compiler :

git clone https://github.com/Dicklesworthstone/frankensonos
cd frankensonos
cargo build --release

Deuxième étape : lancez fsonos setup sur cette machine ; selon la description officielle, il prend le relais et termine la configuration initiale.

Troisième étape, depuis n'importe quelle machine du tailnet, pointez l'agent vers le démon :

claude mcp add --transport http fsonos https://<mac>.<tailnet>.ts.net:8443/mcp

Pour le premier appel, choisissez l'étape la plus légère : lire la ressource MCP sonos://zones pour voir les zones d'enceintes et vérifier que la chaîne fonctionne, avant de toucher au matériel. Côté signaux de succès, les preuves ne décrivent pas le texte de sortie exact ; ce qui est confirmé, c'est que l'endpoint et les noms de ressources viennent mot pour mot du texte officiel. Si vous voulez que l'agent exécute des actions de contrôle, notez qu'elles agissent sur du vrai matériel ; les preuves n'offrent aucun chemin d'annulation, ne les traitez donc pas comme réversibles. Le point de contrôle se place avant l'action : regardez ce que l'agent va appeler et sur quelle zone, puis laissez passer. Séparer le premier essai en lecture seule du contrôle réel, c'est le rythme le plus serein.

Cas d'usage

Cas un : l'agent inventorie les enceintes de la maison. Scénario : l'agent est déjà connecté au démon via l'endpoint ci-dessus, et vous voulez vérifier vite fait quelles pièces diffusent de la musique avant de sortir. À essayer : lire la ressource MCP sonos://zones. Résultat attendu : les informations des zones d'enceintes ; les champs et formats exacts ne figurent pas dans les preuves, la réponse réelle fait foi. Hors du réseau, n'importe quelle machine du tailnet permet à l'agent la même lecture — pratique pour les souvent absents ; sur la durée, cette lecture peut devenir le petit contrôle quotidien de routine.

Cas deux : sans passer par l'agent, piloter l'audio maison directement au terminal. Scénario : vous travaillez juste sur la machine qui fait tourner le démon. À essayer : le CLI fsonos, qui prend --json en charge partout. Résultat attendu : une sortie en JSON, facile à analyser en script et à brancher dans vos automatismes existants ; la liste exacte des sous-commandes n'est pas dans les preuves, aucun exemple inventé ici. Les scripts appellent le CLI, l'agent passe par MCP — les deux se combinent selon le contexte.

Limites d'usage

• Nature lecture/écriture : les appels de contrôle agissent réellement sur les enceintes. Les preuves ne donnent ni l'annotation lecture/écriture des outils MCP, ni leurs noms, ni leurs paramètres ; elles confirment seulement que le serveur embarque des outils plus les deux ressources sonos://zones et sonos://dj.
• Sur les enceintes elles-mêmes : la phrase officielle est « Nothing is installed on the speakers and nothing about them is changed » — rien n'est installé sur les enceintes et rien n'y est modifié ; mais cela ne rend pas les actions sans effets, et le contrôle de la lecture reste un vrai changement sur l'appareil. La lecture ou l'écriture de fichiers et données locales en dehors des enceintes n'est pas non plus documentée.
• Clients et entrées : la seule commande d'accrochage d'agent donnée officiellement est celle de claude ; le transport MCP accepte streamable HTTP ou stdio ; la connexion d'autres clients n'est pas documentée.
• Réseau et déploiement : le même LAN est un prérequis dur ; l'accès hors réseau dépend du tailnet, avec un endpoint de la forme https://<mac>.<tailnet>.ts.net:8443/mcp, où les placeholders sont à remplacer par votre propre domaine tailnet. L'authentification et les identifiants requis ne sont pas documentés.
• État de version : pré-version, pas de téléchargement officiel, les artefacts CI expirent avec le pipeline, la version officielle commencera à 0.1.0, et le chemin de mise à jour n'est pas documenté.
• À confirmer : noms et paramètres des outils MCP, mécanisme d'authentification, le fait que la lecture de ressources déclenche des actions sur les appareils, mécanisme d'annulation. Ces inconnues ne signifient pas l'absence de risque ; avant de laisser l'agent agir seul pour la première fois, limitez ses actions à la lecture, puis élargissez pas à pas.