Hallo zusammen, hallo @pierre-gilles,
Hier ist eine Idee, zu der ich gerne deine Meinung hören würde, bevor ich weitergehe: die Möglichkeit, eine Dashboard-Karte aus mehreren Elementen (Werten, Anzeigen, Diagrammen) zu komponieren, die aus beliebigen Geräten von Gladys ausgewählt werden.
Die Feststellung
Heute entspricht ein Widget einer Funktion. Um einen Raum zu überwachen, staple ich zum Beispiel:
- ein Widget „Raumtemperatur“ für den aktuellen Wert,
- ein Widget „Diagramm“ für den Verlauf,
- ein Widget „Anzeige“ für die Luftfeuchtigkeit.
Das sind drei Karten, jede mit ihrem eigenen Titel, ihren Rändern und leerem Raum, für Informationen, die zusammengehören. Besonders auf dem Handy scrollt man schnell viel Bildschirm für wenig Information.
(Ich weiß, dass das Diagramm-Widget bereits den letzten Wert und die Veränderung über der Kurve anzeigt: Das deckt den einfachsten Fall ab, aber nicht die Mischung aus mehreren Geräten oder mehreren Anzeigetypen.)
Was das ermöglichen würde
Einige konkrete Beispiele:
- Ein Raum auf einer Karte: Temperatur und Luftfeuchtigkeit als Kacheln, Temperaturverlauf über 24 Stunden darunter.
- Energie: Anzeige der momentanen Leistung + Diagramm des Wochenverbrauchs.
- Vergleich: Zwei Diagramme nebeneinander (Innen-/Außentemperatur, Solarproduktion/-verbrauch).
- Heizung: Sollwert, gemessene Temperatur und Zustand des Ventils als Kacheln, mit dem Verlauf der gemessenen Temperatur.
- Außenseite: Einige Werte der Wetterstation + die Regenkurve.
Warum ich das nicht mit einer externen Integration gemacht habe
Ich habe geschaut, ob die Widgets der externen Integrationen (Gladys 5.1) dafür geeignet wären, da ihr Format schon fast alles hat: Zeile mit Kacheln (Wert, Anzeige), Diagramm verbunden mit dem Geräteverlauf, Text…
Aber zwei Dinge verhindern das, und das ist normal:
- Ein Integrations-Widget kann nur seine eigenen Geräte zitieren. Der Kern kennt keine Geräte einer anderen Integration (ein Diagramm, das eines zitiert, wird komplett entfernt). Das ist eine gewollte Isolation, und ich finde sie gesund.
- Nur ein Hauptelement pro Karte (Diagramm, Liste oder Bild), in einer vom Kern festgelegten Reihenfolge: keine Diagramme nebeneinander.
Der einzige mögliche Umweg wäre eine Integration, die die Gladys-API mit einem API-Schlüssel liest, um „flache“ Daten zurückzugeben. Das würde funktionieren, aber ohne Echtzeit, mit einem Vollzugriffsschlüssel in einem Drittanbieter-Container und gegen den Geist der Isolation. Ich möchte da nicht ohne deine Meinung weitermachen.
Zwei mögliche Ansätze
Ansatz A — ein natives „Komposit“-Widget (meine Präferenz)
Ein neuer Widget-Typ im Kern, dessen Bearbeitung darin besteht, Blöcke hinzuzufügen:
- mögliche Blöcke: Wert, Anzeige, Diagramm (unter Wiederverwendung der bestehenden Widgets);
- einfache Anordnung: eine oder zwei Spalten, die Blöcke stapeln sich in der gewählten Reihenfolge;
- jeder Block verweist auf beliebige Gerätefunktionen, über denselben Selektor wie die aktuellen Widgets.
Vorteile: Nichts verlässt den Kern, keine neuen Sicherheitsfragen, Echtzeit über Websocket wie bei den anderen Widgets, und der Code der bestehenden Widgets kann wahrscheinlich weitgehend wiederverwendet werden.
Ansatz B — Erlaubnis für Integrations-Widgets, Geräte auszuwählen, die vom Benutzer gewählt wurden
Eine Widget-Einstellung vom Typ „Gerät“, die alle Geräte anbietet (und nicht nur die der Integration). Der Benutzer gibt seine ausdrückliche Zustimmung, Gerät für Gerät, beim Konfigurieren des Widgets.
Vorteil: Die Community könnte alle Arten von Layouts veröffentlichen, ohne den Kern zu berühren. Nachteil: Das öffnet eine Lücke in der Isolation, da eine Integration Daten lesen könnte, die nicht ihre eigenen sind. Und es löst nicht das Problem eines einzigen Diagramms pro Karte.
Die Auswirkungen, die ich sehe
- Leistung: Eine Karte mit mehreren Diagrammen macht so viele Anfragen für den Verlauf. Eine Begrenzung (z. B. 4 Blöcke, 2 Diagramme) würde die Dinge vernünftig halten, besonders auf dem Raspberry Pi.
- Mobil: Zwei Spalten nebeneinander müssen wahrscheinlich auf kleinen Bildschirmen in eine einzige Spalte umgewandelt werden.
- Bearbeitung: Das Formular eines Komposit-Widgets ist komplexer als das der anderen Widgets. Es muss einfach zu bedienen bleiben.
- Wartung: Ansatz A fügt einen Widget-Typ zur Wartung hinzu. Ansatz B verlagert diese Arbeit zu den Integrationen, berührt aber das Sicherheitsmodell.
- Kompatibilität: Beide Ansätze sind additiv. Kein bestehendes Widget wird geändert.
Meine Fragen
- Spricht dich das Bedürfnis an, und siehst du das im Kern?
- Ansatz A, Ansatz B oder etwas anderes (z. B. einfach die Widgets Diagramm und Anzeige mehrere Werte anzeigen lassen)?
- Ist die Isolation der Integrations-Widgets ein Prinzip, das nicht angetastet werden sollte?
Wenn dir Ansatz A zusagt, würde ich gerne den Pull Request übernehmen, unter deiner Anleitung zum Umfang.
Danke!