[Featurewunsch] Datenkomprimierung nach bestimmter Zeit

[Brick]

Hallo,

weiß jetzt nicht, ob es den Wunsch schon gab/gibt... aber ich kuck mir gerade wieder so die Daten der Datenarchive per SQLyog an..
und stell mir die Frage ob es nicht eine einfache Möglichkeit gäbe (ähnlich RRDTools) bei älteren Werten die Auflösung zu ändern.
Ich hab zb. bei der Außentemperatur 5 min. für 1 Jahr eingestellt.. das ist zwar nett.. aber jetzt nach einem Jahr würde mir das
für die älteren Werte vielleicht stündlich reichen..
Per SQL hab ich schon genau das geschafft.. einfach alle Werte bis auf die Stündlichen zu löschen.. Das ist zwar einfach aber auch nicht
100% korrekt.. eigentlich müsste der Durchschnitt aus den Werten der Stunde errechnet werden und also stündlicher Wert eingetragen werden.
Auch das war/ist machbar... aber alles sehr mühsam..

Schick wäre hier ein LBS der zb. einmal täglich über die Archive drüber schaut... bzw. noch schicker, wenn das Nativ von Edomi aus gehen würde..

habt ihr da eine bessere Idee ?

Gruß Martin

[ChrisAllgaeu]

Ich nutze die RRD Tools intensiv fuer meine Heizungssteuerung (laeuft noch parallel zu Edomi, mit Heizungssteuerung meine ich hier die Steuerung der Solaranlage, Pelletheizung, Brauchwasser, Puffersteuerung, OelTherme und Heizkreisvorlauftemperaturregelungen). Das hab ich alles auf einem RasPi der mir einen Ringspeicher auf einem NAS jede 10 Sekunden mit 32 Messwerten aus der Anlage fuettert. RRD like wird das dann taeglich, monatlich und jaehrlich "komprimiert". Ich ueberleg mir schon lange, wie ich die RRD Funktionalitaet auch in Edomi rein bekomme, sollte per LBS nicht so aufwendig sein, da das RRD Toolset ja relativ simpel installiert werden kann... Mal sehen, der naechste Winter kommt bestimmt. Mir gefallen die graphischen Ausgabemoeglichkeiten beim RRD extrem gut, momentan gehe ich den Umweg, dass ich mir ein JPG als Grafik aus dem RRD Toolset per CLI generieren lasse und dieses dann als Bild in meiner Edomi Visu aufrufe.

[starwarsfan]

Hallo miteinander

Ich ueberleg mir schon lange, wie ich die RRD Funktionalitaet auch in Edomi rein bekomme, sollte per LBS nicht so aufwendig sein, da das RRD Toolset ja relativ simpel installiert werden kann... Mal sehen, der naechste Winter kommt bestimmt. Mir gefallen die graphischen Ausgabemoeglichkeiten beim RRD extrem gut, momentan gehe ich den Umweg, dass ich mir ein JPG als Grafik aus dem RRD Toolset per CLI generieren lasse und dieses dann als Bild in meiner Edomi Visu aufrufe.

Da würde mich mal interessieren, was genau Du mit graphischen Ausgabemoeglichkeiten meinst! Wie sieht das bei Dir konkret aus? Hast Du ein paar Beispiele?

Ich habe RRD-Tool auch schon lange im Einsatz aber in Zeiten von Grafana & Co ist das optisch schon irgendwie altbacken. Dazu kommt, dass es sich um ein eigenes Binärformat handelt und damit wäre es m.M.n. für den Einsatz unter Edomi ungeeignet, weil man viel zu wenig resp. gar keinen Einfluss darauf hat, welche Daten wie lange in welcher Dichte vorgehalten werden.

Wenn ich so drüber nachdenke, fände ich einen LBS praktisch, welchen man nach dem Motto konfigurieren kann "Alle Daten des iKO X, welche älter als Y sind auf den Zeitraum Z verdichten". Dabei wäre Z bspw. ein Tag/Woche/Monat oder so in der Art. Das Ganze ist aber nicht trivial, da der LBS erkennen müsste, ob die entsprechenden Daten bereits verdichtet sind oder nicht. Einfacher wäre es vielleicht, wenn der LBS direkt bei der Verwendung der Daten zum Einsatz kommt, also die Daten den LBS durchlaufen, bevor sie bspw. in der Visu angezeigt werden. Damit bleibt in der DB die volle Genauigkeit erhalten, für die Weiterverarbeitung wird aber ein ausgedünnter Datensatz verwendet.

