<p dir="ltr">Hallo Andre,</p>
<p dir="ltr">hast du dir mal die Datenbankeinträge für den heftigen positiv/negativ-Peak angeschaut? Wäre interessant, ob in der Datenbank falsche Zählerstände stehen oder realistische Zählerstände mit falschen Timestamps.<br>
Ich hatte anfangs auch immer wieder ähnliche Peaks in meinen Diagrammen, was wohl daran lag, dass das ständige Auslesen zeitweise die I/O-Leistung meines Raspis überforderte und deshalb das System so lahm war, dass manchmal ein Messwert seinen Zeitstempel deutlich zu spät zugeordnet bekam. Dadurch war die Zeitdifferenz vor dem Messwert länger als real und die danach kürzer als real. Das äußerte sich in den Diagrammen als Kombination eines erst negativen und dann positiven Peaks, allerdings ging die Kurve nie unter null, d.h. die Reihenfolge der Messwerte blieb intakt. Ich habe das System dann dadurch entlastet, dass ich vzlogger nur noch alle 15s einen Wert an die Middleware übertragen lasse. Seitdem ist die I/O-Last erträglich und die Peaks sind weg.<br>
Bei deinem Diagramm würde ich fast vermuten, dass ein eigentlich später erfasster Messwert mit einem früheren Timestamp in der DB steht, warum auch immer. Wenn dann zu einem späteren Zeitpunkt nochmal ein geringerer Zählerstand kommt, würde das den Peak ins negative erklären.</p>
<p dir="ltr">Viele Grüße<br>
Frank</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hallo Andreas,<br>
<br>
habe schon mit der Positionierung gespielt. Glaube aber eher an ein
Einstellungs- Softwareproblem. Da wenn ich den Befehl cat
/dev/ttyAMA0 aufrufe die Daten in Ordnung sind und auch dem
aktuellen Zählerstand entsprechen.<br>
Wirk- und Scheinleistung gibt mein Zähler nicht aus, nur den
Zählerstand.<br>
<br>
Gruß Andre<br>
<br>
<div>Am 31.05.2015 um 13:36 schrieb Andreas
Götz:<br>
</div>
<blockquote type="cite">
<div>Ich kenn mich mit dem Obis Zeugs leider nixht aus, aber was
sind denn die 96.x Obis Codes? Falls da Wirk- oder
Scheinleistung dabei wäre könnte das vielleicht besser
funktionieren als Zählerstände?</div>
<div><br>
</div>
<div>Was mich verwirrt ist Deine Grafik. Die sieht nämlich nicht
nur so aus als würde der Zählerstand nach oben springen
(Überschwinger der Leistung) sondern auch als würde er wieder
zurück springen?</div>
<div><br>
</div>
<div>Vllt wäre es auch noch einen Versuch Wert die Justierung des
Kopfes nochmal etwas zu verändern?</div>
<div><br>
</div>
<div>Viele Grüße, Andreas</div>
<div><br>
<br>
<br>
</div>
<div><br>
Am 31.05.2015 um 12:46 schrieb Viper <<a href="mailto:viper@viper1.de" target="_blank">viper@viper1.de</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>
Ich bin leider immer noch nicht weiter wegen des Fehlers. Das
Log quillt immer noch vor Fehlern über. Ich habe mal einen
Dump von den Messwerten angelegt. Der sieht gut aus, leider
scheint da kein Zeitstempel bei zu sein. Auffällig ist das der
letzte Wert im Dump 6kWh hinter dem wahren Zählerstand
hinterher hängt.<br>
Wenn man vzlogger stoppt und neu startet stimmt der
Zählerstand wieder was zu einem enormen Peak in der Anzeige
des Fontend führt.<br>
Aber auch ohne Neustart kommen solche Peaks in dieser Woche
wieder extrem mit einem plus Ausschlag von <b>76,</b><b>5TW </b>mit
einem anschließenden <b>minus </b>von <b>78,1TW</b> obwohl
ich gar keinen Strom einspeise.<br>
Man beachte auch den von vzlogger errechneten Gesamtverbrauch.
Da bei mir eh nur der Zählerstand erfasst wird bräuchte dieser
auch nur im Fontend dargestellt und nicht errechnet zu werden.<br>
<br>
Hier noch ein Auszug aus dem Dump:<br>
<br>
##### 75.449117000s ( -61 ms) read<br>
>>>>> 75.449251000s ( 0 ms) <br>
0a 0a 2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30
/ISk5MT671-000 <br>
31 0a 0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 1
1-0:0.0.0*2 <br>
35 35 28 33 33 31 33 30 30 2d 35 30 33 33 31 32
55(331300-503312 <br>
34 29 0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 4)
1-0:1.8.1*25 <br>
35 28 30 33 31 32 39 36 2e 34 31 30 34 29 0a 0a
5(031296.4104) <br>
31 2d 30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38
1-0:96.5.5*255(8 <br>
30 29 0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 0)
0-0:96.1.255 <br>
2a 32 35 35 28 33 39 32 32 35 34 37 39 29 0a 0a
*255(39225479) <br>
21
! <br>
<br>
##### 5.452544000s ( -61 ms) read<br>
>>>>> 5.452681000s ( 0 ms) <br>
2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30 31 0a
/ISk5MT671-0001 <br>
0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 35 35
1-0:0.0.0*255 <br>
28 33 33 31 33 30 30 2d 35 30 33 33 31 32 34 29
(331300-5033124) <br>
0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 35 28
1-0:1.8.1*255( <br>
30 33 31 32 39 36 2e 34 31 35 32 29 0a 0a 31 2d
031296.4152) 1- <br>
30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38 30 29
0:96.5.5*255(80) <br>
0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 2a 32
0-0:96.1.255*2 <br>
35 35 28 33 39 32 32 35 34 37 39 29 0a 0a 21
55(39225479) ! <br>
<br>
##### 35.455505000s ( -61 ms) read<br>
>>>>> 35.455639000s ( 0 ms) <br>
0a 0a 2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30
/ISk5MT671-000 <br>
31 0a 0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 1
1-0:0.0.0*2 <br>
35 35 28 33 33 31 33 30 30 2d 35 30 33 33 31 32
55(331300-503312 <br>
34 29 0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 4)
1-0:1.8.1*25 <br>
35 28 30 33 31 32 39 36 2e 34 31 35 34 29 0a 0a
5(031296.4154) <br>
31 2d 30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38
1-0:96.5.5*255(8 <br>
30 29 0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 0)
0-0:96.1.255 <br>
2a 32 35 35 28 33 39 32 32 35 34 37 39 29 0a 0a
*255(39225479) <br>
21
! <br>
<br>
##### 65.458572000s ( -61 ms) read<br>
>>>>> 65.458699000s ( 0 ms) <br>
2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30 31 0a
/ISk5MT671-0001 <br>
0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 35 35
1-0:0.0.0*255 <br>
28 33 33 31 33 30 30 2d 35 30 33 33 31 32 34 29
(331300-5033124) <br>
0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 35 28
1-0:1.8.1*255( <br>
30 33 31 32 39 36 2e 34 31 39 34 29 0a 0a 31 2d
031296.4194) 1- <br>
30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38 30 29
0:96.5.5*255(80) <br>
0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 2a 32
0-0:96.1.255*2 <br>
35 35 28 33 39 32 32 35 34 37 39 29 0a 0a 21
55(39225479) ! <br>
<br>
##### 95.461526000s ( -61 ms) read<br>
>>>>> 95.461659000s ( 0 ms) <br>
0a 0a 2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30
/ISk5MT671-000 <br>
31 0a 0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 1
1-0:0.0.0*2 <br>
35 35 28 33 33 31 33 30 30 2d 35 30 33 33 31 32
55(331300-503312 <br>
34 29 0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 4)
1-0:1.8.1*25 <br>
35 28 30 33 31 32 39 36 2e 34 31 39 36 29 0a 0a
5(031296.4196) <br>
31 2d 30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38
1-0:96.5.5*255(8 <br>
30 29 0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 0)
0-0:96.1.255 <br>
2a 32 35 35 28 33 39 32 32 35 34 37 39 29 0a 0a
*255(39225479) <br>
21
! <br>
<br>
##### 25.464507000s ( -61 ms) read<br>
>>>>> 25.464641000s ( 0 ms) <br>
2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30 31 0a
/ISk5MT671-0001 <br>
0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 35 35
1-0:0.0.0*255 <br>
28 33 33 31 33 30 30 2d 35 30 33 33 31 32 34 29
(331300-5033124) <br>
0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 35 28
1-0:1.8.1*255( <br>
30 33 31 32 39 36 2e 34 32 33 34 29 0a 0a 31 2d
031296.4234) 1- <br>
30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38 30 29
0:96.5.5*255(80) <br>
0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 2a 32
0-0:96.1.255*2 <br>
35 35 28 33 39 32 32 35 34 37 39 29 0a 0a 21
55(39225479) ! <br>
<br>
##### 55.471947000s ( -57 ms) read<br>
>>>>> 55.472075000s ( 0 ms) <br>
0a 0a 2f 49 53 6b 35 4d 54 36 37 31 2d 30 30 30
/ISk5MT671-000 <br>
31 0a 0a 0a 0a 31 2d 30 3a 30 2e 30 2e 30 2a 32 1
1-0:0.0.0*2 <br>
35 35 28 33 33 31 33 30 30 2d 35 30 33 33 31 32
55(331300-503312 <br>
34 29 0a 0a 31 2d 30 3a 31 2e 38 2e 31 2a 32 35 4)
1-0:1.8.1*25 <br>
35 28 30 33 31 32 39 36 2e 34 32 33 36 29 0a 0a
5(031296.4236) <br>
31 2d 30 3a 39 36 2e 35 2e 35 2a 32 35 35 28 38
1-0:96.5.5*255(8 <br>
30 29 0a 0a 30 2d 30 3a 39 36 2e 31 2e 32 35 35 0)
0-0:96.1.255 <br>
2a 32 35 35 28 33 39 32 32 35 34 37 39 29 0a 0a
*255(39225479) <br>
21
! <br>
<br>
<div><br>
<ggdcjaeb.png><br>
<br>
<br>
-------- Weitergeleitete Nachricht --------
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Betreff:
</th>
<td>Re: Fehler "Too much data for obis_code" im
vzlogger.log</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Datum:
</th>
<td>Thu, 21 May 2015 19:48:11 +0200</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Von:
</th>
<td>Viper <a href="mailto:viper@viper1.de" target="_blank"><viper@viper1.de></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Antwort
an: </th>
<td><a href="mailto:viper@viper1.de" target="_blank">viper@viper1.de</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">An:
</th>
<td><a href="http://volkszaehler.org" target="_blank">volkszaehler.org</a>
- users <a href="mailto:volkszaehler-users@demo.volkszaehler.org" target="_blank"><volkszaehler-users@demo.volkszaehler.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
Hat den keiner eine Idee woran dies liegen könnte. Im Log
kommen jeden Tag ca. 1000 neue Einträge mit "Too much data
for obis_code" hinzu.<br>
<br>
<div>Am 09.05.2015 um 13:52 schrieb
Viper:<br>
</div>
<blockquote type="cite">
Hallo,<br>
<br>
zuerst möchte ich mich noch mal bei Andreas und Matthias
bedanken, welche sich wirklich bemüht haben um meinen
Fehler im Threat: "Stromdaten werden mit 4 Stündiger
Verspätung angezeigt" zu beheben.<br>
<br>
Ich bin mir zwischenzeitlich sicher, dass dieser mit dem
Fehler welchen ich hier beschreibe zusammenhängt. Und zwar
habe ich ein sehr merkwürdiges Phänomen... <br>
Ich lese den Zählerstand aus meinen Iska MT671 mittels
einer einfachen Infarotdiode welcher an GPIO 15 hängt.
Nach dem Neuaufsetzen meines Raspberry Pi mit dem Immage:
volkszaehler_2015_11_02.img von Udo von der Volkszähler
Seite kamen mittels des Befehls "cat /dev/ttyAMA0" solche
merkwürdigen Daten an:<br>
<br>
<pre>��S�5M�6��-000��
�
�-0:0.0.0��55(33�300-5033�����
�-0:�.�.���55(030��3.9�03��
�-0:96.5.5��55(�0��
0-0:96.�.�55��55(39��5��9��
!�</pre>
Auf anraten von Udo habe ich minicom gestartet und die
Daten waren in Ordnung ohne das ich eine Einstellung in
minicom gemacht hätte.<br>
<br>
Nun kann ich den Befehl "cat /dev/ttyAMA0" Stundenlang
laufen lassen und es kommen immer Daten in dieser Form:<br>
<br>
/ISk5MT671-0001<br>
<br>
1-0:0.0.0*255(331300-5033124)<br>
1-0:1.8.1*255(030913.8795)<br>
1-0:96.5.5*255(80)<br>
0-0:96.1.255*255(39225479)<br>
!<br>
<br>
Lass ich aber minicom laufen kommen Reproduzierbar nach
einigen Sekunden folgende Daten:<br>
<br>
/ISk5MT671-0001
<br>
<br>
1-0:0.0.0*255(331300-5033124)
<br>
1-0:1.8.1*255(030913.6591)
<br>
1-0:96.5.5*255(80)
<br>
0-0:96.1.255*255(39225479)
<br>
!
<br>
255(80)1.255*25(3922579)
<br>
/ISk5MT6
<br>
1-0:0331300-033124)
<br>
1-0:1..1*255(30913.699)
<br>
1-:96.5.5255(80)5(3922579)
<br>
/ISk5MT6
<br>
1-0:00.0*255331300-033124)
<br>
1-0:1..1*255(030913.6603) <br>
1-:96.5.5255(80)
<br>
0-0:961.255*25(3922579)
<br>
/ISk5MT6
<br>
1-0:00.0*255331300-033124)
<br>
1-0:1..1*255(30913.607) <br>
1-:96.5.5255(80)
<br>
0-0:961.255*25(3922579) <br>
<br>
Die Minicom 2.6.1 Einstellungen: 9600 Baud, 7E1, NOR,
VT102 <br>
<br>
Stoppe ich minicom und starte es neu sind die Daten für
die ersten Sekunden wieder in Ordnung bevor die Fehler
wiederkommen. Öffne ich ein zweites Terminal und starte
dort "cat /dev/ttyAMA0" stoppen in minicom die falschen
Daten und nach dem beenden des cat Befehls laufen die
Daten in minicom ohne Fehler weiter.<br>
<br>
vzlogger scheint auch wie minicom ein Problem zu bekommen
die Daten zu lesen denn das Log (Loglevel 1) ist voll von
folgenden Fehlern:<br>
<br>
[May 07 19:39:59][d0] Failed to parse obis code
(1-0/ISk5MT671-00)<br>
[May 07 20:56:59][d0] Too much data for value
(byte=0x31)<br>
[May 07 20:56:59][d0] Too much data for value
(byte=0x2D)<br>
[May 07 20:56:59][d0] Too much data for value
(byte=0x30)<br>
[May 07 20:56:59][d0] Too much data for value
(byte=0x3A)<br>
[May 07 20:56:59][d0] Too much data for value
(byte=0x30)<br>
[May 07 20:56:59][d0] Too much data for value
(byte=0x2E)<br>
<br>
Und:<br>
<br>
May 07 21:02:59][d0] Too much data for identification
(byte=0x36)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x37)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x31)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x2D)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x30)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x30)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x30)<br>
[May 07 21:02:59][d0] Too much data for identification
(byte=0x31)<br>
<br>
Dies zeigt sich in der Datenbank dann damit das der
Zählerstand mehrere kWh hinterherläuft wahrscheinlich
zählt vzlogger nur den mindesumsatz dazu.<br>
<br>
Starte ich nun minicom oder "cat /dev/ttyAMA0" bekommt
vzlogger den aktuellen Zählerstand welches sich dann im
Webfontend mit einem Peak von mehreren kW bis GW bemerkbar
macht, siehe Bild.<br>
<br>
Hier noch meine vzlogger.conf:<br>
<br>
{<br>
"retry": 30, // how long to sleep between
failed requests, in seconds<br>
"daemon": true, // run periodically<br>
"verbosity": 1, // between 0 and 15<br>
"log": "/var/log/vzlogger.log", // path to
logfile, optional<br>
<br>
"local": {<br>
"enabled": false, // should we start the local
HTTPd for serving live readings?<br>
"port": 8080, // the TCP port for the local
HTTPd<br>
"index": true, // should we provide a index
listing of available channels if no UUID was requested?<br>
"timeout": 30, // timeout for long polling
comet requests, 0 disables comet, in seconds<br>
"buffer": 600 // how long to buffer readings
for the local interface, in seconds<br>
},<br>
<br>
"meters": [<br>
{<br>
"enabled": true, // disabled
meters will be ignored (default)<br>
"skip": false, // if enabled,
errors when opening meter will lead to meter being ignored<br>
"protocol": "d0", // see
'vzlogger -h' for list of available protocols<br>
"device": "/dev/ttyAMA0",<br>
// "dump_file": "/var/log/dumpD0.txt", //
optional, if set logs all received/transmitted data to
this file<br>
// "read_timeout": 10, // optional, default 10s.
Timeout value in secs between single bytes received from
device<br>
// "baudrate_change_delay": 400, // optional,
default none. Delay value in ms after ACKSEQ send before
baudrate change<br>
"parity": "7E1", // 7E1 oder
8N1<br>
"baudrate": 9600, // 9600moder
300<br>
// "pullseq": "2F3F210D0A", // Pullsequenz
in 'hex'<br>
// "ackseq": "063030300d0a", // optional
(default: keine Antwortsequenz auf Zaehlerantwort) kann
entweder feste hex-Sequenz sein (z.B. 063035300d0a für
mode C mit 9600bd oder 063030300d0a = 300bd) oder kann auf
"auto" gesetzt werden, damit die Sequenz autom. berechnet
wird und autom. auf die max. Baudrate umgeschaltet wird
(baudrate_read wird dann ignoriert)<br>
// "baudrate_read": 300, //
Baudratenumschaltung auf gewünschte Baudrate, abhängig von
Zählerantwort<br>
"aggtime": 30, // in Sekunden<br>
"aggmode": "SUM", // AVG
Mittelwert für Leistung, "MAX" für Zähler, "SUM" für
Counter<br>
"interval": 30, // Wartezeit
in Sekunden bis neue Werte in die middleware übertragen
werden<br>
"channel": { //
Beispiel-channel<br>
"uuid": "c2cafa00-c502-11e4-9b6d-xxxxxx",<br>
"middleware": <a href="http://vzxxxx/middleware.php" target="_blank">"http://vzxxxx/middleware.php"</a>,<br>
"identifier": "1-0:1.8.1*255" // alias
for '1-0:1.8.1', see 'vzlogger -h' for list of available
aliases<br>
},<br>
}<br>
]<br>
}<br>
<br>
<br>
Ich hoffe jemand hat eine Idee.<br>
<br>
Gruß Andre<br>
<br>
<mime-attachment.png><br>
</blockquote>
<br>
<br>
</div>
<br>
</div>
</blockquote>
</blockquote>
<br>
</div>
</div>