Re: [vz-users] Absolute Zählerstände mit Peaks
Hallo, am Montag, 20. März 2023 um 13:32 hat René W geschrieben: > Ein Schuss ins Blaue: Könntest du die Werte per SML abfragen? Das wäre der erste mir bekannte Zähler der beide Protokolle unterstützt... mfg Daniel
Re: [vz-users] Absolute Zählerstände mit Peaks
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 : 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=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87, value=00.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 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 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
Re: [vz-users] Absolute Zählerstände mit Peaks
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 < brln...@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=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97, > value=00.00, unit=kWh) > [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88, > value=00.00, unit=kWh) > [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87, > value=00.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 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 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
Re: [vz-users] Absolute Zählerstände mit Peaks
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=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*00, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*99, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*98, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*97, value=00.00, unit=kWh) [Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0*96, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*95, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*94, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*93, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*92, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*91, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*90, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*89, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*88, value=00.00, unit=kWh) [Mar 20 10:38:28][d0] Parsed reading (OBIS code=2.8.0*87, value=00.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 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 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
Re: [vz-users] Absolute Zählerstände mit Peaks
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 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 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 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
>>>
>>>
>>>
Re: [vz-users] Absolute Zählerstände mit Peaks
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 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 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
Re: [vz-users] Absolute Zählerstände mit Peaks
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 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 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
>>
>>
>>
Re: [vz-users] Absolute Zählerstände mit Peaks
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 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
Re: [vz-users] Absolute Zählerstände mit Peaks
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 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
>
>
>
[vz-users] Absolute Zählerstände mit Peaks
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
