Ejemplo: Migración de Philips Hue
Lo probé en casa con Melcloud, ¡y funciona perfectamente! Lo fusiono.
¡Hola!
Al final me he pasado a HA precisamente por eso 
Con la última newsletter, me doy cuenta de que has dado marcha atrás para volver al principio de la V3, lo cual no me disgusta 
Voy a seguirlo un poco más de cerca para ver cómo evoluciona y seguramente montar una instancia ahora.
¡Buen trabajo en cualquier caso!
¡Gracias @MathieuA, me alegra mucho leerlo, y sobre todo me alegra verte de nuevo en el foro! 
En principio, sí. En cambio, técnicamente, la implementación ya no tiene mucho que ver con la de la V3. Esta vez, tenemos un aislamiento completo entre Gladys y cada integración, con un verdadero desacoplamiento. Las dependencias se instalan en el momento del build, y no más en tiempo de ejecución como era el caso en la V3.
Al final, recuperamos la simplicidad y la libertad de la V3, manteniendo una arquitectura mucho más robusta. En resumen, ¡lo mejor de ambos mundos!
¿Veremos también el regreso de @VonOx? 
¡Sería increíble!!
¡Me encantaría!!
¡Bienvenido de nuevo @MathieuA,
Al principio de Gladys V4, ¡te leí mucho! También en los archivos del diseño de Gladys V4 con tus intercambios, a vosotros, los « viejos » de Gladys!!
Es un placer ver mentes como la tuya (y espero que otras) pasar de nuevo por aquí.
Hola super nueva 
Lo mejor de ambos mundos v3 v4 
Solo problema :
2026-08-01T22:49:50+0200 <warn> errorMiddleware.js:71 (errorMiddleware) Error: (código HTTP 400) inesperado - NanoCPUs no se puede establecer, ya que su kernel no admite el planificador de CPU CFS o el cgroup no está montado
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 no se puede establecer, ya que su kernel no admite el planificador de CPU CFS o el cgroup no está montado'
}
}
Estoy en un nas synology 920+
Un repaso al directorio /data de las imágenes Docker de las extensiones externas:
El VOLUME [« /data »] deja el directorio como root, mientras que el contenedor se ejecuta como node (uid 1000): la integración no tenía acceso de escritura al único lugar que el Dockerfile documenta como escribible.
Claude añade líneas en el Dockerfile para solucionar este problema. ¿Podemos corregirlo en la plantilla?
He encontrado la causa del problema: en los NAS Synology, el núcleo se compila sin el
« CFS bandwidth control », que es el mecanismo que permite a Docker limitar el CPU de un
contenedor. Por lo tanto, cuando Gladys pedía a Docker que creara el contenedor de
la integración con un límite de CPU, Docker se negaba con el error « NanoCPUs can not be set »
y la instalación fallaba.
La corrección: Gladys ahora pregunta a Docker si sabe gestionar los límites de CPU al
iniciar, y si no es así, simplemente no envía este límite.
Los otros límites (memoria, número de procesos, tamaño de los logs) siguen en su lugar
en todos los casos. En tu NAS, las integraciones funcionarán sin límite de CPU,
es el contorno estándar para este tipo de núcleo.
Muy lamentable para los usuarios de Synology, que estarán un poco menos protegidos que los demás, pero bueno, es así
Hola, gracias por el comentario, ¡era un error real! 
Buena noticia: la causa no estaba en tu imagen, sino en Gladys. El /data se monta en bind mount desde el host, y como la carpeta no existía antes de la creación del contenedor, Docker la creaba él mismo en root:root, por lo que la integración (que se ejecuta en node, uid 1000) no podía escribir nada allí. Por eso los contornos en el Dockerfile no podían funcionar: un bind mount enmascara completamente el contenido de la imagen, por lo que un chown hecho en la construcción no tiene ningún efecto.
La corrección está en esta PR: Fix /data ownership of external integration containers by Pierre-Gilles · Pull Request #2743 · GladysAssistant/Gladys · GitHub. Gladys ahora crea la carpeta y la asigna al uid 1000 antes de crear el contenedor (incluidos los volúmenes de los subcontenedores para las integraciones multi-contenedores). Y es retrocompatible: las instalaciones existentes se reparan solas en la próxima recreación del contenedor (actualización, reinicio…), sin tocar nada.
Tan pronto como se publique, podrás eliminar las líneas de contorno de tu Dockerfile: la plantilla oficial documenta /data como el único lugar escribible, y será cierto sin trucos. 
Pues yo lo encuentro simplemente genial 
Para el Syno, se puede poner una prioridad en los contenedores y es interesante lo de los subcontenedores que no se pueden limitar en CPU.
Debería probarlo en ZimaOS para ver si el comportamiento es idéntico.
¡Gracias por tu respuesta! 
¡Las dos devoluciones se han fusionado en master y partirán hoy en otro parche de lanzamiento! ¡Gracias por sus pruebas y sus comentarios!
Las correcciones están en vivo en Gladys Assistant 4.84.2:
¡Excelente noticia! Estoy en Home Assistant precisamente porque uso muchos productos que no son (o no eran) reconocidos en Gladys, pero sigo a Gladys porque el proyecto me gusta mucho. Por eso lo miro regularmente (tengo Gladys en prueba en una Raspberry como complemento a mi HA) y tuve la agradable sorpresa de que Airzone cloud es reconocido.
Pero no entiendo: tengo un Airzone con 5 habitaciones y un TADO que me permite controlar una clim Hitachi separada (no Airzone).
Cuando hice la integración en Gladys, encontró todo. Sin embargo, solo me muestra la temperatura de mi veranda (clim TADO) y mi salón (habitación donde está mi zona principal Airzone). Encuentra mis otras 4 habitaciones Airzone pero me dice « no se ha registrado ninguna temperatura recientemente ». No sé muy bien dónde buscar.
Gracias por su ayuda si alguno de ustedes tiene un Airzone.
Una idea para mejorar el seguimiento de las aplicaciones externas: una categoría con subcategorías para cada aplicación externa integrada. Esto permitiría reportar errores y haría que fuera más legible, y cada desarrollador podría seguir su desarrollo sin tener que etiquetarlo y, por lo tanto, sin conocer quién desarrolló la aplicación externa.
De lo contrario, habría que pasar a un seguimiento de errores que pueda estar vinculado a GitHub.
ex: un proyecto sería una aplicación externa y cada desarrollador sería notificado tan pronto como alguien informe un error en su proyecto. Un mini ciclo de vida común de un error a una aplicación externa debería crearse. Aunque sea un seguimiento de errores, también se podría permitir presentar solicitudes de mejora.
El foro aquí sería más para el núcleo de Gladys o para solicitudes de desarrollo de aplicaciones externas.
Ya está hecho. No sé si lo he hecho bien (especialmente en cuanto a la etiqueta). No dudes en decírmelo si he metido la pata 
Me parece un poco pesado, lo admito, y en sí es el mismo problema que actualmente, ¿cómo saber qué cuenta del foro corresponde a la cuenta de Github?
¡Ya es posible desde ahora! Es posible crear un problema en el repositorio de la integración externa, y al menos el mantenedor recibe una notificación a través de Github. Es cierto que puede ser la forma más sencilla de comunicarse directamente con el mantenedor, pero requiere tener una cuenta de Github.
¡Perfecto, gracias @filbou40!
Bien visto @mutmut, no es intencional 
Las etiquetas de las tarjetas del catálogo (Local, Cloud, Gladys Plus…) se colocan a partir
de la información de cada integración, y para las integraciones externas solo muestro
hoy « Comunidad », el distintivo de estado y « actualización disponible ».
Lo más tonto es que la información ya existe: el manifiesto de una integración externa
declara obligatoriamente sus transports (local, cloud, o ambos), lo que se usa para
la configuración « preferir conexión local » y los distintivos Local/Cloud en cada
aplicación. Simplemente no lo uso aún en la tarjeta del catálogo.
¡Lo reviso!