[vz-users] falschen Messwert in der Aggregation löschen

[Frank Richter]

Am 09.02.2017 22:49 schrieb <china2013 at abwesend.de>:

Würde mich auch interessieren. Was machst Du mit den Gradienten- Power
Disaggregation oder etwas in der Art?

Nun, einfach ausgedrückt, soll ein mathematisches System lernen, in wie
viele einzeln erkannte Verbraucher man die Messwerte aufsplitten kann. Über
deren Häufigkeitsverteilung sollen später auch Prognosen (=Gewohnheiten)
ermittelt werden, mit denen dann ein besseres Energie~ und Netz~ und
Speichermanagement erreicht werden soll. Downside ist dann sicher auch die
totale Überwachung. Aber man wird auch ermitteln, wie unscharf man die
Daten machen muss, damit die Verbraucher anonym bleiben. Wenn man die PV
nun nicht hochgenau aufzeichnen würde, dann könnte man nur die Nacht-Daten
verwenden. Darum.

Daher ein dickes Lob für den Volkszähler, gerade weil er so viel
aufzeichnen kann, ohne dass die Daten nach draußen gehen. Mehr soll ich
nicht sagen.  ;-)


OK, damit kann man doch zumindest mal die Beweggründe verstehen. Sammelst
du mit dem Pi nur die Datenbasis, die später weiterverarbeitet wird, oder
läuft der Algorithmus auch dort? Wenn er dort mitläuft, könntest du dich
wirklich an den Push-Server dran hängen und die Archivierung vermeiden.
Generell sollte sowas (im Produktbetrieb) idealerweise im RAM passieren,
denn den Verbraucher musst du dann ja gleich erkennen, und das Archiv
sollte dann besser aus dem Nutzungsprofil der Geräte bestehen statt aus
hochauflösenden Verbrauchsdaten, die dann niemand mehr braucht.


Zur SD-Kartenproblematik kann ich nur sagen wer billig kauft, kauft 2x.
Und die Highspeed Karten zerstören sich unter großer Hitze selbst.
Daher bleibe ich bei meiner Meinung, alle Temp und Logfiles haben auf der
SD-Karte nichts verloren, damit sie nicht zu schnell an einer Stelle
altern. Ausnahme: Errors, aber auch die könnte das System per Mail
zusenden. Wer schaut schon Logfiles an, wenn er glaubt, das System laufe
gut?


Ich glaube dass ein Großteil der Schreiblast auch von der DB verursacht
wird. Ob da die paar Logfiles noch viel schaden können? Wenn deine DB jetzt
3,5GB hat, wurde mit Sicherheit ein Vielfaches davon auf die Karte
geschrieben.
Wenn du deine Nerven schonen willst, nimm für diesen Zweck potentere
Hardware (x86, aktueller Celeron/Pentium+schlichtes Board+SSD geht heute
auch unter 10W idle und für vielleicht 250 Euro). Das wäre es mir wert,
wenn ich mich dafür nicht ständig kümmern muss, weil irgendwas aus dem
Ruder läuft.
Oder gönn deinem Pi zumindest eine SSD.

RESET:
Damit das nicht nochmal passiert, wie geht man nun optimal vor, um diese
Peaks zu killen?
Sie sind ja wohl in "data" und dann vererbt auch in "aggregate".


Wie viele sind das? Ich hatte sowas bisher nur sporadisch und hab das dann
händisch gemacht (Peak im Frontend gesucht, Zeit in Timestamp umgerechnet
und dann die böse Zeile in der DB gesucht und gelöscht). Bei deinem 2.
Screenshot würde ich einfach die betroffenen 3-4 betroffenen Minuten
komplett löschen, dann bleibt für den Bereich halt nur die
Durschnittsleistung übrig, aber das wird jetzt kein Beinbruch sein...
Scriptlösung gibt es da soweit ich weiß bisher keine. Ist auch nicht
trivial da nachträglich zu entscheiden welcher Wert jetzt echt ist und
welcher nicht (vielleicht keiner?).
Eine einigermaßen klare Sache ist es nur, wenn bei nach Timestamp
sortierten Datensätzen ein höherer Zählerstand vor einem niedrigeren kommt,
aber das erzeugt logischerweise auch negative Peaks, die ich hier nicht
sehe.

Die sind aufgetreten, als die CPU Last zu hoch war. Vermutlich werden dann
Daten mit verschobenen Timestamps geschrieben. (Die Diskussion, wie man das
verhindern könnte hatten wir schon.)


Müssen wir suchen oder kannst du uns nochmal auf die Sprünge helfen?

Grüße
Frank


Besonders viele Grüße an Andreas
Saftwerk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170210/ad2722cd/attachment.html>