J’ai suivi tes échanges sur GitHub avec l’usine à plugins, notamment ce commentaire :
Please find another solution to be sure that those “new” devices are in fact the same as the previous ones saved in Gladys.
En réalité, ce n’est pas le plugin qui gère cette partie, donc Claude Code ne pourra pas vraiment améliorer quoi que ce soit concernant le mécanisme d’appairage.
Si tu rencontres des difficultés avec Matterbridge dans ton cycle de développement et de tests, le plus pertinent serait plutôt d’ouvrir une issue sur le dépôt principal de Matterbridge pour expliquer précisément ce qui ne fonctionne pas et voir avec son développeur s’il est possible d’améliorer le workflow.
Par contre, si on lance cette discussion, il vaut mieux arriver avec des cas reproductibles et, si possible, des exemples provenant de plugins déjà utilisés en production. Ça permettra de montrer qu’il s’agit bien d’une limitation générale de Matterbridge et non d’un cas spécifique au plugin.
cc @prohand : Je penses que tu es concerné également dans tes tests
oui cette IA commence à m’irriter le poil sur ce dev
Matterbridge n’est pas en cause pour moi.
Il y a un serial number pour les clims mitsubishi qui sont de 36 caractères : je ne sais pas qui les génère sachant que matterbridge n’en envoie que 32 à Gladys.
Donc quand il y a un arrêt du plugin et restart, on a des nouveaux endpoint avec les mêmes serial number dans matterbridge mais pas dans Gladys d’où les nouveaux devices au lieu d’un silple update.
J’ai donc demandé à l’IA de trouver une solution pour avoir un serial number plus court.
Et cette andouille d’IA (désolé, c’est la moutarde…) me modifie le code (2 fois déjà) et génère un serial number encore plus long !
Bref, si ça ne marche pas avec mon dernier commentaire, je laisse tomber car je ne sais pas lui parler comme il faut (mais bon ça a démarré avec les débuts de Siri à l’époque et je ne sais toujours pas lui parler).
De mon expérience, Claude Opus 4.8 est vraiment au niveau d’un bon développeur. Donc si l’expérience est frustrante, le problème vient probablement d’ailleurs que de “l’intelligence” de Claude
Scope confusant : ici tu lui demandes en réalité de gérer “2 plugins en un”. Ça augmente fortement la complexité et rend le comportement difficile à cadrer, surtout si derrière tu testes uniquement une des deux branches. Je pense que ça vaudrait le coup de re-créer un ticket plus simple : un seul plugin, une seule API, un seul cas d’usage. Ça rend le développement et surtout la validation beaucoup plus simple.
Absence de feedback de l’IA : l’usine pourrait améliorer l’expérience en renvoyant systématiquement un retour dans l’issue GitHub. Par exemple une phrase simple du type : “j’ai modifié X / je n’ai rien trouvé à changer / pas assez d’infos”. Aujourd’hui, on a une impression de travail “dans le vide”, ce qui est frustrant côté test, parce qu’on ne sait même pas si l’IA a réellement eu quelque chose à faire ou si elle a conclu qu’il n’y avait rien à modifier.
Le SERIAL_NUMBER affiché dans Gladys est purement informatif : il ne sert pas à faire la réconciliation entre deux appareils ayant des NodeID différents.
Pour la déduplication / mise à jour d’un device existant, si aucun n’appareil n’existe avec le même NodeId, Gladys s’appuie plutôt sur le uniqueId fourni par Matter, et non sur le serial number !
Je comprends, et ça alimente sûrement ma frustration et recommencer de zéro l’augmente d’autant plus … bref, je vais voir quand ça ira mieux.
Pour le dernier fix de l’usine, il a très bien géré les envois des serial number et unique ID de matterbridge vers Gladys, et ils sont strictement identiques.
Ma question est qui gère/génère les NodeID ?
Comment est-ce que je peux le trouver ?
En toute logique et suivant ce que tu décris comme comportement, Gladys devrait voir que le Unique ID est identique, non ? Et donc mettre un update au lieu d’un ajout ?
Là je pense que le soucis vient de Gladys et non de l’usine, je suis dans le vrai ?
PS : :je suis bien en 4.80.0 sur ma Gladys de test.
Je me suis renseigné, dans le cas de Matterbridge, le NodeId est généré/attribué lors de l’appairage de l’instance avec le fabric Matter (donc Gladys ici).
Ensuite, chaque appareil est en mode « ChildBridge » sous Matterbridge, et est identifié par son numéro d’endpoint.
Donc en fait ici, tu auras un seul Node ID, c’est vraiment un cas particulier de Matter le cas Matterbridge.
Dans Gladys, tu peux retrouver cette structure directement dans les paramètres de l’intégration Matter : tu y verras le NodeId de l’instance Matterbridge, puis les endpoints associés à chaque device.
Je te mets le pastebin de ma discussion avec l’IA sur le repo matterbridge qui m’a aidé à comprendre tout ça
Je ne rejoins pas forcément ce qui est écrit mais soit.
Pour exemple, j’ai testé et retesté le plug-in somfy officiel de matterbridge : ajout de tous mes volets dans Gladys, désinstallation du plug-in, réinstallation et donc nouveaux end points → aucun nouveau device à ajouter dans Gladys, tout était reconnu et fonctionnel.
Comportement totalement identique avec juste un disable plug-in et enable plug-in.
C’est pour ça que je je comprends pas pourquoi pour l’instant il y a cette telle différence de comportement.
