Matterbridge + IA = Révolution pour Gladys 🚀

[pierre-gilles]

Salut à tous,

J’ai pas mal bidouillé la semaine dernière autour de Matterbridge, et j’ai eu une vrai révélation que je voulais vous partager ici

On va pouvoir rendre n’importe quel appareil compatible Matter (et donc compatible Gladys), et ce sans coder !!

Un peu de contexte

Je vous avais déjà parlé de Matterbridge, un projet qui permet d’installer des plugins pour ajouter dans Matter des appareils non-Matter.

Aujourd’hui, Matterbridge vous permet déjà d’utiliser dans Gladys :

• des volets Somfy
• des appareils Shelly de génération 1, 2 et 3
• bientôt votre aspirateur robot Roborock

Mais Matterbridge est encore jeune, et n’a pas de plugin pour tout.

Le problème que ça résout

Dans Gladys, j’ai toujours pris l’approche de développer de « grandes intégrations » sur-mesure, en passant beaucoup de temps sur l’expérience utilisateur et l’interface.

Sauf que certains d’entre vous ont des besoins très spécifiques : des appareils peu répandus, parfois même plus vendus. Pour ces produits, difficile de justifier le temps de développement d’une intégration native pour ne servir qu’une poignée d’utilisateurs.

Et si ces intégrations pouvaient être de simples plugins Matterbridge, développés par une IA ?

Le système de plugin Matterbridge est bien codifié, bien documenté, avec plein d’exemples.

Et souvent, ces intégrations existent déjà ailleurs en open-source (Node-RED, Home Assistant) : on peut simplement demander à l’IA de traduire un plugin Node-RED en plugin Matterbridge.

Il n’y a rien à inventer, c’est juste « traduire du code » !

Ce que j’ai testé

J’ai développé un plugin Matterbridge pour ma climatisation Mitsubishi, sans écrire une seule ligne de code.

Je vous montre tout ça ici :

Je code un plugin Matterbridge avec l'IA (Compatibilité Universelle)

Et maintenant ?

La suite logique : et si on automatisait complètement la création de plugins Matterbridge ?

Imaginez une « usine à plugins », pilotée par Claude Code, tournant sur un serveur, qui dépilerait des tickets GitHub et développerait les plugins sans intervention humaine.

Avec un système pareil, on pourrait industrialiser le développement d’intégrations, et réduire l’écart entre Gladys et des projets comme Home Assistant.

Je pense que c’est une vraie révolution. Et ça me conforte dans mon choix d’investir beaucoup de ressources sur Matter cette année, car c’est vraiment l’avenir de la maison connectée.

Qu’en pensez-vous ?

[guim31]

Je trouve que c’est une très bonne analyse, car dans le même esprit il m’est arrivé d’utiliser l’IA pour « traduire » un flow de scène que j’avais en tête et le transformer en JSON importable dans Node-red. Je trouve que c’est un usage pertinent de l’IA.

Je m’interroge juste sur la manière de sécuriser tout cela en terme d’efficacité : il faudrait intégrer des tests pour s’assurer que les plugins générés soient pertinents et fonctionnels non ? Ou bien c’est une revue manuelle de ta part ?

Parce que j’ai l’impression que ça pourrait vite être un beau bordel ^^

En tout cas l’idée est très intéressante et pourrait en effet répondre à la fameuse « faiblesse » de Gladys, à savoir la quantité d’intégrations / appareils supportés

[pierre-gilles]

@guim31

Je m’interroge juste sur la manière de sécuriser tout cela en terme d’efficacité : il faudrait intégrer des tests pour s’assurer que les plugins générés soient pertinents et fonctionnels non ? Ou bien c’est une revue manuelle de ta part ?

Claude Code est suffisamment intelligent pour réaliser lui-même des tests avec une vraie instance Matterbridge. En revanche, pour les tests sur du matériel réel, il faudra forcément un retour utilisateur.

Pour moi, ça pourrait fonctionner via des tickets GitHub : l’utilisateur donne son feedback à Claude Code, et celui-ci propose ensuite un fix jusqu’à obtenir un résultat correct.

L’idée serait vraiment d’aller vers une chaîne “100% automatisée”. De mon côté, mon temps est trop limité pour pouvoir reviewer manuellement tous les plugins

J’en ai parlé d’ailleurs au fondateur de Matterbridge et ça a l’air de l’exciter pas mal aussi !

AI Plugin Factory to accelerate Matterbridge ecosystem growth · Luligu...

Reste maintenant la question du coût : qui finance les tokens nécessaires pour générer les plugins ?

[bjm]

Petite question : Le plugin développé sera-t-il utilisable uniquement pour Gladys ou pourra-t-il être utilisé par tous les systèmes implémentant Matterbridge ?

[Will_71]

Matterbridge expose sur le protocole Matter. Donc tous les systèmes pouvant intégrer des appareils matter.

[pierre-gilles]

Oui, exact. Matterbridge est juste un logiciel qui connecte Matter ↔ n’importe quel protocole

Donc le plugin fonctionnera avec tout: Apple Maison, Google, Alexa, Gladys, Home Assistant, etc…

[forresst]

@pierre-gilles

Pour moi, ça pourrait fonctionner via des tickets GitHub : l’utilisateur donne son feedback à Claude Code, et celui-ci propose ensuite un fix jusqu’à obtenir un résultat correct.

