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 :