<div dir="ltr">Hallo Andre,<div><br></div><div>vermutlich löst das dein Problem nicht, aber auf jeden Fall sollte bei einem Zählerstand <span style="font-size:12.8000001907349px">"aggmode": "MAX" und nicht </span><span style="font-size:12.8000001907349px">"aggmode": "SUM" stehen.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Gruß</span></div><div><span style="font-size:12.8000001907349px">Frank</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">Am 9. Mai 2015 um 13:52 schrieb Viper <span dir="ltr"><<a href="mailto:viper@viper1.de" target="_blank">viper@viper1.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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>
<img src="cid:part1.01060108.02050104@viper1.de" alt=""><br>
</div>
</blockquote></div><br></div>