<div dir="auto">Noch was vergessen: so lang dein Zähler nichts genaueres liefert als eine Auflösung von 1kWh, solltest du eine sehr lange aggtime einstellen (z.B. 900-3600).<div dir="auto"><br><div dir="auto">aggfixedinterval brauchst du in deinem Setup nicht, das wird erst interessant bei mehreren Zählern, mit deren Werten gerechnet werden soll.</div><div dir="auto"><br></div><div dir="auto">Gruß</div><div dir="auto">Frank</div></div></div><br><div class="gmail_quote"><div dir="ltr">Am Sa., 29. Dez. 2018, 17:25 hat Andreas Witsch <<a href="mailto:andreaswitsch@googlemail.com">andreaswitsch@googlemail.com</a>> geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo<br>
<br>
und danke schonmal soweit - jetzt brauche ich wenigstens nichtmehr in <br>
die falsche Richtung probieren und es ist klar. Bei verbose 15 bekomme <br>
ich je Sekunde folgendes:<br>
<br>
[Dec 29 17:18:37][mtr0] Got 1 new readings from meter:<br>
[Dec 29 17:18:37][mtr0] Reading: <br>
id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255 value=6445000.00 <br>
ts=14632565000<br>
[Dec 29 17:18:37][chn0] Adding reading to queue (value=6445000.00 <br>
ts=14632565000)<br>
[Dec 29 17:18:37][MAX]  6445000.000000 @ 14632565000<br>
[Dec 29 17:18:37][MAX]  RESULT 6445000.000000 @ 14632565000<br>
[Dec 29 17:18:37][chn0] ==> number of tuples: 1<br>
[Dec 29 17:18:37][chn0] compare: 14632564000 14632565000<br>
[Dec 29 17:18:37][chn0] copied 1/1 values for middleware transmission<br>
[Dec 29 17:18:37][chn0] JSON request body: [ [ 14632565000, 6445000 ] ]<br>
[Dec 29 17:18:37][chn0] CURL: Hostname localhost was found in DNS cache<br>
[Dec 29 17:18:37][chn0] CURL:   Trying ::1...<br>
[Dec 29 17:18:37][chn0] CURL: TCP_NODELAY set<br>
[Dec 29 17:18:37][chn0] CURL: Connected to localhost (::1) port 80 (#17)<br>
[Dec 29 17:18:37][chn0] CURL: Sent 28 bytes..<br>
[Dec 29 17:18:37][chn0] CURL: Sent '[ [ 14632565000, 6445000 ] ]' bytes<br>
[Dec 29 17:18:37][chn0] CURL: upload completely sent off: 28 out of 28 bytes<br>
[Dec 29 17:18:37][chn0] CURL: HTTP 1.0, assume close after body<br>
[Dec 29 17:18:37][chn0] CURL: Received 26 bytes<br>
[Dec 29 17:18:37][chn0] CURL: Received '{"version":"0.3","rows":1}' bytes<br>
[Dec 29 17:18:37][chn0] CURL: Curl_http_done: called premature == 0<br>
[Dec 29 17:18:37][chn0] CURL: Closing connection 17<br>
[Dec 29 17:18:37][chn0] CURL Request succeeded with code: 200<br>
[Dec 29 17:18:37][chn0] emptied all (1) values<br>
<br>
Jetzt hätte ich aber schon erwartet, dass ich eine gerade sehe, welche <br>
den aktuellen Zählerstand dar stellt.<br>
<br>
MfG<br>
<br>
         Andreas<br>
<br>
<br>
Am 29.12.2018 um 11:27 schrieb Daniel Lauckner:<br>
> Hallo,<br>
><br>
><br>
> ein Logfile (verbose = 15) dazu wäre wichtig.<br>
><br>
><br>
> am Samstag, 29. Dezember 2018 um 09:34 hat Andreas Witsch geschrieben:<br>
>> also in Fall 1 (Konfig wie zuvor beschrieben)<br>
>> /var/log/vzlogger.log bekomme ich je Übertragung (verbose = 5)       einen solchen Eintrag:<br>
>><br>
>> [Dec 28 15:15:18][chn0] Adding reading to queue (value=6400000.00   ts=14538767000)<br>
>>         [Dec 28 15:15:19][chn0] Adding reading to queue<br>
>> (value=6400000.00       ts=14538768000)<br>
> Wir sind zwar durchaus auch mal dafür ein Logfile sinnvoll zu kürzen,<br>
> 2 Zeilen sind aber defintiv zu wenig.<br>
><br>
>>   xxd </dev/ttyUSB0<br>
>>    00000000: 7678 0000 1b1b 1b1b 1a01 273a 1b1b 1b1b          vx........':....<br>
> Ganz eindeutig SML.<br>
><br>
>> Dieser String "LGZ", der hier auftaucht, scheint auch bei dem<br>
>> E350 vor zu kommen:<br>
> Das Modell spricht aber d0.<br>
> Es ist keine Überraschung für uns wenn ähnlich klingende Zähler<br>
> eines Herstellers unterschiedliche Protokolle unterstützen.<br>
><br>
><br>
><br>
> mfg Daniel<br>
><br>
</blockquote></div>