@Andre: könntest Du mal bitte Folgendes ausführen: composer require doctrine/dbal:2.5.*
Danach sollten die Exceptions aus dem Log hoffentlich verschwinden. Viele Grüße, Andreas 2015-05-03 19:57 GMT+02:00 Andreas Goetz <cpui...@gmail.com>: > 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. > > Das zweite Problem- die Fehlermeldung- müssen wir uns nochmal genauer > anschauen. Nachvollziehen kann ich sie mittlerweile: > > {"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}} > > Ich vermute dass das mit > https://github.com/volkszaehler/volkszaehler.org/pull/278 zusammen hängt. > > Viele Grüße, > Andreas > > > 2015-05-03 19:23 GMT+02:00 Viper <vi...@viper1.de>: > >> 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: >> >> Timestamp: 1430672787528 = 2015-05-03 19:06:27 30819.4757 kW >> >> Timestamp: 1430672817529 = 2015-05-03 19:06:57 30827.5601 kW >> >> >> Am 03.05.2015 um 18:18 schrieb Viper: >> >> Hallo, >> >> unbeachtet, dass es vielleicht noch ein Problem mit der Fehlerbehandlung >> gibt muss ich doch noch mal auf mein Ursprüngliches Problem eingehen. >> 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. >> >> 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. >> >> Installiert wurde mit dem Image für den Raspberry von der Volkszähler >> Homepage. >> Dann habe ich die Datenbank und das Fontend auf meinem Webspace nach >> einer Anleitung von der Volkszähler Homepage eingerichtet. >> Mein Stromzähler gibt nur den aktuellen Zählerstand aus, welcher mit >> einem Timestamp in die Datenbank geschrieben wird. >> Nachdem ich den letzten Datenbankeintrag mir angeschaut habe stimmt der >> Timestamp aber nicht der Zählerstand!!! Es fehlen ca. 6kWh. >> Also vermute ich jetzt das es wohl eher einen Fehler in meiner >> Konfiguration gibt. Kann sich einer von den Profis diese mal anschauen: >> >> Hier meine vzlogger.conf: >> >> /** >> * 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-9b6xxxxxxx", >> "middleware": "http://xxxxx/middleware.php" >> <http://xxxxx/middleware.php>, >> "identifier": "1-0:1.8.1*255" // alias for '1-0:1.8.1', >> see 'vzlogger -h' for list of available aliases >> }, >> } >> ] >> } >> >> >> >> >> >> >