🧹 Gladys allège son cœur : l'avenir des intégrations natives

[pierre-gilles]

Bonjour à tous !

Depuis l’arrivée des intégrations communautaires (installables en un clic depuis le catalogue, chacune isolée dans son propre conteneur), l’écosystème a littéralement explosé : plus de 900 intégrations sont aujourd’hui disponibles dans le store. Merci à tous les développeurs qui les publient

Ça change la donne pour le cœur de Gladys. Une intégration native, c’est du code qu’il faut maintenir, tester et livrer avec chaque version de Gladys, même quand l’API d’un fabricant change du jour au lendemain. Une intégration communautaire, elle, évolue à son rythme et se met à jour sans attendre une version de Gladys. Et si elle plante, Gladys continue de tourner.

L’objectif : sortir du cœur tout ce qui peut l’être, pour ne garder que ce qui est vraiment interne à Gladys ou vraiment indispensable. Voici l’inventaire complet des intégrations natives et ce qu’elles vont devenir.

Ce qui reste dans le cœur

Intégration	Pourquoi elle reste
Matter	Le standard de la maison connectée, un socle de Gladys
Zigbee2mqtt	Le protocole le plus utilisé par la communauté
MQTT	La brique de base du DIY : appareils MQTT, déclencheurs et actions de scène MQTT
Suivi de l’énergie, Thermostat	Ce sont des fonctionnalités de Gladys, pas des intégrations de marque
MCP	Le serveur qui permet à vos assistants IA de piloter Gladys
Amazon Alexa, Google Home, Enedis, OwnTracks, Intelligence Artificielle	Services liés à Gladys Plus
Apple HomeKit	Expose vos appareils Gladys dans l’app Maison d’Apple, comme Alexa et Google Home

Intégrations dépréciées : un remplaçant communautaire existe déjà

Ces intégrations natives portent déjà le badge « Bientôt dépréciée » et seront supprimées dans une prochaine version de Gladys

Je pense qu’il va falloir bientôt communiquer sur leur suppression d’ailleurs !

Leur remplaçant est disponible dans le catalogue :

Intégration native	Remplaçant communautaire
Philips Hue	Philips Hue
TP-Link	TP-Link Kasa (et Tapo pour la gamme Tapo)
Tuya	Tuya
Netatmo	Netatmo
MELCloud	MELCloud (et MELCloud Home pour les comptes MELCloud Home)
Sonos	Sonos
Z-Wave JS UI	Z-Wave JS UI
Telegram	Telegram
Nextcloud Talk	Nextcloud Talk
Free Mobile	Free Mobile SMS
OpenWeather	OpenWeather, ou Open-Meteo / Météo France

Comment migrer sans rien perdre ?

1. Installez l’intégration communautaire depuis le catalogue, configurez-la et créez vos appareils.
2. Sur la page de l’ancienne intégration, cliquez sur Migrer sur chaque appareil et choisissez son équivalent. Gladys déplace l’historique, met à jour vos scènes et vos tableaux de bord, puis supprime l’ancien appareil.

Pour la messagerie (Telegram, Nextcloud Talk, Free Mobile) et la météo, il n’y a pas d’appareil à migrer : installez la nouvelle intégration, puis remplacez dans vos scènes les actions qui utilisaient l’ancienne (par exemple « Envoyer un SMS » devient « Envoyer un message » sur le canal Free Mobile SMS).

Prochaines dépréciations : remplaçant disponible, retours bienvenus

Ces intégrations ont déjà un équivalent communautaire. Avant de les déprécier officiellement, on veut s’assurer que rien ne manque : si vous les utilisez, testez le remplaçant et dites-nous ce qui coince.

Intégration native	Remplaçant communautaire	À savoir
CallMeBot	CallMeBot	Intégration officielle
eWeLink	Sonoff / eWeLink	La version native ne fonctionne plus depuis le changement d’API eWeLink de 2023
Broadlink	Broadlink	Télécommandes RM (IR/RF), prises SP, multiprises MP1, capteurs A1
Tasmota	Tasmota	En MQTT ou en HTTP
Xiaomi Home (passerelles Xiaomi/Aqara)	Zigbee2mqtt ou Matter pour les capteurs Aqara, Xiaomi MIoT pour les appareils Wi-Fi	La version native repose sur le mode développeur des anciennes passerelles, qui n’existe plus
EcoWatt	RTE éCO2mix, EcoWatt & EcoGaz	Demande une clé gratuite du portail de données RTE

