Feature request: Ignore duplicate counter values

[andig]

Aus der ML:

2015-01-02 15:09 GMT+01:00 Martin Heinze martin-heinze@gmx.net:

Gerade bei Zählerständen ist es nicht wirklich notwendig zu jeder Auslesung einen Wert in der DB zu speichern

Sehe ich auch so, ist allerdings vom Anwendungfall abhängig.

Es sollte relativ einfach sein einen Konfigparameter in der Art von ignoreDuplicateReadings oder besser minReadingDelta (flexible) zu bauen den der vzlogger mit dem vorhergegenden Absolut(!)wert vergleicht und nur schreibt wenn größer. Damit kann man sich Roundtrips in die Middleware/DB ersparen.

[skre]

Dein Ansatz bei minReadingDelta geht von einem aufsteigendem Zählwert aus - was ich gut finde. Hat aber mehrere Konsequenzen:

1. Bei einerm Zählerwechsel müsste also eine neue UUID angelegt werden.
2. Bei einem plotzlichen Sprung durch Fehlübertragungen (kommen bei mir vor) müsste man ein Fallback haben

[nyphis]

Ich hätte da noch ein paar Gedanken on top ...

• Damit bei reinen Zählerständen keine Rampe sondern ein richtiger Peak dargestellt wird, müsste der vzlogger bei einer Änderung des Zählerstandes zwei Einträge vornehmen ...
  1. den vorherigen Zählerstand bei aktuellem Timestamp minus 'interval' und
  2. den neuen Zählerstand am aktuellen TS ...
• Die Idee eines minReadingDelta muss ja nicht nur für einen aufsteigenden Zählerwert gelten, oder?
• Für mich stellt sich die Frage, ob das nicht auch die Middleware übernehmen kann - da da eh' eine DB-Verbindung besteht, könnte die auch vor einem Neueintrag mal schnell den alten Wert ziehen und dann vergleichen ...

[nyphis]

Aus der ML:

Am Freitag, 9. Januar 2015 schrieb Mike Grüger :

Mit dem Betriebsstundenzaehler sollte es gehen, oder? Der Zaehler braucht Impulse, reicht eine 1 fuer „An“ und 0 fuer „Aus“ oder wird die Zeit aus der Frequenz der Impulse ermittelt? Bei zwei Impulsen alle 15 Sekunden sind das mächtig viele Eintraege in der Datenbank.

Das ist IMHO das gleiche Thema.

[andig]

@nyphis

Damit bei reinen Zählerständen keine Rampe sondern ein richtiger Peak dargestellt wird, müsste der vzlogger bei einer Änderung des Zählerstandes zwei Einträge vornehmen ...

Besser: Darstellung auf "steps" stellen.

Die Idee eines minReadingDelta muss ja nicht nur für einen aufsteigenden Zählerwert gelten, oder?

Nein, der Vergleich sollte einfach mit Absolutwerten arbeiten.

Für mich stellt sich die Frage, ob das nicht auch die Middleware übernehmen kann

Prinzipiell ja, aber das erfordert eine zusätzliche DB-Abfrage während der vzlogger ja schon alle Informationen hat. Daher würde ich die Logik lieber dort ansiedeln.

@mbehr1 was meinst Du? Mit wenig Aufwand umsetzbar und Meter-unabhängig?

[mbehr1]

Ich könnte in vzlogger/api/volkszaehler eine Logik einbauen, den Wert nicht zu schicken, wenn er dem vorherigen entspricht. Das ginge ganz schnell.
Das wäre Meter unabhängig.

Lediglich das Rampenproblem bleibt (Middleware zeigt dann Rampe vom Zeitpunkt des letzten Wert zum Zeitpunkt vom neu geänderten).
Ggf. könnte ich auch noch einbauen, dass bei einer Reihe von gleichen Werte der erste und letzte geschickt wird, nicht jedoch die mittleren. Damit wären alle Rampen komplett in Ursprungsform. Soll ich das mal prüfen?

