[vz-users] Landis & Gyr E320

[Frank Richter]

Wie geschrieben, deine Daten stehen mit Datum von 1970 in der DB.

Am Sa., 29. Dez. 2018, 22:12 hat Andreas Witsch <
andreaswitsch at googlemail.com> geschrieben:

> 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> 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> 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> 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/816386fd/attachment.html>