[vz-users] Stromdaten werden mit 4 Stündiger Verspätung angezeigt

[Matthias Behr]

Hallo,

ich glaube, die Sprünge liegen einfach an Bitfehlern, wie z.B. die auch:
[Apr 24 01:19:01][d0]   Failed to parse obis code (1-0:1.8.1*25/ISk)
[Apr 24 01:31:01][d0]   Too much data for value (byte=0x2E)
[Apr 24 01:31:01][d0]   Too much data for value (byte=0x30)
[Apr 24 01:31:01][d0]   Too much data for unit (byte=0x32)
[Apr 24 01:31:01][d0]   Too much data for unit (byte=0x34)

Ich habe mir den Dump noch nicht angeschaut, aber akt. wir kein CRC (falls vorhanden, je nach Logger) ausgewertet.

> Am 03.05.2015 um 19:23 schrieb Viper <viper at viper1.de>:
> 
> So jetzt stimmt der Eintrag in der Datenbank wieder mit dem Zählerstand überein aber es gibt in zwei aufeinander folgenden Einträgen (30s) einen Sprung von 8kW:
> 
> Timestamp: 1430672787528 = 2015-05-03 19:06:27 30819.4757 kW
>   
> Timestamp: 1430672817529 = 2015-05-03 19:06:57 30827.5601 kW
> 
> Am 03.05.2015 um 18:18 schrieb Viper:
>> Hallo,
>> 
>> unbeachtet, dass es vielleicht noch ein Problem mit der Fehlerbehandlung gibt muss ich doch noch mal auf mein Ursprüngliches Problem eingehen.
>> Ich habe heute noch mal darauf geachtet wann der Herd an war und zwar von 10:45 Uhr bis 11:55 Uhr. In meinem Fontend ist der max. Verbrauch zu dieser Zeit ca. 450 Watt was für einen Herd viel zu wenig ist. Wenn man nun 4 Stunden weiter schaut ist dort ein Peak zu sehen. Der passt aber auch nicht ganz zum Herd weil dann 16 Uhr der Verbauch wieder auf normales Niveau hätte sinken müssen.
>> 
>> Nach dem Hinweis von Andreas hatte ich ja die Datenbankeinträge gelöscht um zu schauen ob es dort Verzögerungen gibt. Nach dem Neustart wurden gleich mehrere Einträge eingetragen und nicht wie von mir vermutet einer und dann alle 30s ein neuer.
>> 
>> Installiert wurde mit dem Image für den Raspberry von der Volkszähler Homepage.
>> Dann habe ich die Datenbank und das Fontend auf meinem Webspace nach einer Anleitung von der Volkszähler Homepage eingerichtet.
>> Mein Stromzähler gibt nur den aktuellen Zählerstand aus, welcher mit einem Timestamp in die Datenbank geschrieben wird.
>> Nachdem ich den letzten Datenbankeintrag mir angeschaut habe stimmt der Timestamp aber nicht der Zählerstand!!! Es fehlen ca. 6kWh.
>> Also vermute ich jetzt das es wohl eher einen Fehler in meiner Konfiguration gibt. Kann sich einer von den Profis diese mal anschauen:
>> 
>> Hier meine vzlogger.conf:
>> 
>> /**
>>  * vzlogger configuration
>>  *
>>  * use proper encoded JSON with javascript comments
>>  *
>>  * take a look at the wiki for detailed information:
>>  * http://wiki.volkszaehler.org/software/controller/vzlogger#configuration <http://wiki.volkszaehler.org/software/controller/vzlogger#configuration>
>> */
>> 
>> {
>>     "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": "MAX",               //  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-9b6xxxxxxx",
>>                 "middleware": "http://xxxxx/middleware.php" <http://xxxxx/middleware.php>,
>>                 "identifier": "1-0:1.8.1*255"   // alias for '1-0:1.8.1', see 'vzlogger -h' for list of available aliases
>>             },
>>         }
>>     ]
>> }
>> 
>> <Mail-Anhang.png>
>> 
>> 
> 

Gruß

Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150503/5118be2e/attachment.html>