Am 17.02.2015 um 10:22 schrieb andig notifications@github.com:

@nyphis https://github.com/nyphis
Damit bei reinen Zählerständen keine Rampe sondern ein richtiger Peak dargestellt wird, müsste der vzlogger bei einer Änderung des Zählerstandes zwei Einträge vornehmen ...

Besser: Darstellung auf "steps" stellen.

Die Idee eines minReadingDelta muss ja nicht nur für einen aufsteigenden Zählerwert gelten, oder?

Nein, der Vergleich sollte einfach mit Absolutwerten arbeiten.

Für mich stellt sich die Frage, ob das nicht auch die Middleware übernehmen kann

Prinzipiell ja, aber das erfordert eine zusätzliche DB-Abfrage während der vzlogger ja schon alle Informationen hat. Daher würde ich die Logik lieber dort ansiedeln.

@mbehr1 https://github.com/mbehr1 was meinst Du? Mit wenig Aufwand umsetzbar und Meter-unabhängig?

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß

Matthias

[andig]

Am 17.02.2015 um 21:20 schrieb Matthias Behr notifications@github.com:

Ich könnte in vzlogger/api/volkszaehler eine Logik einbauen, den Wert nicht zu schicken, wenn er dem vorherigen entspricht. Das ginge ganz schnell.
Das wäre Meter unabhängig.

Klingt gut.

Lediglich das Rampenproblem bleibt (Middleware zeigt dann Rampe vom Zeitpunkt des letzten Wert zum Zeitpunkt vom neu geänderten).
Ggf. könnte ich auch noch einbauen, dass bei einer Reihe von gleichen Werte der erste und letzte geschickt wird, nicht jedoch die mittleren. Damit wären alle Rampen komplett in Ursprungsform. Soll ich das mal prüfen?

Bin mir nicht sicher warum. Du versuchst eine Information zu erfinden die es nicht gibt, denk n die Auflösung des Zählers. M.e. Reicht display steps dafür.

Viele Grüße, Andreas

Am 17.02.2015 um 10:22 schrieb andig notifications@github.com:

@nyphis https://github.com/nyphis
Damit bei reinen Zählerständen keine Rampe sondern ein richtiger Peak dargestellt wird, müsste der vzlogger bei einer Änderung des Zählerstandes zwei Einträge vornehmen ...

Besser: Darstellung auf "steps" stellen.

Die Idee eines minReadingDelta muss ja nicht nur für einen aufsteigenden Zählerwert gelten, oder?

Nein, der Vergleich sollte einfach mit Absolutwerten arbeiten.

Für mich stellt sich die Frage, ob das nicht auch die Middleware übernehmen kann

Prinzipiell ja, aber das erfordert eine zusätzliche DB-Abfrage während der vzlogger ja schon alle Informationen hat. Daher würde ich die Logik lieber dort ansiedeln.

@mbehr1 https://github.com/mbehr1 was meinst Du? Mit wenig Aufwand umsetzbar und Meter-unabhängig?

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß

Matthias

—
Reply to this email directly or view it on GitHub.

[mbehr1]

Ich könnte in vzlogger/api/volkszaehler eine Logik einbauen, den Wert nicht zu schicken, wenn er dem vorherigen entspricht. Das ginge ganz schnell.
Das wäre Meter unabhängig.

Klingt gut.

Lediglich das Rampenproblem bleibt (Middleware zeigt dann Rampe vom Zeitpunkt des letzten Wert zum Zeitpunkt vom neu geänderten).
Ggf. könnte ich auch noch einbauen, dass bei einer Reihe von gleichen Werte der erste und letzte geschickt wird, nicht jedoch die mittleren. Damit wären alle Rampen komplett in Ursprungsform. Soll ich das mal prüfen?

Bin mir nicht sicher warum. Du versuchst eine Information zu erfinden die es nicht gibt, denk n die Auflösung des Zählers. M.e. Reicht display steps dafür.

Das ist keine neue Info sondern eher ein „komprimieren“ der Infos.

