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

[Matthias Behr]

Hallo,

welche Version nutzt du? (vzlogger -V)

Bist du sicher, dass du den identifier 1-0:1.8.1*255 brauchst? (Und nicht z.B. 1-0:1.8.1*0?) In früheren Versionen war *255 eine Wildcard und einige Logger schicken als *1, *2,… die Historiendaten mit.)

> Am 27.04.2015 um 19:49 schrieb Viper <viper at viper1.de>:
> 
> Hallo Andreas,
> 
> danke für deine Antwort. Ich habe gestern um 16Uhr wie du angeraten hast alle Daten in der Datenbank gelöscht. Dafür hatte ich vzlogger gestoppt die Daten gelöscht und vzlogger gestartet.
> Nach dem Start wurden direkt 15 Datensätze übertragen!? Eigentlich sollte nur alle 30s ein Datensatz eingetragen werden. Daher kommt auch der Peak direkt am Anfang.
> Der zweite Peak gegen 19Uhr kommt daher das ich beim Starten von vzlogger eine Fehlermeldung wegen eines unbekannten Identifier bekam und ich deshalb die vzlogger.conf mehrmals bearbeitet habe und dafür auch vzlogger mehrmals gestoppt und wieder gestartet habe.
> Habe aus der vzlogger.conf jetzt alle Beispielzähler gelöscht und der Fehler ist weg.
> 
> Ich vermute das die Peaks daher kommen das auf einmal mehrere Datensätze übertragen werden.
> 
> Vielleicht kommt die Verzögerung auch durch falsche Einstellungen in der vzlogger.conf. Kann da einer mal bitte einen Blick drauf werfen:
> 
> /**
>  * 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-9********",
>                 "middleware": "http://*****/middleware.php" <http://*****/middleware.php>,
>                 "identifier": "1-0:1.8.1*255"   // alias for '1-0:1.8.1', see 'vzlogger -h' for list of available aliases
>             },
>         }
>     ]
> }
> 
> <gdichfhd.png>
> 
> Am 26.04.2015 um 11:28 schrieb Andreas Goetz:
>> Moin,
>> 
>> 2015-04-23 19:53 GMT+02:00 Viper <viper at viper1.de <mailto:viper at viper1.de>>:
>> Hallo,
>> 
>> seitdem ich die Daten und die Anzeige bei meinem Webspace (Strato) mache scheint die Anzeige des Stromverbrauchs eine 4 stündige Verspätung zu haben. 
>> So muss der z.B. der Peak um kurz nach 10 Uhr der Wasserkocher sein welcher kurz nach 6 Uhr betätigt wurde und der höhere Verbrauch um 16 Uhr der Herd gegen 12 Uhr. 
>> Als ich dies noch lokal auf meinem Raspi gemacht habe hatte ich schon das Gefühl das es eine einstündige Verspätung gab.
>> 
>> Ich hab jetzt mal reingeschaut:
>> - Zeitanzeige im FE ist ok, was auch nicht wunder da timezone=browser ja immer stimmen sollte
>> - Wenn ich das Frontend anweise Daten aus der Zukunft anzuzeigen (&to=xxxx) dann kommen keine zusätzlichen, vorher versteckten Daten.
>> 
>> Heißt für mich: die letzten Daten die gespeichert sind sind die Daten für die aktuelle Zeit- insofern ist keine Verschiebung zu erkennen.
>>  
>> Auf dem Raspi ergibt der Befehl Date, dass die Zeit stimmt. Bei meinem Webspace habe ich nur einen FTP Zugang so das ich nicht weiß wie ich die Zeit dort abfragen kann.
>> 
>> Du könntest Dir ein kleines HPP Skript schreiben das time() oder eine andere Funktion ausgibt.
>>  
>> Wenn ich mir den letzten Timestamp aus der Datenbank anschaue stimmt dieser auch.
>> 
>> Hat jemand eine Idee was da schief läuft?
>> 
>> Ehrlich gesagt- ich glaube gar nichts. Um zu testen ob Du Dich einfach irrst würde ich vorschlagen:
>> 
>> - backup
>> - alle Daten des Kanales löschen (delete from data where channel_id = xyz, analog für aggregate falls Du das nutzt)
>> - Daten erfassen
>> - Ins Frontend schauen: tauchen die neuen Daten sofort auf? Dann sind es auch die aktuellen und es gibt keien Verschiebung ;)
>>  
>> Viele Grüße,
>> Andreas
>> 
>> 
>> Gruß Andre
>> 
>> <Mail-Anhang.png>
>> 
> 

Gruß

Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150427/80c921ac/attachment.html>