[vz-users] configuration to read MT681 / vzlogger webpage shows different values than measured

[Rupert Schöttler]

Hallo Tilman,


Am 20.04.21 um 01:17 schrieb Tilman Glötzner:
> ad c)
>
> Ich habe den Kopf um 180 Grad gedreht -- danach gab es keine Einträge
> mehr im Logfile. Nachdem ich ihn wieder in die alter Orientierung 
> versetzt habe, sprudelt es im Logfile wieder. Meisten mit 4 Einträgen
> pro Minute --  seltener kommt auch mal 10 Minuten nichts. Ich habe ein
> 2 Sample der Logfiles angehängt. In vzlogger.log wird mindestens einen
> neuer Datensatz in der Minute gelesen. vzlogger1.log ist ein Beispiel,
> bei dem zwischen 2 Obisdatensätzen circa 7 Minuten vergehen. Mir fällt
> nichts besonders auf, z.B. Fehlermeldungen. Wenn die Zeit zwischen 2
> Obis-Datensätzen lang wird, füllen folgenden, sich wiederholende
> Logmeldungen  den Zeitraum:
>
> [Apr 19 22:27:33][mtr0] Got 0 new readings from meter:
> [Apr 19 22:27:33][chn0] ==> number of tuples: 0
> [Apr 19 22:27:33][chn0] JSON request body is null. Nothing to send now.
>
Hab's mir angeschaut, kann aber auch keinen Hinweis auf die Ursache
finden. Vielleicht findet ja ein Experte aus der NG noch was.


> ad d)
>
> >Derartige Diskussionen hatten wir hier schon reichlich.
>
> Das glaube ich sofort :-) Und inhaltlich bin ich fast bei Dir.
>
> Wie Du schreibst, hat es man in der Regel mit Zeit- und
> wertkontinuiertlichen Vorgängen zu tun, die die man durch Abtastung zu
> einem Zeitpunkt diskretisiert, so dass man im Prinzip keine Aussage
> über die Zwischwerte zwischen zwei Abtastpunkten treffen kann. Man
> kann  aber eine Annahme treffen, und einen Zwischenwert durch
> Interpolieren erzeugen(z.B. durch eine Linearisierung). Um bei dem
> Temperaturbeispiel zu bleiben: Bei zwei hintereinander abgestasteten
> Temperaturwerten 25 und 27 Grad wird die Temperatur zu einem
> Zwischenzeitpunkt wohl  26 Grad gewesen sein.
>
Schön: Ich sehe, die Grundlagen sind Dir vertraut, da macht die
Diskussion Spaß! :-)

Ja, die Zwischentemperatur 26° MUSS sogar irgendwann vorhanden gewesen
sein, denn Temperatur kann nicht springen. Es KANN aber auch sein, dass
sie zwischen den beiden Messpunkten irgendwo weit außerhalb dieses
Fensters war. Daher liegt es am Designer des Messaufbaus, Abtastrate und
Messgenauigkeit sinnvoll an die gestellte Aufgabe anzupassen. Dann ist
das einfache Verfahren der Linearisierung "gut genug" und kann auch vom
Volkszähler ausgeführt werden -- in der Grafik, wenn man die
entsprechende Darstellung (Stil: Linien) auswählt.

Für Leistung nutzen die meisten Leute eher "Stil: Stufen", denn so passt
es zum Messprinzip des Arbeitszählers: Wir teilen ein Delta W durch
Delta t und damit war die *mittlere* Leistung in diesem Zeitraum P --
mehr wissen wir nicht, aber diese mittlere Leistung *ist korrekt* *in
den Grenzen *(Messgenauigkeit und Diskretisierung), wie W und t erfasst
wurden. Wohlgemerkt: Dies gilt für die Grafik. Bei den Auswertungen
unter der Grafik (min, max, Mittelwert, Verbrauch, ...) macht das
Frontend keine "Kopfstände" für irgendwelche potentiellen Dinge zwischen
zwei Messpunkten. Der Verbrauch z.B. stimmt nicht 100% mit der Summe /
dem Integral über den angezeigten Zeitraum überein, weil "links und
rechts" immer der nächste Datenpunkt *außerhalb* des angezeigten
Zeitraums verwendet wird, keine Interpolation o.ä. auf exakt den
Zeitraum, der über der Grafik steht. Das ist eine bekannte Eigenschaft
der Software.