Bsp. aus einer Kette von 1,1,1,1,2,2,2,2,3,4 mit dazugehörigen Timestamps würde ich: 1,1,2,2,3,4 machen. Die inneren Timestamps tragen in dem Sinne ja keine Information.
Das müsste noch relativ schnell gehen (speichern vom ersten Wert, der geändert ist und etztem Tuple, das den gleichen Wert hat).

Viele Grüße, Andreas

Am 17.02.2015 um 10:22 schrieb andig notifications@github.com:

@nyphis https://github.com/nyphis
Damit bei reinen Zählerständen keine Rampe sondern ein richtiger Peak dargestellt wird, müsste der vzlogger bei einer Änderung des Zählerstandes zwei Einträge vornehmen ...

Besser: Darstellung auf "steps" stellen.

Die Idee eines minReadingDelta muss ja nicht nur für einen aufsteigenden Zählerwert gelten, oder?

Nein, der Vergleich sollte einfach mit Absolutwerten arbeiten.

Für mich stellt sich die Frage, ob das nicht auch die Middleware übernehmen kann

Prinzipiell ja, aber das erfordert eine zusätzliche DB-Abfrage während der vzlogger ja schon alle Informationen hat. Daher würde ich die Logik lieber dort ansiedeln.

@mbehr1 https://github.com/mbehr1 was meinst Du? Mit wenig Aufwand umsetzbar und Meter-unabhängig?

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß

Matthias

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß

Matthias Behr

[andig]

Bin mir nicht sicher warum. Du versuchst eine Information zu erfinden die es nicht gibt, denk an die Auflösung des Zählers. M.e. Reicht display steps dafür.

Das ist keine neue Info sondern eher ein „komprimieren“ der Infos. Bsp. aus einer Kette von 1,1,1,1,2,2,2,2,3,4 mit dazugehörigen Timestamps würde ich: 1,1,2,2,3,4 machen.

Verstanden. Das hatte ich mir vor ewiger Zeit mal als Enhancement für vzcompress überlegt aber wieder verworfen. Letztlich ist dann die Aggregation draus geworden.

Die inneren Timestamps tragen in dem Sinne ja keine Information.

Jaein. Sie tragen die Information dass sich der Wert zwischenzeitlich nicht geändert hat. Genau die gleiche Information habe ich aber auch wenn kein neuer Wert mehr auftaucht- dann ist der alte Wert weiterhin der gültige.
Ich weiss allenfalls dass der Kanal überhaupt noch mit Werten versorgt wird. Genau die Info bekomme ich bei Deinem Verfahren aber ebenfalls nicht da Du den Wert ja nicht schreiben würdest.

Das müsste noch relativ schnell gehen (speichern vom ersten Wert, der geändert ist und etztem Tuple, das den gleichen Wert hat).

Ist sicher einfach gemacht aber ich sehe den Nutzen einfach nicht. Würde die Komplexität sparen uns sowas wie duplicates: 'ignore' vorschlagen.
Wenns mal akut würde ließe sich duplicates: 'thin' o.ä. ja immer noch nachrüsten.
Ergänzend ginge auch noch duplicates: <integer> der sicherstellt dass mindestens alle x Sekunden ein- auch identischer- Wert geschrieben würde. Damit ließe sich dann auch Aktualisierung anhand des Kanales überprüfen.

[mbehr1]

ok. Der Vorschlag ist gut:

pro channel kann konfiguriert werden:
duplicates: // 0 = default (send all values), x>0: send only if value changes or last sent value was more than x sec ago. On change sent last ignored value as well (to keep proper waveform).

Implementation erst mal nur für volkszaehler api.

Ok?

Am 18.02.2015 um 11:16 schrieb andig notifications@github.com:

Bin mir nicht sicher warum. Du versuchst eine Information zu erfinden die es nicht gibt, denk an die Auflösung des Zählers. M.e. Reicht display steps dafür.

