Am 12.01.2014 16:26 schrieb Andreas Goetz:
Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den
letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja
nicht wissen ob/ dass "keine Daten" = 0, oder nach welcher zeti dies gelten
soll...
Das ist vermutlich das Problem, dass der Ethersex Watchasync niemals
Datenbankeinträge mit 0 schreibt, sondern erst wieder wenn Impulse eintreffen.
Das erklärt die falsche Statistik für "aktuell".
Das Verhalten für 20:30 lässt sich erklären:
commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a
Merge: feb7ca2 ff2ced5
Author: Justin Otherguy <jus...@justinotherguy.org
<mailto:jus...@justinotherguy.org>>
Date: Sun Jan 12 03:26:35 2014 -0800
Merge pull request #87 from andig/master-timestampfix
Make all interpreters use timestamp at end of period
Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die
Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt; aber
halt anders. gleiches Bild, der 0-Wert wird nur später erreicht.
Schau Dir für eine Erklärung gerne mal den PR an.
Ich stecke jetzt in den Details nur wenig drin, ich finde nur das die grafische
Darstellung falsch ist. Um bei dem Beispiel des Tageswertes zu bleiben: Um ca.
20:15 wird ein Eintrag mit n S0-Impulsen in die Datenbank geschrieben. Der
Verbrauch geht danach auf nahezu 0. Um ca. 21:15 wird vermutlich ein einziger
S0-Impus in die Datenbank geschrieben. Dann berechnet sich doch der
Momentanverbrauch zwischen 20:15 und 21:15 aus der Zeitspanne (hier 1 Stunde)
und dem in der Zeit aufgelaufenen Impulsen (hier 1). Die grafisch Darstellung
und auch der Cursor zeigt in dem Zeitfenster aber irgendwas von 570W - und das
ist schlichweg falsch.
Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da
ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den
aktuell Wert bei abgeschaltetem Verbraucher s.u.).
Für die Wochendarstellung ok/aktuell ist die Ursache eine andere. Hier liegts
daran, dass auf aggregierte Werte mit geringerer zeitlicher Auflösung
(groupy=hour) zurückgegriffen wird.
Ja aber auch hier darf in Zeitfenstern mit 0-Verbrauch die steps Linie nicht auf
dem letzten wert kleben bleiben, weil das nicht der Realität entspricht. In der
Datenbank werden in den Intervallen mit nahezu 0 Verbrauch auch keine S0-Impulse
stehen.
Es funktioniert ja auch mit der "alten" Version.
Ich versuche das noch mal mit dem schrittweisen git reset. Würde es Dir helfen
wenn ich Dir die funktionierende Version einfach mal vom Server abziehe und
zukommen lasse?
Wenn Dir das nicht gefällt kannst Du mal in der options.js mit der Variable
speedupFactor rumspielen. Kleinere Werte bringen bessere Auflösung, sind aber
auch langsamer wenn das FE dann kein groupby mehr auswählt...
Erklärung nachvollziehbar und Problem gelöst?
Die Erklärung warum das jetzt anders ist habe ich glaube ich verstanden, nur mit
dem Endresultat der Darstellung bin ich gar nicht einverstanden ;)
Gruß
Volker
--
Volker Troyke
Homepage: www.troyke.de
E-Mail : v...@gmx.de
