[vz-users] Absolute Zählerstände mit Peaks
Christian Lange
brlnr23 at gmail.com
Mo Mär 20 12:03:31 CET 2023
Hi Frank,
ja, das sind die Stände, wie sie in der DB stehen. In den Logs sehe ich
auch nur 2 Nachkommastellen und auch der Zähler selbst zeigt nur zwei
Stellen an. Scheint also einfach am Zähler zu liegen.
Das Auslesen dauert aber tatsächlich recht lange, weil eine Vielzahl von
Daten abgefragt werden. Nicht nur ein Haufen OBIS Codes sondern auch
noch ein Haufen Vorwertzählerstände. Wie ich die loswerde muss ich wohl
mit dem Hersteller mal klären ...
Das sieht dann für einen einzigen Code so aus:
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0,
value=000149.98, unit=kWh)
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*01,
value=000000.00, unit=kWh)
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00,
value=000000.00, unit=kWh)
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99,
value=000000.00, unit=kWh)
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98,
value=000000.00, unit=kWh)
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97,
value=000000.00, unit=kWh)
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88,
value=000000.00, unit=kWh)
[Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87,
value=000000.00, unit=kWh)
Korrigiert habe ich jetzt die Position der Leseköpfe nochmal, aber ich
erwarte da keine Wunder :/ Bleibt also wohl nur das manuelle
korrigieren, nachdem die Daten in der DB gelandet sind.
Vielen Dank aber in jedem Fall für die Tips!
Christian
Am 17.03.2023 um 21:11 schrieb Frank Richter:
> Hallo Christian,
>
> aggmode: max ist schon richtig für Zählerstände, alles andere
> verfälscht nur das Ergebnis.
>
> Zu deinem Screenshot: sind das die Zählerstände so wie sie in der DB
> stehen? Dann würde ich am ehesten einen Übertragungsfehler vermuten.
> D0 bringt ja leider keine Checksumme oder ähnliches mit, um diese
> auszusortieren. Hast du versucht die Positionierung des Lesekopfs zu
> optimieren?
> Liefert der Zähler nur 2 Dezimalstellen, oder sind die abgeschnitten?
>
> Grüße
> Frank
>
> Christian Lange <brlnr23 at gmail.com> schrieb am Fr., 17. März 2023, 14:57:
>
> Ahoi,
>
> die 20s stammen vom Debuggen. Vielleicht war da auch der
> Flaschenhals. Ich kann das ja nochmal messen und berichten, wie
> lange es dauert bis sich in den Logs ein "parsed Value" findet.
>
> Wieder was gelernt mit dem inexistenten Intervall ;) Bleibt die
> Frage nach dem sinnvollen Aggmode :/
>
> Die Timestamps enden auf 0, weil ich die Query für's bessere
> Vergleichen/Lesen dahingehend gebaut habe (timestamp DIV 60*60).
> Real sind die Werte andere.
>
> Viele Grüße,
> Christian
> Am 17.03.2023 um 14:51 schrieb Frank Richter:
>> 20 s dauert einmal Auslesen? Puh, das ist lang.
>>
>> Ohne interval sollte er das einfach in Dauerschleife machen.
>>
>> Warum enden deine Timestamps glatt auf :00?
>>
>> Grüße
>> Frank
>>
>> Christian Lange <brlnr23 at gmail.com> schrieb am Fr., 17. März
>> 2023, 13:02:
>>
>> Hi Frank,
>>
>> das mit der Aggregation war gestern Abend auch schon mein
>> Gedanke. Ich bin jetzt mal mit aggTime: 60 und Interval: 30
>> ins Rennen gegangen. Das reine Auslesen dauert knapp unter
>> 20s - 30s Intervall sollte also passen. Die Anzahl der
>> Ausreißer ist auch geringer geworden. Es gibt sie aber
>> weiterhin. Der AggMode ist aktuell "max" - das dürfte aber
>> auch eigentlich nichts bringen - wenn innerhalb des
>> Aggregationszeitraumes ein fehlerhafter Wert ausgelesen wird,
>> dann ist der i.d.R. = dem Max Wert und wird also reported.
>>
>> Zu deinem Vorschlag, mit dem Intervall zu spielen: Wie
>> bekomme ich den Pull Zähler zum reden, wenn ich kein
>> Intervall angebe?
>>
>> Hier mal ein Beispiel - um 23:24:00 ist der ermittelte Wert
>> weit höher als vorher und(!) nachher. Ich brauche also
>> irgendeine Möglichkeit diesen Fehler zu korrigieren. Für's
>> menschliche Auge easy - für eine elegante softwarelösung
>> nicht ganz so trivial ;)
>>
>> Ideen sind willkommen :))
>>
>> Viele Grüße,
>> Christian
>>
>> Am 17.03.2023 um 00:10 schrieb Frank Richter:
>>> Hallo Christian,
>>>
>>> denke das liegt am fixen Intervall. Manchmal erwischst du
>>> den Zählerstand wenn er frisch umgesprungen ist, und
>>> manchmal liegt er schon ein paar Sekunden an bis er gelesen
>>> wird.
>>> Vermutlich sind die Push Zähler hier im Vorteil, weil sie
>>> das Push-Intervall in gewissen Grenzen an die anliegende
>>> Leistung anpassen können.
>>> Ich würde mal mit kurzem/ohne Intervall und einer längeren
>>> aggtime rumprobieren.
>>>
>>> Grüße
>>> Frank
>>>
>>>
>>> Christian Lange <brlnr23 at gmail.com> schrieb am Do., 16. März
>>> 2023, 13:56:
>>>
>>> Ahoi zusammen,
>>>
>>> ich hab seit kurzem zwei neue Stromzähler installiert
>>> bekommen. Mit ein
>>> bisschen rumprobieren ist es auch gelungen die Daten von
>>> beiden
>>> auszulesen (die absoluten Zählerstände). Was mir jetzt
>>> nach einigen
>>> Tagen jedoch aufgefallen ist: Manchmal sind Sprünge in
>>> den Zählerständen
>>> drin. Nicht viel, aber definitiv ungewöhnlich. Bei den
>>> alten Zählern war
>>> das nicht der Fall (Push, SML, mit aggtime alle 60s).
>>>
>>> Was ich mich jetzt frage: Kennt ihr dieses Phänomen und
>>> liegt es eher am
>>> Zähler oder am VZ Logger? Hier der Auszug aus der conf:
>>>
>>> "enabled" : true,
>>> "protocol" : "d0",
>>> "device" : "/dev/ttyUSB0",
>>> "pullseq": "2F3F210D0A",
>>> "ackseq": "auto",
>>> "baudrate": 300,
>>> "baudrate_read": 19200,
>>> "parity": "7e1",
>>> "wait_sync": "off",
>>> "read_timeout": 10,
>>> "baudrate_change_delay": 400,
>>> "interval": 60,
>>> "channels" : [{
>>> "uuid": "...",
>>> "identifier": "255-255:1.8.0",
>>> "api": "volkszaehler",
>>> "middleware": "..."
>>> },{
>>> "uuid": "...",
>>> "identifier": "255-255:2.8.0",
>>> "api": "volkszaehler",
>>> "middleware": "..."
>>> }],
>>>
>>> Vielleicht kennt ja jemand von euch dieses Phänomen -
>>> oder noch besser:
>>> hat eine Idee, wie man das elegant lösen kann ;)
>>>
>>> Viele Grüße,
>>> Chris
>>>
>>>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20230320/730a62f2/attachment.html>
Mehr Informationen über die Mailingliste volkszaehler-users