> Bei dem Energiezähler scheint mir die Situation in sofern anders zu
> sein, als dass der Vorgang als solcher zwar ebenfalls zeit- und
> wertkontinuerlich ist ( auch wenn er sich nicht direkt, sondern durch
> Integration ergibt, nämlich einer Summe von Leistungen über die Zeit).
> Allerdings erfolgt seine Änderung, anders als im Temperaturbeispiel
> nicht gleichmäßig, sondern nur, wenn eine  Einheit  verbraucht oder
> erzeugt wurde, d.h. die gemessene Größe ist wertediskret.  Beim
> klassischen Zähler mit Scheibe und 96 U/kwh  ist die Einheit krumme
> 10.416666 wh gross (wenn der rote Strich nach einer Umdrehung wieder
> am Fenster vorbei kommt) -- bei meinem supersmarten Zähler ist sie
> 1kwh. Die Lineariserung (und das Rückrechnen der Energie auf die
> Leistung) funktioniert hier nur bei höherem Verbräuchen mit
> entsprechend vielen Werten pro Zeiteinheit gut.
>
Ich sehe keinen grundlegenden Unterschied zwischen Deinen Beispielen:
Alle registrierten Änderungen erfolgen wert- und/oder zeitdiskret. Die
Temperatur kann auch nur mit endlicher Auflösung gemessen werden, und
bei den Arbeitszählern ist die Auflösung 0,0001 kWh (häufigste
Einstellung bei elektronischen Zählern nach PIN-Freigabe), 1/96 kWh bei
Deinem Ferraris-Beispiel, oder eben 1 kWh bei Deinem MT681 ohne PIN.

Das "Rückrechnen" von Energie resp. Arbeit auf Leistung entspricht
mathematisch der 1. Ableitung: P = dW/dt. In der diskreten Mathematik
führt das nur dann zu "richtigen" oder wenigstens brauchbaren
Ergebnissen, wenn Abtastfrequenz und -genauigkeit
(Werte-Diskretisierung) zusammenpassen -- und das passt bei Dir eben
genau nicht: Du machst zwar viele dt, aber nur selten gibt es ein dW.
Damit ist P meistens 0 und gelegentlich riesengroß. Das ist ein
Phänomen, das diese Software (Middleware/Frontend) nicht heilen kann.


> Vor dem Hintegrund scheint mir die Einstellung "hourly" und "Tag" oder
> "Woche" ebenfalls eine geeignete, genauso wie der Verzicht auf die
> Darstellung der Energie als Leistungen über Zeit, d.h. als Abbildung
> über die Breite des Balkens. Gleichzeitig finde ich aber, dass man
> diesem Rechnung tragen sollte und die Y-Achse des Koordinatensystem
> mit dem bezeichnet, was man tatsächlich misst: Die Energie in der
> Einheit wh oder kwh (die Einheit ist zumindest in der Datelstellung
> meines Loggers kw). Und das kann die Software nach meinem Dafürhalten
> schon lösen :-) Einige der Smartzähler scheinen zusätzlich die
> aktuelle Leistung zur Verfügung stellen zu können, so dass ich
> vermute, dass man hier eine Fallunterscheidung für die Art des Zählers
> benötigt.
>
Auch wenn ich die Balkendarstellung nicht 100% kenne: Vergiss die Breite
des Balkens! Die einzige Aussage ist seine Höhe, und zwar als Mittelwert
der angezeigten Größe (hier: Leistung!!!!) im gewählten Zeitraum.
Nochmal: Volkszähler kann mit vielen verschiedenen physikalischen Größen
umgehen, auch Temperatur oder Luftfeuchtigkeit oder Ventilstellung
EIN/AUS. Verbrauchszähler (Gas, Wasser, Elektrizität), die Zählerstände
liefern, werden für die Anzeige sofort auf Leistung resp. Verbrauchsrate
(l/h, m³/h) umgerechnet, weil eine monoton steigende Linie des
Zählerstandes langweilig ist und wir dann doch nur die Steigung der
Linie (1. Ableitung!!) abschätzen würden. Das führt dann bei der
erneuten Rückrechnung (Integration) auf den Verbrauch im angezeigten
Zeitraum zu kleinen Ungenauigkeiten, s.o.


> >- Sinnvolle Anpassung der Auflösungen (Zeit und Größe), entweder
> durch Freischalten einer höheren Auflösung der Zählerstände >mittels
> PIN oder durch Reduktion der Abtastrate z.B. auf 1/h (sollte mit
> aggtime gehen)
>
> Die Pin habe ich am Samstag beim Stromversorger angefragt. Mal sehen,
> was da kommt. Und aggtime habe ich nun auf 3600 gesetzt.
>
Gefallen Dir die im Frontend anzeigten Ergebnisse nun besser?


> Vielen Dank und viele Grüße nach Augsburg
>
>
> Tilman
>
Gerne doch :-)

Rupert


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20210421/337fa1c0/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 5996 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20210421/337fa1c0/attachment-0001.bin>