Ich habe deine Diskussionen auf GitHub mit der Plugin-Fabrik verfolgt, insbesondere diesen Kommentar:
Bitte finden Sie eine andere Lösung, um sicherzustellen, dass diese „neuen“ Geräte tatsächlich dieselben sind wie die zuvor in Gladys gespeicherten.
Tatsächlich wird dieser Teil nicht vom Plugin verwaltet, daher kann Claude Code den Mechanismus des Pairings nicht wirklich verbessern.
Wenn du Probleme mit Matterbridge in deinem Entwicklungs- und Testzyklus hast, wäre es sinnvoller, ein Issue im Haupt-Repository von Matterbridge zu öffnen, um genau zu erklären, was nicht funktioniert, und mit dem Entwickler zu sehen, ob es möglich ist, den Workflow zu verbessern.
Aber wenn wir diese Diskussion starten, ist es besser, mit reproduzierbaren Fällen zu kommen und, wenn möglich, mit Beispielen aus bereits in der Produktion verwendeten Plugins. Dadurch kann gezeigt werden, dass es sich um eine allgemeine Einschränkung von Matterbridge und nicht um einen spezifischen Fall des Plugins handelt.
cc @prohand: Ich denke, du bist auch in deinen Tests betroffen.
ja, diese KI beginnt, mir auf diesem Dev die Haare zu sträuben
Matterbridge ist für mich nicht das Problem.
Es gibt eine Seriennummer für Mitsubishi-Klimaanlagen, die 36 Zeichen lang ist: Ich weiß nicht, wer sie generiert, da Matterbridge nur 32 an Gladys sendet.
Daher gibt es bei einem Plugin-Stopp und Neustart neue Endpunkte mit denselben Seriennummern in Matterbridge, aber nicht in Gladys, wodurch neue Geräte entstehen, anstatt einfach nur ein Update.
Ich habe die KI also gebeten, eine Lösung zu finden, um eine kürzere Seriennummer zu haben.
Und diese dumme KI (entschuldige, aber mir geht der Kamm schwimmen…) ändert den Code (bereits zweimal) und generiert eine noch längere Seriennummer!
Kurz gesagt, wenn es mit meinem letzten Kommentar nicht klappt, gebe ich auf, denn ich weiß nicht, wie man mit ihr richtig umgeht (aber es hat damals mit den Anfängen von Siri angefangen und ich weiß immer noch nicht, wie man mit ihr redet).
Aus meiner Erfahrung ist Claude Opus 4.8 wirklich auf dem Niveau eines guten Entwicklers. Wenn die Erfahrung also frustrierend ist, liegt das Problem wahrscheinlich woanders als bei „Claudes“ „Intelligenz“
Unklare Anforderungen: Hier verlangst du im Grunde von ihm, „2 Plugins in einem“ zu verwalten“. Das erhöht die Komplexität erheblich und macht das Verhalten schwer fassbar, besonders wenn du anschließend nur einen der beiden Zweige testest. Ich denke, es wäre sinnvoll, ein einfacheres Ticket zu erstellen: ein einziges Plugin, eine einzige API, ein einziger Anwendungsfall. Das macht die Entwicklung und vor allem die Validierung viel einfacher.
Fehlendes Feedback der KI: Die Fabrik könnte das Erlebnis verbessern, indem sie systematisch eine Rückmeldung in das GitHub-Issue sendet. Zum Beispiel ein einfacher Satz wie: „Ich habe X geändert / ich habe nichts zum Ändern gefunden / nicht genug Informationen“. Heute hat man das Gefühl, „ins Leere“ zu arbeiten, was frustrierend ist, weil man nicht einmal weiß, ob die KI tatsächlich etwas zu tun hatte oder ob sie geschlossen hat, dass nichts zu ändern war.
Die in Gladys angezeigte SERIAL_NUMBER ist rein informativ: Sie wird nicht verwendet, um zwischen zwei Geräten mit unterschiedlichen NodeID abzugleichen.
Für die Deduplizierung / Aktualisierung eines bestehenden Geräts, wenn kein Gerät mit derselben NodeId existiert, stützt sich Gladys stattdessen auf die von Matter bereitgestellte uniqueId und nicht auf die Seriennummer!
Ich verstehe, und das nährt sicherlich meine Frustration und das erneute Starten von vorne macht es noch schlimmer … kurz gesagt, ich werde sehen, wann es mir besser geht.
Für den letzten Fix der Fabrik hat er die Seriennummer und die Unique ID von matterbridge zu Gladys sehr gut verwaltet, und sie sind streng identisch.
Meine Frage ist, wer verwaltet/erzeugt die NodeID?
Wie kann ich das herausfinden?
Logischerweise und gemäß dem von dir beschriebenen Verhalten sollte Gladys sehen, dass die Unique ID identisch ist, oder? Und daher ein Update statt einer Hinzufügung durchführen?
Jetzt denke ich, dass das Problem von Gladys und nicht von der Fabrik kommt, habe ich recht?
Ich habe mich erkundigt, im Fall von Matterbridge wird die NodeId beim Koppeln der Instanz mit dem Matter-Fabric (also Gladys hier) generiert/zugewiesen.
Anschließend ist jedes Gerät im « ChildBridge »-Modus unter Matterbridge und wird durch seine Endpunktnummer identifiziert.
Also hier hast du nur eine einzige Node-ID, das ist wirklich ein besonderer Fall von Matter im Fall von Matterbridge.
In Gladys kannst du diese Struktur direkt in den Matter-Integrationsparametern finden: Dort siehst du die NodeId der Matterbridge-Instanz und dann die Endpunkte, die jedem Gerät zugeordnet sind.
Ich zeige dir den pastebin meines Gesprächs mit der KI im matterbridge-Repo, das mir geholfen hat, das alles zu verstehen
Ich stimme nicht unbedingt dem zu, was dort steht, aber egal.
Zum Beispiel habe ich das offizielle Somfy-Plugin von Matterbridge getestet und erneut getestet: Hinzufügen aller meiner Rollläden in Gladys, Deinstallation des Plugins, Neuinstallation und daher neue Endpunkte → keine neuen Geräte in Gladys hinzufügen, alles wurde erkannt und funktionierte.
Gleiches Verhalten mit nur einem Deaktivieren des Plugins und Aktivieren des Plugins.
Deshalb verstehe ich nicht, warum es bisher einen solchen Unterschied im Verhalten gibt.
