[vz-users] Stromdaten werden mit 4 Stündiger Verspätung angezeigt
Viper
viper at viper1.de
Tue Apr 28 17:23:29 CEST 2015
Hallo Matthias,
genaue Version:
0.4.0
based on git version: heads/master-0-g0be995bdf6
Gruß Andre
Am 27.04.2015 um 21:05 schrieb Matthias Behr:
> kannst du mal die genaue Version schicken? (vzlogger -V sollte mehr
> Ausgabe bringen)
>
>> Am 27.04.2015 um 20:20 schrieb Viper <viper at viper1.de
>> <mailto:viper at viper1.de>>:
>>
>> 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 <mailto: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
>>> <mailto: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
>>> */
>>>
>>> {
>>> "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
>>> },
>>> }
>>> ]
>>> }
>>>
>>> <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.
>
> Gruß
>
> Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150428/d4a905b9/attachment-0001.html>
More information about the volkszaehler-users
mailing list