À sortir du cœur : on cherche des volontaires !

Ces intégrations n’ont pas encore d’équivalent communautaire. Le template officiel et le SDK sont là pour vous aider à vous lancer. Signalez-vous dans ce sujet pour éviter que deux personnes portent la même !

Portables dès aujourd’hui :

Intégration	À savoir
CalDAV	Le type « Calendrier » existe déjà. ICS Calendars couvre les agendas publiés en .ics, il manque la synchronisation CalDAV avec identifiants (Nextcloud, iCloud…)
Nuki	Serrures en MQTT local et via l’API web Nuki
Google Cast	Découverte mDNS fournie par Gladys, annonces vocales sur les enceintes
Airplay	Même principe que Google Cast
Node-RED	Lancement du conteneur Node-RED avec son interface accessible sur le réseau local
EDF Tempo	Calendrier Tempo EDF existe déjà : il lui manque d’alimenter le calendrier tarifaire « tempo » utilisé par les contrats d’énergie

D’abord une évolution des intégrations communautaires :

Intégration	Ce qui manque	En attendant
Présence Bluetooth	L’accès à l’adaptateur Bluetooth depuis une intégration	Rien ne change, l’intégration native reste en place
LAN Manager	Un scan du réseau local fourni par Gladys	La présence via votre box ou votre routeur existe déjà : UniFi, OpenWrt, NetAlertX, Livebox, ASUS, NETGEAR…
Caméras (RTSP)	Le streaming vidéo en direct (les intégrations communautaires envoient des images, pas encore de flux en direct)	go2rtc, ONVIF et Frigate existent déjà pour les images
Matterbridge	Maintenant que les intégrations externe Gladys existent, je trouve que Matterbridge ne sert plus trop, à voir si on ne veut pas déprécier cette intégration

À vous la parole

• Une intégration communautaire n’offre pas tout ce que faisait la version native ? Dites-le, c’est exactement ce qu’on veut savoir avant de supprimer quoi que ce soit.
• Vous voulez porter une intégration de la liste « À sortir du cœur » ? Signalez-vous dans ce sujet !

Merci à tous

[Prof_Techno]

Pour la partie que j’ai pu tester, le LAN Manager, qui permet de détecter les appareils connectés au réseau, est facilement remplaçable par l’intégration SFR. Donc, à voir pour les autres intégrations, selon les possibilités de chacune.

[mutmut]

Tout me semble très cohérent.
Je dirais que supprimer matterbridge est un peu too much, je le passerai en intégration externe pour ceux qui ont encore des choses dessus, et ceux qui ne veulent que du Matter au lieu d’intégrations externes.
Il faut prendre le même raisonnement que pour node-red à mon avis.

[pierre-gilles]

@ProtZ tu pourrais migrer Nuki en intégration externe ? Si tu n’as pas de license Claude, on peut s’en occuper , mais je préfère te demander si tu veux rester maintainer de cette intégration !

[GBoulvin]

Tasmota à été testé et éprouvé

[mutmut]

@Prof_Techno

LAN Manager, qui permet de détecter les appareils connectés au réseau, est facilement remplaçable par l’intégration SFR

Que se passe-t-il quand tu passes chez free ?
A mon avis il y a obligation de tout refaire : scènes, dashboard, etc.

Est-il possible d’avoir une intégration externe LAN Manager qui permet de choisir ensuite les appareils issus des intégrations SFR, Unifi, Orange, etc. ?
Ca permettrait d’avoir une couche médiane qui serait utilisée dans les scènes, etc., et qui ne dépendrait pas d’une box particulière.

[GBoulvin]

Je veux bien m’occuper des intégrations à migrer (et les maintenir) mais je ne dispose pas nécessairement du matos pour tester.
Pour Google cast j’ai un chromecast et pour Airplay, un iPad (aucune idée de si cela peut suffire).
Je peux migrer Node-RED (testable) et CalDAV (si c’est pas trop technique).

Nuki et EDF Tempo ne seront pas testables de mon côté.

SI c’est OK, je m’y lance de suite !

[pierre-gilles]

Pour caldav vois juste avec @bertrandda mais le reste vas y, premier arrivé premier servi !

[GBoulvin]

Voilà, Airplay et Google Cast sont live. Node-RED est en cours.