L’idée serait vraiment d’aller vers une chaîne “100% automatisée”. De mon côté, mon temps est trop limité pour pouvoir reviewer manuellement tous les plugins

L’idée me parait excellente toutefois il faudrait peut-être privilégier les demandes de plugin selon la popularité de la demande. C’est à dire si un certain nombre d’utilisateurs approuve ou “like” le ticket Github de la demande. Plusieurs avantages à cela :

• Un contrôle ou une validation sur la demande
• Eviter trop de requête à Claude pour des demandes non populaire : donc diminuer le cout des tokens

@pierre-gilles

Reste maintenant la question du coût : qui finance les tokens nécessaires pour générer les plugins ?

Je ne sais pas s’il est possible de déterminer le coût de Claude pour ta climatisation Mitsubishi. Mais si on pouvait avoir une estimation cela permettrait d’avoir une idée du cout d’un plugin.

Si cela représente des couts inférieurs à quelques euros, je pense que plusieurs personnes seraient en capacité de participer. (Bon ok à mettre en place, c’est peut-être pas si simple …)

[pierre-gilles]

@forresst

L’idée me parait excellente toutefois il faudrait peut-être privilégier les demandes de plugin selon la popularité de la demande.

Tout dépend du coût. Pour moi, l’idée de cette “usine à plugin” est justement de permettre de couvrir aussi des intégrations peu populaires.

Le problème des systèmes de votes, c’est qu’un utilisateur avec un appareil peu répandu n’aura probablement jamais de plugin… ce qui est déjà le cas aujourd’hui dans Gladys

@forresst

Je ne sais pas s’il est possible de déterminer le coût de Claude pour ta climatisation Mitsubishi.

C’était via Windsurf, donc ce n’est pas totalement transparent, mais pour donner un ordre d’idée, je paie 15$ par mois. J’ai développé le plugin en une demi-journée.

Honnêtement, j’ai l’impression que ce pricing est assez agressif et probablement subventionné pour attirer les développeurs. Sur Claude Code en CLI, ça sera sûrement plus cher.

@forresst

Si cela représente des couts inférieurs à quelques euros, je pense que plusieurs personnes seraient en capacité de participer.

Je pense aussi que c’est une bonne piste. Si on se rend compte qu’un plugin coûte 5 à 10$ à générer, c’est largement finançable. La plupart des gens seraient prêts à payer ça pour avoir leur appareil supporté dans Gladys de façon durable

[guim31]

@pierre-gilles

Je pense aussi que c’est une bonne piste. Si on se rend compte qu’un plugin coûte 5 à 10$ à générer, c’est largement finançable. La plupart des gens seraient prêts à payer ça pour avoir leur appareil supporté dans Gladys de façon durable

Je confirme que personnellement, si un plugin coûte 10 voire 15€, je passe au paiement direct ! Je ne représente peut être pas la majorité des gens, mais en soi, si un plugin m’est réellement indispensable je serai même prêt à y mettre le double ^^

[pierre-gilles]

@guim31

Je confirme que personnellement, si un plugin coûte 10 voire 15€, je passe au paiement direct !

Oui, idem, ma climatisation ça m’a coûté plus de 2000€, mettre quelques dizaines d’euros une seule fois pour l’avoir connectée dans toute ma domotique, c’est une évidence

[Terdious]

On connait déjà mon avis sur ce point ^^ Evidemment. Lorsqu’on compare cela à l’utilité, ce n’est vraiment pas cher pareil. Et pour le coup tout le monde peu priorisé selon ses besoins réel.

Ne pas oublier tout de même que pour du très spécifique il y aura de tout de façon du développement Gladys également. Je pense à des appareils par exemple du type Robot tondeuse => Nouvelles feature category/type ; Implémentation de gestion Dashboard / scènes.

Mai spour 90% des équipements habituels, c’est tout bénéf’ ^^

[pierre-gilles]

@Terdious

Ne pas oublier tout de même que pour du très spécifique il y aura de tout de façon du développement Gladys également

À partir du moment où on couvrira 100% de la spec Matter dans Gladys, il n’y aura plus rien à faire côté Gladys mais oui, tant que ce n’est pas le cas, il faut faire quelques ajustements, comme ce que j’ai fait récemment sur les aspirateurs robots par exemple !

[bjm]

@pierre-gilles

Oui, exact. Matterbridge est juste un logiciel qui connecte Matter ↔ n’importe quel protocole

Donc le plugin fonctionnera avec tout: Apple Maison, Google, Alexa, Gladys, Home Assistant, etc…

On est en plein dans la logique du logiciel libre : « un développement qui profite à tous ».

Reste maintenant la question du coût : qui finance les tokens nécessaires pour générer les plugins ?

Je verrais bien un système d’achat de jetons.

Par exemple, 15 jetons pour le développement d’un plugin.

Première étape : une personne dépose le produit qu’elle souhaite rendre compatible.

Deuxième étape : les personnes intéressées par ce même produit se font connaître pour partager les coûts et passer à la production.

Par exemple, trois personnes mettent 5 jetons.

Troisième étape : si personne d’autre ne se manifeste ou si la personne est pressée, elle finance l’intégralité et passe à la production.