Das ist keine neue Info sondern eher ein „komprimieren“ der Infos. Bsp. aus einer Kette von 1,1,1,1,2,2,2,2,3,4 mit dazugehörigen Timestamps würde ich: 1,1,2,2,3,4 machen.

Verstanden. Das hatte ich mir vor ewiger Zeit mal als Enhancement für vzcompress überlegt aber wieder verworfen. Letztlich ist dann die Aggregation draus geworden.

Die inneren Timestamps tragen in dem Sinne ja keine Information.

Jaein. Sie tragen die Information dass sich der Wert zwischenzeitlich nicht geändert hat. Genau die gleiche Information habe ich aber auch wenn kein neuer Wert mehr auftaucht- dann ist der alte Wert weiterhin der gültige.
Ich weiss allenfalls dass der Kanal überhaupt noch mit Werten versorgt wird. Genau die Info bekomme ich bei Deinem Verfahren aber ebenfalls nicht da Du den Wert ja nicht schreiben würdest.

Das müsste noch relativ schnell gehen (speichern vom ersten Wert, der geändert ist und etztem Tuple, das den gleichen Wert hat).

Ist sicher einfach gemacht aber ich sehe den Nutzen einfach nicht. Würde die Komplexität sparen uns sowas wie duplicates: 'ignore' vorschlagen.
Wenns mal akut würde ließe sich duplicates: 'thin' o.ä. ja immer noch nachrüsten.
Ergänzend ginge auch noch duplicates: der sicherstellt dass mindestens alle x Sekunden ein- auch identischer- Wert geschrieben würde. Damit ließe sich dann auch Aktualisierung anhand des Kanales überprüfen.

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß
Matthias

[nyphis]

Klingt super ... die Idee, das als Zeitfenster zu programmieren toppt das noch etwas. Da hat man dann noch eine Sicherheit, dass alle Naselang mal ein Wert in der DB steht (z.B. des nächtens, wenn die Wärmepumpe gar nix verbraucht).
Wichtig wäre noch, dass der vzlogger zum Start den ersten gelesenen Wert sendet - aber das versteht sich ja sicherlich von selbst ;-)

[mbehr1]

Siehe PR#125.

Ungetestet, ich füge jetzt Unit Tests hinzu, wäre gut, wenn jemand aber auch am realen System mit testen könnte.

Am 18.02.2015 um 22:12 schrieb Martin Heinze notifications@github.com:

Klingt super ... die Idee, das als Zeitfenster zu programmieren toppt das noch etwas. Da hat man dann noch eine Sicherheit, dass alle Naselang mal ein Wert in der DB steht (z.B. des nächtens, wenn die Wärmepumpe gar nix verbraucht).
Wichtig wäre noch, dass der vzlogger zum Start den ersten gelesenen Wert sendet - aber das versteht sich ja sicherlich von selbst ;-)

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß
Matthias

[mbehr1]

Habe PR mit Unit Tests aktualisiert. Scheint zu funktionieren.

Am 18.02.2015 um 22:58 schrieb Matthias Behr mbehr@mcbehr.de:

Siehe PR#125.

Ungetestet, ich füge jetzt Unit Tests hinzu, wäre gut, wenn jemand aber auch am realen System mit testen könnte.

Am 18.02.2015 um 22:12 schrieb Martin Heinze <notifications@github.com mailto:notifications@github.com>:

Klingt super ... die Idee, das als Zeitfenster zu programmieren toppt das noch etwas. Da hat man dann noch eine Sicherheit, dass alle Naselang mal ein Wert in der DB steht (z.B. des nächtens, wenn die Wärmepumpe gar nix verbraucht).
Wichtig wäre noch, dass der vzlogger zum Start den ersten gelesenen Wert sendet - aber das versteht sich ja sicherlich von selbst ;-)

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß
Matthias

[mbehr1]

Merged with PR #125.

[andig]

Siehe hier- wäre das ein alternativer oder zusätzlicher Lösungsansatz?

http://comments.gmane.org/gmane.network.volkszaehler.devel/2055

[mbehr1]

