<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Moin.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 31 Jul 2016, at 11:24, <a href="mailto:china2013@abwesend.de" class="">china2013@abwesend.de</a> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
Ich glaube das wird was größeres…</div></div></blockquote><div><br class=""></div>Nur wenn Du eins draus machst. Jetzt mal ganz langsam.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
Also die Rohdaten eines beliebigen Zeitraums als CSV zu bekommen ist
schon ein echtes Heckmeck.<br class="">
Entweder bekomme ich trotz angefügtem "&options=raw" weiterhin
keine Rohdaten, oder sie sind aus dem falschem Zeitabschnitt bis
"jetzt”.<br class=""></div></div></blockquote><div><br class=""></div>Verlangt ja niemand CSV. Lies einfach- wie immer- Wiki/howto/debug. Ist alles erklärt.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
Ich hab's auch über den Zwischenschritt Export->Permalink und
dann "&options=raw" anfügen probiert -> weiterhin keine
Rohdaten.<br class=""></div></div></blockquote><div><br class=""></div>Nein, da Du damit auch das Frostend aufrufst und nicht die Middleware.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
Erfolgreich war ich erst mit einem modifizierten Export JSON Link
und angehängtem "&options=raw", weil "CSV" sofort eine Datei
herunter läd und JSON im Browser gezeigt wird. <br class=""></div></div></blockquote><div><br class=""></div>Genau. Export JSON macht nix anderes als die Middleware aufzurufen und- wenn Du options=raw anhängts- die erhaltenen (Roh)daten auszugeben…</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
(Ändern der JSON-URL in .../middleware.php/data.<b class=""><font color="#ff0000" class="">csv</font></b>?from=...)<br class="">
<br class="">
Hier zunächst die Rohdaten und danach meine Vermutung zur
Fehlerursache<br class=""></div></div></blockquote><div><br class=""></div>Erstmal fehlt die Information welcher Kanal (=uuid) eigentlich das Problem hat- insofern sagen die Daten unten nix. In Deinem Chart wars der lilane.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<hr size="2" width="100%" class="">{"version":"0.3","data":[<br class="">
{"tuples":[<br class="">
[1467465427475,29792242,1],<br class="">
[1467465430089,29792242.2,1],<br class="">
[1467465432693,29792242.4,1],<br class="">
[1467465435276,29792242.6,1],<br class="">
[1467465437715,29793674.1,1], <-------------<br class="">
[1467465437849,29792242.8,1], <-------------<br class="">
[1467465439091,29793674.5,1], <——————</div></div></blockquote><div><br class=""></div>Ich vermute (…) das ist der fehlerhafte Kanal und es handelt sich gem. Chart um Wählerstände. Dann ists ganz einfach: Dein Zählerstand steigt und fällt wieder. Das würde mich sehr wundern- da scheint einfach der Wert falsch, warum auch immer. Lösch ihn einfach und gut ists.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
[1467465440443,29792243,1],<br class="">
[1467465443046,29792243.2,1],<br class="">
[1467465445619,29792243.4,1],<br class="">
[1467465448233,29792243.6,1],<br class="">
[1467465450817,29792243.8,1],<br class="">
[1467465453388,29792244,1]<br class="">
],"uuid":"00000010-0002-0180-ffff-0123456789ab","from":1467465424882,"to":1467465453388,"average":0,"consumption":0,"rows":14},<br class="">
{"tuples":[<br class="">
[1467465427475,276.5,1],<br class="">
[1467465430089,277.2,1],<br class="">
[1467465432693,277.9,1],<br class="">
[1467465437715,1045.4,1],<br class="">
[1467465437849,278.6,1],<br class="">
[1467465439091,1039.9,1],<br class="">
[1467465440443,277.2,1],<br class="">
[1467465443046,278.6,1],<br class="">
[1467465445619,277.9,1],<br class="">
[1467465448233,278.6,1],<br class="">
[1467465453388,279.9,1]<br class="">
],"uuid":"00000011-0002-1570-ffff-0123456789ab","from":1467465424882,"to":1467465453388,"average":0,"consumption":0,"rows":12}<br class="">
]}<br class="">
<hr size="2" width="100%" class=""># source:;<a href="http://volkszaehler.org" class="">volkszaehler.org</a><br class="">
# version:;0.3<br class="">
<br class="">
# uuid:;00000010-0002-0180-ffff-0123456789ab<br class="">
# title:;PV<br class="">
# from:;2016-07-02 15:17:04<br class="">
# to:;2016-07-02 15:17:33<br class="">
# average:;0<br class="">
# consumption:;0<br class="">
# rows:;14<br class="">
2016-07-02 15:17:07;29792242;1<br class="">
2016-07-02 15:17:10;29792242.2;1<br class="">
2016-07-02 15:17:12;29792242.4;1<br class="">
2016-07-02 15:17:15;29792242.6;1<br class="">
<b class=""><font color="#ff0000" class="">2016-07-02 15:17:17</font></b>;29793674.1;1<br class="">
<font color="#ff0000" class=""><b class="">2016-07-02 15:17:17</b></font>;29792242.8;1<br class="">
2016-07-02 15:17:19;29793674.5;1<br class="">
2016-07-02 15:17:20;29792243;1<br class="">
2016-07-02 15:17:23;29792243.2;1<br class="">
2016-07-02 15:17:25;29792243.4;1<br class="">
2016-07-02 15:17:28;29792243.6;1<br class="">
2016-07-02 15:17:30;29792243.8;1<br class="">
2016-07-02 15:17:33;29792244;1<br class="">
<br class="">
# uuid:;00000011-0002-1570-ffff-0123456789ab<br class="">
# title:;PV Watt<br class="">
# from:;2016-07-02 15:17:04<br class="">
# to:;2016-07-02 15:17:33<br class="">
# average:;0<br class="">
# consumption:;0<br class="">
# rows:;12<br class="">
2016-07-02 15:17:07;276.5;1<br class="">
2016-07-02 15:17:10;277.2;1<br class="">
2016-07-02 15:17:12;277.9;1<br class="">
<font color="#ff0000" class=""><b class="">2016-07-02 15:17:17;1045.4;1</b><b class=""><br class="">
</b><b class="">2016-07-02 15:17:17</b></font>;278.6;1<font color="#ff0000" class=""><b class=""><br class="">
</b></font>2016-07-02 15:17:19;<font color="#ff0000" class=""><b class="">1039.9;1</b></font><br class="">
2016-07-02 15:17:20;277.2;1<br class="">
2016-07-02 15:17:23;278.6;1<br class="">
2016-07-02 15:17:25;277.9;1<br class="">
2016-07-02 15:17:28;278.6;1<br class="">
2016-07-02 15:17:33;279.9;1<br class="">
<hr size="2" width="100%" class="">meine Auswertung:<br class="">
1. Die Anzahl bei rows: stimmt nicht.<br class=""></div></div></blockquote><div><br class=""></div>Doch, tut sie. Das erste Tube konsumiert die Middleware intern.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
2. Es treten doppelte Timestamps auf.<br class=""></div></div></blockquote><div><br class=""></div>Nein, das geht in der Datenbank nicht. Du hast nur die Millisekunden unterschlagen.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
3. Die beiden Tabellen "PV" und "PV Watt" kommen vom selben eHZ
Zähler aber haben nicht die gleiche Anzahl Tupelo.<br class=""></div></div></blockquote><div><br class=""></div>Kommt halt drauf an was Du da loggst.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
4. In der unteren Tabelle "PV Watt" sind zwei unmögliche
Leistungssprünge enthalten.<br class=""></div></div></blockquote><div><br class=""></div>In Deinen Zählerständen sind zwei unmögliche Zählerstände.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
5. Mir ist nun klar warum, je nach Zoom unterschiedliche Werte
anzeigt werden.<br class="">
6. mit der ursprünglichen Annahme Stromsusfall des Raspberry hat das
nichts mehr zu tun (der war deutlich früher)<br class="">
<br class="">
zu2+3+4: Im vzlogger das könnte man doppelte Timestamps abfangen,
damit keine falschen Werte in die Datenbank kommen. </div></div></blockquote><div><br class=""></div>Nicht nötig. Da kommen keine doppelten Werte. Du könntest Dich aber fragen warum Du im 2-Sekundenabstand loggen musst.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">Ich würde sogar
soweit gehen und das ganze Datenpaket vom eHz verwerfen, weil
vermutlich eine falsche Checksumme oder Übertragungsfehler die
Ursache war. </div></div></blockquote><div><br class=""></div>Das klingt plausibel und da liegt auch die Lösung: einfach die falschen Werte löschen und gut ists.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">Anscheinend wurden schon bei "PV Watt" zwei Tupels
verworfen.<br class="">
<br class="">
Greetings<br class="">
Saftwerk<br class="">
</div>
</div></blockquote><br class=""></div><div>Viele Grüße, Andreas</div><div><br class=""></div><br class=""></div></body></html>