La fábrica de plugins Matterbridge: haz que cualquier dispositivo sea compatible con Gladys

@mutmut Gracias por la respuesta.

En cuanto al nivel de batería de las persianas, el plugin Tahoma muestra:

como hay mucho sol en este momento, no sé si es fiable…

En cuanto al plugin Cosytouch, ¿se necesita un hub Cosytouch o solo una cuenta?

¿Se hace a través de la nube?

Las dos, mi capitán :sweat_smile:
Bueno, digo eso, pero no tengo Cosytouch, pero uso este plugin para Somfy con una box ConneXoon.
Intenté pasar a local sin éxito y no obtuve respuesta a mi solicitud en GitHub.

Voy a probar este nuevo plugin entonces.

Retorno de experiencia: por qué ahora recomiendo las integraciones externas en lugar de Matterbridge

Hola a todos :waving_hand:

Después del lanzamiento de las integraciones externas en Gladys, quería compartir con ustedes mi experiencia con Matterbridge, y explicar por qué ahora orientaré a los usuarios hacia las integraciones externas.

Cuando descubrí Matterbridge, me pareció que el concepto era realmente excelente: permitir hacer compatibles con Gladys dispositivos “pre-Matter” gracias a una capa de abstracción. Creí en ello, recomendé esta solución y incluso orienté varios desarrollos en esta dirección con la esperanza de que permitiera a más usuarios unirse al ecosistema Gladys.

Después de aproximadamente dos meses de uso y retroalimentación de la comunidad, debo reconocer que ya no estoy completamente satisfecho con este enfoque. Con el tiempo, creo que las integraciones externas de Gladys son superiores en todos los aspectos, y será esta la solución que recomendaré a partir de ahora.

¿Por qué?

1. Una experiencia de usuario mucho más robusta

Matterbridge es un muy buen proyecto, pero sigue siendo, ante todo, pensado por desarrolladores, para desarrolladores.

A la vista de los comentarios que he podido leer en el foro, la experiencia suele ser complicada en cuanto algo no funciona. Los problemas son difíciles de diagnosticar y las soluciones no siempre evidentes.

En mi opinión, esto se debe principalmente a las elecciones técnicas realizadas.

Matterbridge funciona un poco como Gladys v3: los plugins se instalan directamente en el contenedor principal, con una instalación de dependencias al inicio (runtime). Este enfoque es práctico al principio, pero se vuelve rápidamente frágil: una actualización de dependencia puede romper un plugin sin previo aviso.

Las integraciones externas de Gladys siguen un enfoque muy diferente:

  • cada integración está aislada en su propio contenedor;
  • las dependencias se instalan en el momento del build, y no al inicio;
  • una integración no puede romper las otras;
  • las actualizaciones son mucho más predecibles.

Esta elección de arquitectura cambia por completo la situación en términos de estabilidad.

2. Los límites de Matter siguen siendo los límites de Matter

Matterbridge sigue dependiendo del estándar Matter.

Sin embargo, si algunos dispositivos aún no son compatibles con Matter hoy en día, generalmente no es por casualidad: a menudo es porque el protocolo aún no permite expresar todas sus funcionalidades, o porque ciertos tipos de dispositivos simplemente no existen en la especificación.

En otras palabras, Matterbridge siempre estará limitado por las posibilidades ofrecidas por Matter.

A la inversa, una integración externa de Gladys puede explotar el 100% de las capacidades de un dispositivo, sin estar limitada por un estándar intermedio.

3. Una dependencia menos

Finalmente, Matterbridge es un proyecto externo.

Cuando algunos usuarios encontraban errores, era a menudo frustrante para mí, porque simplemente no podía corregirlos. Dependía de la evolución de otro proyecto.

Con las integraciones externas, controlamos completamente la plataforma. Los desarrolladores pueden publicar sus integraciones libremente, hacerlas evolucionar a su ritmo y podemos mejorar el ecosistema sin depender de una capa intermedia.

¿Y ahora?

Ahora que existen las integraciones externas, ya no veo realmente ninguna razón para seguir destacando Matterbridge para este uso.

