[vz-users] Fehler "Too much data for obis_code" im vzlogger.log
Viper
viper at viper1.de
Sat May 9 13:52:38 CEST 2015
Hallo,
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.
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...
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:
��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��
!�
Auf anraten von Udo habe ich minicom gestartet und die Daten waren in
Ordnung ohne das ich eine Einstellung in minicom gemacht hätte.
Nun kann ich den Befehl "cat /dev/ttyAMA0" Stundenlang laufen lassen
und es kommen immer Daten in dieser Form:
/ISk5MT671-0001
1-0:0.0.0*255(331300-5033124)
1-0:1.8.1*255(030913.8795)
1-0:96.5.5*255(80)
0-0:96.1.255*255(39225479)
!
Lass ich aber minicom laufen kommen Reproduzierbar nach einigen Sekunden
folgende Daten:
/ISk5MT671-0001
1-0:0.0.0*255(331300-5033124)
1-0:1.8.1*255(030913.6591)
1-0:96.5.5*255(80)
0-0:96.1.255*255(39225479)
!
255(80)1.255*25(3922579)
/ISk5MT6
1-0:0331300-033124)
1-0:1..1*255(30913.699)
1-:96.5.5255(80)5(3922579)
/ISk5MT6
1-0:00.0*255331300-033124)
1-0:1..1*255(030913.6603)
1-:96.5.5255(80)
0-0:961.255*25(3922579)
/ISk5MT6
1-0:00.0*255331300-033124)
1-0:1..1*255(30913.607)
1-:96.5.5255(80)
0-0:961.255*25(3922579)
Die Minicom 2.6.1 Einstellungen: 9600 Baud, 7E1, NOR, VT102
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.
vzlogger scheint auch wie minicom ein Problem zu bekommen die Daten zu
lesen denn das Log (Loglevel 1) ist voll von folgenden Fehlern:
[May 07 19:39:59][d0] Failed to parse obis code (1-0/ISk5MT671-00)
[May 07 20:56:59][d0] Too much data for value (byte=0x31)
[May 07 20:56:59][d0] Too much data for value (byte=0x2D)
[May 07 20:56:59][d0] Too much data for value (byte=0x30)
[May 07 20:56:59][d0] Too much data for value (byte=0x3A)
[May 07 20:56:59][d0] Too much data for value (byte=0x30)
[May 07 20:56:59][d0] Too much data for value (byte=0x2E)
Und:
May 07 21:02:59][d0] Too much data for identification (byte=0x36)
[May 07 21:02:59][d0] Too much data for identification (byte=0x37)
[May 07 21:02:59][d0] Too much data for identification (byte=0x31)
[May 07 21:02:59][d0] Too much data for identification (byte=0x2D)
[May 07 21:02:59][d0] Too much data for identification (byte=0x30)
[May 07 21:02:59][d0] Too much data for identification (byte=0x30)
[May 07 21:02:59][d0] Too much data for identification (byte=0x30)
[May 07 21:02:59][d0] Too much data for identification (byte=0x31)
Dies zeigt sich in der Datenbank dann damit das der Zählerstand mehrere
kWh hinterherläuft wahrscheinlich zählt vzlogger nur den mindesumsatz dazu.
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.
Hier noch meine vzlogger.conf:
{
"retry": 30, // how long to sleep between failed
requests, in seconds
"daemon": true, // run periodically
"verbosity": 1, // between 0 and 15
"log": "/var/log/vzlogger.log", // path to logfile, optional
"local": {
"enabled": false, // should we start the local HTTPd for
serving live readings?
"port": 8080, // the TCP port for the local HTTPd
"index": true, // should we provide a index listing of
available channels if no UUID was requested?
"timeout": 30, // timeout for long polling comet requests,
0 disables comet, in seconds
"buffer": 600 // how long to buffer readings for the local
interface, in seconds
},
"meters": [
{
"enabled": true, // disabled meters will be
ignored (default)
"skip": false, // if enabled, errors when
opening meter will lead to meter being ignored
"protocol": "d0", // see 'vzlogger -h' for
list of available protocols
"device": "/dev/ttyAMA0",
// "dump_file": "/var/log/dumpD0.txt", // optional, if set logs
all received/transmitted data to this file
// "read_timeout": 10, // optional, default 10s. Timeout value
in secs between single bytes received from device
// "baudrate_change_delay": 400, // optional, default none.
Delay value in ms after ACKSEQ send before baudrate change
"parity": "7E1", // 7E1 oder 8N1
"baudrate": 9600, // 9600moder 300
// "pullseq": "2F3F210D0A", // Pullsequenz in 'hex'
// "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)
// "baudrate_read": 300, // Baudratenumschaltung auf
gewünschte Baudrate, abhängig von Zählerantwort
"aggtime": 30, // in Sekunden
"aggmode": "SUM", // AVG Mittelwert für
Leistung, "MAX" für Zähler, "SUM" für Counter
"interval": 30, // Wartezeit in Sekunden
bis neue Werte in die middleware übertragen werden
"channel": { // Beispiel-channel
"uuid": "c2cafa00-c502-11e4-9b6d-xxxxxx",
"middleware": "http://vzxxxx/middleware.php",
"identifier": "1-0:1.8.1*255" // alias for
'1-0:1.8.1', see 'vzlogger -h' for list of available aliases
},
}
]
}
Ich hoffe jemand hat eine Idee.
Gruß Andre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150509/fe909584/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fgggaadi.png
Type: image/png
Size: 70760 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150509/fe909584/attachment-0001.png>
More information about the volkszaehler-users
mailing list