<div dir="ltr"><div><div>Die zeitliche Verzögerung kann m.E. nicht am vzlogger liegen. Mein Vorschlag wäre mal Deinen Zähler mit einem Terminalprogramm anzuschauen. These: er gibt schon krumme/alte/wie auch immer Daten aus.<br><br></div><div>Das zweite Problem- die Fehlermeldung- müssen wir uns nochmal genauer anschauen. Nachvollziehen kann ich sie mittlerweile:<br><br>{"version":"0.3","exception":{"message":"An exception occurred while executing 'INSERT INTO data (channel_id, timestamp, value) VALUES (10,?,?)' with params [1430675600210, \"1\"]:\n\nSQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '10-1430675600210' for key 'data_unique'","type":"DBALException","code":0}}<br><br></div><div>Ich vermute dass das mit <a href="https://github.com/volkszaehler/volkszaehler.org/pull/278">https://github.com/volkszaehler/volkszaehler.org/pull/278</a> zusammen hängt.<br><br></div>Viele Grüße,<br></div>Andreas<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-05-03 19:23 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">
So jetzt stimmt der Eintrag in der Datenbank wieder mit dem
Zählerstand überein aber es gibt in zwei aufeinander folgenden
Einträgen (30s) einen Sprung von 8kW:<br>
<br>
Timestamp: 1430672787528 = 2015-05-03 19:06:27 30819.4757 kW<br>
<br>
Timestamp: 1430672817529 = 2015-05-03 19:06:57 30827.5601 kW<div><div class="h5"><br>
<br>
<div>Am 03.05.2015 um 18:18 schrieb Viper:<br>
</div>
<blockquote type="cite">
Hallo,<br>
<br>
unbeachtet, dass es vielleicht noch ein Problem mit der
Fehlerbehandlung gibt muss ich doch noch mal auf mein
Ursprüngliches Problem eingehen.<br>
Ich habe heute noch mal darauf geachtet wann der Herd an war und
zwar von 10:45 Uhr bis 11:55 Uhr. In meinem Fontend ist der max.
Verbrauch zu dieser Zeit ca. 450 Watt was für einen Herd viel zu
wenig ist. Wenn man nun 4 Stunden weiter schaut ist dort ein Peak
zu sehen. Der passt aber auch nicht ganz zum Herd weil dann 16 Uhr
der Verbauch wieder auf normales Niveau hätte sinken müssen.<br>
<br>
Nach dem Hinweis von Andreas hatte ich ja die Datenbankeinträge
gelöscht um zu schauen ob es dort Verzögerungen gibt. Nach dem
Neustart wurden gleich mehrere Einträge eingetragen und nicht wie
von mir vermutet einer und dann alle 30s ein neuer.<br>
<br>
Installiert wurde mit dem Image für den Raspberry von der
Volkszähler Homepage.<br>
Dann habe ich die Datenbank und das Fontend auf meinem Webspace
nach einer Anleitung von der Volkszähler Homepage eingerichtet.<br>
Mein Stromzähler gibt nur den aktuellen Zählerstand aus, welcher
mit einem Timestamp in die Datenbank geschrieben wird.<br>
Nachdem ich den letzten Datenbankeintrag mir angeschaut habe
stimmt der Timestamp aber nicht der Zählerstand!!! Es fehlen ca.
6kWh.<br>
Also vermute ich jetzt das es wohl eher einen Fehler in meiner
Konfiguration gibt. Kann sich einer von den Profis diese mal
anschauen:<br>
<br>
Hier meine vzlogger.conf:<br>
<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-9b6xxxxxxx",<br>
"middleware": <a href="http://xxxxx/middleware.php" target="_blank">"http://xxxxx/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:part3.05090800.05070005@viper1.de" alt=""><br>
<br>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>