🧹 Gladys aligera su corazón: el futuro de las integraciones nativas

¡Hola a todos!

Desde la llegada de las integraciones comunitarias (instalables con un clic desde el catálogo, cada una aislada en su propio contenedor), el ecosistema ha explotado literalmente: más de 900 integraciones están disponibles en la tienda. ¡Gracias a todos los desarrolladores que las publican! :folded_hands:

Esto cambia las cosas para el núcleo de Gladys. Una integración nativa es código que hay que mantener, probar y entregar con cada versión de Gladys, incluso cuando la API de un fabricante cambia de la noche a la mañana. Una integración comunitaria, en cambio, evoluciona a su propio ritmo y se actualiza sin esperar una versión de Gladys. Y si falla, Gladys sigue funcionando.

El objetivo: sacar del núcleo todo lo que se pueda, para mantener solo lo que es realmente interno de Gladys o realmente indispensable. Aquí está el inventario completo de las integraciones nativas y lo que les va a pasar.

:white_check_mark: Lo que se queda en el núcleo

Integración Por qué se queda
Matter El estándar de la casa conectada, un pilar de Gladys
Zigbee2mqtt El protocolo más utilizado por la comunidad
MQTT El bloque básico del DIY: dispositivos MQTT, desencadenantes y acciones de escena MQTT
Seguimiento de energía, Termostato Son funcionalidades de Gladys, no integraciones de marca
MCP El servidor que permite a tus asistentes de IA controlar Gladys
Amazon Alexa, Google Home, Enedis, OwnTracks, Inteligencia Artificial Servicios relacionados con Gladys Plus
Apple HomeKit Expone tus dispositivos Gladys en la app Casa de Apple, como Alexa y Google Home

:warning: Integraciones obsoletas: ya existe un reemplazo comunitario

Estas integraciones nativas ya tienen la etiqueta « Próximamente obsoleta » y serán eliminadas en una próxima versión de Gladys

¡Creo que pronto habrá que comunicar su eliminación!

Su reemplazo está disponible en el catálogo:

