[vz-users] Landis & Gyr E320
Andreas Witsch
andreaswitsch at googlemail.com
Sat Dec 29 22:12:37 CET 2018
Ok macht. Sinn. Danke!
Aber komisch, dass ich keinen Graph sehe, obwohl die Y-Achse jetzt
sinnvoll zu skalieren scheint...
Am 29.12.2018 um 22:01 schrieb Frank Richter:
> Kennst du https://wiki.volkszaehler.org/development/api/reference schon?
>
> min und max sind 2er-Tupel aus Timestamp und Wert, alle anderen sind
> 3er-Tupel aus Timestamp, Wert und Anzahl Datensätze, aus denen der
> Wert berechnet wurde.
>
>
> Am Sa., 29. Dez. 2018, 20:17 hat Andreas Witsch
> <andreaswitsch at googlemail.com <mailto:andreaswitsch at googlemail.com>>
> geschrieben:
>
> Und noch ein letztes:
>
> Warum sagt die GUI folgendes zu meiner UUID?
>
> {"version":"0.3","data":{"tuples":[[14642458000,0,1]],"uuid":"b0f82f60-094d-11e9-9828-5bd8461afe20","from":14642457000,"to":14642458000,"min":[14642458000,0],"max":[14642458000,0],"average":0,"consumption":0,"rows":2}}
>
> Das rows nur 2 sind finde ich etwas merkwürdig. Min und Max deutet sehen ausserdem wie ein Zeitstempel aus und nicht wie Messwerte. Macht das Sinn?
>
> Ich hätte für min 0, für max 1 und als rows die Anzahl der Messwerte erwartet?
>
> Gruß und Danke! Jetzt bin ich mit meinen Fragen erstmal durch... zumindest bis ich es schaffe meinen Zähler in den "erweiterten Modus" zu versetzen. :D
>
> Andreas
>
>
>
> Am 29.12.2018 um 20:09 schrieb Frank Richter:
>> Ja, das passt für Zählerstände.
>>
>> Am Sa., 29. Dez. 2018, 20:07 hat Andreas Witsch
>> <andreaswitsch at googlemail.com
>> <mailto:andreaswitsch at googlemail.com>> geschrieben:
>>
>> Hallo nochmal,
>>
>> Ist denn aggmode MAX sinnvoll?
>>
>> Gruß
>>
>> Andreas
>>
>>
>>
>> Am 29.12.2018 um 17:39 schrieb Frank Richter:
>>> 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).
>>>
>>> aggfixedinterval brauchst du in deinem Setup nicht, das wird
>>> erst interessant bei mehreren Zählern, mit deren Werten
>>> gerechnet werden soll.
>>>
>>> Gruß
>>> Frank
>>>
>>> Am Sa., 29. Dez. 2018, 17:25 hat Andreas Witsch
>>> <andreaswitsch at googlemail.com
>>> <mailto:andreaswitsch at googlemail.com>> geschrieben:
>>>
>>> Hallo
>>>
>>> und danke schonmal soweit - jetzt brauche ich wenigstens
>>> nichtmehr in
>>> die falsche Richtung probieren und es ist klar. Bei
>>> verbose 15 bekomme
>>> ich je Sekunde folgendes:
>>>
>>> [Dec 29 17:18:37][mtr0] Got 1 new readings from meter:
>>> [Dec 29 17:18:37][mtr0] Reading:
>>> id=1-0:1.8.0*255/ObisIdentifier:1-0:1.8.0*255
>>> value=6445000.00
>>> ts=14632565000
>>> [Dec 29 17:18:37][chn0] Adding reading to queue
>>> (value=6445000.00
>>> ts=14632565000)
>>> [Dec 29 17:18:37][MAX] 6445000.000000 @ 14632565000
>>> [Dec 29 17:18:37][MAX] RESULT 6445000.000000 @ 14632565000
>>> [Dec 29 17:18:37][chn0] ==> number of tuples: 1
>>> [Dec 29 17:18:37][chn0] compare: 14632564000 14632565000
>>> [Dec 29 17:18:37][chn0] copied 1/1 values for middleware
>>> transmission
>>> [Dec 29 17:18:37][chn0] JSON request body: [ [
>>> 14632565000, 6445000 ] ]
>>> [Dec 29 17:18:37][chn0] CURL: Hostname localhost was
>>> found in DNS cache
>>> [Dec 29 17:18:37][chn0] CURL: Trying ::1...
>>> [Dec 29 17:18:37][chn0] CURL: TCP_NODELAY set
>>> [Dec 29 17:18:37][chn0] CURL: Connected to localhost
>>> (::1) port 80 (#17)
>>> [Dec 29 17:18:37][chn0] CURL: Sent 28 bytes..
>>> [Dec 29 17:18:37][chn0] CURL: Sent '[ [ 14632565000,
>>> 6445000 ] ]' bytes
>>> [Dec 29 17:18:37][chn0] CURL: upload completely sent
>>> off: 28 out of 28 bytes
>>> [Dec 29 17:18:37][chn0] CURL: HTTP 1.0, assume close
>>> after body
>>> [Dec 29 17:18:37][chn0] CURL: Received 26 bytes
>>> [Dec 29 17:18:37][chn0] CURL: Received
>>> '{"version":"0.3","rows":1}' bytes
>>> [Dec 29 17:18:37][chn0] CURL: Curl_http_done: called
>>> premature == 0
>>> [Dec 29 17:18:37][chn0] CURL: Closing connection 17
>>> [Dec 29 17:18:37][chn0] CURL Request succeeded with
>>> code: 200
>>> [Dec 29 17:18:37][chn0] emptied all (1) values
>>>
>>> Jetzt hätte ich aber schon erwartet, dass ich eine
>>> gerade sehe, welche
>>> den aktuellen Zählerstand dar stellt.
>>>
>>> MfG
>>>
>>> Andreas
>>>
>>>
>>> Am 29.12.2018 um 11:27 schrieb Daniel Lauckner:
>>> > Hallo,
>>> >
>>> >
>>> > ein Logfile (verbose = 15) dazu wäre wichtig.
>>> >
>>> >
>>> > am Samstag, 29. Dezember 2018 um 09:34 hat Andreas
>>> Witsch geschrieben:
>>> >> also in Fall 1 (Konfig wie zuvor beschrieben)
>>> >> /var/log/vzlogger.log bekomme ich je Übertragung
>>> (verbose = 5) einen solchen Eintrag:
>>> >>
>>> >> [Dec 28 15:15:18][chn0] Adding reading to queue
>>> (value=6400000.00 ts=14538767000)
>>> >> [Dec 28 15:15:19][chn0] Adding reading to queue
>>> >> (value=6400000.00 ts=14538768000)
>>> > Wir sind zwar durchaus auch mal dafür ein Logfile
>>> sinnvoll zu kürzen,
>>> > 2 Zeilen sind aber defintiv zu wenig.
>>> >
>>> >> xxd </dev/ttyUSB0
>>> >> 00000000: 7678 0000 1b1b 1b1b 1a01 273a 1b1b 1b1b
>>> vx........':....
>>> > Ganz eindeutig SML.
>>> >
>>> >> Dieser String "LGZ", der hier auftaucht, scheint auch
>>> bei dem
>>> >> E350 vor zu kommen:
>>> > Das Modell spricht aber d0.
>>> > Es ist keine Überraschung für uns wenn ähnlich
>>> klingende Zähler
>>> > eines Herstellers unterschiedliche Protokolle
>>> unterstützen.
>>> >
>>> >
>>> >
>>> > mfg Daniel
>>> >
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20181229/5d0755f4/attachment-0001.html>
More information about the volkszaehler-users
mailing list