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

Viper viper at viper1.de
Mon Apr 27 19:49:14 CEST 2015


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
*/

{
    "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",
                "identifier": "1-0:1.8.1*255"   // alias for
'1-0:1.8.1', see 'vzlogger -h' for list of available aliases
            },
        }
    ]
}



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
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150427/28b7133f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdichfhd.png
Type: image/png
Size: 47185 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150427/28b7133f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 63291 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150427/28b7133f/attachment-0003.png>


More information about the volkszaehler-users mailing list