Integración nativa Reemplazo comunitario
Philips Hue Philips Hue
TP-Link TP-Link Kasa (y Tapo para la gama Tapo)
Tuya Tuya
Netatmo Netatmo
MELCloud MELCloud (y MELCloud Home para las cuentas 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, o Open-Meteo / Météo France

¿Cómo migrar sin perder nada?

  1. Instala la integración comunitaria desde el catálogo, configúrala y crea tus dispositivos.
  2. En la página de la antigua integración, haz clic en Migrar en cada dispositivo y elige su equivalente. Gladys mueve el historial, actualiza tus escenas y tus paneles de control, y luego elimina el dispositivo antiguo.

Para la mensajería (Telegram, Nextcloud Talk, Free Mobile) y el clima, no hay dispositivos que migrar: instala la nueva integración y luego reemplaza en tus escenas las acciones que usaban la antigua (por ejemplo, « Enviar un SMS » se convierte en « Enviar un mensaje » en el canal Free Mobile SMS).

:soon_arrow: Próximas obsolescencias: reemplazo disponible, se aceptan comentarios

Estas integraciones ya tienen un equivalente comunitario. Antes de declararlas oficialmente obsoletas, queremos asegurarnos de que no falte nada: si las usas, prueba el reemplazo y dínos qué falla.

Integración nativa Sustituto comunitario Para saber
CallMeBot CallMeBot Integración oficial
eWeLink Sonoff / eWeLink La versión nativa ya no funciona desde el cambio de API de eWeLink de 2023
Broadlink Broadlink Mandos a distancia RM (IR/RF), enchufes SP, regletas MP1, sensores A1
Tasmota Tasmota En MQTT o en HTTP
Xiaomi Home (puertas de enlace Xiaomi/Aqara) Zigbee2mqtt o Matter para los sensores Aqara, Xiaomi MIoT para los dispositivos Wi-Fi La versión nativa se basa en el modo desarrollador de los antiguos puentes de enlace, que ya no existe
EcoWatt RTE éCO2mix, EcoWatt & EcoGaz Requiere una clave gratuita del portal de datos de RTE

:person_raising_hand: Para sacar del núcleo: ¡buscamos voluntarios!

Estas integraciones aún no tienen un equivalente comunitario. La plantilla oficial y el SDK están ahí para ayudarte a empezar. ¡Anúnciate en este tema para evitar que dos personas lleven lo mismo!

Listos para hoy:

Integración Para saber
CalDAV El tipo « Calendario » ya existe. ICS Calendars cubre los calendarios publicados en .ics, falta la sincronización CalDAV con credenciales (Nextcloud, iCloud…)
Nuki Cerraduras en MQTT local y a través de la API web de Nuki
Google Cast Descubrimiento mDNS proporcionado por Gladys, anuncios de voz en los altavoces
Airplay Mismo principio que Google Cast
Node-RED Lanzamiento del contenedor Node-RED con su interfaz accesible en la red local
EDF Tempo Calendario Tempo EDF ya existe: le falta alimentar el calendario tarifario « tempo » utilizado por los contratos de energía

Primero una evolución de las integraciones comunitarias:

Integración Lo que falta Mientras tanto
Presencia Bluetooth El acceso al adaptador Bluetooth desde una integración Nada cambia, la integración nativa sigue en su lugar
LAN Manager Un escaneo de la red local proporcionado por Gladys La presencia a través de tu box o tu router ya existe: UniFi, OpenWrt, NetAlertX, Livebox, ASUS, NETGEAR…
Cámaras (RTSP) El streaming de video en directo (las integraciones comunitarias envían imágenes, aún no hay flujo en directo) go2rtc, ONVIF y Frigate ya existen para las imágenes
Matterbridge Ahora que las integraciones externas de Gladys existen, creo que Matterbridge ya no sirve mucho, habrá que ver si no queremos depreciar esta integración

:speech_balloon: Tu turno

  • ¿Una integración comunitaria no ofrece todo lo que hacía la versión nativa? ¡Dilo, es exactamente lo que queremos saber antes de eliminar algo!
  • ¿Quieres llevar una integración de la lista « Para sacar del núcleo »? ¡Anúnciate en este tema!

¡Gracias a todos :rocket:!

De la parte que he podido probar, el Administrador de red (LAN Manager), que permite detectar los dispositivos conectados a la red, es fácilmente reemplazable por la integración de SFR. Por lo tanto, habrá que ver con las otras integraciones, según las posibilidades de cada una.

Todo me parece muy coherente.
Yo diría que eliminar matterbridge es un poco demasiado, lo pondré en integración externa para quienes aún tengan cosas allí, y para quienes solo quieran Matter en lugar de integraciones externas.
Creo que hay que seguir el mismo razonamiento que con node-red.

@ProtZ, ¿podrías migrar Nuki a integración externa? Si no tienes una licencia Claude, podemos encargarnos de ello :grin:, pero prefiero preguntarte si quieres seguir siendo el maintainer de esta integración.

Tasmota ha sido probado y comprobado :wink:

¿Qué pasa cuando te cambias a free?
En mi opinión, hay que volver a hacer todo: escenas, dashboard, etc.

¿Es posible tener una integración externa de LAN Manager que permita luego elegir los dispositivos de las integraciones de SFR, Unifi, Orange, etc.?
Esto permitiría tener una capa intermedia que se utilizaría en las escenas, etc., y que no dependería de un box en particular.

¡Me encantaría encargarme de las integraciones a migrar (y mantenerlas) pero no necesariamente dispongo del equipo para probarlas!
Para Google Cast tengo un Chromecast y para AirPlay, un iPad (no tengo ni idea de si eso será suficiente).
Puedo migrar Node-RED (probable) y CalDAV (si no es demasiado técnico).

Nuki y EDF Tempo no podré probarlos por mi parte.

¡Si está bien, me pongo con ello ahora mismo!

Para caldav habla solo con @bertrandda pero lo demás está bien, el primero en llegar es el primero en ser atendido.

¡Listo! Airplay y Google Cast están en línea. Node-RED está en progreso.

Estoy esperando las respuestas de @bertrandda (CalDAV) y de @ProtZ (NUKI) antes de lanzarlo sobre Claude :wink:

A ver si estos límites son aceptables, especialmente para Node-RED:
Para Node-RED:

  • Sin acceso USB/serie ni difusión de red (mDNS, descubrimiento UDP) desde los flujos: Gladys no da acceso privilegiado a los subcontenedores.
  • Cambiar la dirección MQTT: localhost designa a Node-RED mismo. Los nodos MQTT deben apuntar a la dirección IP de la máquina Gladys.
  • Migración manual: los flujos se exportan desde el antiguo editor e importan en el nuevo, luego hay que volver a ingresar las contraseñas de los nodos de configuración.
  • Una sola versión (Node-RED 5) en lugar de la elección entre 3, 4 y 5.

Para Airplay:

  1. Licencia AGPL-3.0: la biblioteca AirPlay (@lox-audioserver/node-airplay-sender, la que usa el servicio integrado) está bajo AGPL-3.0 y se incluye en la imagen Docker. Por lo tanto, he puesto el proyecto bajo AGPL-3.0-or-later en lugar de Apache-2.0 del template. Dime si quieres otro enfoque.
  2. Volumen de «Reproducir una notificación» ignorado: Gladys no transmite este volumen a las integraciones externas, solo la URL del audio. La notificación se reproduce entonces al volumen del altavoz. Para ajustarlo en una escena, primero hay que tener una acción «Controlar un dispositivo».
  3. Riesgo de red Docker: algunos altavoces AirPlay 2 deben volver a contactar al emisor para sincronizarse, lo que puede fallar detrás de la red Docker. Un altavoz podría entonces ser encontrado pero quedarse mudo. La solución prevista es forzar «AirPlay 1 (RAOP)» en la configuración. Es el punto a verificar en prioridad en el hardware real.

Google Cast: Volumen de los anuncios: Gladys no transmite el volumen de la acción «Reproducir una notificación» a las integraciones externas. Se ajusta entonces en la configuración de la integración, y el volumen original se restaura después del anuncio.

Hola @GBoulvin, Pierre-Gilles me había hablado de esto esta mañana en privado y había lanzado un plan Claude para CalDAV. Si te parece bien, también puedo lanzar la implementación para ocuparme de esta integración.

No sé si has visto que la lib @lox-audioserver/node-airplay-sender está archivada en Github, se han fusionado con Sonn audio y la nueva lib mantenida es @sonn-audio/node-airplay. Quizás valga la pena usar esta, ¿qué opinas?

Le hice tu pregunta a Claude y la respuesta es mixta:

"Sí, creo que hay que pasar a @sonn-audio/node-airplay. Pero al examinarla, encontré un problema más importante que la elección de la biblioteca: afecta a los HomePod, independientemente de la biblioteca utilizada.

¿Por qué cambiar?

  • Mantenimiento: @lox-audioserver/node-airplay-sender está archivada, mientras que la nueva se publicó a finales de agosto y la 0.1.2 es del 22 de septiembre.
  • Licencia: la nueva está bajo Apache-2.0, como el template, y no tiene dependencias. La integración podría, por tanto, salir de la AGPL que le había impuesto debido a la antigua.
  • Calidad: el autor dice haberla probado en un HomePod (OS 27) y un BeoLab 50. Realmente gestiona AirPlay 2, eligiendo automáticamente el método de sincronización que el altavoz acepta (PTP o NTP). También gestiona el intercambio de autenticación de algunos viejos receptores AirPlay 1 que rechazan la conexión sin él.
  • Un argumento fuerte: su README indica que los HomePod y Apple TV recientes (OS 27) aceptan una sesión AirPlay 1 pero se quedan mudos. La antigua biblioteca solo hacía un AirPlay 2 « best-effort ». En un HomePod reciente, la integración actual podría, por tanto, no producir ningún sonido.

Lo que cuesta

  • La biblioteca es joven (0.1.x, un solo autor).
  • Su interfaz es de bajo nivel: conexión, sincronización, paquetes de audio. Sería necesario reescribir la lógica de lectura, es decir, unas 250 líneas en src/player.js. Esta sesión no está en ejecución, por lo que sus archivos no pueden abrirse. Envíe un mensaje para reiniciarla.
  • Este archivo está aislado del resto: el descubrimiento, las escenas, el widget y las pruebas de la aplicación no cambian. Solo sería necesario conservar, además, el campo et de los registros mDNS.

El problema de fondo, que la biblioteca no resuelve

He verificado en el código de Gladys cómo crea el contenedor de una integración. Está en una red Docker en modo bridge, con todas las capacidades Linux retiradas. No es posible ningún modo de red host, ni para el contenedor principal ni para un subcontenedor, y los puertos expuestos se asignan aleatoriamente.

  • Para los HomePod / Apple TV (PTP): el emisor debe servir el reloj en los puertos UDP 319/320, y el altavoz viene a interrogarlo a la dirección que el emisor le da. Esta dirección sería la IP interna del contenedor (172.x), inalcanzable desde la red local. Estos dispositivos probablemente se quedarían, por tanto, mudos.
  • Para los altavoces de terceros en NTP y los receptores AirPlay 1: es más favorable, pero nada lo garantiza, ya que el altavoz también debe volver a contactar con el emisor.

Lo había señalado como un límite; en realidad, es potencialmente bloqueante para los HomePod. La verdadera solución sería que Gladys ofreciera una opción de red para este tipo de integración. Vale la pena abordarlo con los mantenedores de Gladys."

¿Quizás guardar esta solución bajo el brazo y esperar a que madure un poco?

Y en realidad, aún no he tenido la oportunidad de probarlo, pero quizá aún no sea posible pasar a integración externa en este estado

Sí, había visto la librería para la « antigua » integración interna, pero quizá tengas razón, podemos vigilarla para usarla más tarde. En general, siempre es mejor tener una librería mantenida que una vieja librería abandonada.

Dada la última frase que has puesto de tu Claude, sí, en efecto no me parece que sea posible. Voy a intentar probarlo rápidamente, y te digo si funciona.

@GBoulvin no parece funcionar, haré más pruebas el domingo con un verdadero 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)