geht nur für absolute Werte. Könnte leicht eingebaut werden, aber ist noch eine weitere Config-Option....
(für das Config Thema folgt demnächst ein Vorschlag)
Hat mit dem ursprünglichen Titel weniger zu tun. Separates Issue?

[andig]

geht nur für absolute Werte

Jetzt bin ich verwirrt. Hier gehts doch auch um absolute Werte (=Zählerstände) dachte ich?

[andig]

Ich mache die Diskussion hier nochmal auf. Aus der ML (http://volkszaehler.org/pipermail/volkszaehler-dev/2015-March/004311.html, leider HTML Mail):

Scheint so gewollt zu sein, lt. Diskussion bei GIT: "If the value changes the last ignored duplicate will be send to keep the "waveform".".

Das ist zumindest nicht das Verhalten das ich verwarten würde und es ist- wie erwähnt- m.E. falsch und irreführend.

Ich versteh das nicht. Nach meiner Auffassung muss für eine realitätsnahe Darstellung aus der Zeitdifferenz zwischen zwei Zählersprüngen und der verbrauchten Arbeit von 0,1 KWh die mittlere entnommene Leistung berechnet und als Waagerechte Linie zwischen die beiden Timestamps gezeichnet werden. Welchen Sinn hat es, Werte zwischen die Zählerstandsänderungen zu schreiben?

Meine Meinung. Wer "die Wellenform halten" will kann das im Frontend mittels steps statt lines machen.

Neues Issue oder weitere Diskussion hier da wir sie bereits hatten?

[mbehr1]

Ich verstehe den Punkt nicht ganz.
Willst du zusätzlich den aggmode "delta" haben oder das duplicate Handling ersetzt haben?
Mein Kommentar war lediglich, dass aggmode "delta" nur für abs. Wählerstände funktionieren würde und ich dachte, die meisten nur gerade in Richtung Frontend Impulse/Deltas.
Aber ich kann so ein aggmode "delta" auch zusätzlich einbauen.
Führt mich nur zu dem Punkt, dass die Config immer komplexer wird. Siehe dazu mein Issue #130 als Idee.

[andig]

Willst du zusätzlich den aggmode "delta" haben oder das duplicate Handling ersetzt haben?

Nein, ich denke "duplicate Handling" reicht erstmal. Der Aggmode DELTA ist auch interessant aber m.E. erstmal nicht notwendig. Entschuldige die Verwirrung. Evtl. mache ich für DELTA nochmal ein Issue zur Doku auf.

duplicates: // 0 = default (send all values), x>0: send only if value changes or last sent value was more than x sec ago. On change sent last ignored value as well (to keep proper waveform).

Das ist aus meiner Sicht FALSCH. Für "proper waveform" gibt es display steps.

Die jetzige Implementierung schreibt in die Middleware

1 ... 1 2 .....

M.E. ist es richtig zu schreiben

1 ... 2 ...

Argumentation dazu siehe meine Kommentare im PR #125 dazu.

[mbehr1]

Die jetzige Implementierung fügt keine nicht vorhandenen Werte ein, sondern lässt nur paar raus.
D.h. aus:

11111 22222 33333
wird
1...1 2...2 3.....

Das ist doch nicht falsch/verkehrt. Dadurch bleibt die "waveform". Einziger Nachteil ist, dass ein paar Werte zu viel geloggt werden oder anders ausgedrückt: nicht alle duplicate werden entfernt. Aber es werden keine falschen Punkte/Werte hinzugefügt.
Willst du eine Option haben, komplett alle Duplicates zu entfernen?

[junibart]

Hi,
ich schalte mich hier mal ein, von mir kommt der oben zitierte Eintrag aus der vz-dev Mailinglist.
Vielleicht versteh ich ja das mit der waveform etc. nicht... hab den vz erst vor einigen Tagen kennengelernt. Aber mein Anliegen ist:
Ich nutze ein Smartmeter, das nur eine Nachkommastelle der KWh-Zählung ausgibt (EMH itz). Zwischen den Zählersprüngen kann man nur von einer konstanten Energieabnahme ausgehen- alles andere ist noch weiter hergeholt.
Nun wird dieses Smrtmeter etwa alle 90 Sekunden abgefragt und liefert entweder
11111 22222 33333 (ohne duplicate-Entfernung)
oder
1...1 2...2 3..... (mit duplicate-Entfernung).
Das führt in der Stunden- und Tagesgrafik dazu, dass zwischen den identischen Ablesungen (..1 1..) scheinbar 0 W Energie verbraucht wird, und in den 90 Sekunden bei einem Sprung (..1 2 ..) die 0,1 KWh gezählt werden, also ein Peak mit 4000 W entsteht.
Das ist in meiner Anwendung (klassischer Verbrauchszähler) völliger Unsinn. Den Hauptzweck, nämlich mal die Grundlast z.B. nachts erkennen und von Spitzenverbräuchen zu trennen, ist in der Grafik nur in der Wochenansicht möglich.
Aus meiner SIcht ist die richtige Methode, jeden Zählerstand genau ein Mal in die Datenbank zu schreiben. Dann kann aus der Zeitdifferenz der 0,1KWh-Sprünge der mittlere Energieverbrauch in dieser Zeit ermittelt und dargestellt werden.
Testweise hab ich für die Mitte des folgenden Diagramms mal die doppelten Werte manuell aus der Datenbank entfernt- mit m.E. korrektem Ergebnis.

Zur Frage im Beitrag darüber: Ja, eine Option, alle Duplikate zu entfernen, wäre die Lösung.

Danke,
Gunnar

[andig]

Das ist in meiner Anwendung (klassischer Verbrauchszähler) völliger Unsinn

So ist es. Zumal:

• der von Matthias gewünschte Effekt im Frontend durch steps erreicht werden kann (ich wiederhole mich da)
• der Effekt durch die Paketierung von Tupeln in der Middleware ohnehin nicht mit Sicherheit erziel werden kann und
• das Problem der Zählerauflösung völlig ignoriert wird

Der letzte "Alt-"messwert DARF nicht gespeichert werden.

[mbehr1]

Ok. Ich füge Parameter hinzu mit dem man steuern kann, ob man den letzten Wert habe möchte (Default keine Doppler) (und werde mir dann bei mir im Frontend auch mal "steps" anschauen ;-)

Gruß
Matthias

Sent from a mobile device.

Am 04.03.2015 um 08:35 schrieb andig notifications@github.com:

Das ist in meiner Anwendung (klassischer Verbrauchszähler) völliger Unsinn

So ist es. Zumal:

der von Matthias gewünschte Effekt im Frontend durch steps erreicht werden kann (ich wiederhole mich da)
der Effekt durch die Paketierung von Tupeln in der Middleware ohnehin nicht mit Sicherheit erziel werden kann und
das Problem der Zählerauflösung völlig ignoriert wird
Der letzte "Alt-"messwert DARF nicht gespeichert werden.

—
Reply to this email directly or view it on GitHub.

[andig]

Ich füge Parameter hinzu mit dem man steuern kann, ob man den letzten Wert habe möchte

Bitte nicht. Einfach den Wert weg lassen. Wer den haben will muss die duplicate Option nicht nutzen. Ich habs- Hand aufs Herz- vor "Erfindung" der Aggregation hoch und runter analysiert (Beweis durch Behauptung ;)

[mbehr1]

Ich mag nicht, dass das dadurch eine wichtige Information verloren geht:
wann war der letzte Zeitpunkt, bei dem der Wert noch gleich war.
Bei absoluten Zählerständen ist das egal (und die Argumentation dass der Verbrauch ja eigentlich in der gesamten Zeit angefallen ist, ist komplett korrekt), bei relativ (/differenzierten) Werten (Verbrauch/Leistung) aber nicht. Da hat die Leistungsänderung nur in dem letzten Zeitabschnitt stattgefunden.
(Bsp: Verbrauch Wasser pro Messung:
2 2 2 2 2 0
2 0
ist Informationsverlust)

Ein Parameter mit Default auf deinem gewünschten Verhalten, der also auch weggelassen werden kann, schadet doch nicht. (-> Anwendungsfall für den Conf Editor, wo solche Parameter zB nur im Expertenmode abgefragt werden).

Gruß
Matthias

Sent from a mobile device.

Am 04.03.2015 um 10:12 schrieb andig notifications@github.com:

Ich füge Parameter hinzu mit dem man steuern kann, ob man den letzten Wert habe möchte

Bitte nicht. Einfach den Wert weg lassen. Wer den haben will muss die duplicate Option nicht nutzen. Ich habs- Hand aufs Herz- vor "Erfindung" der Aggregation hoch und runter analysiert (Beweis durch Behauptung ;)

—
Reply to this email directly or view it on GitHub.

[nyphis]

Das sehe ich auch so.
Beispiel aus der Realität: Meine Wärmepumpe verbraucht über den Tag beim aktuellen Wetter recht kontiniuerlich Strom.
Dabei gibt es über den Tag aber durch den Netzversorger 3x 1h Abschaltzeiten in denen der Netzversorger per Zeitschaltuhr die Stromentnahme auf dem Wärmepumpenzähler verbietet. In diesem Zeitraum verbraucht die Wärmepumpe nix.
Und auch des nächtens verbraucht die Wärmepumpe über ca. 7h keinen Strom. Sollte aber die Wassertemperatur mal in den Keller gehen, weil mitten in der Nacht jemand duscht, springt die WP auch da mal kurz an.

In beiden Fällen hätte ich keine Zeiten mehr, wo nichts verbraucht wird, sondern einen kontinuierlichen Verbrauch lt. Frontend obwohl nichts angefallen ist. Der Wert mag über die Nacht verschwindend gering sein, aber über den Tag (und wenn die WP im Winter ordernlich ballert) macht sich das schon bemerkbar.

Ich kann bei reinen Zählerständen nunmal nicht ermitteln, in welchem Zeitraum und welcher Höhe die Stromentnahme stattgefunden hat. Aber ich kann mir leider keinen anderen Zähler aussuchen.

[andig]

In beiden Fällen hätte ich keine Zeiten mehr, wo nichts verbraucht wird, sondern einen kontinuierlichen Verbrauch lt. Frontend obwohl nichts angefallen ist.

Wie kommst Du darauf? Auf welchen Wert hast Du 'duplicates' eingestellt? Mit z.B. 300 könntest Du alle 5min einen Wert speichern, das Datenaufkommen ist vernachlässigbar.

[mbehr1]

Also: nach kurzem Telefonat mit andig hat sich die Situation geklärt:
a) Duplicates darf nur für abs. Zählerstände genutzt werden.
b) bei Impulsen macht Duplicates(entfernen) keinen Sinn. Dafür ist aggregate da.
c) die von mir angedachte Lösung ist in der Middleware/Frontend überhaupt nicht vorhanden

