<div dir="ltr">Hallo Andre,<br><div class="gmail_extra"><br><div class="gmail_quote">2015-04-27 19:49 GMT+02:00 Viper <span dir="ltr"><<a href="mailto:viper@viper1.de" target="_blank">viper@viper1.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hallo Andreas,<br>
<br>
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.<br>
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.<br></div></blockquote><div><br></div><div>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?<br><br></div><div>Wenn das so ist dann versteh ich grad nicht worin jetzt das konkrete Problem besteht- vielleicht kannst Du's nochmal beschreiben?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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.<br>
Habe aus der vzlogger.conf jetzt alle Beispielzähler gelöscht und
der Fehler ist weg.<br>
<br>
Ich vermute das die Peaks daher kommen das auf einmal mehrere
Datensätze übertragen werden.<br>
<br>
Vielleicht kommt die Verzögerung auch durch falsche Einstellungen in
der vzlogger.conf. Kann da einer mal bitte einen Blick drauf werfen:<br></div></blockquote><div><br></div><div>Viele Grüße,<br></div><div>Andreas<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
/**<br>
* vzlogger configuration<br>
*<br>
* use proper encoded JSON with javascript comments<br>
*<br>
* take a look at the wiki for detailed information:<br>
*
<a href="http://wiki.volkszaehler.org/software/controller/vzlogger#configuration" target="_blank">http://wiki.volkszaehler.org/software/controller/vzlogger#configuration</a><br>
*/<br>
<br>
{<br>
"retry": 30, // how long to sleep between failed
requests, in seconds<br>
"daemon": true, // run periodically<br>
"verbosity": 1, // between 0 and 15<br>
"log": "/var/log/vzlogger.log", // path to logfile, optional<br>
<br>
"local": {<br>
"enabled": false, // should we start the local HTTPd for
serving live readings?<br>
"port": 8080, // the TCP port for the local HTTPd<br>
"index": true, // should we provide a index listing of
available channels if no UUID was requested?<br>
"timeout": 30, // timeout for long polling comet
requests, 0 disables comet, in seconds<br>
"buffer": 600 // how long to buffer readings for the
local interface, in seconds<br>
},<br>
<br>
"meters": [<br>
{<br>
"enabled": true, // disabled meters will
be ignored (default)<br>
"skip": false, // if enabled, errors
when opening meter will lead to meter being ignored<br>
"protocol": "d0", // see 'vzlogger -h' for
list of available protocols<br>
"device": "/dev/ttyAMA0",<br>
// "dump_file": "/var/log/dumpD0.txt", // optional, if set
logs all received/transmitted data to this file<br>
// "read_timeout": 10, // optional, default 10s. Timeout
value in secs between single bytes received from device<br>
// "baudrate_change_delay": 400, // optional, default none.
Delay value in ms after ACKSEQ send before baudrate change<br>
"parity": "7E1", // 7E1 oder 8N1<br>
"baudrate": 9600, // 9600moder 300<br>
// "pullseq": "2F3F210D0A", // Pullsequenz in 'hex'<br>
// "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)<br>
// "baudrate_read": 300, // Baudratenumschaltung
auf gewünschte Baudrate, abhängig von Zählerantwort<br>
"aggtime": 30, // in Sekunden<br>
"aggmode": "MAX", // AVG Mittelwert für
Leistung, "MAX" für Zähler, "SUM" für Counter<br>
"interval": 30, // Wartezeit in
Sekunden bis neue Werte in die middleware übertragen werden<br>
"channel": { // Beispiel-channel<br>
"uuid": "c2cafa00-c502-11e4-9********",<br>
"middleware": <a href="http://*****/middleware.php" target="_blank">"http://*****/middleware.php"</a>,<br>
"identifier": "1-0:1.8.1*255" // alias for
'1-0:1.8.1', see 'vzlogger -h' for list of available aliases<br>
},<br>
}<br>
]<br>
}<br>
<br>
<img src="cid:part1.01000605.07030002@viper1.de" alt=""><div><div class="h5"><br>
<br>
<div>Am 26.04.2015 um 11:28 schrieb Andreas
Goetz:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Moin,<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-04-23 19:53 GMT+02:00 Viper <span dir="ltr"><<a href="mailto:viper@viper1.de" target="_blank">viper@viper1.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hallo,<br>
<br>
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. <br>
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. <br>
Als ich dies noch lokal auf meinem Raspi gemacht habe
hatte ich schon das Gefühl das es eine einstündige
Verspätung gab.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Ich hab jetzt mal reingeschaut:<br>
</div>
<div>- Zeitanzeige im FE ist ok, was auch nicht wunder da
timezone=browser ja immer stimmen sollte<br>
</div>
<div>- Wenn ich das Frontend anweise Daten aus der Zukunft
anzuzeigen (&to=xxxx) dann kommen keine zusätzlichen,
vorher versteckten Daten.<br>
<br>
</div>
<div>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.<br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Du könntest Dir ein kleines HPP Skript schreiben das
time() oder eine andere Funktion ausgibt.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Wenn ich mir den
letzten Timestamp aus der Datenbank anschaue stimmt
dieser auch.<br>
<br>
Hat jemand eine Idee was da schief läuft?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Ehrlich gesagt- ich glaube gar nichts. Um zu testen ob
Du Dich einfach irrst würde ich vorschlagen:<br>
<br>
</div>
<div>- backup<br>
</div>
<div>- alle Daten des Kanales löschen (delete from data
where channel_id = xyz, analog für aggregate falls Du das
nutzt)<br>
</div>
<div>- Daten erfassen<br>
</div>
<div>- Ins Frontend schauen: tauchen die neuen Daten sofort
auf? Dann sind es auch die aktuellen und es gibt keien
Verschiebung ;)<br>
</div>
<div> <br>
</div>
<div>Viele Grüße,<br>
</div>
<div>Andreas<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Gruß Andre<br>
<br>
<img src="cid:part3.02060000.01020303@viper1.de" alt=""><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>