Matterbridge + IA = Revolución para Gladys 🚀

¡Hola a todos,

La semana pasada me dediqué a experimentar con Matterbridge, y tuve una verdadera revelación que quería compartir con ustedes aquí :smiley:

:backhand_index_pointing_right: ¡Podremos hacer cualquier dispositivo compatible con Matter (y, por lo tanto, compatible con Gladys), ¡y sin necesidad de codificar!

Un poco de contexto

Ya les había hablado de Matterbridge, un proyecto que permite instalar plugins para agregar dispositivos no-Matter en Matter.

Hoy en día, Matterbridge ya les permite usar en Gladys:

Pero Matterbridge aún es joven y no tiene plugins para todo.

El problema que resuelve

En Gladys, siempre he tomado el enfoque de desarrollar « grandes integraciones » personalizadas, invirtiendo mucho tiempo en la experiencia de usuario y la interfaz.

Sin embargo, algunos de ustedes tienen necesidades muy específicas: dispositivos poco comunes, a veces incluso ya no se venden. Para estos productos, es difícil justificar el tiempo de desarrollo de una integración nativa para servir solo a unos pocos usuarios.

¿Y si estas integraciones pudieran ser simples plugins de Matterbridge, desarrollados por una IA?

El sistema de plugins de Matterbridge está bien codificado, bien documentado, con muchos ejemplos.

Y a menudo, estas integraciones ya existen en otros lugares en código abierto (Node-RED, Home Assistant): simplemente podemos pedirle a la IA que traduzca un plugin de Node-RED a un plugin de Matterbridge.

¡No hay nada que inventar, es solo « traducir código »!

Lo que he probado

Desarrollé un plugin de Matterbridge para mi climatización Mitsubishi, sin escribir una sola línea de código.

Les muestro todo aquí:

¿Y ahora?

La siguiente lógica: ¿y si automatizáramos completamente la creación de plugins de Matterbridge?

Imaginen una « fábrica de plugins », controlada por Claude Code, ejecutándose en un servidor, que procesaría tickets de GitHub y desarrollaría los plugins sin intervención humana.

Con un sistema así, podríamos industrializar el desarrollo de integraciones y reducir la brecha entre Gladys y proyectos como Home Assistant.

Creo que es una verdadera revolución. Y esto refuerza mi decisión de invertir muchos recursos en Matter este año, porque realmente es el futuro de la casa conectada.

¿Qué opinan?

Creo que es un análisis muy bueno, porque en el mismo espíritu, me ha pasado usar la IA para « traducir » un flujo de escena que tenía en mente y convertirlo en JSON importable en Node-red. Creo que es un uso pertinente de la IA.

Solo me pregunto sobre la manera de asegurar todo esto en términos de eficacia: ¿no habría que integrar pruebas para asegurarse de que los plugins generados sean pertinentes y funcionales? ¿O es una revisión manual por tu parte?

Porque tengo la impresión de que podría convertirse rápidamente en un gran lío ^^

En todo caso, la idea es muy interesante y podría responder efectivamente a la famosa « debilidad » de Gladys, a saber, la cantidad de integraciones/aparatos soportados :+1::+1:

Claude Code es lo suficientemente inteligente como para realizar pruebas con una instancia real de Matterbridge. En cambio, para las pruebas en hardware real, habrá que contar con el feedback de los usuarios.

Para mí, podría funcionar a través de tickets de GitHub: el usuario da su feedback a Claude Code, y este propone luego un fix hasta obtener un resultado correcto.

La idea sería ir hacia una cadena “100% automatizada”. Por mi parte, mi tiempo es demasiado limitado para poder revisar manualmente todos los plugins :grinning_face_with_smiling_eyes:

De hecho, ya hablé con el fundador de Matterbridge y parece que le emociona bastante también.

Queda ahora la cuestión del coste: ¿quién financia los tokens necesarios para generar los plugins?

Pregunta rápida: ¿El plugin desarrollado solo será utilizable para Gladys o también podrá ser utilizado por todos los sistemas que implementen Matterbridge?

Matterbridge se expone sobre el protocolo Matter. Por lo tanto, todos los sistemas pueden integrar dispositivos Matter.

Sí, exacto. Matterbridge es solo un software que conecta Matter ↔ cualquier protocolo

Por lo tanto, el plugin funcionará con todo: Apple Casa, Google, Alexa, Gladys, Home Assistant, etc…

La idea me parece excelente, sin embargo, quizá sería mejor priorizar las solicitudes de plugins según la popularidad de la solicitud. Es decir, si un cierto número de usuarios aprueba o “likea” el ticket de GitHub de la solicitud. Varios beneficios de esto:

  • Un control o una validación de la solicitud
  • Evitar demasiadas solicitudes a Claude para solicitudes no populares: por lo tanto, reducir el costo de los tokens

No sé si es posible determinar el costo de Claude para tu climatización Mitsubishi. Pero si pudiéramos tener una estimación, permitiría tener una idea del costo de un plugin.

Si esto representa costos inferiores a unos pocos euros, creo que varias personas estarían en capacidad de participar. (Bueno, ok, ponerlo en marcha, quizá no es tan simple…)

Depende del costo. Para mí, la idea de esta « fábrica de complementos » es precisamente permitir cubrir también integraciones poco populares.

El problema de los sistemas de votación es que un usuario con un dispositivo poco común probablemente nunca tendrá un complemento… lo cual ya es el caso hoy en Gladys :grinning_face_with_smiling_eyes:

