Es wäre interessant, einen oder mehrere Dienste auf einen anderen RPI auszulagern.
Beispiel:
Mein Gladys 4 ist auf einem Synology-NAS installiert.
Ich möchte die Anwesenheitserkennung über Bluetooth nutzen und möchte daher den Bluetooth-Dienst auf einen dedizierten RPI Zero auslagern.
Hallo, ich sehe, dass du dich für die Teilnahme an der Entwicklung bewirbst, aber hast du eine Idee, wie man vorgehen soll? Ich bin generell sehr am Konzept interessiert, auch wenn ich nicht denke, dass ich es selbst benötige.
@AlexTrovato Ich denke, es geht um das Konzept des „Gladys Pod“, über das wir ausführlich gesprochen haben 
Das Ziel wäre es, „Pods“ zu haben, die mit einem Haupt-Gladys kommunizieren (wahrscheinlich über MQTT)
Man müsste sehen, wie sich das in Bezug auf die Benutzererfahrung auswirkt. Installiert der Benutzer ein vollständiges Gladys auf einer anderen Maschine und aktiviert dann ein „Pod“-Modul auf der Instanz?
Installiert der Benutzer einfach ein „Pod“-Image, das nur den Code bestimmter kompatibler „Pod“-Dienste enthält und alle Daten per MQTT an den Master sendet? (Und wie konfiguriert man diesen Dienst ohne CLI?)
Ich denke, es gibt viel zu diskutieren, aber auf jeden Fall ist es ein interessantes Thema, das wir ohnehin irgendwann behandeln würden 
Das könnte mich auch interessieren! Da ich meine Verbrauchsinformationen nicht von Enedis abrufen kann, werde ich gezwungen sein, über TIC zu gehen. Und eine der Lösungen besteht darin, dies an eine RPi Zero anzuschließen. Und ich hatte die Idee, diese Informationen über MQTT an Gladys zu senden.
Die Idee wäre, eine Gladys Lite-Instanz mit nur bestimmten Integrationen zu erstellen?
Mehr oder weniger, das ist noch zu definieren!
Die Idee ist, einen „Haupt“-Gladys zu haben und kleine Pods, die Informationen zurückgeben.
Bisher hatte ich die Idee nur zu Beginn der v4 theoretisiert, aber nichts ist bisher definiert, alles bleibt noch zu tun
@pierre-gilles Wenn ich dein Pod-Konzept richtig verstanden habe, geht es darum, einen Gladys zu starten, bei dem alles außer den Diensten deaktiviert ist, und einen Event-Handler zu haben, der alle Events in ein (oder mehrere) MQTT-Topic(s) an den „Haupt“-Gladys überträgt?
@cbe317 Im Prinzip genau das
Ich hatte sogar ein Schema im technischen Manifest gemacht:
Jetzt müsste man definieren, wie man es funktionieren lassen möchte:
Ich denke, das wäre die einfachste und praktischste Idee für den Benutzer. Mit der Möglichkeit, die zu deployenden Dienste auszuwählen. (Wie groß ist eine leere Version von Gladys?)
Das ist doch nichts Ich glaube, Gladys complet wiegt etwa 120 MB.
Wie du sagtest, scheint eine Installationsoption, die angibt, dass die Instanz ein Pod ist, eine gute Option zu sein. Es ist nicht nötig, mit einer „Lite“-Instanz zu beginnen, angesichts ihres Gewichts.
Grundsätzlich ist die Plattform des Benutzers das Haupt-Gladys und vor allem das Dashboard. Wenn wir die Philosophie der Einfachheit beibehalten und verhindern wollen, dass der Benutzer die Hände schmutzig machen muss, könnte ich mir eine Standardverbindung vorstellen.
Man könnte sich während der Installation, nachdem man ausgewählt hat, dass ein Pod installiert wird, eine Informationsseite vorstellen, auf der man die IP des Hauptservers oder einen MQTT-Server angibt, an den man sich anschließen wird.
