[vz-dev] Aggregationsmode "DELTA"- eingebaut?

Mon Mar 2 08:51:24 CET 2015

Wir sollte nur an einer Stelle diskutieren, am Besten hier:
https://github.com/volkszaehler/vzlogger/issues/98

M.E. ist die aktuelle Implementierung nicht ideal wie Dein Verhalten auch
zeigt.

Viele Grüße,
Andreas

2015-03-01 21:48 GMT+01:00 <g.re at gmx.de>:

> Hallo,
>
> danke, der Tipp geht erstmal in die richtige Richtung. Mittlerweile ist es
> mir erstmal gelungen, den vzlogger aus GIT zu updaten.
> Die Konfigurationseinstellung duplicates zeigt zunächst einmal Wirkung:
> Aktuelle und vorhergehende Ablesung werden verglichen, die Middleware wird
> nur angesprochen, wenn sich etwas geändert hat. Den duplicates-Wert habe
> ich auf 1800 gesetzt.
>
> Wenn der Duplicates-check jedoch identische Ablesungen übersprungen hat,
> werden nach einem Zählersprung zwei Wertepaare übergeben- der alte Stand
> mit einem zurückliegenden Zeitstempel, und der neue mit dem aktuellen
> Zeitstempel.
> Scheint so gewollt zu sein, lt. Diskussion bei GIT: "If the value changes
> the last ignored duplicate will be send to keep the "waveform".".
>
> 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?
>
> Jedenfalls habe ich nun wieder jeden Zählerstand doppelt mit
> aufeinanderfolgenden Zeitstempeln in der Datenbank, worauf mir das Frontend
> wieder schöne Sägezähne malt (Lines) bzw. den Stromverbrauch als
> Pulsweitenmodulation zwischen  4000 und 0 W darstellt. Erst bein rauszoomen
> auf mindestens zwei Tage kann man eine sinnvolle Darstellung sehen.
>
> Hier mal die Sendungen an die middleware rausgegrept:
>
>  [Mar 01 16:30:33][chn0] CURL: Sent '[ [ 1425223727377.2668, 12811.9 ], [
> 1425223821363.771, 12812 ] ]' bytes
> [Mar 01 16:32:07][chn0] CURL: Sent '[ [ 1425223915356.1479, 12812.1 ] ]'
> bytes
> [Mar 01 16:35:15][chn0] CURL: Sent '[ [ 1425224009348.9038, 12812.1 ], [
> 1425224103341.6541, 12812.200000000001 ] ]' bytes
> [Mar 01 16:36:49][chn0] CURL: Sent '[ [ 1425224197333.084,
> 12812.299999999999 ] ]' bytes
> [Mar 01 16:39:57][chn0] CURL: Sent '[ [ 1425224291327.21,
> 12812.299999999999 ], [ 1425224385318.4551, 12812.4 ] ]' bytes
> [Mar 01 16:43:05][chn0] CURL: Sent '[ [ 1425224479311.2769, 12812.4 ], [
> 1425224573303.761, 12812.5 ] ]' bytes
> [Mar 01 16:44:39][chn0] CURL: Sent '[ [ 1425224667298.7129, 12812.6 ] ]'
> bytes
> [Mar 01 16:54:03][chn0] CURL: Sent '[ [ 1425225137282.1331, 12812.6 ], [
> 1425225231274.6128, 12812.700000000001 ] ]' bytes
> [Mar 01 17:06:35][chn0] CURL: Sent '[ [ 1425225889270.3091,
> 12812.700000000001 ], [ 1425225983261.8311, 12812.799999999999 ] ]' bytes
> [Mar 01 17:14:25][chn0] CURL: Sent '[ [ 1425226359233.0588,
> 12812.799999999999 ], [ 1425226453225.5471, 12812.9 ] ]' bytes
> [Mar 01 17:25:23][chn0] CURL: Sent '[ [ 1425227017188.312, 12812.9 ], [
> 1425227111181.811, 12813 ] ]' bytes
> [Mar 01 17:33:13][chn0] CURL: Sent '[ [ 1425227487151.6379, 12813 ], [
> 1425227581144.2151, 12813.1 ] ]' bytes
> [Mar 01 17:39:29][chn0] CURL: Sent '[ [ 1425227863122.0879, 12813.1 ], [
> 1425227957113.9099, 12813.200000000001 ] ]' bytes
> [Mar 01 17:50:27][chn0] CURL: Sent '[ [ 1425228521069.259,
> 12813.200000000001 ], [ 1425228615061.877, 12813.299999999999 ] ]' bytes
> [Mar 01 18:01:25][chn0] CURL: Sent '[ [ 1425229179016.3411,
> 12813.299999999999 ], [ 1425229273009.458, 12813.4 ] ]' bytes
> [Mar 01 18:10:49][chn0] CURL: Sent '[ [ 1425229742973.4321, 12813.4 ], [
> 1425229836964.6731, 12813.5 ] ]' bytes
> [Mar 01 18:20:13][chn0] CURL: Sent '[ [ 1425230306937.6572, 12813.5 ], [
> 1425230400930.061, 12813.6 ] ]' bytes
>
>  Das kommt in der Datenbank an:
>      12458 10 1425223821364 12812  12459 10 1425223915356 12812,1  12460
> 10 1425224009349 12812,1  12461 10 1425224103342 12812,2  12462 10
> 1425224197333 12812,3  12463 10 1425224291327 12812,3  12464 10
> 1425224385319 12812,4  12465 10 1425224479311 12812,4  12466 10
> 1425224573304 12812,5  12467 10 1425224667299 12812,6  12468 10
> 1425225137282 12812,6  12469 10 1425225231275 12812,7  12470 10
> 1425225889270 12812,7  12471 10 1425225983262 12812,8  12472 10
> 1425226359233 12812,8  12473 10 1425226453226 12812,9  12474 10
> 1425227017188 12812,9  12475 10 1425227111182 12813  12476 10
> 1425227487152 12813  12477 10 1425227581144 12813,1  12478 10
> 1425227863122 12813,1  12479 10 1425227957114 12813,2  12480 10
> 1425228521069 12813,2  12481 10 1425228615062 12813,3  12482 10
> 1425229179016 12813,3  12483 10 1425229273010 12813,4  12484 10
> 1425229742973 12813,4  12485 10 1425229836965 12813,5  12486 10
> 1425230306938 12813,5  12487 10 1425230400930 12813,6
>
> Sowohl die "Lines"- als auch die "Steps"-Darstellung sind unbefriedigend,
> erstere vor allem, wenn man bedenkt, dass die elektrische Arbeit ja die
> Fläche unter dem Graphen entsprechen müsste:
>
> [image: Inline-Bild 1]
>
> [image: Inline-Bild 2]
>
> Wenn ich mittels phpmyadmin die doppelten Einträge aus der Datenbank
> rausschmeiße, sieht es vernünftig aus, aber das kann ja nicht die Lösung
> sein.
>
> Nun, vielleicht hat ja einer eine Idee, was hier schief läuft?
>
> Am besten sah es bisher aus, wenn ich  den "interval"-Wert so hoch gesetzt
> hatte, dass mindestens ein Zählersprung in das Intervall fallen musste- bei
> ca. 310 W "Grundlast" immerhin 20 Minuten, was dann auch die maximale
> Auflösung insgesamt wäre.
> Wie schon gesagt- erwarten würde ich im Frontend waagerechte Linien in
> Höhe des durchschnittlichen Energieverbrauchs zwischen zwei Zählersprüngen.
> Alles andere ("Rampen", schräge Graphen, scheinbarer "0 Watt" Verbrauch)
> ist bei dieser Art von Zähler nicht richtig.
>
> Danke fürs Lesen,
> über etwas Hilfe freue ich mich.
>
> Beste Grüße,
>
> Gunnar
>
>
>
>
>
>
> *Gesendet:* Sonntag, 01. März 2015 um 17:28 Uhr
> *Von:* "Andreas Goetz" <cpuidle at gmail.com>
> *An:* "volkszaehler.org" <volkszaehler-dev at demo.volkszaehler.org>
> *Betreff:* Re: [vz-dev] Aggregationsmode "DELTA"- eingebaut?
>  @Gunnar: war es das oder brauchst Du noch Hilfe?
>
> 2015-02-27 18:54 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:
>>
>>  Schau mal hier- suchst Du das?
>>
>> https://github.com/volkszaehler/vzlogger/issues/98
>>
>> Viele Grüße,
>> Andreas
>>
>>
>> 2015-02-27 17:40 GMT+01:00 <g.re at gmx.de>:
>>>
>>>   Hallo VZ-Enwickler,
>>>
>>> habe vor einigen Tagen das aktuelle Raspi-Image mit Udos Lesekopf an
>>> einem EMH-ITZ zum laufen gebracht. Es läuft grundsätzlich, aber ich habe
>>> folgendes Problem:
>>>
>>> der EMH ITZ hat über die D0-Schnittstelle eine Auflösung von 0,1 KWh.
>>> Bei einer Abfrage von 1/Minute oder weniger entstehen in der Stunden- und
>>> Tagesgrafik im Frontend keine Kurven, sondern Peaks (wenn der Zähler um 0,1
>>> KWh weitergezählt hat) und Nullwerten (zwischen den Zählersprüngen). In der
>>> Wochengrafik sieht es dann besser aus, Summation etc. funktionieren.
>>> Das Frontend sollte richtig konfiguriert sein: Typ El. Energie
>>> (Zählerstände), Auflösung 1/KWh, Style Stufen.
>>>
>>> Ich könnte den Abstand der Ablesungen vergrößern, so dass bei Grundlast
>>> (nachts) mindestens ein Zählersprung im Abfrageintervall liegt. Das geht
>>> jedoch auf Kosten der (möglichen) Auflösung in Spitzenzeiten.
>>>
>>> Aus meiner Sicht wäre die Lösung, nur dann einen Zählerwert in die
>>> Datenbank zu schreiben, wenn er sich gegenüber dem vorherigen Wert geändert
>>> hat.
>>>
>>> Das ist vor anderthalb Jahren hier mal besprochen worden, jemand hat
>>> Code für einen aggmode DELTA hier gepostet.
>>> (http://comments.gmane.org/gmane.network.volkszaehler.devel/2055)
>>> Das scheint genau in Richtung meines Problems zu gehen. Leider ist es
>>> mir nicht gelungen, mit diesem Parameter etwas zu erreichen.
>>>
>>> Ist der Code für diesen Aggregations-Modus in den aktuellen VZLogger
>>> eingegangen? Wie genau muss er konfiguriert werden? Welchen Threshold-Wert
>>> sollte ich in meinem Fall wählen? Sind die Parameter im meter- oder
>>> channel-Abschnitt der .conf einzutragen?
>>> Oder muss ich einen ganz anderen Ansatz wählen? Bin ich der einzige mit
>>> so einem gering auflösenden Zähler?
>>>
>>> Es wäre schön, wenn mir da jemand weiterhelfen kann. (Beispiel-config
>>> o.ä.)
>>>
>>>
>>> Danke für die Entwicklung des Volkszählers! Ein Klasse Projekt.
>>>
>>> Grüße,
>>>
>>> Gunnar
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20150302/d5f272d9/attachment-0001.html>