[vz-dev] Aggregationsmode "DELTA"

[vz at stromtarif-24.de]

Im Anhang die Diff-Ausgabe...

In der vzlogger conf ist dann beim Channel die Einstellung

"aggmode" : "DELTA",
"deltathreshold" : "5"

Zu ergänzen.


-----Ursprüngliche Nachricht-----
Von: volkszaehler-dev-bounces at lists.volkszaehler.org
[mailto:volkszaehler-dev-bounces at lists.volkszaehler.org] Im Auftrag von
Thorben Thuermer
Gesendet: Dienstag, 5. November 2013 13:42
An: volkszaehler-dev at lists.volkszaehler.org
Betreff: Re: [vz-dev] Aggregationsmode "DELTA"

On Sun, 3 Nov 2013 10:36:04 +0100 <vz at stromtarif-24.de> wrote:
> Meine Antwort ist wohl verloren gegangen, daher hier nochmal.
> 
> Hab von Github noch keinen echten Plan daher Code anbei...
[code]

sorry, aber so ist unguenstig (zuviel fehleranfaellige manuelle arbeit)...
du musst dich ja nicht bei github anmelden, aber einmal die ausgabe von 'git
diff' in eine datei umleiten und als attachment waehre gut.

> Entscheidend ist, dass innerhalb eines Aggregationszeitraumes mind. 1 
> Wert geschrieben wird. Zur Zeit schreibe ich immer den ersten Wert 
> plus die Veränderten in die DB.
> 
> Auf diese Weise lässt sich die Datenmenge reduzieren und die Unschärfe 
> (in der Darstellung) beschränkt sich auf den Agg-Zeitraum.

- Thorben



es folgt ein nicht markiertes zitat?

> Ich denke jetzt nochmal laut...
> 
>  
> 
> 2013/10/28 Andreas Goetz <cpuidle at gmail.com>
> 
> Moin,
> 
>  
> 
> 2013/10/28 Thorben Thuermer <r00t at constancy.org>
> 
> ...
> 
>  
> 
> > 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.
> 
> beschraenkt sich das problem nicht drauf, jeweils die erste UND die 
> letzte null drinzulassen?
> wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, 
> in welchem zeitraum die naechste aenderung stattgefunden hat, und 
> verteilt sie halt auf den gesamten zeitraum seit dem letzten wert.
> 
>  
> 
> Schon getestet- tut es leider nicht. Das Problem ist "so gross", wie 
> Tupel zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 
> 0 und x auf
> x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und 
> y) auf
> y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von x/2 
> bis
> y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel 
> aggegiert werden desto größer die Abweichung.
> 
>  
> 
> Das Problem ist dass wir im Moment (wenn das FT tupels=xyz übergibt) 
> Pakete schnüren. Seit dem entsprechenden Patch macht das die Datenbank:
> 
>     $sql = 'SELECT MAX(aggregate.timestamp) AS timestamp,
> SUM(aggregate.value) AS value, COUNT(aggregate.value) AS count '.
>            'FROM ('.
>            '    SELECT timestamp, value, @row:=@row+1 AS row '.
>            '     FROM data WHERE channel_id=?' . $sqlTimeFilter . 
>            ') AS aggregate '.
>            'GROUP BY row DIV ' . $packageSize .' '.
>            'ORDER BY timestamp ASC';
>  
> 
> In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen 
> Hinweis bekommen wird dass zwischendurch die 0 "steht"  und die Daten 
> ausgedünnt sind.
> 
>  
> 
> Was spräche denn jetzt dagegen, stattdessen äquidistante Stücke zu 
> schneiden, also nach timestamp DIV $packageSize zu gruppieren? und den 
> entsprechenden Timestamp im Select hochzuzählen? Das Ganze noch mit 
> IFNULL Statements ergänzt sollten wir in der Lage sein, fehlende 
> (Null-)Werte zu ergänzen. Performance to be tested.
> 
> Dann besteht natürlich wieder die Gefahr, dass wir zwischen zwei 
> Zählerwerten eine Null erfinden falls sich da kein weiterer Messwert
> anfindet- Tuples darf also nicht granularer werden als Messwerte 
> wirklich vorliegen.
> 
> Wär hätte Lust einen Prototyp zu bauen und Performance zu testen??
> 
> vg
> 
> Andreas
> 
>  
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Buffer.cpp.diff
Type: application/octet-stream
Size: 1183 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20131108/a8bfef97/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Buffer.hpp.diff
Type: application/octet-stream
Size: 834 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20131108/a8bfef97/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Channel.cpp.diff
Type: application/octet-stream
Size: 852 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20131108/a8bfef97/attachment-0002.obj>