Daher werde ich die Implementierung wie von Andreas vorgeschlagen ändern. D.h. Duplikate können entweder komplett entfernt werden oder alle x Sek ein Wert eingefügt, nicht jedoch noch den letzten Wert vor Wechsel (den ursprünglich als "Waveform" erhaltenden).

[junibart]

Hey, das klingt gut. Freu mich schon auf einen Test.
Danke, dass Ihr hier so engagiert entwickelt...

Gunnar

[andig]

...und uns die Köpfe heissreden ;)

Danke Matthias für Deine Geduld!

[mbehr1]

Siehe PR #139. Um keine Duplicates zu bekommen, muss der Timeout aktuell auf hohen Wert eingestellt werden (z.B. alle 2Mio Sek / 23Tage). Das sollte für alle praktischen/realen Fälle reichen, oder?

[mbehr1]

merged PR after +1 from andig.

Issue can be closed, right?

[junibart]

Hi,
hab es getestet. Es wird, wie erwartet, nur der aktuelle Zählerstand einmal nach dem Sprung gesendet. Wunderbar! Danke, dass das so schnell eingebaut wurde.
werde mich mit einer Erweiterung des Wiki-Eintrags zu "meinem" Zähler revanchieren.
Grüße,

Gunnar

[skre]

Super Sache!
@junibart spontan würde ich das nicht bei einem speziellen Zähler dokumentieren. Die Erweiterung betrifft doch alle Zähler, die absolute Werte übergben.