Fue a través de Windsurf, por lo que no es totalmente transparente, pero para dar una idea, pago 15$ al mes. Desarrollé el complemento en medio día.

Honestamente, me parece que este precio es bastante agresivo y probablemente subvencionado para atraer a los desarrolladores. En Claude Code en CLI, seguramente será más caro.

También creo que es una buena pista. Si nos damos cuenta de que un complemento cuesta 5 a 10$ para generar, es ampliamente financiado. La mayoría de las personas estarían dispuestas a pagar eso para tener su dispositivo soportado en Gladys de manera duradera :slightly_smiling_face:

Confirmo que personalmente, si un plugin cuesta 10 o incluso 15€, ¡pago directamente! Quizás no represente a la mayoría de la gente, pero en sí, si un plugin me es realmente indispensable, ¡estaré dispuesto a pagar el doble! ^^

Sí, lo mismo, mi aire acondicionado me costó más de 2000€, gastar unas decenas de euros una sola vez para tenerlo conectado en toda mi domótica, es evidente :smiley:

Ya conocéis mi opinión sobre este punto ^^ :wink: Evidentemente. Cuando se compara esto con la utilidad, no es realmente caro. Y en este caso, todos pueden priorizar según sus necesidades reales.

No olvidemos, sin embargo, que para cosas muy específicas habrá de todo, desarrollo Gladys también. Pienso en aparatos, por ejemplo, del tipo cortacésped robot => Nueva categoría/ tipo de función; Implementación de gestión de Dashboard / escenas.

Pero para el 90% de los equipos habituales, es todo beneficios ^^

En cuanto cubramos el 100% de la especificación Matter en Gladys, no habrá nada más que hacer en Gladys :grin: pero sí, mientras no sea el caso, hay que hacer algunos ajustes, como lo que hice recientemente con los robots aspiradores, por ejemplo.

Estamos en plena lógica del software libre: «un desarrollo que beneficia a todos».

Ahora queda la cuestión del coste: ¿quién financia los tokens necesarios para generar los plugins?

Yo vería bien un sistema de compra de tokens.

Por ejemplo, 15 tokens para el desarrollo de un plugin.

Primera etapa: una persona deposita el producto que desea hacer compatible.

Segunda etapa: las personas interesadas en el mismo producto se dan a conocer para compartir los costes y pasar a la producción.

Por ejemplo, tres personas ponen 5 tokens.

Tercera etapa: si nadie más se manifiesta o si la persona tiene prisa, financia la totalidad y pasa a la producción.

Hola a todos, esto es muy emocionante porque, de hecho, soluciona la « debilidad » de Gladys con los dispositivos un poco exóticos…

Sinceramente, pagar 10€ por una integración, lo haría sin problema.

Hoy en día, no soy usuario de Gladys, sino de Home Assistant por dos razones:

  • el número de dispositivos compatibles con HA es mucho mayor
  • la potencia de implementación de paneles de control «gráficos» es mucho más avanzada.

La fábrica de plugins es interesante y estoy dispuesto a pagar 5 o 10 euros por un plugin, pero ¿qué pasa con el mantenimiento? ¿Habría que pagar por una actualización de los plugins? Pagar 5 o 10 euros me parece razonable, pero si hay que pagar cada vez que se necesita una actualización, la fábrica será mucho menos interesante.

¿Qué pasa con los paneles de control, que, en mi opinión, es otro punto débil de Gladys?
¿Qué se planea, a largo plazo, para hacer que la interfaz de Gladys sea más «sexy» para el usuario final?

¡Hola @filbou40, gracias por tu respuesta!

En cuanto al mantenimiento, es una buena pregunta :grinning_face_with_smiling_eyes:. Depende de los cambios, en realidad. Si es muy complejo, puede costar lo mismo que un plugin. Si es muy simple, puede ser muy barato. Podríamos pedirle a la IA que evalúe la complejidad de la tarea antes de hacerlo.

¡Estoy muy interesado en este punto, te importaría crear un tema separado para discutirlo?

¡Lo mismo para esto!!

Los comentarios de los usuarios que no usan Gladys son muy valiosos para mí, por lo que realmente me encantaría tener tu opinión completa!

Hola, he creado un tema dedicado a los tableros de control en “Solicitud de funciones”. Espero haberlo creado en el lugar correcto.

1er PoC de la fábrica de plugins esta mañana (la fábrica fue codificada por completo por la IA, obviamente :p)

¡Estoy probándolo por mi parte!

La configuración:

  1. Creé un repositorio: GitHub - GladysAssistant/matterbridge-ai-plugin-factory: AI-powered factory for creating Matterbridge plugins from GitHub issues · GitHub
  2. En el repositorio, creé una plantilla de issue:

Así, las solicitudes están estandarizadas y corresponden a lo que la IA espera.
3. Inicié un servidor en Hetzner.
4. En el servidor, tengo un pequeño script que ejecuta Claude Code en los issues del repositorio
5. La IA hace su vida en completa autonomía y publica sus avances en el ticket:

  1. Los costos:

Tomé el plan « Pro » a 21,60€ al mes.

Por ahora, en 20 minutos de trabajo, los créditos ya están bastante consumidos:

Espero poder hacer al menos un plugin por « sesión » ^^

Para generar un complemento, se utilizó el 52% del límite de sesión actual. Sin sorpresa, al intentar generar un segundo complemento falló a mitad del proceso:

Pero es muy prometedor, ¡el código generado parecía excelente para el primer complemento!