Re: [vz-dev] vzlogger + middelware und Timestamps
On Fri, 29 Mar 2013 22:54:41 +0100 Rainer Gauweiler volkszaeh...@moppl.inka.de wrote: ich glaube dass sowohl der vzlogger als auch die middleware an den Zeitstempeln falsch drehen. Vzlogger: [Mar 29 21:46:44][chn0] Adding reading to queue (value=6545.03 ts=1364590003.991) [Mar 29 21:46:44][chn0] == number of tuples: 1 [Mar 29 21:46:44][chn0] compare: 0 1364590003991 1364590003991.138916 [Mar 29 21:46:44][chn0] JSON request body: [ [ 1364590003991.138916, 6545.034668 ] ] Man sieht, der Zeitstempel beim Request ist nicht der gleiche wie zum Zeitpunkt der Wertmessung. Ich vermute, der Stempel wird neu ermittelt, wenn der Request zusammengebaut wird - ist das möglich? Das wäre nicht *sooo* tragisch, aber wird vermutlich ziemliche Verschiebungen erzeugen, wenn ein Request temporär nicht durch geht. Middleware: In der Datenbank steht 1364590003990 als Zeitstempel. Übernimmt hier die Middleware nicht den Wert aus dem Request, sondern ermittelt ihn neu selbst? Kann jemand mit Codekenntnissen da bitte mal einen prüfenden Blick an die entsprechenden Stellen werfen? sorry, aber das ist jedesmal (fast) genau der gleiche timestamp, nur mit anderer komma-position, und wohl mit leichten abweichungen durch speicherung als float: 1364590003.991 1364590003 991 1364590003 991.13891 1364590003 991.138916 1364590003 990 man konnte vlt. mal durchgehend ausreichend grosse (int/fixed-point?) typen benutzen um's sauberer zu haben, die abweichung um 1ms am ende ist etwas merkwuerdig, aber auch nicht weiter tragisch... Gruss Rainer - Thorben
Re: [vz-dev] vzlogger + middelware und Timestamps
Hallo Thorben, Am 30.03.2013 11:33, schrieb Thorben Thuermer: sorry, aber das ist jedesmal (fast) genau der gleiche timestamp, nur mit anderer komma-position, und wohl mit leichten abweichungen durch speicherung als float: 1364590003.991 1364590003 991 1364590003 991.13891 1364590003 991.138916 1364590003 990 Ja, mir geht es um das fast, sprich um den Anteil nach dem Komma. Mir ist klar, dass wir hier über Mikrosekundenbruchteile reden. Falls das durch Umrechnen in einen Float ist ist es mir auch egal (auch wenn es mich verwundert). Falls aber der Unterschied dadurch kommt, dass der Zeitstempel etwas später (nämlich beim Bau des Requests) nochmal erzeugt wird, dann habe ich ein Problem damit. Wenn der Request das erste Mal scheitert (z.B: WLAN kurz weg) und nach 30 Sekunden bei der Wiederholung der Zeitstempel wieder neu ermittelt wird, weil der Request erneut zusammengebaut wird dann haben wir eine Differenz von 30 Sekunden. Falls die Unterbrechung noch länger ist haben wir plötzlich mehrere Zeitwerte innerhalb von wenigen Millisekunden zusammengelegt und bekommen plötzlich eine ganz andere Leistung. Und exakt das ist es, was ich hier ab und an beobachte, da mein Netz regelmäßig ausfällt. Daher meine Frage ob innerhalb des vzloggers sicher gestellt ist, dass der Zeitstempel genau ein einziges Mal beim Empfang des Messwertes gesetzt wird. die abweichung um 1ms am ende ist etwas merkwuerdig, aber auch nicht weiter tragisch... S.o. auch hier gilt: Eine Drift von 1mS ist mir egal. Wenn aber auch hier der Zeitstempel nicht übernommen wird, sondern neu durch die Middleware erzeugt, dann bekomme ich hier falsche Werte, falls der Empfang der Messwerte und die Übergabe zu lang auseinander liegt. Gruss Rainer
Re: [vz-dev] Error executing grouped queries
Hallo Jakob hi, Developers, ich habe probleme gruppierte anfragen auszuführen: http://localhost/vz/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.json?group=year Cool, group= kannte ich selbst garnicht. Mit was für einem Channel benutzt du das denn? Channel vom Typ Strommesser (HW selbst gebaut). Drauf gekommen bin ich weil ich mir ein kleines Dashboard bauen wollte und dafür aktuelle/ aggrgierte Daten brauchte- hab's in der Doku gefunden. dürfte DataIterator __construct sein: // skipping first reading, just for getting first timestamp $this-from = $this-stmt-fetchColumn(); Wenn es nur 1 row im resultset gibt verschwindet dann genau diese. Wenn die Zeile auskommentiert wird läuft es. Jein. Für group wird die selbe Leistungsberechnung durchgeführt wie sonst auch, und dafür werden eben mindestens zwei Zeitstempel gebraucht. group fasst aber komplette Zeiträume vorher zusammen, so daß pro group-Intervall nur ein Tupel (timestamp, value-sum) rauskommt. Damit vom aktuellen group-Intervall was angezeigt werden kann, braucht man also noch den letzten Zeitstempel des vorherigen Intervalls. Für normale Queries wird der schon geholt, ist also kein großes Problem, daß auch für group zu machen. Ist auch eine gute Gelegenheit, getData etwas aufzuhübschen. Ich mach das mal. Klasse- stehe zum Testen bereit (gerne auch an cpui...@gmx.de). Was die Leistungsberechnung angeht habe ich ein weiteres Problem- nämlich die Tatsache, dass die Durchschnittswerte alle falsch sind. Es wird jeweils 0 (oder ein Werte nahe 0) ausgegeben, auch wenn eindeutig mehr angefallen ist. Etwas verwirrend ist aber auch die Ausgabe, da (wie sonst auch) der timestamp des Intervall-Starts angegeben wird, der liegt aber jeweils im vorherigen group-Interval. Beispiel (Testdaten, als csv): # from: 2013-03-17 23:59:04 # to: 2013-03-29 02:25:05 # min: 2013-03-19 23:31:34 = 1,377 # max: 2013-03-18 23:59:59 = 298,174 # average: 83,773 # consumption: 22320 # rows: 6 2013-03-17 23:59:04;298,143;1432 2013-03-18 23:59:59;298,174;1403 2013-03-19 23:31:34;1,377;53 2013-03-27 23:59:09;298,138;1431 2013-03-28 23:59:05;297,935;145 Die letzte Zeile bedeutet, daß von 2013-03-28 23:59:05 bis jetzt (genauer: zum letzten vorliegenden Impuls) die Durchschnittsleistung 297,935W war. Mhm- bei mir haut das mit dem Average nicht hin. Wenn's bei Dir läuft dann muss ich wohl auch an der Stelle ein bisschen in den Code einsteigen. Viele Grüße, Andreas
