Am 28.10.2013 10:19, schrieb Andreas Goetz:
Hallo,
die Sache hat leider einen Haken.
2013/10/27 <v...@stromtarif-24.de <mailto:v...@stromtarif-24.de>>
...
Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein
gewisses Delta zum vorhergehenden Wert überschreitet.
Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend
die nachfolgenden Werte im Buffer bewertet, ob das Delta einen
prozentualen Wert des alten Wertes überschreitet. Ist das nicht
der Fall, wird der Wert als gelöscht markiert. So wird der
latest-Wert und alle relevanten Änderungen eingetragen. Da das
Delta prozentual vom Istwert berechnet wird, werden bei kleinen
Werten auch kleine Änderungen erfasst.
...
Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne
nennenswerte Darstellungsverluste.
Das kann ich leider nicht bestätigen. Bei meinen Experimenten habe
aufeinander folgende 0- Werte in der DB gelöscht (da ja PV nachts
wenig produziert) was die Datenmenge für den entsprechenden Kanal mal
schlapp halbiert hat. Leider kommt es dazu zu erheblichen
Darstellungsproblemen beim Übergang da die Middleware für's Frontend
die Daten aggregiert- und zwar portionsweise je Datenbanktupel und
nicht nach gleich großen Zeitscheiben.
Im Ergebnis führt das dazu, dass das FE hässliche "Rampen" an den
Stellen anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren
Intervallen) wieder auf Daten übergegangen wird.
Mir ist dafür bisher keine Lösung eingefallen- falls es da eine gibt
könnte man neben Änderungen im Logger auch ein späteres Aufräumen der
DB auf diesem Wege ohne Daten- und Darstellungsverlust implementieren.
vg
Andreas
Hallo
Um die Menge an Daten in Griff zu bekommen würde ich vorschalgen die
Daten in eine RRD-DB abzulegen.
http://oss.oetiker.ch/rrdtool/
Gruß NetFritz