[mbehr1]

Kann geschlossen werden, oder?

[andig]

Denke auch. Danke für die Geduld!

[skre]

Hallo,
ich bin gerade verwirrt. Wenn ich den Intervall auf 301 setze - sollte ich dann den Parameter duplicates ebenfalls auf 301 setzen?

[mbehr1]

Hallo,

eher nicht. Wenn du Duplicates auf 301 (s) setzt, dann werden alle 301s ein Wert geschickt, auch wenn der dem vorherigen entspricht.
Wenn du gleichzeitig intervall auf 0 hast, wird der Zähler ständig gepollt. Wenn sich nun der Wert häufig ändert, dann bekommst du jede Änderung in die Datenbank geschrieben. Wenn sich der Wert nicht ändert, nur alle 301s.
Wenn du intervall auf 301 setzt, dann wird der Zähler nur alle 301s gepollt (defacto wird zwischen dem Zählerabfragen/-pollen einfach 301s gewartet). Dann ist Duplicates eigentlich sinnlos, da ja dann eh jeder Wert (weil >=301s alt) geschickt wird.

Am 11.04.2015 um 14:15 schrieb skre notifications@github.com:

Hallo,
ich bin gerade verwirrt. Wenn ich den Intervall auf 301 setze - sollte ich dann den Parameter duplicates ebenfalls auf 301 setzen?

