<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Moin René, im Datenblatt zum Zähler finde ich nur Angaben zu d0.
Ist also leider nichts mit SML :( <br>
</p>
<div class="moz-cite-prefix">Am 20.03.2023 um 13:32 schrieb René W:<br>
</div>
<blockquote type="cite"
cite="mid:CAOgXsDsxsLTZTk4ZK3Ab3Ty++wPZMFn2y_61h_Xiy1nuqHWMEw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Mo., 20. März 2023 um
12:04 Uhr schrieb Christian Lange <<a
href="mailto:brlnr23@gmail.com" moz-do-not-send="true"
class="moz-txt-link-freetext">brlnr23@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Frank, <br>
</p>
<p>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. <br>
</p>
<p>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 ... <br>
</p>
<p>Das sieht dann für einen einzigen Code so aus:<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS code=2.8.0,
value=000149.98, unit=kWh)<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS
code=2.8.0*01, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS
code=2.8.0*00, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS
code=2.8.0*99, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS
code=2.8.0*98, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS
code=2.8.0*97, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:27][d0] Parsed reading (OBIS
code=2.8.0*96, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*95, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*94, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*93, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*92, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*91, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*90, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*89, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*88, value=000000.00, unit=kWh)<br>
[Mar 20 10:38:28][d0] Parsed reading (OBIS
code=2.8.0*87, value=000000.00, unit=kWh)<br>
</p>
<p>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. <br>
</p>
<p>Vielen Dank aber in jedem Fall für die Tips!</p>
<p>Christian<br>
</p>
<p><br>
</p>
<div>Am 17.03.2023 um 21:11 schrieb Frank Richter:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>Hallo Christian,</div>
<div dir="auto"><br>
</div>
<div dir="auto">aggmode: max ist schon richtig für
Zählerstände, alles andere verfälscht nur das
Ergebnis.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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?</div>
<div dir="auto">Liefert der Zähler nur 2 Dezimalstellen,
oder sind die abgeschnitten?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Grüße</div>
<div dir="auto">Frank<br>
<br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">Christian Lange
<<a href="mailto:brlnr23@gmail.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">brlnr23@gmail.com</a>>
schrieb am Fr., 17. März 2023, 14:57:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Ahoi, <br>
</p>
<p>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.<br>
</p>
<p>Wieder was gelernt mit dem inexistenten
Intervall ;) Bleibt die Frage nach dem
sinnvollen Aggmode :/ <br>
</p>
<p>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.</p>
Viele Grüße,<br>
Christian
<div>Am 17.03.2023 um 14:51 schrieb Frank
Richter:<br>
</div>
<blockquote type="cite">
<div dir="auto">20 s dauert einmal Auslesen?
Puh, das ist lang.
<div dir="auto"><br>
</div>
<div dir="auto">Ohne interval sollte er das
einfach in Dauerschleife machen.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Warum enden deine Timestamps
glatt auf :00?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Grüße</div>
<div dir="auto">Frank </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Christian
Lange <<a
href="mailto:brlnr23@gmail.com"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">brlnr23@gmail.com</a>>
schrieb am Fr., 17. März 2023, 13:02:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Frank, <br>
</p>
<p>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. <br>
</p>
<p>Zu deinem Vorschlag, mit dem
Intervall zu spielen: Wie bekomme ich
den Pull Zähler zum reden, wenn ich
kein Intervall angebe? <br>
</p>
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 ;)<br>
<p><img alt="" moz-do-not-send="true"></p>
<p>Ideen sind willkommen :)) <br>
</p>
<p>Viele Grüße,<br>
Christian</p>
<div>Am 17.03.2023 um 00:10 schrieb
Frank Richter:<br>
</div>
<blockquote type="cite">
<div dir="auto">Hallo Christian,
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto">Vermutlich sind die
Push Zähler hier im Vorteil, weil
sie das Push-Intervall in gewissen
Grenzen an die anliegende Leistung
anpassen können.</div>
<div dir="auto">Ich würde mal mit
kurzem/ohne Intervall und einer
längeren aggtime rumprobieren.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Grüße</div>
<div dir="auto">Frank </div>
<div dir="auto"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Christian
Lange <<a
href="mailto:brlnr23@gmail.com"
rel="noreferrer noreferrer
noreferrer noreferrer"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">brlnr23@gmail.com</a>>
schrieb am Do., 16. März 2023,
13:56:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Ahoi
zusammen,<br>
<br>
ich hab seit kurzem zwei neue
Stromzähler installiert bekommen.
Mit ein <br>
bisschen rumprobieren ist es auch
gelungen die Daten von beiden <br>
auszulesen (die absoluten
Zählerstände). Was mir jetzt nach
einigen <br>
Tagen jedoch aufgefallen ist:
Manchmal sind Sprünge in den
Zählerständen <br>
drin. Nicht viel, aber definitiv
ungewöhnlich. Bei den alten
Zählern war <br>
das nicht der Fall (Push, SML, mit
aggtime alle 60s).<br>
<br>
Was ich mich jetzt frage: Kennt
ihr dieses Phänomen und liegt es
eher am <br>
Zähler oder am VZ Logger? Hier der
Auszug aus der conf:<br>
<br>
"enabled" : true,<br>
"protocol" : "d0",<br>
"device" : "/dev/ttyUSB0",<br>
"pullseq": "2F3F210D0A",<br>
"ackseq": "auto",<br>
"baudrate": 300,<br>
"baudrate_read": 19200,<br>
"parity": "7e1",<br>
"wait_sync": "off",<br>
"read_timeout": 10,<br>
"baudrate_change_delay": 400,<br>
"interval": 60,<br>
"channels" : [{<br>
"uuid": "...",<br>
"identifier":
"255-255:1.8.0",<br>
"api": "volkszaehler",<br>
"middleware": "..."<br>
},{<br>
"uuid": "...",<br>
"identifier":
"255-255:2.8.0",<br>
"api": "volkszaehler",<br>
"middleware": "..."<br>
}],<br>
<br>
Vielleicht kennt ja jemand von
euch dieses Phänomen - oder noch
besser: <br>
hat eine Idee, wie man das elegant
lösen kann ;)<br>
<br>
Viele Grüße,<br>
Chris<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>