Die Matterbridge-Plugin-Fabrik: Machen Sie jedes Gerät mit Gladys kompatibel

Erfahrungsbericht: Warum ich nun externe Integrationen statt Matterbridge empfehle

Hallo zusammen :waving_hand:

Nach dem Release der externen Integrationen in Gladys möchte ich euch meinen Erfahrungsbericht zu Matterbridge teilen und erklären, warum ich nun die Nutzer auf externe Integrationen umleiten werde.

Als ich Matterbridge entdeckte, fand ich das Konzept wirklich ausgezeichnet: Es ermöglicht, Geräte „vor Matter“ mit Gladys kompatibel zu machen, dank einer Abstraktionsschicht. Ich habe daran geglaubt, diese Lösung empfohlen und sogar einige Entwicklungen in diese Richtung gelenkt, in der Hoffnung, dass sie mehr Nutzern den Einstieg in das Gladys-Ökosystem erleichtert.

Nach etwa zwei Monaten Nutzung und Feedback der Community muss ich jedoch zugeben, dass ich mit diesem Ansatz nicht mehr vollständig zufrieden bin. Im Nachhinein denke ich, dass die externen Gladys-Integrationen in jeder Hinsicht überlegen sind, und dies wird nun die Lösung sein, die ich empfehle.

Warum?

1. Eine viel robustere Benutzererfahrung

Matterbridge ist ein sehr gutes Projekt, aber es ist vor allem von Entwicklern für Entwickler gedacht.

Aus den Rückmeldungen, die ich im Forum lesen konnte, ist die Erfahrung oft kompliziert, sobald etwas nicht funktioniert. Die Probleme sind schwer zu diagnostizieren, und die Lösungen sind nicht immer offensichtlich.

Meiner Meinung nach liegt das hauptsächlich an den technischen Entscheidungen, die getroffen wurden.

Matterbridge funktioniert ein wenig wie Gladys v3: Die Plugins werden direkt im Hauptcontainer installiert, mit einer Installation der Abhängigkeiten bei der Ausführung (runtime). Dieser Ansatz ist praktisch am Anfang, wird aber schnell fragil: Ein Update einer Abhängigkeit kann ein Plugin ohne Vorwarnung beschädigen.

Die externen Integrationen von Gladys verfolgen einen völlig anderen Ansatz:

  • jede Integration ist in ihrem eigenen Container isoliert;
  • die Abhängigkeiten werden zum Zeitpunkt des Builds installiert und nicht bei der Ausführung;
  • eine Integration kann die anderen nicht beschädigen;
  • die Updates sind viel vorhersehbarer.

Diese Architekturentscheidung ändert alles in Bezug auf Stabilität.

2. Die Grenzen von Matter bleiben die Grenzen von Matter

Matterbridge ist weiterhin vom Matter-Standard abhängig.

Wenn bestimmte Geräte heute noch nicht Matter-kompatibel sind, ist das meistens kein Zufall: Es liegt oft daran, dass das Protokoll noch nicht alle Funktionen ausdrücken kann oder bestimmte Gerätetypen in der Spezifikation einfach nicht existieren.

Mit anderen Worten, Matterbridge wird immer durch die Möglichkeiten begrenzt sein, die Matter bietet.

Im Gegensatz dazu kann eine externe Gladys-Integration 100 % der Fähigkeiten eines Geräts nutzen, ohne durch einen Zwischenstandard eingeschränkt zu werden.

3. Eine Abhängigkeit weniger

Schließlich ist Matterbridge ein externes Projekt.

Wenn einige Nutzer auf Bugs stießen, war das oft frustrierend für mich, weil ich sie einfach nicht beheben konnte. Ich war von der Entwicklung eines anderen Projekts abhängig.

Mit externen Integrationen haben wir die volle Kontrolle über die Plattform. Entwickler können ihre Integrationen frei veröffentlichen, sie in ihrem eigenen Tempo weiterentwickeln, und wir können das Ökosystem verbessern, ohne von einer Zwischenschicht abhängig zu sein.

Und jetzt?

Jetzt, wo externe Integrationen existieren, sehe ich keinen Grund mehr, Matterbridge für diesen Zweck weiter zu empfehlen.

Externe Integrationen erfüllen genau dieselbe Funktion, mit besserer Stabilität, besserer Benutzererfahrung und viel mehr Möglichkeiten.

Im Laufe der Zeit, wenn externe Integrationen die Matterbridge-Plugins ersetzen, die ich empfohlen habe, werde ich die Dokumentation aktualisieren und schrittweise die Matterbridge-Tutorials zugunsten dieser neuen Integrationen entfernen.

Was die Plugin-Fabrik betrifft, sie stellt monatliche Kosten dar (Server + KI). Ich denke nicht, dass ich sie langfristig beibehalten werde: Ich möchte diese Ressourcen lieber direkt in die Entwicklung von Gladys investieren. :grinning_face_with_smiling_eyes:

Zum Schluss

Ich hoffe, ihr versteht diesen Positionswechsel. Es ist nicht „Wetterfahne spielen“: Die KI verändert unsere Art zu entwickeln in atemberaubendem Tempo, und ich denke, es ist wichtig, seine Entscheidungen infrage zu stellen, wenn bessere Lösungen auftauchen.

Am Ende behalte ich vor allem eines aus diesem Abenteuer: Matterbridge hat mir die Idee gegeben, die zu den externen Integrationen von Gladys führte.

Ohne diese Erfahrung wäre diese Funktion wahrscheinlich nie entstanden. Und heute denke ich aufrichtig, dass es eine der wichtigsten Entwicklungen von Gladys seit langem ist.

Danke an euch alle für euer Feedback, eure Tests und euer Vertrauen :heart: