<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">Am 09.02.2017 22:49 schrieb <<a href="mailto:china2013@abwesend.de">china2013@abwesend.de</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="quoted-text">
<blockquote type="cite">Würde mich auch interessieren. Was machst Du mit den
Gradienten- Power Disaggregation oder etwas in der Art?<br>
</blockquote></div>
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.<br>
<br>
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. ;-)<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Zur SD-Kartenproblematik kann ich nur sagen wer billig kauft, kauft
2x.<br>
Und die Highspeed Karten zerstören sich unter großer Hitze selbst.<br>
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?<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto">Oder gönn deinem Pi zumindest eine SSD.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">RESET:<br>
Damit das nicht nochmal passiert, wie geht man nun optimal vor, um
diese Peaks zu killen?<br>
Sie sind ja wohl in "data" und dann vererbt auch in "aggregate".<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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...</div><div dir="auto">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?).</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"></div></blockquote></div></div></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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.)<br></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Müssen wir suchen oder kannst du uns nochmal auf die Sprünge helfen?</div><div dir="auto"><br></div><div dir="auto">Grüße</div><div dir="auto">Frank</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Besonders viele Grüße an Andreas<br>
Saftwerk<br>
</div>
</blockquote></div><br></div></div></div>