[Brick]

starwarsfan .. schick wäre es schon, wenn man alle Daten behalten könnte und nur bei der Bearbeitung die ausgedünnten Daten verwenden könnte (Ladezeit)..
aber ob das technisch machbar ist, bezweifle ich etwas... (leider)...

Theoretisch könnte man die Grafiken (Grafana/Cacti) auch "Website Element" einbinden.. aber wie du schon schreibst.. optisch eher altbacken...

Per LBS stell ich mir dahingegend schwer vor, wenn man mal was an den Zeitintervallen ändert.. heute stell ich ein, das er mir alles älter als eine
Woche auf 12 Std. .. irgendwann will fällt mir aber auf, das es zu wenig ist, dann sind die Daten schon weg...

kein einfaches Thema..

[vento66]

starwarsfan Wenn Du immer Von den Daten den Durchschnitt nimmst (Tag / Woche / Monat) sollte es kein Problem geben. Der LBS nimmt die Werte eines Tages, rechnet den Durchschnitt aus, und speichert den Wert. startet der LBS erneut, hat er nur einen Wert, und da ist der Durchschnitt gleich des gespeicherten Wertes. Oder liege ich da falsch?

[saegefisch]

Die Frage ist gut und eine solche Lösung scheint mir durchaus zweckdienlich. In Business Warehouse-Systemen wird dies meist über eine weitere Fortschreibung in aggregierter Form gelöst, bevor die hoch-granularen Daten rollierend gelöscht werden; möglicherweise wäre das auch eine alternativer Ansatz; ob in edomi oder LBS (alternativ meint hier zu einer Lösung direkt auf DB-Ebene). Der Vorteil einer "Fortschreibung" (eben per LBS oder edomi-Befehl) wäre, dass man sich den vorhandenen Mechanismen (Durchschnitte,...) in edomi bedienen kann, nur die Pfade sind so noch nicht direkt in edomi vorgesehen.

Ich mache bislang noch nocht so sonderlich viel mit Diagrammen, aber die Frage stellte ich mir anfangs auch und habe es einfach wo gelöst, wie gleichfalls oft in DWH-System gelöst wird: Ich schreibe die Daten hoch-granular in Archiv 1 mit einer Lebensdauer 6 Monaten, weniger granular in Archiv 2 für 1 Jahr, und stark aggregiert in ein Archiv 3 mit sehr langer Residenzzeit. Das macht natürlich eine nahtlose Integration in Diagramme mit "Zoom" (über KOs) nicht so charmant möglich. Aber meist passen die Zoom-Wünsche in das Archiv 1 (man wählt es halt entsprechend groß). Archiv 3 wäre wunderbar für Vorjahres-Vergleiche - aber dazu gab es ja kürzlich schon eine anderes Thema.

[starwarsfan]

Hi

Der LBS nimmt die Werte eines Tages, rechnet den Durchschnitt aus, und speichert den Wert. startet der LBS erneut, hat er nur einen Wert, und da ist der Durchschnitt gleich des gespeicherten Wertes. Oder liege ich da falsch?

Ja, das ist der Schönwetterfall. Was aber, wenn der Baustein nun mit geänderter Zeitspanne oder zum falschen Zeitpunkt nochmal läuft? Dann habe ich mglw. ein paar "neue" Werte und einen alten Durchschnittswert. Daraus wird dann wieder ein Durchschnitt gemacht, welcher aber alles andere als der wirkliche Durchschnitt ist. Also müsste man irgendwie sicherstellen, dass die Berechnung bspw. für den Monatsdurchschnitt immer exakt am gleichen Tag gemacht wird. Bspw. am ersten Tag des Folgemonats oder soetwas.

Machbar ist sicher alles, ich wollte nur sagen, dass es nicht mal so eben mit Durchschnitt ausrechnen getan ist. Zudem habe ich die ursprüngliche Frage auch so verstanden, dass ggf. die Daten in der DB ausgedünnt werden sollen. Unterm Strich sind das nun schon mindestens drei verschiedene Anforderungen:

1. Will ich nur für die Anzeige resp. Visu weniger Daten verarbeiten?
2. Will ich die vereinfachten Daten persistent haben?
3. Will ich die Menge der ursprünglichen Daten reduzieren?

Je mehr man drüber nachdenkt, desto...