[vz-dev] vzlogger.log läuft voll

Reinhard Wilzeck reinhard at wilzeck.de
Sun Feb 19 21:05:36 CET 2017


Hallo Christian,
ob das ein Fehler ist, oder nicht ist ein bisschen eine philosphische Frage.
Wenn die Meldung kommt empfängt der vzlogger keine Antwort vom Zähler.
(Wenn Du den Lesekopf vom Zähler nimmst, wirst Du den gleichen Effekt
haben.)

Sprich es werden auch keine Daten aufgezeichnet.
Das finde ich ist ein Fehler für eine Anwendung, deren einziger Sinn die
Datenerfassung ist.

Die  Meldung hat auch Vorrang vor "duplicates". Wenn gar nichts
empfangen wird, hat der Filter für Duplikate nichts zu tun, weil gar
nichts eingetragen wird.

Ich habe mich vor Jahren mal intensiver mit dem MeterD0 befaßt, da mein
Zähler bockig war und nicht antworten wollte.
In den verschiedenen Auszügen der vzlogger.conf in der Diskussion ist es
mal
/dev/ttyUSB1 und mal /dev/ttyUSB0

Die besten Ergebnisse scheinst Du mit /dev/ttyUSB0 zu haben.
Ich nehme an, Du verwendest Udos Infrarotlesekopf?
Wenn Du Zweifel hast, welche Schnittstelle es ist, hilft eine
Digitalkamera. Die ist im Infrarot empfindlich und Du kannst sehen, das
das Abfragetelegram aus der Sendediode gesendet wird.

Das log file ist da auch eine Hilfe. (Das da was drinsteht ist nicht da
Problem, sondern das es etwas einzutragen gibt.)

Gib mal Verbosity=15 ein und Du siehst, was abläuft.
Dort werden dann auch die interpretieten Daten eingetragenn bevor es
überhaupt an  die Datenbank geht.
Im schlimmsten Fall hilft es da, das dump file zu aktivieren. Damit wird
aufgezeichnet, was der Lesekopf empfängt.  (Wenn er was empfängt)

Mein Zähler verlangt z.B. , dass immer die AckSequenze gesendet wird.
Auf die Pullsequence antworted er nur mit Typ und seiner maximalen
Datenrate, gibt aber noch keine Daten raus...
Aber Deiner antwortet vielleicht freiwillig.

Gruß
    Reinhard

