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

[Viper]

Hallo Matthias, 
vzlogger Version 0.4.0

Und mein Stromzähler liefert unter dem Identifier 1-0:1.8.1*255 den Zählerstand. 

Gruß Andre 

Am 27. April 2015 19:58:38 MESZ, schrieb Matthias Behr <mbehr at mcbehr.de>:
>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

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150427/88bedfe1/attachment-0001.html>