[vz-users] Absolute Zählerstände mit Peaks

Mo Mär 20 13:32:04 CET 2023

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/8182aa76/attachment-0001.html>