Ich stelle hier die Frage, vielleicht habe ich etwas übersehen, aber ich weiß, dass es Arbeit an den Aggregationen über 24h / 7 Tage / … gegeben hat.
Das Problem, das ich feststelle, ist, dass es absolut unbrauchbar ist, wenn man 7 Tage für einen Temperatursensor einstellt.
Ich möchte die verschiedenen Temperaturabfälle im Haus nachts vergleichen und mit dem Tag vergleichen. Wenn ich 24 Stunden einstelle, ist das sehr gut, ich sehe die Temperaturänderungen insgesamt. Aber über 7 Tage, totale Flaute.
Natürlich, bei 7 Tagen 1 Punkt pro Tag, sehe ich nicht den Sinn, diese Information nutzen zu können.
Es wäre meiner Meinung nach besser, 1 Punkt pro Stunde zu haben, besonders über 7 Tage?
Ich finde auch, dass dieser Teil der Grafiken eher unpraktisch ist (vielleicht ist er in anderen Fällen aber doch praktisch). Aber ja, ich nutze die Grafiken auch für die Temperaturen und sobald man über 24 Stunden hinausgeht, ist es an sich nicht nutzbar.
Eigentlich könnte ein Punkt pro Tag nützlich sein, wenn man die Daten tatsächlich nutzt, also zum Beispiel einen Durchschnitt, ein Maximum, ein Minimum berechnet. Wenn man also mehrere Informationen pro Tag erzeugt. Und in diesem Fall könnte man die Graphen ein bisschen besser nutzen.
Diese Intervalle können angepasst werden, aber man sollte bedenken, dass je mehr Daten angefordert/angezeigt werden, desto langsamer wird die Anzeige. Es muss also ein guter Kompromiss zwischen zu vielen und zu wenigen Daten gefunden werden!
Ok danke für die Rückmeldung, jetzt verstehe ich besser.
In diesem Fall bin ich einverstanden, wir können die Datenbank „explodieren“ lassen, wenn wir zu viele Daten behalten. Aber in einem anderen Sinne, wenn die Daten nicht nutzbar sind, können wir sie auch einfach löschen
Meiner Meinung nach sollten die Daten nutzbar sein:
innerhalb einer Woche, ein Punkt pro Stunde
innerhalb eines Monats, 4 Punkte pro Tag? (0 Uhr / 6 Uhr / 12 Uhr / 18 Uhr) Das ist übrigens für Temperatursensoren recht repräsentativ für die Realität, da die Arbeitszeiten und das Abschalten der Heizung etc. berücksichtigt werden
darüber hinaus, aktuell sieht man am Diagramm (unmöglich zu zoomen / auf einen bestimmten Tag zurückzugehen), man könnte vielleicht so lassen, außer > 6 Monate => 2 / 4 Punkte pro Monat, das kostet nicht viel
Was denkst du dazu?
Man könnte immer zwei Betriebsmodi mit einer Konfiguration im Dashboard haben, die erklärt, wie die Aggregation funktioniert? Ein „Speicherplatzsparmodus“ und ein „Hochlastmodus“.
weiß ich nicht unbedingt, ob das nützlich ist. Wir haben die Daten, nutzen sie aber nicht.
Bei Thanos zum Beispiel (Backend zur Auswertung von Metriken aller Art, System / Anwendung) haben wir die Möglichkeit, Aggregationen auf Daten durchzuführen, die älter als x Tage / Monate sind.
Daher können wir statt der rohen Daten unbegrenzt zu speichern, sagen, nach 1 Monat nur noch 1 Punkt alle 10 Minuten statt jede Minute und dann nach 3 Monaten 1 Punkt alle h
hallo,
ohne unhöflich sein zu wollen, stellt sich hier die Frage nach der Funktionalität der Berechnungsmethode der Diagramme!
Denn ab 24 Stunden zeigt das Diagramm „gemittelte“ Werte an, was in vielen Fällen für eine Nachverfolgung (Wetterdaten, Raumtemperatur, Gewächshaus, Aquarium usw.) wenig Sinn macht.
Zum Beispiel in den letzten Tagen hatte ich bei 24-Stunden-Daten für Dienstag und Mittwoch Regenwerte von 17 mm und 38 mm. Jetzt, wenn ich das 7-Tage-Diagramm ansehe, zeigt es mir für Dienstag 11 mm und für Mittwoch 29 mm an, was weit von der Realität entfernt ist und für eine Nachverfolgung keinen Sinn ergibt. Daher mein Wunsch, „Max“- oder „Min“-Werte verwenden zu können…
Die bloße Berechnung von Minimal- oder Maximalwerten löst das „Problem“ nicht unbedingt.
Angenommen:
wir produzieren Minimal-, Maximal- und Durchschnittswerte pro Tag im Fall des 7-Tage-Grafen oder mehr
wir fügen Punkte hinzu (z. B. stündlich statt täglich)
Ich mag jedoch Minimal-/Maximalwerte nicht besonders, denn sie sind nicht unbedingt für jeden verständlich und ich finde sie in Gladys schwer nutzbar. Ein Graph mit einem Durchschnitt, der häufiger erfasst wird, ist meiner Meinung nach leicht nutzbar und visualisierbar.
abhängig von der Nutzung, für Wetterdaten oder die Temperaturüberwachung eines Gewächshauses oder Aquariums sagt der Durchschnitt nichts aus: Mittwoch 38 mm Regen in absoluten Zahlen hat Sinn, aber 29 mm im Durchschnitt im 7-Tage-Graphen sagen nichts mehr aus. Es hängt alles von der Nutzung der Graphen ab, die man macht. Für mich bedeutet das Fehlen dieser Funktion in Gladys, dass ich eine separate App für das Wetter und eine andere für mein Gewächshaus nutzen muss. Dadurch verliert Gladys als Smart-Home-App ein wenig an Sinn, wenn man mehrere Apps nutzen muss. Gleichzeitig muss man andere Integrationen entwickeln (was gut ist, aber…).
Gladys kann von allen mit unterschiedlichen Bedürfnissen genutzt werden, daher muss man großzügig planen. Deshalb spreche ich von Minimal-, Maximal- und Durchschnittswerten, die es ermöglichen, die meisten Möglichkeiten abzudecken, auch wenn der Durchschnitt in deinem Fall nicht nützlich ist, in anderen Fällen aber schon.
Und natürlich muss man auch eine Entscheidung treffen, die einfach umzusetzen ist und nicht zu viel Entwicklungszeit in Anspruch nimmt.
Achtung, hier geht es nur um die Anzeige! Die Speicherung erfolgt auf eine andere Weise, das ist von dem, worüber wir hier sprechen, entkoppelt.
Ich denke, das ist ein guter Anfang, das zu ändern. Das wären 7 * 2 = 168 Punkte pro Woche, das ist nicht verrückt.
Man könnte sogar 6 Punkte setzen, das bliebe im gleichen Umfang wie für eine Woche (6*30 = 180), das ist kohärent. Mal sehen, wie man das in SQL umsetzt
Ja, ich bin zu 100% deiner Meinung, in dem aktuellen Zustand sind die Langzeitdiagramme für Regensensoren nicht nutzbar. Allerdings scheint mir, dass deine Anfrage nicht so viel Popularität hatte?
ich bin mir nicht sicher, ob jeder den Nutzen versteht (zu sehr auf Alarm-Überwachung und Motorisierung fokussiert… auf kurze Sicht, aber nicht auf eine langfristige Verfolgung) und das ist wirklich schade, denn um den Anwendungsbereich dieses Tools zu erweitern, wäre das sehr nützlich.
Und parallel dazu bin ich mir nicht sicher, ob alle Entwicklungen (spontane Entwicklungen) systematisch Gegenstand von Anfragen oder Abstimmungen sind, die sehr wichtig sind.
Ich bezweifle nicht diese Entwicklungen, aber man sollte nicht systematisch bestimmte Anfragen auf die langen Bank schieben (oder unter den Teppich kehren), was mir hier der Fall zu sein scheint (wie z. B. zwave js, von dem man nichts mehr hört…).
Wenn wir die grafische Ansicht anzeigen, kannst du zwischen 4 Datensätzen wählen: Live, stündliche Daten, tägliche Daten oder monatliche Daten.
Die Idee deines Feedbacks war es, die Abfrage zu ändern, die bei der Anzeige die Daten abruft und gruppiert. Der Teil der Berechnung der aggregierten Daten ändert sich nicht
Okay, ich habe ein paar Dinge gesehen, die geändert werden müssen. Ich werde die entsprechenden Änderungen vornehmen. Ich dachte, wir wollten die Anzahl der Punkte pro Anzeigedauer der Graphen genauer festlegen. Aber kein Problem, ich hatte diese Datei bereits entdeckt
