Re: [vz-dev] Aggregationsmode "DELTA"
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-boun...@lists.volkszaehler.org
[mailto:volkszaehler-dev-boun...@lists.volkszaehler.org] Im Auftrag von
Thorben Thuermer
Gesendet: Dienstag, 5. November 2013 13:42
An: volkszaehler-dev@lists.volkszaehler.org
Betreff: Re: [vz-dev] Aggregationsmode "DELTA"
On Sun, 3 Nov 2013 10:36:04 +0100 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
>
> Moin,
>
>
>
> 2013/10/28 Thorben Thuermer
>
> ...
>
>
>
> > 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
>
>
>
Buffer.cpp.diff
Description: Binary data
Buffer.hpp.diff
Description: Binary data
Channel.cpp.diff
Description: Binary data
Re: [vz-dev] Aggregationsmode "DELTA"
On Sun, 3 Nov 2013 10:36:04 +0100 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
>
> Moin,
>
>
>
> 2013/10/28 Thorben Thuermer
>
> ...
>
>
>
> > 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
>
>
>
Re: [vz-dev] Aggregationsmode "DELTA"
Meine Antwort ist wohl verloren gegangen, daher hier nochmal.
Hab von Github noch keinen echten Plan daher Code anbei...
Src/Buffer.cpp (ab Zeile 136):
else if(_aggmode == DELTA) {
Reading *latest=NULL;
double aggvalue=0;
double deltavalue=0;
for(iterator it = _sent.begin(); it != _sent.end(); it++) {
if(! it->deleted()) {
if(!latest) {
latest=&*it;
aggvalue=it->value();
}
if(aggvalue > it->value()) {
deltavalue=aggvalue-it->value();
} else {
deltavalue=it->value()-aggvalue;
}
if(deltavalue <
abs((aggvalue/100.0*_deltathreshold)) && &*it != latest) {
it->mark_delete();
} else {
latest=&*it;
aggvalue=it->value();
print(log_debug, "NEW VALUE %f @
%f", "DELTA", it->value(),it->tvtod());
}
}
}
}
Src/Channel.cpp (ab Zeile 64):
const char *aggmode_str = optlist.lookup_string(pOptions,
"aggmode");
double deltathreshold = atof(optlist.lookup_string(pOptions,
"deltathreshold"));
if(strcasecmp(aggmode_str,"max")==0 ) {
_buffer->set_aggmode(Buffer::MAXIMUM);
} else if( strcasecmp(aggmode_str,"avg")==0 ) {
_buffer->set_aggmode(Buffer::AVG);
} else if( strcasecmp(aggmode_str,"sum")==0 ) {
_buffer->set_aggmode(Buffer::SUM);
} else if( strcasecmp(aggmode_str,"delta")==0 ) {
_buffer->set_aggmode(Buffer::DELTA);
_buffer->set_deltathreshold(deltathreshold);
} else if( strcasecmp(aggmode_str,"none")==0 ) {
_buffer->set_aggmode(Buffer::NONE);
} else {
throw vz::VZException("Aggmode unknown.");
}
Includes/Buffer.hpp
Zeile 44: enum aggmode { NONE,MAXIMUM,AVG,SUM,DELTA }; Zeile 73: inline void
set_deltathreshold(double deltathreshold) {_deltathreshold=deltathreshold;}
Zeile 80: double _deltathreshold;
Und in der vzlogger.conf sieht das bei mir so aus:
"meters" : [{
"enabled" : true, /* disabled meters will be ignored */
"protocol" : "sml", /* see 'vzlogger -h' for list of available
protocols */
"device" : "/dev/ttyUSB0",
"aggtime" : 30,
"channels": [{
"uuid" : "xxx",
"middleware" : "http://xxx/vz/htdocs/middleware.php";,
"identifier" : "1-0:16.7.0", /*Haus Bezug Leistung*/
"aggmode" : "DELTA",
"deltathreshold" : "5"
}]
}, {
"enabled" : true, /* disabled meters will be ignored */
"protocol" : "sml", /* see 'vzlogger -h' for list of available
protocols */
"device" : "/dev/ttyUSB1",
"aggtime" : 30,
"channels": [{
"uuid" : "xxx",
"middleware" : "http://xxx/vz/htdocs/middleware.php";,
"identifier" : "1-0:16.7.0", /*Solarerzeugung Leistung*/
"aggmode" : "DELTA",
"deltathreshold" : "5"
}]
}]
}
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.
Ich denke jetzt nochmal laut...
2013/10/28 Andreas Goetz
Moin,
2013/10/28 Thorben Thuermer
...
> 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 bede
Re: [vz-dev] Aggregationsmode "DELTA"
Ich denke jetzt nochmal laut...
2013/10/28 Andreas Goetz
> Moin,
>
> 2013/10/28 Thorben Thuermer
>
>> ...
>>
>> > 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
Re: [vz-dev] Aggregationsmode "DELTA"
Moin, 2013/10/28 Thorben Thuermer > ... > > 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. 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. vg Andreas
Re: [vz-dev] Aggregationsmode "DELTA"
On Mon, 28 Oct 2013 10:19:22 +0100 Andreas Goetz wrote: > 2013/10/27 [...] > > Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein gewisses > > Delta zum vorhergehenden Wert überschreitet. > > > > Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend die > > nachfolgenden Werte im Buffer bewertet, ob das Delta einen prozentualen > > Wert des alten Wertes überschreitet. Ist das nicht der Fall, wird der Wert > > als gelöscht markiert. So wird der latest-Wert und alle relevanten > > Änderungen eingetragen. Da das Delta prozentual vom Istwert berechnet wird, > > werden bei kleinen Werten auch kleine Änderungen erfasst. [...] > > Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne > > nennenswerte Darstellungsverluste. > > > > Das kann ich leider nicht bestätigen. Bei meinen Experimenten habe > aufeinander folgende 0- Werte in der DB gelöscht (da ja PV nachts wenig > produziert) was die Datenmenge für den entsprechenden Kanal mal schlapp > halbiert hat. Leider kommt es dazu zu erheblichen Darstellungsproblemen > beim Übergang da die Middleware für's Frontend die Daten aggregiert- und > zwar portionsweise je Datenbanktupel und nicht nach gleich großen > Zeitscheiben. > 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. > Mir ist dafür bisher keine Lösung eingefallen- falls es da eine gibt könnte > man neben Änderungen im Logger auch ein späteres Aufräumen der DB auf > diesem Wege ohne Daten- und Darstellungsverlust implementieren. > > vg > Andreas - Thorben
Re: [vz-dev] Aggregationsmode "DELTA"
Am 28.10.2013 10:19, schrieb Andreas Goetz: Hallo, die Sache hat leider einen Haken. 2013/10/27 mailto:v...@stromtarif-24.de>> ... Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein gewisses Delta zum vorhergehenden Wert überschreitet. Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend die nachfolgenden Werte im Buffer bewertet, ob das Delta einen prozentualen Wert des alten Wertes überschreitet. Ist das nicht der Fall, wird der Wert als gelöscht markiert. So wird der latest-Wert und alle relevanten Änderungen eingetragen. Da das Delta prozentual vom Istwert berechnet wird, werden bei kleinen Werten auch kleine Änderungen erfasst. ... Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne nennenswerte Darstellungsverluste. Das kann ich leider nicht bestätigen. Bei meinen Experimenten habe aufeinander folgende 0- Werte in der DB gelöscht (da ja PV nachts wenig produziert) was die Datenmenge für den entsprechenden Kanal mal schlapp halbiert hat. Leider kommt es dazu zu erheblichen Darstellungsproblemen beim Übergang da die Middleware für's Frontend die Daten aggregiert- und zwar portionsweise je Datenbanktupel und nicht nach gleich großen Zeitscheiben. 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. Mir ist dafür bisher keine Lösung eingefallen- falls es da eine gibt könnte man neben Änderungen im Logger auch ein späteres Aufräumen der DB auf diesem Wege ohne Daten- und Darstellungsverlust implementieren. vg Andreas Hallo Um die Menge an Daten in Griff zu bekommen würde ich vorschalgen die Daten in eine RRD-DB abzulegen. http://oss.oetiker.ch/rrdtool/ Gruß NetFritz
Re: [vz-dev] Aggregationsmode "DELTA"
Hallo, die Sache hat leider einen Haken. 2013/10/27 > ... > > ** ** > > Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein gewisses > Delta zum vorhergehenden Wert überschreitet. > > Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend die > nachfolgenden Werte im Buffer bewertet, ob das Delta einen prozentualen > Wert des alten Wertes überschreitet. Ist das nicht der Fall, wird der Wert > als gelöscht markiert. So wird der latest-Wert und alle relevanten > Änderungen eingetragen. Da das Delta prozentual vom Istwert berechnet wird, > werden bei kleinen Werten auch kleine Änderungen erfasst. > ... > > ** ** > > Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne > nennenswerte Darstellungsverluste. > Das kann ich leider nicht bestätigen. Bei meinen Experimenten habe aufeinander folgende 0- Werte in der DB gelöscht (da ja PV nachts wenig produziert) was die Datenmenge für den entsprechenden Kanal mal schlapp halbiert hat. Leider kommt es dazu zu erheblichen Darstellungsproblemen beim Übergang da die Middleware für's Frontend die Daten aggregiert- und zwar portionsweise je Datenbanktupel und nicht nach gleich großen Zeitscheiben. 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. Mir ist dafür bisher keine Lösung eingefallen- falls es da eine gibt könnte man neben Änderungen im Logger auch ein späteres Aufräumen der DB auf diesem Wege ohne Daten- und Darstellungsverlust implementieren. vg Andreas
Re: [vz-dev] Aggregationsmode "DELTA"
On Sun, 27 Oct 2013 17:36:13 +0100 wrote: > In meiner Installation vom vzlogger auf einem Raspberry habe ich mir eine > weitere Aggregartions-Methode eingebaut, die ich so von Prozessleitsystemen > her kenne. > > Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein gewisses > Delta zum vorhergehenden Wert überschreitet. > > Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend die > nachfolgenden Werte im Buffer bewertet, ob das Delta einen prozentualen Wert > des alten Wertes überschreitet. Ist das nicht der Fall, wird der Wert als > gelöscht markiert. So wird der latest-Wert und alle relevanten Änderungen > eingetragen. Da das Delta prozentual vom Istwert berechnet wird, werden bei > kleinen Werten auch kleine Änderungen erfasst. > > Der Threshold ist pro Channel in der vzlogger.conf einzutragen. > Aggtime und aggmode(DELTA) wie gehabt auch. > > Interessant oder Nonsens? klingt sehr sinnvoll/vernuenftig/naheliegend. koennen wir uns den code mal anschauen, bzw hast du's auf github und schickst einen pull-request, oder ansonsten zB. ein diff an die liste? > Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne nennenswerte > Darstellungsverluste. > > Viele Grüße > Andreas Oberzier - Thorben
[vz-dev] Aggregationsmode "DELTA"
Hallo Liste (sagt man das so?!?), ich habe mir das Projekt installiert und bin ziemlich begeistert von den Möglichkeiten, die sich damit auftun In meiner Installation vom vzlogger auf einem Raspberry habe ich mir eine weitere Aggregartions-Methode eingebaut, die ich so von Prozessleitsystemen her kenne. Ein neuer Wert wird nur in die Datenbank geschrieben, wenn er ein gewisses Delta zum vorhergehenden Wert überschreitet. Innerhalb der Aggregationszeit werden vom latest-Wert ausgehend die nachfolgenden Werte im Buffer bewertet, ob das Delta einen prozentualen Wert des alten Wertes überschreitet. Ist das nicht der Fall, wird der Wert als gelöscht markiert. So wird der latest-Wert und alle relevanten Änderungen eingetragen. Da das Delta prozentual vom Istwert berechnet wird, werden bei kleinen Werten auch kleine Änderungen erfasst. Der Threshold ist pro Channel in der vzlogger.conf einzutragen. Aggtime und aggmode(DELTA) wie gehabt auch. Interessant oder Nonsens? Bei mir reduzieren sich dadurch die Datensätze auf rd. 20% ohne nennenswerte Darstellungsverluste. Viele Grüße Andreas Oberzier Dipl.-Ing.(FH) Andreas Oberzier An den Drei Kreuzen 10 53894 Mechernich Germany