J’attends les réponses de @bertrandda (CalDAV) et de @ProtZ (NUKI) avant de lancer Claude dessus

[GBoulvin]

A voir si ces limites sont acceptables, surtout pour Node-RED :
Pour Node-RED :

• Pas d’accès USB/série ni de diffusion réseau (mDNS, découverte UDP) depuis les flux : Gladys ne donne pas d’accès privilégié aux sous-conteneurs.
• Adresse MQTT à changer : localhost désigne Node-RED lui-même. Les nœuds MQTT doivent viser l’adresse IP de la machine Gladys.
• Migration manuelle : les flux s’exportent depuis l’ancien éditeur et s’importent dans le nouveau, puis il faut ressaisir les mots de passe des nœuds de configuration.
• Une seule version (Node-RED 5) au lieu du choix entre 3, 4 et 5.

Pour Airplay :

1. Licence AGPL-3.0 : la bibliothèque AirPlay (@lox-audioserver/node-airplay-sender, celle qu’utilise le service intégré) est sous AGPL-3.0 et elle est incluse dans l’image Docker. J’ai donc mis le projet sous AGPL-3.0-or-later au lieu de l’Apache-2.0 du template. Dites-moi si vous voulez une autre approche.
2. Volume de « Jouer une notification » ignoré : Gladys ne transmet pas ce volume aux intégrations externes, seulement l’URL de la voix. La notification est donc jouée au volume de l’enceinte. Pour la régler dans une scène, il faut d’abord une action « Contrôler un appareil ». .
3. Risque réseau Docker : certaines enceintes AirPlay 2 doivent recontacter l’émetteur pour se synchroniser, ce qui peut échouer derrière le réseau Docker. Une enceinte pourrait alors être trouvée mais rester muette. Le contournement prévu est de forcer « AirPlay 1 (RAOP) » dans la configuration. C’est le point à vérifier en priorité sur du vrai matériel.

Google Cast : Volume des annonces : Gladys ne transmet pas le volume de l’action « Jouer une notification » aux intégrations externes. Il se règle donc dans la configuration de l’intégration, et le volume d’origine est remis après l’annonce.

[bertrandda]

@GBoulvin

J’attends les réponses de @bertrandda (CalDAV) et de @ProtZ (NUKI) avant de lancer Claude dessus

Salut @GBoulvin, Pierre-Gilles m’en avait parlé ce matin en privé et j’avais lancé un plan Claude dans la foulée pour CalDAV. Si ça te va aussi je lance l’implémentation pour m’occuper de cette intégration.

@GBoulvin

Pour Airplay :

1. Licence AGPL-3.0 : la bibliothèque AirPlay (@lox-audioserver/node-airplay-sender, celle qu’utilise le service intégré) est sous AGPL-3.0 et elle est incluse dans l’image Docker. J’ai donc mis le projet sous AGPL-3.0-or-later au lieu de l’Apache-2.0 du template. Dites-moi si vous voulez une autre approche.

Je ne sais pas si tu as vu la lib @lox-audioserver/node-airplay-sender est archivé sur Github, ils ont fusionné avec Sonn audio et la nouvelle lib maintenue est @sonn-audio/node-airplay. Ça vaudrait peut être le coup d’utiliser celle là, qu’en penses tu ?

[GBoulvin]

@bertrandda

la nouvelle lib maintenue est @sonn-audio/node-airplay. Ça vaudrait peut être le coup d’utiliser celle là, qu’en penses tu ?

J’ai posé ta question à Claude et la réponse est mitigée :

"Oui, je pense qu’il faut passer à @sonn-audio/node-airplay. Mais en l’examinant, j’ai trouvé un problème plus important que le choix de la bibliothèque : il touche les HomePod quelle que soit la bibliothèque utilisée.

Pourquoi changer

• Maintenance : @lox-audioserver/node-airplay-sender est archivée, alors que la nouvelle a été publiée fin août et que la 0.1.2 date du 22 septembre.
• Licence : la nouvelle est sous Apache-2.0, comme le template, et n’a aucune dépendance. L’intégration pourrait donc quitter l’AGPL que je lui avais imposée à cause de l’ancienne.
• Qualité : l’auteur dit l’avoir testée sur un HomePod (OS 27) et un BeoLab 50. Elle gère vraiment AirPlay 2, en choisissant automatiquement la méthode de synchronisation que l’enceinte accepte (PTP ou NTP). Elle gère aussi l’échange d’authentification de certains vieux récepteurs AirPlay 1 qui refusent la connexion sans lui.
• Un argument fort : son README indique que les HomePod et Apple TV récents (OS 27) acceptent une session AirPlay 1 mais restent muets. L’ancienne bibliothèque ne faisait qu’un AirPlay 2 « best-effort ». Sur un HomePod récent, l’intégration actuelle risque donc de ne produire aucun son.