Las integraciones externas cumplen exactamente el mismo papel, con una mejor estabilidad, una mejor experiencia de usuario y muchas más posibilidades.

A medida que las integraciones externas reemplacen los plugins Matterbridge que había recomendado, actualizaré la documentación y retiraré progresivamente los tutoriales de Matterbridge en favor de estas nuevas integraciones.

En cuanto a la fábrica de plugins, representa un costo mensual (servidores + IA). No creo que la mantenga a largo plazo: prefiero invertir estos recursos directamente en el desarrollo de Gladys. :grinning_face_with_smiling_eyes:

Para concluir

Espero que comprendan este cambio de postura. No es “cambiar de opinión”: la IA está haciendo evolucionar nuestra manera de desarrollar a una velocidad increíble, y creo que es importante saber cuestionar sus elecciones cuando aparecen mejores soluciones.

Al final, lo que más retengo de esta aventura es que Matterbridge me dio la idea que condujo a las integraciones externas de Gladys.

Sin esta experiencia, esta funcionalidad probablemente nunca habría visto la luz. Y hoy, creo sinceramente que es una de las evoluciones más importantes de Gladys en mucho tiempo.

Gracias a todos por sus comentarios, sus pruebas y su confianza :heart:

Hola @pierre-gilles,

Estoy siguiendo con interés lo que está pasando en el universo de Gladys con la llegada de la IA. Temo que Gladys se deje llevar por este entusiasmo creador de nuevos módulos sin pensar demasiado en la filosofía de Gladys. Me explico. Observo que la mayoría de los nuevos módulos se basan en las nubes de los fabricantes. Sin embargo (en mi opinión), lo que hace fuerte a Gladys (y todo su interés para mí) es la seguridad de nuestros datos.

¿Puedes tranquilizarme sobre esta cuestión?

Hola @l.dolle,

La filosofía no ha cambiado: sigo promoviendo las integraciones locales siempre que sea posible (Zigbee, Matter, etc.).

Sin embargo, también hay que ser realistas: la mayoría de las personas, en Francia y en otros lugares, ya poseen dispositivos que no son ni Zigbee ni Matter. Una cámara comprada en Lidl, un enchufe encontrado en Amazon, una estación meteorológica regalada por un ser querido… Estos dispositivos existen, y los usuarios quieren poder integrarlos.

Hasta ahora, esto era un verdadero obstáculo para Gladys. Cada año, los usuarios elegían Home Assistant porque es compatible con casi todo (más de 1.300 integraciones), mientras que Gladys solo contaba con 36 hasta la semana pasada.

En mi opinión, mantener una posición muy estricta habría terminado perjudicando al proyecto. El objetivo no es renunciar a nuestros valores, sino permitir que más personas utilicen Gladys con el material que ya poseen.

Las integraciones externas cambian por completo el panorama: nos permiten finalmente ser competitivos, sin sacrificar el núcleo del proyecto. Las integraciones locales siguen siendo la referencia, pero ya no excluimos otras posibilidades cuando responden a una verdadera necesidad.

Incluso creo que es beneficioso a largo plazo. Alguien que comienza con una integración en la nube, por ejemplo, descubrirá gradualmente las ventajas de Zigbee o Matter (rapidez, fiabilidad, independencia de la nube) y tendrá naturalmente la tendencia a privilegiar dispositivos locales para sus próximas compras.

Hoy en día, nuestro problema no es que los usuarios compren demasiados dispositivos en la nube. Nuestro problema es que no vienen a Gladys porque no pueden conectar los dispositivos que ya poseen. Las integraciones externas permiten eliminar esta barrera de entrada, al tiempo que seguimos promoviendo una domótica local y duradera.

Gracias por tu respuesta.

Efectivamente, esto deja más libertad a los usuarios.

¡Bravo por tu trabajo!

Estoy de acuerdo, me hice la misma reflexión en cuanto vi la actualización de las integraciones externas. Es mucho más sencillo para un usuario común en comparación con matterbridge, que al final es bastante técnico para alguien que no es desarrollador.