Am 19.02.2017 um 19:37 schrieb Christian Wulff:
>
> …..kann es sein, das es gar kein Fehler ist, und dies bei Verbosity=0
> gar nicht in den Log geschrieben werden sollte?
>
>  
>
> Die Fehlermeldung lautet:
>
> [Feb 19 15:21:28][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:21:28][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
>  
>
> In einer kommentierten vzlogger.conf habe ich gefunden:
>
> "read_timeout": 10,             // optional read timeout, default 10s.
> Data reading is considered finished if no state change after that timeout
>
>  
>
> „Das Datenlesen wird als beendet betrachtet, wenn nach diesem Timeout
> keine Zustandsänderung erfolgt.“
>
>  
>
> Ja das ist so. Dann ist das doch gar kein Fehler?!
>
>  
>
> Wenn ich eins und eins zusammenzähle handelt es sich nicht um einen
> (schwerwiegenden) Fehler, sondern lediglich um eine Statusmeldung, die
> bei verbosity=0 nichts im logfile zu suchen hat?!
>
> Dann wäre es ein Bug, das diese Statusmeldung im Logfile bei
> Verbosity=0 überhaupt auftaucht.
>
>  
>
> Lieben Gruß,
>
> Chris
>
>  
>
>  
>
> *Von:*Christian Wulff [mailto:christianwulff at gmx.de]
> *Gesendet:* Sonntag, 19. Februar 2017 19:28
> *An:* 'volkszaehler.org'
> *Betreff:* AW: [vz-dev] vzlogger.log läuft voll
>
>  
>
> Moin Frank,
>
>  
>
> …..weil der Abstand der timestamps mit gleichem Wert nun niedriger ist?
>
> Vorher hatte ich mit duplicates=3600 nachts ja auch mehrfach die
> gleichen Werte in der DB. Da hatte ich aber nicht solche mega Peaks?!
>
> Versteh einer diese Schnittstelle….
>
> Für mein Verständnis würde das korrekt funktionieren, wenn der
> duplicates Wert unendlich ist, dann würden niemals unnötigerweise
> identische Werte in die Datenbank geschrieben werden.
>
>  
>
> Lieben Gruß,
>
> Chris
>
>  
>
> *Von:*Frank Richter [mailto:frank.richter83 at gmail.com]
> *Gesendet:* Sonntag, 19. Februar 2017 19:03
> *An:* volkszaehler.org
> *Betreff:* Re: [vz-dev] vzlogger.log läuft voll
>
>  
>
> Das ist kein Unsinn, sondern liegt am deaktivierten duplicates. Da die
> Auflösung deines Zählers so grob ist, landet mehrfach der gleiche Wert
> in der DB, daraus ergibt sich eine Leistung von 0 zwischen diesen
> Timestamps. Wenn der Zählerstand dann mal umspringt, ist die Leistung
> im betreffenden Intervall halt entsprechend hoch.
>
>  
>
> Grüße
>
> Frank
>
>  
>
> Am 19. Februar 2017 um 18:49 schrieb Christian Wulff
> <christianwulff at gmx.de <mailto:christianwulff at gmx.de>>:
>
> Jetzt kommt nur noch Unsinn dabei raus L
>
>  
>
> …das soll einer verstehen?!
>
>  
>
> *Von:*Christian Wulff [mailto:christianwulff at gmx.de
> <mailto:christianwulff at gmx.de>]
> *Gesendet:* Sonntag, 19. Februar 2017 15:40
> *An:* 'volkszaehler.org <http://volkszaehler.org>'
> *Betreff:* AW: [vz-dev] vzlogger.log läuft voll
>
>  
>
>     {
>
>       "enabled": true,
>
>       "allowskip": false,
>
>       "interval": 30,
>
>       "aggtime": 60,
>
>      "aggfixedinterval": false,
>
>       "channels": [
>
>        {
>
>           "uuid": "89c0c960-8e59-11e6-81d7-efe19b94c4aa",
>
>           "identifier": "1.8.0",
>
>           "api": "volkszaehler",
>
>           "middleware": "http://localhost/middleware.php",
>
>           "aggmode": "none",
>
>           "duplicates": 0
>
>         }
>
>       ],
>
>       "protocol": "d0",
>
>       "device": "/dev/ttyUSB1",
>
>       "pullseq": "2F3F210D0A",
>
>       "baudrate": 300,
>
>       "parity": "7e1",
>
>       "read_timeout": 60
>
>     },
>
>  
>
>  
>
> Der Fehler kommt nun wieder alle 60 Sekunden:
>
>  
>
> [Feb 19 15:21:27][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:21:27][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:21:28][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:21:28][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:23:05][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:23:05][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:23:06][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:23:06][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:25:53][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:25:53][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:25:54][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:25:54][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:28:05][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:28:05][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:28:08][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:28:08][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:30:53][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:30:53][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:30:58][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:30:58][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
> [Feb 19 15:33:05][d0]   nothing received for more than 60 seconds
>
> [Feb 19 15:33:05][d0]   read timed out!, context: 0, bytes read: 0,
> last byte 0x7f
>
>  
>
> Die Rohdaten werden nun alle ~30 Sekunden geschrieben
>
>  
>
> 2017-02-19 15:23:41;9683.2;1
>
> 2017-02-19 15:24:16;9683.2;1
>
> 2017-02-19 15:24:52;9683.2;1
>
> 2017-02-19 15:26:28;9683.3;1
>
> 2017-02-19 15:27:04;9683.3;1
>
> 2017-02-19 15:28:41;9683.3;1
>
> 2017-02-19 15:29:16;9683.3;1
>
> 2017-02-19 15:29:51;9683.3;1
>
> 2017-02-19 15:31:29;9683.4;1
>
>  
>
> Die Frage ist immer noch: Warum taucht die Fehlermeldung im Log auf
> und welche Einstellung muss man wie anpassen, damit das normal ohne
> Fehler läuft?
>
>  
>
> Lieben Gruß,
>
> Chris
>
>  
>
> *Von:*Christian Wulff [mailto:christianwulff at gmx.de]
> *Gesendet:* Sonntag, 19. Februar 2017 13:55
>
>
> *An:* 'volkszaehler.org <http://volkszaehler.org>'
> *Betreff:* Re: [vz-dev] vzlogger.log läuft voll
>
>  
>
> Okay, das Komma habe ich nun auch korrigiert, aber nachdem der
> vzlogger gar nicht mehr lieft hab ich manuell gestartet und dann kam
> die Fehlermeldung, dass duplicates <0 ist nicht erlaubt ist.
>
> Nu läuft er wieder
>
>  
>
> Ich teste also mal weiter….
>
>  
>
>  
>
> Lieben Gruß,
>
> Chris
>
>  
>
>  
>
> *Von:*Frank Richter [mailto:frank.richter83 at gmail.com]
> *Gesendet:* Sonntag, 19. Februar 2017 13:37
> *An:* volkszaehler.org <http://volkszaehler.org>
> *Betreff:* Re: [vz-dev] vzlogger.log läuft voll
>
>  
>
> Komma hinter read_timeout ist falsch.
>
> Am 19.02.2017 13:29 schrieb "Christian Wulff" <christianwulff at gmx.de
> <mailto:christianwulff at gmx.de>>:
>
> Okay, nun hab ich folgendes getestet:
>
>
>     {
>       "enabled": true,
>       "allowskip": false,
>       "interval": 30,
>       "aggtime": 60,
>       "aggfixedinterval": false,
>       "channels": [
>        {
>           "uuid": "b672f2c0-8e59-11e6-be34-2f0c157b74af",
>           "identifier": "1.8.1",
>           "api": "volkszaehler",
>           "middleware": "http://localhost/middleware.php",
>           "aggmode": "none",
>           "duplicates": -1
>         },
>       {
>           "uuid": "0f619f10-97e7-11e6-88bd-e79ee73590e6",
>           "identifier": "1.8.2",
>           "api": "volkszaehler",
>           "middleware": "http://localhost/middleware.php",
>           "aggmode": "none",
>           "duplicates": -1
>         }
>       ],
>       "protocol": "d0",
>       "device": "/dev/ttyUSB0",
>       "pullseq": "2F3F210D0A",
>       "baudrate": 300,
>       "parity": "7e1",
>       "read_timeout": 120,
>     },
>
> Das gute ist: Es wird kein Logfile mehr erzeugt :-)
>
> Das schlechte: Es kommen leider auch keine Daten mehr :-(    ....gar
> keine, auch nicht die anderen Kanäle?!
> Also hängt der VZ sich irgendwo auf?!
>
> Lieben Gruß
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Frank Richter [mailto:frank.richter83 at gmail.com
> <mailto:frank.richter83 at gmail.com>]
> Gesendet: Sonntag, 19. Februar 2017 03:04
> An: volkszaehler.org <http://volkszaehler.org>
> Betreff: Re: [vz-dev] vzlogger.log läuft voll
>
> Hallo Christian,
>
> Am 18. Februar 2017 um 15:56 schrieb Christian Wulff
> <christianwulff at gmx.de <mailto:christianwulff at gmx.de>>:
> > Test ich gerade.
> > Nun kommt die Fehlermeldung alle 60 Sekunden.
> > ....ich versteh es nicht :-(
>
> Na ist doch irgendwie logisch: vzlogger wartet 60s auf neue Daten vom
> Zähler, es kommen aber keine. Dann landet die Fehlermeldung im Log,
> und es geht von vorne los (mit pullseq).
> Ich hatte allerdings gehofft, dass interval: 30 dafür sorgt, dass die
> Pull-Sequenz alle 30s geschickt wird und vzlogger damit nicht in den
> Timeout läuft. Offenbar klappt das so nicht. Hab wie gesagt keine
> eigene Erfahrung mit Zählern die gepullt werden müssen.
>
> Vielleicht können Matthias oder Daniel was dazu sagen?
>
> > Soll ich nochmal mit "duplicates": -1 testen?
>
> Ja, mach das mal eine Stunde lang, und poste die Rohdaten für diesen
> Zeitraum.
>
> Grüße
> Frank
>
>
> > Lieben Gruß,
> > Chris
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Frank Richter [mailto:frank.richter83 at gmail.com
> <mailto:frank.richter83 at gmail.com>]
> > Gesendet: Donnerstag, 16. Februar 2017 00:00
> > An: volkszaehler.org <http://volkszaehler.org>
> > Betreff: Re: [vz-dev] vzlogger.log läuft voll
> >
> > Und sowas wie
> >
> > "interval": 30,
> > "read_timeout": 60,
> >
> > hattest du mal getestet?
> >
> > Grüße
> > Frank
> >
> > Am 15. Februar 2017 um 22:42 schrieb Christian Wulff
> <christianwulff at gmx.de <mailto:christianwulff at gmx.de>>:
> >> Here it is:
> >>
> >>
> >>
> >>     {
> >>
> >>       "enabled": true,
> >>
> >>       "allowskip": false,
> >>
> >>       "interval": -1,
> >>
> >>       "aggtime": 60,
> >>
> >>       "aggfixedinterval": false,
> >>
> >>       "channels": [
> >>
> >>        {
> >>
> >>           "uuid": "89c0c960-8e59-11e6-81d7-efe19b94c4aa",
> >>
> >>           "identifier": "1.8.0",
> >>
> >>           "api": "volkszaehler",
> >>
> >>           "middleware": "http://localhost/middleware.php",
> >>
> >>           "aggmode": "none",
> >>
> >>           "duplicates": 3600
> >>
> >>         }
> >>
> >>       ],
> >>
> >>       "protocol": "d0",
> >>
> >>       "device": "/dev/ttyUSB1",
> >>
> >>       "pullseq": "2F3F210D0A",
> >>
> >>       "baudrate": 300,
> >>
> >>       "parity": "7e1",
> >>
> >>       "read_timeout": 30,
> >>
> >>     },
> >>
> >>
> >>
> >> ….AHA, duplicates steht auf 3600. Ich nehme mal an, das sind
> >> Sekunden, also sind 3600 Sekunden = 1 Stunde
> >>
> >> Nun kommen wir der Sache langsam auf die Spur
> >>
> >>
> >>
> >> Von: Frank Richter [mailto:frank.richter83 at gmail.com
> <mailto:frank.richter83 at gmail.com>]
> >> Gesendet: Mittwoch, 15. Februar 2017 22:26
> >>
> >>
> >> An: volkszaehler.org <http://volkszaehler.org>
> >> Betreff: Re: [vz-dev] vzlogger.log läuft voll
> >>
> >>
> >>
> >> duplicates in vzlogger.conf gesetzt?
> >> Poste am besten die ganze den Zähler betreffende Config, damit wir
> >> den aktuellen Stand kennen.
> >>
> >> Am 15.02.2017 22:18 schrieb "Christian Wulff"
> <christianwulff at gmx.de <mailto:christianwulff at gmx.de>>:
> >>
> >> Okay, nu hats geklappt:
> >>
> >>
> >>
> >> Zählerstand 10190,1 kWh passt….
> >>
> >>
> >>
> >> Allerdings versteh ich den timestamp mal gar nicht.
> >>
> >> Sieht für mich so aus, als ob ein Wert pro Stunde gespeichert wird.
> >>
> >> Außer wenn sich der Wert um 0,1 ändert, dann wird öfter ein Wert
> >> gespeichert.
> >>
> >>
> >>
> >> Was für ein Unfug. Der müsste doch nur einen Wert speichern, wenn er
> >> sich ändert?!
> >>
> >>
> >>
> >> 2017-02-13 23:41:04;10190.1;1
> >>
> >> 2017-02-14 00:41:25;10190.1;1
> >>
> >> 2017-02-14 01:41:34;10190.1;1
> >>
> >> 2017-02-14 02:03:57;10190.1;1
> >>
> >> 2017-02-14 03:04:12;10190.1;1
> >>
> >> 2017-02-14 04:04:26;10190.1;1
> >>
> >> 2017-02-14 05:04:42;10190.1;1
> >>
> >> 2017-02-14 06:04:57;10190.1;1
> >>
> >> 2017-02-14 07:05:12;10190.1;1
> >>
> >> 2017-02-14 07:17:02;10190.2;1
> >>
> >> 2017-02-14 07:20:09;10190.3;1
> >>
> >> 2017-02-14 07:23:17;10190.4;1
> >>
> >> 2017-02-14 07:26:27;10190.5;1
> >>
> >> 2017-02-14 07:29:36;10190.6;1
> >>
> >> 2017-02-14 07:32:43;10190.7;1
> >>
> >> 2017-02-14 07:35:48;10190.8;1
> >>
> >> 2017-02-14 07:39:03;10190.9;1
> >>
> >> 2017-02-14 07:41:34;10191;1
> >>
> >> 2017-02-14 07:44:44;10191.1;1
> >>
> >> 2017-02-14 07:47:53;10191.2;1
> >>
> >> 2017-02-14 07:51:00;10191.3;1
> >>
> >> 2017-02-14 07:53:30;10191.4;1
> >>
> >> 2017-02-14 07:56:37;10191.5;1
> >>
> >> 2017-02-14 08:11:11;10191.6;1
> >>
> >> 2017-02-14 08:14:57;10191.7;1
> >>
> >> 2017-02-14 08:18:03;10191.8;1
> >>
> >> 2017-02-14 08:21:48;10191.9;1
> >>
> >> 2017-02-14 08:24:57;10192;1
> >>
> >> 2017-02-14 08:28:44;10192.1;1
> >>
> >> 2017-02-14 08:31:51;10192.2;1
> >>
> >> 2017-02-14 08:35:02;10192.3;1
> >>
> >> 2017-02-14 08:38:48;10192.4;1
> >>
> >> 2017-02-14 08:41:57;10192.5;1
> >>
> >> 2017-02-14 08:45:41;10192.6;1
> >>
> >> 2017-02-14 08:48:47;10192.7;1
> >>
> >> 2017-02-14 08:52:29;10192.8;1
> >>
> >> 2017-02-14 08:55:35;10192.9;1
> >>
> >> 2017-02-14 08:59:18;10193;1
> >>
> >> 2017-02-14 09:02:23;10193.1;1
> >>
> >> 2017-02-14 09:06:07;10193.2;1
> >>
> >> 2017-02-14 09:09:13;10193.3;1
> >>
> >> 2017-02-14 09:12:58;10193.4;1
> >>
> >> 2017-02-14 09:16:08;10193.5;1
> >>
> >> 2017-02-14 09:19:53;10193.6;1
> >>
> >> 2017-02-14 09:23:01;10193.7;1
> >>
> >> 2017-02-14 09:26:45;10193.8;1
> >>
> >> 2017-02-14 09:30:28;10193.9;1
> >>
> >> 2017-02-14 09:33:41;10194;1
> >>
> >> 2017-02-14 09:36:52;10194.1;1
> >>
> >> 2017-02-14 09:40:40;10194.2;1
> >>
> >> 2017-02-14 09:43:50;10194.3;1
> >>
> >> 2017-02-14 09:46:58;10194.4;1
> >>
> >> 2017-02-14 09:50:15;10194.5;1
> >>
> >> 2017-02-14 09:54:03;10194.6;1
> >>
> >> 2017-02-14 09:57:14;10194.7;1
> >>
> >> 2017-02-14 10:57:55;10194.7;1
> >>
> >> 2017-02-14 10:58:36;10194.8;1
> >>
> >> 2017-02-14 11:28:20;10194.9;1
> >>
> >> 2017-02-14 11:32:06;10195;1
> >>
> >> 2017-02-14 11:35:17;10195.1;1
> >>
> >> 2017-02-14 11:38:24;10195.2;1
> >>
> >> 2017-02-14 11:42:10;10195.3;1
> >>
> >> 2017-02-14 11:45:18;10195.4;1
> >>
> >> 2017-02-14 11:48:26;10195.5;1
> >>
> >> 2017-02-14 11:51:42;10195.6;1
> >>
> >> 2017-02-14 11:54:50;10195.7;1
> >>
> >> 2017-02-14 11:58:35;10195.8;1
> >>
> >> 2017-02-14 12:01:43;10195.9;1
> >>
> >> 2017-02-14 12:04:51;10196;1
> >>
> >> 2017-02-14 12:07:57;10196.1;1
> >>
> >> 2017-02-14 12:11:04;10196.2;1
> >>
> >> 2017-02-14 12:14:12;10196.3;1
> >>
> >> 2017-02-14 12:17:30;10196.4;1
> >>
> >> 2017-02-14 12:20:00;10196.5;1
> >>
> >> 2017-02-14 12:23:09;10196.6;1
> >>
> >> 2017-02-14 12:25:40;10196.7;1
> >>
> >> 2017-02-14 12:28:47;10196.8;1
> >>
> >> 2017-02-14 12:39:51;10196.9;1
> >>
> >> 2017-02-14 13:40:14;10196.9;1
> >>
> >> 2017-02-14 14:16:08;10197;1
> >>
> >> 2017-02-14 14:59:40;10197.1;1
> >>
> >> 2017-02-14 15:02:47;10197.2;1
> >>
> >> 2017-02-14 15:06:29;10197.3;1
> >>
> >> 2017-02-14 15:09:34;10197.4;1
> >>
> >> 2017-02-14 15:12:42;10197.5;1
> >>
> >> 2017-02-14 15:15:47;10197.6;1
> >>
> >> 2017-02-14 15:18:57;10197.7;1
> >>
> >> 2017-02-14 15:22:41;10197.8;1
> >>
> >> 2017-02-14 15:25:54;10197.9;1
> >>
> >> 2017-02-14 15:29:02;10198;1
> >>
> >> 2017-02-14 16:01:55;10198.1;1
> >>
> >> 2017-02-14 17:02:07;10198.1;1
> >>
> >> 2017-02-14 17:39:26;10198.2;1
> >>
> >> 2017-02-14 18:06:55;10198.3;1
> >>
> >> 2017-02-14 18:10:42;10198.4;1
> >>
> >> 2017-02-14 18:13:50;10198.5;1
> >>
> >> 2017-02-14 18:16:57;10198.6;1
> >>
> >> 2017-02-14 18:20:04;10198.7;1
> >>
> >> 2017-02-14 18:23:48;10198.8;1
> >>
> >> 2017-02-14 18:26:56;10198.9;1
> >>
> >> 2017-02-14 18:30:03;10199;1
> >>
> >> 2017-02-14 18:33:15;10199.1;1
> >>
> >> 2017-02-14 18:36:59;10199.2;1
> >>
> >> 2017-02-14 18:40:05;10199.3;1
> >>
> >> 2017-02-14 18:43:11;10199.4;1
> >>
> >> 2017-02-14 18:46:18;10199.5;1
> >>
> >> 2017-02-14 18:50:02;10199.6;1
> >>
> >> 2017-02-14 18:53:09;10199.7;1
> >>
> >> 2017-02-14 18:56:14;10199.8;1
> >>
> >> 2017-02-14 18:59:21;10199.9;1
> >>
> >> 2017-02-14 19:01:53;10200;1
> >>
> >> 2017-02-14 19:05:02;10200.1;1
> >>
> >> 2017-02-14 19:08:09;10200.2;1
> >>
> >> 2017-02-14 19:11:15;10200.3;1
> >>
> >> 2017-02-14 19:13:44;10200.4;1
> >>
> >> 2017-02-14 19:16:53;10200.5;1
> >>
> >> 2017-02-14 19:19:25;10200.6;1
> >>
> >> 2017-02-14 19:22:35;10200.7;1
> >>
> >> 2017-02-14 19:25:07;10200.8;1
> >>
> >> 2017-02-14 19:28:16;10200.9;1
> >>
> >> 2017-02-14 19:30:53;10201;1
> >>
> >> 2017-02-14 19:34:02;10201.1;1
> >>
> >> 2017-02-14 19:37:11;10201.2;1
> >>
> >> 2017-02-14 19:50:17;10201.3;1
> >>
> >> 2017-02-14 20:13:37;10201.4;1
> >>
> >> 2017-02-14 20:16:43;10201.5;1
> >>
> >> 2017-02-14 20:19:52;10201.6;1
> >>
> >> 2017-02-14 20:23:37;10201.7;1
> >>
> >> 2017-02-14 20:26:43;10201.8;1
> >>
> >> 2017-02-14 20:29:50;10201.9;1
> >>
> >> 2017-02-14 20:32:58;10202;1
> >>
> >> 2017-02-14 20:36:44;10202.1;1
> >>
> >> 2017-02-14 20:40:00;10202.2;1
> >>
> >> 2017-02-14 20:43:15;10202.3;1
> >>
> >> 2017-02-14 20:46:25;10202.4;1
> >>
> >> 2017-02-14 20:50:15;10202.5;1
> >>
> >> 2017-02-14 20:53:24;10202.6;1
> >>
> >> 2017-02-14 20:56:29;10202.7;1
> >>
> >> 2017-02-14 21:56:48;10202.7;1
> >>
> >> 2017-02-14 22:56:57;10202.7;1
> >>
> >> 2017-02-14 23:57:16;10202.7;1
> >>
> >> 2017-02-15 00:57:25;10202.7;1
> >>
> >>
> >>
> >>
> >>
> >> Von: Frank Richter [mailto:frank.richter83 at gmail.com
> <mailto:frank.richter83 at gmail.com>]
> >> Gesendet: Mittwoch, 15. Februar 2017 22:05
> >> An: volkszaehler.org <http://volkszaehler.org>
> >> Betreff: Re: [vz-dev] vzlogger.log läuft voll
> >>
> >>
> >>
> >> Ups, versehentlich einen Slash gelöscht.
> >> http://IP/middleware.php/data/UUID.csv?options=raw&from=14-02-2017&to
> >> =
> >> 15-02-2017
> >>
> >> Am 15.02.2017 21:58 schrieb "Frank Richter"
> <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>>:
> >>
> >> Hi Christian,
> >>
> >> mach besser einen Screenshot von einer Stunde statt über Tage, dann
> >> erkennt man auch die Zeitauflösung.
> >> Wenn du Rohdaten aus der DB holen willst, versuch mal das hier:
> >> http:/IP/middleware.php/data/UUID.csv?options=raw&from=14-02-2017&to=
> >> 1
> >> 5-02-2017
> >>
> >> Nur noch deine IP, UUID und gewünschten Zeitraum einsetzen.
> >>
> >> Grüße
> >> Frank
> >>
> >>
> >>
> >>
> >>
> >> Am 15.02.2017 21:45 schrieb "Christian Wulff"
> <christianwulff at gmx.de <mailto:christianwulff at gmx.de>>:
> >>
> >> So, mal gucken, ob ich die letzten drei Antworten wieder zu einer
> >> email zusammengeflockt bekomme und wieder an der richtigen Stelle
> >> weitermachen kann.
> >>
> >> Also  Intervall steht auf "interval": -1, ist das wohlmöglich falsch?
> >> Nun hab ich mir die Daten im Frontend angesehen bevor und nachdem ich
> >> von
> >> "read_timeout": 30, auf "read_timeout": 300, gewechselt habe.
> >> Siehe da, es gibt einen Unterschied. Beim timeout300_1.jpg steht der
> >> Cursor in der Mitte. Links davon ist timeout=30, rechts davon ist
> timeout=300.
> >> Beim timeout300_2.jpg steht der Cursor in der Mitte. Links davon ist
> >> timeout=300, rechts davon ist timeout=30.
> >> Mit größerem Timeout nimmt die Auflösung der Messgenauigkeit ab?!
> >>
> >> "ich meine den Zeitabstand zwischen 2 Datensätzen bei einem der
> D0-Kanäle.
> >> Die Frage ist: liefert der Zähler nach der Pullsequenz nur 1x Daten
> >> und läuft dann in den Timeout, oder liefert er zunächst regelmäßig
> >> Daten und der Timeout passiert später?"
> >>
> >> Ich weiss leider nicht wie ich das rauskriegen kann. (Da bräuchte ich
> >> ne Anleitung für VZ-, Linux- und SQL-Anfänger) Ich habs mit dem
> >> Export aus dem Frontend probiert. Leider ist da kein Format dabei mit
> >> dem ich was anfangen könnte.
> >> Hab versucht das .csv in Excel zu importieren. Da kommen nur Zahlen
> >> bei raus die mit dem Zählerstand nichts zu tun haben.
> >>
> >> ...hab grad mal wieder in die Datenbank gesehen, ich glaube da sind
> >> schon über 4 Mio. Einträge...
> >>
> >> Ich würde ja gerne die S0 Daten zählen, dann allerdings wäre meine
> >> bevorzugte Strategie 1x am Tag per D0 den richtigen Zählerstand
> >> auszulesen, und danach mit den S0 Impulsen diesen Zählerstand
> >> aufaddieren. Dann könnte man echte Zählerstände in der Datenbank
> >> speichern und nicht nur "1"sen, die ohne einen Startwert keinen Sinn
> >> ergeben. Wer weiss denn schon ob sich der
> >> S0 Zähler nicht verzählt hat. Mit der zuvor genannten Strategie wäre
> >> man sich sicher, dass er sich maximal nur am Tag verzählen kann, sich
> >> die Fehler aber niemals über einen Tag hinaus aufaddieren können,
> >> weil jeden Tag mit der D0 Abfrage der Startwert perfekt akkurat
> aktualisiert wird.
> >>
> >> Lieben Gruß,
> >> Chris
> >>
> >>
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Daniel Lauckner [mailto:vz at jahp.de <mailto:vz at jahp.de>]
> >> Gesendet: Montag, 6. Februar 2017 04:36
> >> An: volkszaehler.org <http://volkszaehler.org>
> >> Betreff: Re: [vz-dev] vzlogger.log läuft voll
> >>
> >> Hallo Christian,
> >>
> >>
> >> am Sonntag, 5. Februar 2017 um 23:05 hast du geschrieben:
> >>> Welches Zeitintervall meinst du nun genau?
> >>
> >> Ich denke der Parameter "interval".
> >>
> >> Der Paramter ist nicht zwingend, aber sinnvoll in Zusammenhang mit
> >> d0-Zähler die zum Senden aufgefordert werden müssen. Insbesondere
> >> wenn die Auflösung so schlecht ist. Da ist es ziemlich Zweckfrei nach
> >> einer Antwortet des Zählers sofort wieder den nächsten Datensatz
> anzufordern.
> >> Steht ja doch wieder der selbe Zählerstand drin...
> >>
> >>
> >>> Ja, bin mir sicher, dass ich die richtige vzlogger.conf editiere.
> >>> Stelle ich das timeout auf 30, so kommt das Fehlerlog alle 30s
> >>
> >> Klingt fast so als hätten wir da nen Fehler im vzlogger. Sehe im Code
> >> aber keine Indizien dafür.
> >>
> >>
> >>> Hat denn noch jemand anderes einen Itron ACE 3000 Typ 260 am
> >>> vzlogger laufen?
> >>
> >> Allerdings bist du der einzige der sich beschwert das sein Log so
> >> vollgemüllt wird. Von daher stellt sich schon die Frage was du anders
> >> machst als alle anderen. Allein schon um die Ursache einzugrenzen.
> >>
> >>
> >> mfg Daniel
> >
> >
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20170219/2b2fe873/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30595 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20170219/2b2fe873/attachment-0001.png>


More information about the volkszaehler-dev mailing list