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

[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/20230317/b18cb161/attachment-0001.html>