@mutmut Merci pour le retour.
Concernant le niveau de batterie des volets le plugin Tahoma affiche :
comme il y a beaucoup de soleil en ce moment je ne sais pas si c’est fiable…
Concernant le plugin Cosytouch, il faut un hub cosytouch ou bien juste un compte?
Cela passe par le cloud?
les 2 mon capitaine 
Enfin je dis ça mais je n’ai pas cozytouch mais j’utilise ce plug-in pour somfy avec une box connexoon.
J’ai essayé de passer en local sans succès et je n’ai pas eu de réponse à ma demande sur le github.
Je vais tester ce nouveau plug-in alors.
Salut à tous 
Après la sortie des intégrations externes dans Gladys, je voulais vous partager mon retour d’expérience sur Matterbridge, et expliquer pourquoi je vais désormais orienter les utilisateurs vers les intégrations externes.
Quand j’ai découvert Matterbridge, j’ai trouvé le concept vraiment excellent : permettre de rendre compatibles avec Gladys des appareils “pré-Matter” grâce à une couche d’abstraction. J’y ai cru, j’ai recommandé cette solution, et j’ai même orienté plusieurs développements dans cette direction en espérant qu’elle permette à davantage d’utilisateurs de rejoindre l’écosystème Gladys.
Après environ deux mois d’utilisation et de retours de la communauté, je dois reconnaître que je ne suis plus entièrement satisfait de cette approche. Avec le recul, je pense que les intégrations externes Gladys sont supérieures sur tous les plans, et ce sera désormais la solution que je recommanderai.
Matterbridge est un très bon projet, mais il reste avant tout pensé par des développeurs, pour des développeurs.
Au vu des retours que j’ai pu lire sur le forum, l’expérience est souvent compliquée dès que quelque chose ne fonctionne pas. Les problèmes sont difficiles à diagnostiquer, et les solutions pas toujours évidentes.
À mon sens, cela vient principalement des choix techniques réalisés.
Matterbridge fonctionne un peu comme Gladys v3 : les plugins sont installés directement dans le conteneur principal, avec une installation des dépendances au démarrage (runtime). Cette approche est pratique au départ, mais elle devient vite fragile : une mise à jour de dépendance peut casser un plugin sans prévenir.
Les intégrations externes de Gladys suivent une approche très différente :
Ce choix d’architecture change complètement la donne en termes de stabilité.
Matterbridge reste dépendant du standard Matter.
Or, si certains appareils ne sont toujours pas compatibles Matter aujourd’hui, ce n’est généralement pas par hasard : c’est souvent parce que le protocole ne permet pas encore d’exprimer toutes leurs fonctionnalités, ou parce que certains types d’appareils n’existent tout simplement pas dans la spécification.
Autrement dit, Matterbridge restera toujours limité par les possibilités offertes par Matter.
À l’inverse, une intégration externe Gladys peut exploiter 100 % des capacités d’un appareil, sans être contrainte par un standard intermédiaire.
Enfin, Matterbridge est un projet externe.
Lorsque certains utilisateurs rencontraient des bugs, c’était souvent frustrant pour moi, car je ne pouvais tout simplement pas les corriger. J’étais dépendant de l’évolution d’un autre projet.
Avec les intégrations externes, nous maîtrisons entièrement la plateforme. Les développeurs peuvent publier leurs intégrations librement, les faire évoluer à leur rythme, et nous pouvons améliorer l’écosystème sans dépendre d’une couche intermédiaire.
Maintenant que les intégrations externes existent, je ne vois plus vraiment de raison de continuer à mettre Matterbridge en avant pour cet usage.
Les intégrations externes remplissent exactement le même rôle, avec une meilleure stabilité, une meilleure expérience utilisateur et beaucoup plus de possibilités.
Au fur et à mesure que des intégrations externes remplaceront les plugins Matterbridge que j’avais recommandés, je mettrai à jour la documentation et retirerai progressivement les tutoriels Matterbridge au profit de ces nouvelles intégrations.
Concernant l’usine à plugins, elle représente un coût mensuel (serveurs + IA). Je ne pense pas la conserver sur le long terme : je préfère investir ces ressources directement dans le développement de Gladys. 
J’espère que vous comprendrez ce changement de position. Ce n’est pas “faire la girouette” : l’IA fait évoluer notre manière de développer à une vitesse incroyable, et je pense qu’il est important de savoir remettre en question ses choix lorsque de meilleures solutions apparaissent.
Au final, je retiens surtout une chose de cette aventure : Matterbridge m’a donné l’idée qui a conduit aux intégrations externes de Gladys.
Sans cette expérience, cette fonctionnalité n’aurait probablement jamais vu le jour. Et aujourd’hui, je pense sincèrement que c’est l’une des évolutions les plus importantes de Gladys depuis longtemps.
Merci à tous pour vos retours, vos tests et votre confiance 
Bonjour @pierre-gilles ,
Je regarde avec intérêt ce qui se passe dans l’univers Gladys avec l’arrivée de l’IA. Je crains que Gladys se laisse emporter par cet euphorie créatrice de nouveaux modules sans trop penser à la philosophie de Gladys. Je m’explique. Je remarque que la plupart des nouveaux modules s’appuient sur les clouds fabricants. Or (à mon avis) ce qui fait la force de Gladys (et tout son intérêt pour moi) est la sécurité de nos données.
Peux-tu me rassurer sur cette question?
Bonjour @l.dolle,
La philosophie n’a pas changé : je continue à mettre en avant les intégrations locales autant que possible (Zigbee, Matter, etc.).
En revanche, il faut aussi être réaliste : la majorité des gens, en France comme ailleurs, possèdent déjà des appareils qui ne sont ni Zigbee ni Matter. Une caméra achetée chez Lidl, une prise trouvée sur Amazon, une station météo offerte par un proche… Ces appareils existent, et les utilisateurs veulent pouvoir les intégrer.
Jusqu’à présent, c’était un vrai frein pour Gladys. Chaque année, des utilisateurs choisissaient Home Assistant parce qu’il est compatible avec quasiment tout (plus de 1 300 intégrations), alors que Gladys en comptait seulement 36 jusqu’à la semaine dernière.
À mon sens, rester sur une position très stricte aurait fini par desservir le projet. L’objectif n’est pas de renoncer à nos valeurs, mais de permettre à davantage de personnes d’utiliser Gladys avec le matériel qu’elles possèdent déjà.
Les intégrations externes changent complètement la donne : elles nous permettent enfin de devenir compétitifs, sans sacrifier le cœur du projet. Les intégrations locales restent la référence, mais on n’exclut plus les autres possibilités lorsqu’elles répondent à un vrai besoin.
Et je pense même que c’est bénéfique sur le long terme. Quelqu’un qui commence avec une intégration Cloud, par exemple, découvrira progressivement les avantages du Zigbee ou de Matter (rapidité, fiabilité, indépendance du cloud) et aura naturellement tendance à privilégier des appareils locaux pour ses prochains achats.
Aujourd’hui, notre problème n’est pas que les utilisateurs achètent trop d’appareils cloud. Notre problème, c’est qu’ils ne viennent pas sur Gladys parce qu’ils ne peuvent pas connecter les appareils qu’ils possèdent déjà. Les intégrations externes permettent de lever cette barrière d’entrée, tout en continuant à promouvoir une domotique locale et pérenne.
Merci pour ta réponse.
Effectivement ça laisse plus de liberté aux utilisateurs.
Bravo pour ton travail.
Je suis d’accord, je me suis fait la même réflexion dès que j’ai vu la maj des intégrations externe. C’est beaucoup plus simple pour un utilisateur lambda par rapport à matterbridge qui est assez technique finalement pour un non développeur
