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

Thu Apr 30 18:05:05 CEST 2015

Hallo Andre,

2015-04-27 19:49 GMT+02:00 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 Aufhänger für die Diksussion war ja Deine Vermutung dass die Daten mit
4h Verzögerung angezeigt werden. Das Experiment belegt m.E. das das nicht
der Fall ist- einverstanden?

Wenn das so ist dann versteh ich grad nicht worin jetzt das konkrete
Problem besteht- vielleicht kannst Du's nochmal beschreiben?

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

Viele Grüße,
Andreas

>
> /**
>  * 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"
> <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>:
>
>>  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/20150430/a760ff7f/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/20150430/a760ff7f/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/20150430/a760ff7f/attachment-0003.png>