—
Reply to this email directly or view it on GitHub #98 (comment).

Gruß

Matthias

[skre]

Hallo Matthias,
danke für Deine Erklärung. Ich frage mich gerade welchen Wert ich für die Duplicates setzen soll.

Hintergrund: Mein Zähler liefert nur alle 300s einen Wert und hat eine Nachkommastelle.
Ich habe jetzt den Intervall auf 15s gesetzt und Duplicates auf 3000 aber ich denke ich müsste den Wert deutlich erhöhen.

Wahrscheinlich sollte ich den Wert an eine Zeit mit sehr wenig Leistungsaufnahme anpassen (Nachts). Oder gibt es hier Erfahrungen/Empfehlungen?

[mbehr1]

Was ist denn deine Sorge? Wenn dein Zähler eh nur alle 300s einen Wert liefert, hast du doch eh keine hohe Last/kein hohes Datenvolumen. Du kannst duplicates auf sehr hohen Wert setzen (zB 24h=86400). Wenn du eher sehen willst, ob der Zähler noch Werte liefert, dann kannst du auch einen sehr kleinen Wert nehmen (oder duplicates komplett weg lassen).

Gruß
Matthias

Sent from a mobile device.

Am 11.04.2015 um 20:35 schrieb skre notifications@github.com:

Hallo Matthias,
danke für Deine Erklärung. Ich frage mich gerade welchen Wert ich für die Duplicates setzen soll.

Hintergrund: Mein Zähler liefert nur alle 300s einen Wert und hat eine Nachkommastelle.
Ich habe jetzt den Intervall auf 15s gesetzt und Duplicates auf 3000 aber ich denke ich müsste den Wert deutlich erhöhen.

Wahrscheinlich sollte ich den Wert an eine Zeit mit sehr wenig Leistungsaufnahme anpassen (Nachts). Oder gibt es hier Erfahrungen/Empfehlungen?

—
Reply to this email directly or view it on GitHub.

[skre]

Meine Sorge galt der Kurvenform. Aber ich habe nun gesehen, dass ein höherer Duplicate lediglich das zeichnen der Linie bis zum nächsten (veränderten) Datenpunkt verhindert.

Das passt für mich. Vielen Dank für die Erweiterung!