Status: Entwurf, offen für Diskussion
Diskussion: dieses Foren-Thema
Hallo zusammen,
Ich schlage ein neues Feature vor, das die Art und Weise, wie Integrationen in Gladys entwickelt werden, verändern wird.
Es ist ein lang gereiftes Projekt, und ich würde mich freuen, euer Feedback, eure Ideen und eure Anmerkungen zu erhalten, um es weiter zu verbessern 
Warum jetzt
Seit Beginn des Projekts leben alle Integrationen von Gladys im Core. Jeder kann eine entwickeln oder über einen Pull Request verbessern, aber jede Zeile muss von mir überprüft werden, bevor sie gemerged wird. Diese Wahl hat einen enormen Vorteil: Wenn ihr Gladys installiert, ist alles bereits vorhanden. Kein Store, keine Abhängigkeiten zu verwalten, keine kaputten Plugins nach einem Update. Das ist einer der Gründe, warum Gladys einfacher zu bedienen ist als andere Lösungen.
Aber dieses Modell hat eine Grenze, und ich stoße langsam daran. Es gibt tausende Marken, Protokolle, Dienste, und die geringste Änderung einer Integration, selbst eine einfache Übersetzung, muss über mich laufen: Review, Merge, Release. Das ist nicht skalierbar, und es macht mich zum Engpass des Projekts.
Man könnte denken, dass Matter dieses Problem lösen wird. Matter kommt, und wird meiner Meinung nach zum Referenzprotokoll, das alle verbundenen Geräte in der Zukunft steuern wird: ein einziger Standard, alle Geräte nativ kompatibel, keine Integration pro Marke mehr nötig. Aber wir wissen nicht, wann diese Zukunft Realität wird, und das Projekt kann es sich nicht leisten, unbestimmt auf den Wechsel des installierten Parks zu warten.
Und vor allem deckt Matter nur die Steuerung verbundener Geräte ab. Es gibt noch einen ganzen Bereich von Integrationen, die nichts mit Geräten zu tun haben: Kommunikation (Telegram, etc.), Wetter (OpenWeather, Météo France), Kalender (CalDAV, Google Calendar)… All das wird nie über Matter laufen. Wenn wir wollen, dass Gladys zu einem Projekt mit der gleichen Ambition wie Home Assistant wird, müssen wir die Installation externer Integrationen ermöglichen.
Diese RFC schlägt daher vor, Gladys für externe Integrationen zu öffnen: Integrationen, die von jedermann entwickelt und veröffentlicht werden, ohne vorherige Validierung durch mich, installierbar mit einem Klick aus der Benutzeroberfläche.
Die Herausforderung besteht darin, dies zu tun ohne das zu opfern, was Gladys ausmacht. Konkret wurden vier nicht verhandelbare Anforderungen diese Vorschlag geleitet:
- Eine Integration, die abstürzt, darf Gladys nie zum Absturz bringen.
- Keine unverständlichen Zustände: Wenn eine Integration nicht mehr antwortet, muss der Benutzer dies sehen und etwas unternehmen können.
- Die Benutzeroberflächen müssen sauber und untereinander konsistent bleiben.
- Null technische Manipulation für den Benutzer. Kein Terminal, kein YAML, kein manuelles Neustarten.
Was diese RFC nicht vorschlägt
- Wir ersetzen nicht die nativen Integrationen. Die Integrationen der universellen Protokolle (Matter, Zigbee, Z-Wave…) bleiben immer im Core, vorinstalliert, wie heute gepflegt. Das neue System wird daneben hinzugefügt und zielt auf alle Integrationen von Protokollen oder Diensten ab, die nicht universell sind: Von nun an kann jeder eine separate Integration erstellen.
- Wir zielen nicht auf die Kompatibilität mit den Home Assistant / HACS-Integrationen ab. Sie sind tief mit der Architektur von HA gekoppelt; sie in Gladys auszuführen ist unrealistisch. Allerdings lasse ich mich von ihrem Verteilungsmodell inspirieren (Git-Repository + Manifest + Store).
- Wir erlauben den Integrationen nicht, Code in die Benutzeroberfläche zu injizieren. Das ist eine bewusste Entscheidung, die weiter unten detailliert wird.
Vorgeschlagene Architektur
Ein Docker-Container pro Integration
Gladys läuft bereits ausschließlich in Docker, mit dem Docker-Socket gemountet. Wir nutzen dies: Jede externe Integration läuft in ihrem eigenen Container, erstellt und überwacht durch den Gladys-Core.
Dieser Container ist maximal gesperrt:
- Kein privilegierter Modus, kein Zugriff auf das Docker-Socket
- Kein Zugriff auf die Datenbank oder die Dateien von Gladys
- Read-only-Dateisystem, außer einem kleinen Datenverzeichnis, das ihm eigen ist
- Strenge Grenzen für Speicher, CPU und Anzahl der Prozesse
- Netzwerk eingeschränkt auf die Hosts, die die Integration in ihrem Manifest deklariert hat.
Eine Integration, die abstürzt, die Speicherlecks hat oder die in eine Endlosschleife gerät, bleibt in ihrem Container eingeschlossen. Und eine böswillige oder schlecht geschriebene Integration kann nicht „die Datenbank direkt ändern“: Die SQLite-Datei existiert einfach nicht in ihrem Dateisystem.
Diese Wahl bringt einen wichtigen Bonus: Die Integrationen sind nicht mehr auf Node.js beschränkt. Ein Docker-Image kann Python, Go, Rust enthalten. Jeder Autor packt seine Abhängigkeiten in sein Image, und der gesamte Build wird im Voraus, zum Zeitpunkt der Veröffentlichung, und nie zur Laufzeit beim Benutzer erledigt.
Langfristig bringt diese Wahl auch etwas Interessantes: Es wird möglich sein, entfernte Integrationen auszuführen!
Alle Kommunikation läuft über die Host-API
Eine Integration greift nie auf die Internals von Gladys zu. Ihr einziger Zugang ist eine Host-API: Die Integration kommuniziert mit dem Core über eine einfache REST HTTP JSON API, im gleichen Geist wie das, was bereits in Gladys heute existiert.
Die für die v1 vorgesehenen Grundlagen:
- Geräte und deren Funktionen im bestehenden device/feature-Modell von Gladys deklarieren;
- Zustände veröffentlichen und Befehle empfangen
- Konfiguration und Geheimnisse speichern (in der DB auf der Core-Seite gespeichert)
- Strukturierte Logs schreiben
- Eine vermittelte Netzwerkentdeckung anfordern: Es ist der Core, der Zugriff auf das Netzwerk des Hosts hat, der die mDNS-Scans und den Passthrough der USB-Geräte durchführt und dann die Ergebnisse überträgt. Die Integration benötigt somit nie den Modus
hostoder direkten Hardwarezugriff.
Dieser Vertrag auf Protokollebene ist das eigentliche Fundament des Vorschlags. Der Container ist „nur“ der Mechanismus, der diesen Vertrag unumgehbar macht. Er ermöglicht auch die Weiterentwicklung des internen Schemas von Gladys ohne das Ökosystem zu brechen: Solange die Host-API stabil ist, funktionieren die Integrationen weiter.
Überwachung: Keine Zombie-Zustände
Der Core enthält einen Supervisor, der den gesamten Lebenszyklus jeder Integration verwaltet, mit einer Zustandsmaschine immer sichtbar in der Benutzeroberfläche:
Installiert → Start → Laufend → Degradiert → Fehlerhaft → Gestoppt
Der Supervisor sendet regelmäßig ein Heartbeat an jede Integration. Keine Antwort? Die Integration wechselt in „Degradiert“ und wird automatisch neu gestartet, mit einer zunehmenden Verzögerung zwischen den Versuchen. Wenn sie in einer Schleife abstürzt, hört man auf, darauf zu bestehen: Sie wechselt in „Fehlerhaft“, und der Benutzer sieht eine klare Nachricht mit den Logs der Integration und den möglichen Aktionen (neu starten, deaktivieren, dem Entwickler melden).
Alle Aufrufe zwischen dem Core und der Integration haben ein Timeout. Eine Integration, die hängt, blockiert Gladys nie.
Das Ziel: Es sollte keinen nicht beobachtbaren oder nicht wiederherstellbaren Zustand mehr geben. Wenn etwas nicht stimmt, sieht man es, versteht es, handelt, alles aus der Benutzeroberfläche.
Benutzeroberfläche: Deklarativ, kein beliebiger Code
Das ist wahrscheinlich die am meisten diskutierbare Wahl dieser RFC, also ist es besser, sie klar zu vertreten.
Die Integrationen liefern keine Benutzeroberflächenkomponenten. Sie beschreiben ihre Bedürfnisse, und es ist Gladys, der die Benutzeroberfläche mit seinem eigenen Design-System rendert:
- Die Konfiguration wird durch ein Schema (z. B. JSON Schema) beschrieben: Gladys generiert das Formular, die Validierung, die Fehlermeldungen, auf identische Weise für alle Integrationen;
- Geräte werden im bestehenden device/feature-Modell deklariert: Sie werden automatisch mit den gleichen Karten und Steuerungen wie die nativen Integrationen angezeigt;
- Für spezifischere Bedürfnisse wird ein Vokabular deklarativer Widgets definiert und schrittweise erweitert, basierend auf den tatsächlichen Bedürfnissen, die von den Entwicklern gemeldet werden.
Was es kostet: Ein Entwickler kann keinen vollständig maßgeschneiderten Bildschirm erstellen. Was es garantiert: eine konsistente Schnittstelle überall, keine XSS-Lücken von einem Plugin, keine Frontend-Versionenkonflikte und eine identische Erfahrung für den Benutzer, unabhängig vom Ursprung der Integration. Angesichts der Projektprioritäten denke ich, dass dies der richtige Kompromiss ist. Aber genau das ist die Art von Punkt, auf den ich eure Rückmeldungen erwarte.
Verteilung: Ein Store in Gladys
Der Benutzer entdeckt und installiert Integrationen über einen in die Oberfläche integrierten Store. Installieren = ein Klick. Der Kern lädt das Bild herunter, überprüft es, startet den Container und zeigt das Konfigurationsformular an, falls die Integration Anmeldedaten benötigt. Kein Terminal, keine Dateien zum Bearbeiten.
Jede Integration wird mit einem Manifest veröffentlicht: Name, Version, kompatible Gladys-Versionen, angeforderte Berechtigungen (Netzwerkhosts, Geräte), Konfigurationsschema. Die Berechtigungen werden dem Benutzer vor der Installation angezeigt, wie in einem mobilen Store.
Alle externen Integrationen sind „communitybasiert“: Ich plane nicht, sie einzeln zu überprüfen, das würde in die Flaschenhalsituation zurückfallen, die diese RFC gerade zu beseitigen versucht. Eine klare Warnung wird bei der Installation angezeigt, um darauf hinzuweisen, dass es sich um nicht überprüften Fremdcode handelt. Die Aufgabe der deklarierten Berechtigungen und der Containerisolierung besteht darin, diese Öffnung akzeptabel zu machen.
Eine Integration in der Ära der KI entwickeln
Ein Punkt, der alles im Vergleich zu vor einigen Jahren verändert hat: Die Entwicklung einer Integration ist dank KI sehr einfach geworden. Meine Absicht ist es, ein offizielles, sauberes und dokumentiertes Integrationstemplate bereitzustellen. Ausgehend von diesem Template kann mit Claude Code/Cursor die Erstellung einer Integration für einen bestimmten Dienst oder ein bestimmtes Protokoll in wenigen Stunden statt in wenigen Tagen erfolgen.
Dadurch wird dieser Vorschlag wirklich mächtig: Statt zu warten, dass ich jede Integration entwickle oder überprüfe, kann die Community viel mehr und viel schneller produzieren.
Das Tempo, mit dem neue Integrationen erscheinen, wird nicht mehr durch meine Verfügbarkeit begrenzt.
Vorgeschlagener Fahrplan
- Definieren Sie die Host-API und das SDK und bitten Sie einige Entwickler, die ersten externen Integrationen darauf zu erstellen.
- Spezifizieren Sie das Manifest und das Schema der deklarativen Schnittstelle.
- Implementieren Sie den Supervisor und den Start von gesperrten Containern als Proof of Concept für eine einzige Integration.
- Bauen Sie den Store und den Installationspfad mit dem offiziellen Integrationstemplate.
- Öffnen Sie die Veröffentlichung für alle.
Mein Ziel ist es, dieses neue System so schnell wie möglich einzuführen: Mit den KIs ist es möglich, sehr schnell voranzukommen.
Ich plane, die Arbeit diese Woche mit Fable 5 zu beginnen, solange es verfügbar ist.
Offene Fragen an die Community
- Finden Sie den Kompromiss „Nur deklarative UI“ akzeptabel? Welche echten Anwendungsfälle würden nicht darunter fallen?
- Welche Primitiven fehlen in der Host-API für Ihre Traumintegrationen?
- Sollte die v1 auf Node.js-Integrationen (mit einem offiziellen SDK) beschränkt werden, um es zu vereinfachen, oder alle Sprachen von Anfang an öffnen?
Dieser Vorschlag ist ein Ausgangspunkt, keine in Stein gemeißelte Entscheidung: Eure Kritik, Einwände und Ideen sind genau das, was ich brauche, um ihn zu verbessern
, aber ich finde die Idee ausgezeichnet, denn sie wird es ermöglichen, einen großen Sprung nach vorne zu machen, was die Möglichkeiten von Gladys betrifft, mit HA zu konkurrieren. Und das wird es jedem ermöglichen, „einfach“ zur Verbesserung von Gladys beizutragen, die mit einem intakten Kern bleibt!
) und eine lokale Videoüberwachung Frigate/go2rtc (siehe meinen Post), die Docker-Container, GPU und Video-Streams orchestriert. Meine Rückmeldungen basieren auf diesen beiden Erfahrungen.