Ce que ça coûte

• La bibliothèque est jeune (0.1.x, un seul auteur).
• Son interface est bas niveau : connexion, synchronisation, paquets audio. Il faudrait réécrire la logique de lecture, soit environ 250 lignes dans src/player.jsCette session n’est pas en cours d’exécution, ses fichiers ne peuvent donc pas être ouverts. Envoyez un message pour la relancer..
• Ce fichier est isolé du reste : la découverte, les scènes, le widget et les tests de l’application ne changent pas. Il faudrait seulement conserver en plus le champ et des enregistrements mDNS.

Le problème de fond, que la bibliothèque ne règle pas

J’ai vérifié dans le code de Gladys comment il crée le conteneur d’une intégration. Il est sur un réseau Docker en mode bridge, avec toutes les capacités Linux retirées. Aucun mode réseau host n’est possible, ni pour le conteneur principal ni pour un sous-conteneur, et les ports exposés sont attribués au hasard.

• Pour les HomePod / Apple TV (PTP) : l’émetteur doit servir l’horloge sur les ports UDP 319/320, et l’enceinte vient l’interroger à l’adresse que l’émetteur lui donne. Cette adresse serait l’IP interne du conteneur (172.x), injoignable depuis le réseau local. Ces appareils resteraient donc probablement muets.
• Pour les enceintes tierces en NTP et les récepteurs AirPlay 1 : c’est plus favorable, mais rien ne le garantit, car l’enceinte doit aussi recontacter l’émetteur.

Je l’avais signalé comme une limite ; c’est en réalité potentiellement bloquant pour les HomePod. La vraie solution serait que Gladys propose une option réseau pour ce type d’intégration. Ça vaudrait la peine de l’aborder avec les mainteneurs de Gladys."

Peut-être garder cette solution sous le coude et attendre qu’elle mature un peu ?

Et en réalité, je n’ai pas encore eu l’occasion de tester mais ça n’est peut-être pas encore possible de passer en intégration externe en l’état

[bertrandda]

@GBoulvin

Peut-être garder cette solution sous le coude et attendre qu’elle mature un peu ?

Oui j’avais vu la lib pour « l’ancienne » intégration interne mais tu as peut être raison, on peut la surveiller pour l’utiliser plus tard, en général c’est toujours mieux d’avoir une lib maintenue qu’une vieille lib abandonnée.

@GBoulvin

Et en réalité, je n’ai pas encore eu l’occasion de tester mais ça n’est peut-être pas encore possible de passer en intégration externe en l’état

Au vu de la dernière phrase que tu as mis de ton Claude oui en effet j’ai pas l’impression que ce soit possible. Je vais essayer de tester rapidement, et je te dis si ça fonctionne

[bertrandda]

@GBoulvin ça ne semble pas marcher, je te ferrai plus de tests dimanche avec un véritable Homepod

[2026-10-29T21:40:02.135Z] [INFO] [app] Action test_speaker <- ext:ext-gboulvin-gladys-airplay:speaker:faee67b415d7
[2026-10-29T21:40:02.160Z] [INFO] [player] Playing on Speaker (172.16.8.255:7000, AirPlay 2)
/app/node_modules/bplist-parser/bplistParser.js:64
    throw new Error("Invalid binary plist. Expected 'bplist' at offset 0.");
    ^

Error: Invalid binary plist. Expected 'bplist' at offset 0.
    at exports.parseBuffer (/app/node_modules/bplist-parser/bplistParser.js:64:11)
    at Client.processData (/app/node_modules/@lox-audioserver/node-airplay-sender/dist/core/rtsp.js:1501:43)
    at Socket.<anonymous> (/app/node_modules/@lox-audioserver/node-airplay-sender/dist/core/rtsp.js:211:18)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:569:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:520:3)
    at Readable.push (node:internal/streams/readable:400:5)
    at TCP.onStreamRead (node:internal/stream_base_commons:194:23)