Exemple : Migration Philips Hue
Testé chez moi avec Melcloud, et ça marche nickel ! Je merge
Hello !
J’ai fini par passer sur HA pour ma part justement à cause de ça 
Avec la dernière newsletter, je m’aperçois que tu as fait marche arrière pour revenir au principe de la V3, ce qui ne me déplaît pas 
Je vais suivre ça d’un peu plus près pour voir comment ça évolue et sûrement me remonter une instance maintenant.
Beau boulot en tout cas !
Merci @MathieuA, ça fait vraiment plaisir à lire, et surtout content de te revoir sur le forum ! 
Sur le principe, oui. En revanche, techniquement, l’implémentation n’a plus grand-chose à voir avec celle de la V3. Cette fois, on a une isolation complète entre Gladys et chaque intégration, avec un vrai découplage. Les dépendances sont installées au moment du build, et non plus au runtime comme c’était le cas en V3.
Au final, on récupère la simplicité et la liberté de la V3, tout en conservant une architecture beaucoup plus robuste. Bref, le meilleur des deux mondes !
Est-ce qu’on verra le retour de @VonOx également ? 
Ça serait dingue !!
J’adorerais !!
Un bon retour à toi @MathieuA,
Au début de Gladys V4, je t’ai énormément lu ! Egalement dans les archives de la conception de Gladys V4 avec vos échanges, à vous, les « anciens » de Gladys !!
C’est un plaisir de voir des esprits comme toi (et j’espère d’autres) passer de nouveau par ici.
Hello super nouvelle 
Le meilleur des deux mondes v3 v4 
Seul soucis :
2026-08-01T22:49:50+0200 <warn> errorMiddleware.js:71 (errorMiddleware) Error: (HTTP code 400) unexpected - NanoCPUs can not be set, as your kernel does not support CPU CFS scheduler or the cgroup is not mounted
at /src/server/node_modules/docker-modem/lib/modem.js:336:17
at getCause (/src/server/node_modules/docker-modem/lib/modem.js:366:7)
at Modem.buildPayload (/src/server/node_modules/docker-modem/lib/modem.js:335:5)
at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:303:16)
at IncomingMessage.emit (node:events:531:35)
at endReadableNT (node:internal/streams/readable:1698:12)
at processTicksAndRejections (node:internal/process/task_queues:89:21) {
reason: undefined,
statusCode: 400,
json: {
message: 'NanoCPUs can not be set, as your kernel does not support CPU CFS scheduler or the cgroup is not mounted'
}
}
Je suis sur nas synology 920+
Un retour sur le dossier /data des images Docker des extensions externes :
Le VOLUME [« /data »] laisse le répertoire à root, alors que le conteneur tourne en node (uid 1000) : l’intégration n’avait pas accès en écriture au seul emplacement que le Dockerfile documente comme inscriptible.
Claude ajoute des lignes dans le Dockerfile pour contourner ce problème. Est-ce qu’on peut le corriger dans le template ?
J’ai trouvé l’origine du problème : sur les NAS Synology, le noyau est compilé sans le
« CFS bandwidth control », c’est le mécanisme qui permet à Docker de limiter le CPU d’un
conteneur. Du coup, quand Gladys demandait à Docker de créer le conteneur de
l’intégration avec une limite CPU, Docker refusait avec l’erreur « NanoCPUs can not be set »
et l’installation échouait.
Le correctif : Gladys demande maintenant à Docker s’il sait gérer les limites CPU au
démarrage, et si ce n’est pas le cas, elle n’envoie tout simplement pas cette limite.
Les autres limites (mémoire, nombre de processus, taille des logs) restent en place
dans tous les cas. Sur ton NAS, les intégrations tourneront donc sans plafond CPU,
c’est le contournement standard pour ce type de noyau.
Très dommage du coup pour les utilisateurs de Synology qui seront un peu moins protégé que les autres, mais bon c’est comme ça
Salut, merci pour le retour, c’était un vrai bug ! 
Bonne nouvelle : la cause n’était pas dans ton image, mais côté Gladys. Le /data est monté en bind mount depuis l’hôte, et comme le dossier n’existait pas avant la création du conteneur, Docker le créait lui-même en root:root, du coup l’intégration (qui tourne en node, uid 1000) ne pouvait rien y écrire. C’est aussi pour ça que les contournements dans le Dockerfile ne pouvaient pas fonctionner : un bind mount masque complètement le contenu de l’image, donc un chown fait au build n’a aucun effet.
Le correctif est dans cette PR : Fix /data ownership of external integration containers by Pierre-Gilles · Pull Request #2743 · GladysAssistant/Gladys · GitHub. Gladys crée maintenant le dossier et le donne à l’uid 1000 avant de créer le conteneur (y compris les volumes des sous-conteneurs pour les intégrations multi-conteneurs). Et c’est rétrocompatible : les installations existantes se réparent toutes seules à la prochaine recréation du conteneur (mise à jour, restart…), sans rien toucher.
Dès que c’est publié, tu pourras supprimer les lignes de contournement de ton Dockerfile : le template officiel documente /data comme seul emplacement inscriptible, et ce sera vrai sans bricolage. 
Alors je trouve ça tout simplement génial 
Pour le syno, on peut mettre une priorité sur les containers et c’est intéressant cette histoire de sous-containers que l’on ne peut pas limiter en cpu.
Il faudrait que je teste sur zimaOS pour voir si le comportement est identique.
Merci de ton retour ! 
Les deux retours sont mergés sur master et partiront aujourd’hui dans une autre release patch ! Merci de vos tests et de vos retours !
Les correctifs sont live sur Gladys Assistant 4.84.2 :
Super bonne nouvelle. Je suis sur Home Assistant justement car j’utilise pas mal de produits qui ne sont pas (ou n’étaient pas) reconnus sous Gladys mais je suis Gladys car le projet me plait beaucoup. Je regarde donc régulièrement (j’ai Gladys en test sur un Rasp en complément du mon HA) et j’ai eu l’agréable découverte que Airzone cloud était reconnu.
Par contre, je ne comprends pas : j’ai un airzone avec 5 pièces et un TADO qui me permet de contrôler une clim hitachi séparée (non airzone).
Quand j’ai fait l’intégration dans Gladys, il m’a tout trouvé. Par contre, il ne me remonte la température que de ma veranda (clim TADO) et mon salon (pièce où est ma zone principale Airzone. Il me trouve mes 4 autres pièces Airzone mais me dit « aucune température enregistrée récemment ». Je ne sais pas trop où chercher.
Merci de votre aide si certains d’entre vous ont un airzone.
Salut @filbou40, content de te voir sur Gladys !
Est-ce que tu peux créer un sujet spécifique pour Airzone dans Configuration, et tag @Lokkye qui est le développeur de cette intégration 
Une idée pour améliorer le suivi des appli externe: une catégorie où il y au des sous catégories pour chaque appli externe intégré. çà permettrait de faire les remontés de bugs et rendrait plus lisible et chaque dev pourrait suivre son dev sans pour autant que l’on soit obligé de le tagguer et donc de connaître qui a développé l’appli externe
sinon il faudrait passer à un bugtracker qui peut être lié à github.
ex: un projet serait une appli externe et chaque dev serait donc informé dès que quelqu’un émet un bug dans son projet. Un mini cycle de vie commun d’un bug à une appli externe serait à faire. Même si c’est bug tracker on peut aussi permettre de déposer des demandes d’amélioration.
Le forum ici serait plus pour le core gladys ou des demandes de dev d’appli externe
C’est fait. Je ne sais pas si j’ai fait correctement (notamment au niveau du Tag). N’hésites pas à me dire si j’ai merdouillé
Ça me parait un peu lourd j’avoue, et en soit c’est le même souci qu’actuellement, comment savoir quel compte sur le forum correspond au compte sur Github ?
C’est déjà possible dès maintenant, il est possible de créer une issue sur le repo de l’intégration externe, et au moins le mainteneur reçoit une notification via Github ! C’est vrai que c’est peut-être la façon la plus simple de communiquer directement avec le mainteneur, mais ça demande d’avoir un compte Github
C’est parfait, merci @filbou40 !
Bien vu @mutmut, ce n’est pas voulu 
Les tags des cartes du catalogue (Local, Cloud, Gladys Plus…) sont posés à partir
des infos de chaque intégration, et pour les intégrations externes je ne remonte
aujourd’hui que « Communauté », le badge de statut et « mise à jour disponible ».
Le plus bête, c’est que l’info existe déjà : le manifeste d’une intégration externe
déclare obligatoirement ses transports (local, cloud, ou les deux), c’est ce
qui sert au réglage « préférer la connexion locale » et aux badges Local/Cloud sur
chaque appareil. Je m’en sers juste pas encore sur la carte du catalogue.
Je regarde !