[vz-users] Absolute Zählerstände mit Peaks
Christian Lange
brlnr23 at gmail.com
Mo Mär 20 14:56:57 CET 2023
Moin René, im Datenblatt zum Zähler finde ich nur Angaben zu d0. Ist
also leider nichts mit SML :(
Am 20.03.2023 um 13:32 schrieb René W:
> Ein Schuss ins Blaue: Könntest du die Werte per SML abfragen? Ich
> meine, da werden doch weniger Daten übertragen. Kann aber auch sein,
> dass ich völlig daneben liege.
>
> Am Mo., 20. März 2023 um 12:04 Uhr schrieb Christian Lange
> <brlnr23 at gmail.com>:
>
> 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/6cd86c16/attachment-0001.html>
Mehr Informationen über die Mailingliste volkszaehler-users