[vz-dev] Error executing grouped queries
hi, Developers,
ich habe probleme gruppierte anfragen auszuführen:
http://localhost/vz/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.json?group=year
das ergebnis bleibt fälschlich leer:
{version:0.2,data:{uuid:8f20eb60-60df-11e2-81a1-3d3ab836429e,average:0,consumption:0,rows:1}}
Sql etc alles korrekt, nur die ergebnisrow wird unterschlagen. Grund
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.
Mein Fehler oder bekanntest Problem?
Viele Grüsse,
Andreas
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
[vz-dev] jsonp support für vz
Hallo Zusammen, ich hatte den Wunsch, remote (d.h. per iphone-app) auf die mw zuzugreifen. Aus Sicherheitsgründen ist das nur per JsonP, nicht jedoch json möglich. Wenn Interesse besteht hätte ich hier einen Patch mit dem sich JsonP darstellen lässt- es fehlt nur noch eine Default-Konfigurationsoption um das Verhalten standardmäßig zu deaktivieren. Frohe Ostern, Andreas
Re: [vz-dev] Error executing grouped queries
Hi Jakob, die letzten Commits in Deinem Git sind ewig alt- bin ich wirklich an der richtigen Stelle gelandet bzw. ist alles drin? Welcher Branch? vg Andreas On 02.04.2013 01:45, Jakob Hirsch wrote: On 30.03.2013 16:00, Andreas Goetz wrote: Klasse- stehe zum Testen bereit (gerne auch an cpui...@gmx.de). Was die Du kannst mal meinen Fork unter git://github.com/jahir/volkszaehler.org.git probieren. 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. Hm, das passt bei mir: # from: 2013-03-31 23:59:28 # to: 2013-04-02 01:38:51 # min: 2013-04-01 06:59:14 = 290,816 # max: 2013-04-01 21:59:34 = 298,388 # average: 297,783 # consumption: 7640 # rows: 27 2013-03-31 23:59:28;298,279;60 2013-04-01 00:59:49;297,348;59 2013-04-01 01:59:20;298,1;60 2013-04-01 02:59:43;298,175;59 ... 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. Du kannst ja mal einen relevanten Zeitraum exportieren (vorzugsweise mit mysqldump volkszaehler data --where=channel_id=... and timestamp between ... and ...), dann kann ich mal schaue, was da falschläuft.
Re: [vz-dev] Error executing grouped queries
Hallo Jakob, bitte entschuldige- keine Ahnung was ich da gesehen habe... Werde heute testen und mich dann wieder melden. Viele Grüße, Andreas 2013/4/2 Jakob Hirsch j...@plonk.de On 02.04.2013 08:31, Andreas Goetz wrote: die letzten Commits in Deinem Git sind ewig alt- bin ich wirklich an der richtigen Stelle gelandet bzw. ist alles drin? Welcher Branch? Was meinst du mit ewig alt? Laut https://github.com/jahir/volkszaehler.org/commits/master ist der letzte commit vom 1.4.
Re: [vz-dev] jsonp support für vz
Hallo Thorben, On 03.04.2013 08:03, Thorben Thuermer wrote: On Mon, 01 Apr 2013 17:33:46 +0200 Andreas Goetz cpui...@gmail.com wrote: Hallo Zusammen, ich hatte den Wunsch, remote (d.h. per iphone-app) auf die mw zuzugreifen. Aus Sicherheitsgründen ist das nur per JsonP, nicht jedoch json möglich. interessante sache irgendwie... es ist doch eigentlich im frontend vorgesehen, kanaele von verschiedenen middlewares abbonieren zu koennen - funktionierte das bisher garnicht?! Kann nicht. Allerdings habe ich auch keinen Platz in rigendeiner Config gefunden wo ich eine zweite MW hätte eintragen können- für's durch JS hacken fehlte mir bisher die Zeit. Wäre aber eine spannende Aufgabe auch daran ein wenig zu basteln. (fuer die die die problematik nicht kennen: http://en.wikipedia.org/wiki/JSONP ) Wenn Interesse besteht hätte ich hier einen Patch mit dem sich JsonP darstellen lässt- es fehlt nur noch eine Default-Konfigurationsoption um das Verhalten standardmäßig zu deaktivieren. warum schickst du den patch nicht einfach? oder noch besser, einen pull-request auf github. Da war ich schneller ;) https://github.com/volkszaehler/volkszaehler.org/pull/44 In der jetzigen Version ist das allerdings ein potentielles Sicherhitsrisiko- es lassen sich ja nicht nur Daten abfragen sondern auch löschen. Was fehlt ist m.E. eine Konfigurationsoption mit der jsonp standardmäßig erstmal deaktiviert ist. interessant waehre noch die technische umsetzung... ein zusaetzlicher parameter um das format anzugeben, und den namen der callback funktion? Sind nur 3 Zeilen- siehe patch. Aufgerufen wird es- wenn man jQuery einsetzt- indem einfach callback=? an die Anfrage gehängt wird, jQ bastelt daraus dann einen eindeutigen Funktionsnahmen den es auf dem Rückweg auch aufruft und die Daten rausholt. ich denke das standard-rueckgabeformat der middleware zu aendern waehre keine gute idee, zumal es auch andere clients als das standard-frontend gibt. Nicht nötig- es wird ja über den Request gesteuert, der Client kann also entscheiden. Frohe Ostern, Andreas - Thorben Viele Grüße, Andreas
Re: [vz-dev] Error executing grouped queries
Hallo Jakob, habe mir das jetzt nochmal in Ruhe angeschaut. mal möchte ich Dir aber ein kleines goodie zeigen dass Dich vielleicht interessieren wird- nämlich ein kleines Dashboard für meine PV-Anlage das ich als iPhone-WebApp zusammengedübelt habe: Wenn's da Interesse gibt kann ich gerne Code beitragen. Die Widgets sind aus dem emoncms und auf jQuery widgets umgebaut... Sieht gut aus, bringt mir mit meinen Android-Geräten allerdings nix, oder? Ist alles HTML+JS- läuft überall. Die Widgets sind von emoncms.org ausgeborgt und für jQuery angepasst. Komisch- da fromto den gleichen Wert haben, aber anders angegeben waren! Damit glaube ich, dass mindestens noch ein weiteres Problem besteht- sobald from gesetzt ist, wird dieses nämlich in der Abfrage von to als now() gesetzt- die Abfragen sind also counterintuitiv _immer_ relativ zueinander. Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal gefixt. Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde (mit Update der Doku..)- die Logik ist wirklich krank :/ Die Gruppierung läuft allerdings weiter nicht- auch nicht mit: http://localhost/vz/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.json?from=1.1.2013to=1.4.2013group=month Das hab ich gerade mal mit meinem Test-Channel probiert, das funktioniert problemlos: $ curl 'http://localhost/vzdemo/middleware.php/data/x.csv?tsfmt=sqlfrom=1.1.2013to=1.4.2013group=month' # source: volkszaehler.org # version: 0.2 # uuid: x # from: 2013-03-31 23:59:28 # to: 2013-04-01 00:01:29 # min: 2013-03-31 23:59:28 = 297,892 # max: 2013-03-31 23:59:28 = 297,892 # average: 297,892 # consumption: 10 # rows: 2 2013-03-31 23:59:28;297,892;2 Mhm. Bei mir tatsächlich nicht. Ohne group:
Re: [vz-dev] Error executing grouped queries
Hallo, so richtig click macht es bei mir noch nicht. Für Gruppierung nach Monaten kann ich das ja nachvollzieren- aber auch bei Gruppierung nach Wochen oder Tagen kommt nix raus- und spätestens hier müsste es ja 2 Tupel geben: http://localhost/vz/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3ab836429e.json?group=dayfrom=1.1.2013to=today Letztlich- fällt mir gerade noch ein- wenn group=monat oder jahr angegeben ist wäre es evtl. auch sinnvoll, das from-to Intervall, falls nicht angegeben, automatisch auf einen sinnvollen Wert, z.B. dieses Jahr zu setzen? vg Andreas On 04.04.2013 18:25, Jakob Hirsch wrote: Hi, Andreas Goetz, 03.04.2013 19:50: Ja, die Logik in Interpreter ist da etwas kaputt. Ich hab das jetzt mal gefixt. Wäre Klasse wenn der Fix es in die offizielle Version schaffen würde (mit Update der Doku..)- die Logik ist wirklich krank :/ Das dürfte schon klappen :) Ok, schicke ich per PM hinterher. Hab ich mir angeschaut. Das Problem ist, daß du im März Daten hast, aber nicht im Februar. Die Auswertung läuft aber so, daß mit group die Daten einzelner Monate zusammengefasst werden und dann von processData wie sonst auch verarbeitet werden, d.h. vom ersten Tupel wird nur der timestamp genommen und der Rest verworfen, bei dir eben die zusammengefassten Daten vom März. Ohne mittelgroße Umbauten oder unschöne Hacks ist das aber leider nicht zu fixen.Ich schau's mir evt. nochmal an, aber du solltest nicht darauf warten... Workaround für dich: Einen einzelnen Impuls (mit Wert 0) für Ende Februar einfügen (28.2. 23:59:59).
Re: [vz-dev] jsonp support für vz
Hallo Jakob,
danke für den Hinweis! padding=? funktioniert tatsächlich auch (hatte
ich in der Doku anders verstanden)- damit ist alles Paletti, danke!
Jetzt fehlt nur noch ein eleganter weg, zusätzliche MWs in der
Konfiguration anzugeben.
Viele Grüsse,
Andreas
On 07.04.2013 02:33, Jakob Hirsch wrote:
On 04.04.2013 19:14, Andreas Goetz wrote:
Das hab ich glatt übersehen :/, content-type ist definition falsch. Ich
fände dennoch callback statt padding als Parameter schöner- dann
liesse sich nämlich auch jQuery getJSON nutzen. Mit der jetzigen Lösung
Wenn ich die Beschreibung von getJSON richtig verstanden habe (es ist
leider nicht explizit beschrieben), funktioniert das mit jedem
Parameter, der vor =? steht, in unserem Fall also padding=?.
Ich finde padding als Parametername auch nicht so prall (auch wenn es
technisch korrekt ist), aber ohne Not ändert man sowas nicht.
muss man zwangsweise auf $.ajax ausweichen um die notwendigen Parameter
reinzufummeln. Aber ja- es ist möglich ;)
Also der Unterschied zwischen
$.getJSON(url, data, success)
und
$.ajax({dataType: json, url: url, data: data, success: success});
ist jetzt nicht soo riesig...
Re: [vz-dev] Aggregierung von Daten im vzlogger ?
Hallo Zusammen, 2013/4/10 Jan Tamm v...@tamms.net Meinungen? blöde Idee ? Gibt es schon ? Ich schaue mir eh gerade den S0 Meter via RS232 an und wollte das mit dem Durchschnitt eh einfügen. Nun nehme ich Deinen Vorschlag für die Parameternamen und baue das dort einfach einmal ein. Die Änderungen sollten nur pro Meter gemacht werden, ich glaube nicht dass da etwas übergeordnetes geändert werden muss. An welchen Metern wird sonst noch gearbeitet? - Jan Ich bin mir nicht sicher ob es wirklich hierher gehört (falls nein gerne ignorieren): - ich nutze VZ als Datensenke und Visualisierung - Datenerfassung für mehrere Stromzähler (=Impulszähler) habe ich mit Eigenbau Hard- und Software realisierung - Falls das als Meter zählt und ein Interesse an einem ImpulsCounterMeter auf Basis von General Purpose IOs (GPIO) besteht, dann könnte ich meinen Code (Python) in ein Meter wandeln und gerne beitragen. Viele Grüße, Andreas
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo Zusammen, eine Optimierung welche mir für vzcompress noch einfiele wäre die Löschung (nicht nur Komprimierung) redundanter Nullwerte. Hintergrund: bei normalen Stromzählern (aber auch Verbrauchsmessern) ist tagsüber während die PV läuft der Bezug meist 0, ebenso sind Einspeisung und Erzeugung nachts eigentlich immer 0. Diese Nullen ließen sind- bis auf die jeweils erste und letzter einer 0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend keine Rampen in die Darstellung einbaut. Nachteilig ist natürlich dass man nich tmehr so einfach auf der Datenbank Werte mehrerer Kanäle für einen Timestamp zusammenjoinen kann- aber andererseits ist auch klar, dass kein Wert automatisch eine 0 im Verbrauch bedeutet. Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein? Viele Grüße, Andreas
Re: [vz-dev] Alternative Implementierung für vzcompress
Hallo Florian, mit etwas mehr Zeit kann ich Dir jetzt ausführlicher antworten. Zur Erinerung nochmal das Statement (mit kleinen Optimierungen): -- delete - all channels delete from data where id in ( select id from ( select o.channel_id, o.id, ( select max(timestamp) from data i_p where i_p.channel_id = o.channel_id and i_p.timestamp o.timestamp ) as prev_ts, p.id as prev_id, p.value as prev_value, ( select min(timestamp) from data i_n where i_n.channel_id = o.channel_id and i_n.timestamp o.timestamp ) as next_ts, n.id as next_id, n.value as next_value from data o left join data p on p.timestamp = prev_ts and o.channel_id = p.channel_id left join data n on n.timestamp = next_ts and o.channel_id = n.channel_id where o.channel_id in (select id from entities where class = channel) and p.value = o.value and n.value = o.value and o.value = 0 ) ) On 15.04.2013 22:34, Florian Knodt wrote: Nabend die Dritte, das ist jetzt die 0-Wert-Löschung? Er sucht 3 aufeinanderfolgende Werte eines Kanals und löscht wenn alle 0 sind den Mittleren, richtig? Wenn Du Dir das innere SELECT anschaust siehst Du, dass alle Datensätze zurückgegeben werden, die den gleichen Wert aufweisen wie der vorherige und nächste Datensatz im gleichen Kanal- das sind also die innenliegenden Datensätze einer Folge. Mit dem äußeren SELECT wird diese Liste auf die IDs reduziert und der Löschung zugeführt. Die Einschränkung auf Nullwerte erfolgt mit dem letzten Teil der WHERE-Clause. Am 2013-04-14 20:22, schrieb Andreas Goetz: eine Optimierung welche mir für vzcompress noch einfiele wäre die Löschung (nicht nur Komprimierung) redundanter Nullwerte. Bei MeterInterpreter die nullen, bei SensorInterpreter aufeinanderfolgende und identische Werte würde ich sagen - wenns bei letzterem gleich bleibt sollte das ähnlich funktionieren. Guter Punkt. Wenn Die den letzten Teil der WHERE-Clause (=0) weglässt, ist jetzt auch dieser Fall mit abgedeckt. 0-Strecke einsparen. Die letzte 0 wird benötige, damit das Frontend keine Rampen in die Darstellung einbaut. Guter Punkt, das hätte ich glatt verpennt… Leider funktioniert das nach meinen Tests trotzdem nicht. Die Werte stehen korrekt in der DB, werden per JSON korrekt zurückgeliefert, aber im Chart wird die letzte Null eines Bereiches ignoriert. Ursache ist mir nicht klar. Nachteilig ist natürlich dass man nich tmehr so einfach auf der Datenbank Werte mehrerer Kanäle für einen Timestamp zusammenjoinen kann ...und ggf. nicht so weit im Frontend zoomen kann - afair zeigt das nichts an wenn keine Daten vorhanden sind. Wenn wir den ganzen (Sonnen)Tag von 0 reden und z.B. auf Stundenansicht gehen könnte das ggf. auch etwas seltsam aussehen Auch ein guter Punkt- aber das gleiche Problem, welches auch bei Komprimierung der Werte besteht, oder? Im SQL könnte man den maximalen Zoomraum durch Einschränkung der WHERE-Clause vor Löschung schützen: ... and p.timestamp o.timestamp - 1*60*1000 and n.timestamp o.timestamp - 1*60*1000 damit sind dann nur Datensätze betroffen, deren Vorgänger und Nachfolger _innerhalb_ eines angegebenen Intervalls liegen (vmtl. müsste man sich aber eher auf den Intervallanfang/ende konzentrieren- das braucht noch etwas Bastelei). Der Weg sollte der gleiche sein. Wie wär's- bekommen wir das in die Neuimplementierung noch mit rein? noch? ich mach von meiner Seite keinen Schreibschutz drauf und deklariere es als fertig ;) Spaß beiseite: Ist notiert und hört sich erfolgsversprechend an, wenn ich etwas Zeit bekomme und der Schleifenbug raus ist schau ichs mir an. Ich bin gespannt- gibts eigentlich ein GIT dafür? Viele Grüße, Andreas
[vz-dev] Performanceoptimierung MeterInterpreter
Hallo Zusammen,
beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir
aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl
von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der
Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit
Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei
müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese
auch erstmal aus MySQL abgeholt werden.
Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren.
Die untenstehende Methode erledigt das und kann in MeterInterpreter
eingefügt werden (siehe unterer Teil nach EmptyIterator).
Ich freue mich über Feedback/ Testergebnisse:
/**
* Get raw data
*
* Optimized version for thinning meter data
*
* @param string|integer $groupBy
* @return Volkszaehler\DataIterator
*/
protected function getData() {
// get timestamps of preceding and following data points as a
graciousness
// for the frontend to be able to draw graphs to the left and
right borders
if (isset($this-from)) {
$sql = 'SELECT MIN(timestamp) FROM (SELECT timestamp FROM
data WHERE channel_id=? AND timestamp? ORDER BY timestamp DESC LIMIT 2) t';
$from = $this-conn-fetchColumn($sql,
array($this-channel-getId(), $this-from), 0);
if ($from)
$this-from = $from;
}
if (isset($this-to)) {
$sql = 'SELECT MAX(timestamp) FROM (SELECT timestamp FROM
data WHERE channel_id=? AND timestamp? ORDER BY timestamp ASC LIMIT 2) t';
$to = $this-conn-fetchColumn($sql,
array($this-channel-getId(), $this-to), 0);
if ($to)
$this-to = $to;
}
// common conditions for following SQL queries
$sqlParameters = array($this-channel-getId());
$sqlTimeFilter = self::buildDateTimeFilterSQL($this-from,
$this-to, $sqlParameters);
if ($this-groupBy) {
$sqlGroupFields = self::buildGroupBySQL($this-groupBy);
if (!$sqlGroupFields)
throw new \Exception('Unknown group');
$sqlRowCount = 'SELECT COUNT(DISTINCT ' . $sqlGroupFields .
') FROM data WHERE channel_id = ?' . $sqlTimeFilter;
$sql = 'SELECT MAX(timestamp) AS timestamp, SUM(value) AS
value, COUNT(timestamp) AS count'.
' FROM data'.
' WHERE channel_id = ?' . $sqlTimeFilter .
' GROUP BY ' . $sqlGroupFields;
}
else {
$sqlRowCount = 'SELECT COUNT(*) FROM data WHERE channel_id
= ?' . $sqlTimeFilter;
$sql = 'SELECT timestamp, value, 1 AS count FROM data WHERE
channel_id=?' . $sqlTimeFilter . ' ORDER BY timestamp ASC';
}
$this-rowCount = (int) $this-conn-fetchColumn($sqlRowCount,
$sqlParameters, 0);
if ($this-rowCount = 0)
return new \EmptyIterator();
// potential to reduce result set?
if ($this-rowCount $this-tupleCount !$this-groupBy) {
$packageSize = floor($this-rowCount / $this-tupleCount);
// worth doing - go
if ($packageSize 1) {
$this-rowCount = floor($this-rowCount / $packageSize);
$this-conn-query('SET @row:=0;');
$sql = 'SELECT MAX(aggregate.timestamp) AS timestamp,
SUM(aggregate.value) AS value, '.$packageSize.' AS count '.
'FROM ('.
'SELECT timestamp, value, @row:=@row+1 AS row '.
' FROM data WHERE channel_id=?' .
$sqlTimeFilter .
') AS aggregate '.
'GROUP BY row DIV ' . $packageSize .' '.
'ORDER BY timestamp ASC;';
}
}
$stmt = $this-conn-executeQuery($sql, $sqlParameters); //
query for data
return new DataIterator($stmt, $this-rowCount, $this-tupleCount);
}
}
Viele Grüße,
Andreas
Re: [vz-dev] Performanceoptimierung MeterInterpreter
Hi Jakob, Ich habs gemessen- bringt bei mir (5 Kanäle, Auflösung 5min, Raspi, Zoom aufs Jahr, grosser Monitor=500 Tupel) 30% schnellere Antworten. Mit dem Umbau auf feste Zeiträume wärs kein Thema mehr, habe es allerdings nicht geschafft, das elegant in SQL zu realisieren. Wenn Du da eine Idee hast helfe ich gerne. Diff/ Pull Request ist kein Problem, wollte aber abwarten obs jemanden interessiert. Viele Grüsse, Andreas On 24.04.2013 18:47, Jakob Hirsch wrote: Andreas Goetz, 24.04.2013 17:31: beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das Frontend kann ja eh nicht mehr darstellen. müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese auch erstmal aus MySQL abgeholt werden. Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist, weil alle rows erstmal von der Platte gelesen werden müssen. Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren. Die untenstehende Methode erledigt das und kann in MeterInterpreter eingefügt werden (siehe unterer Teil nach EmptyIterator). Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist das allerdings auch nicht gerade hochperformant gelöst (mit callbacks und Interface-Klasse). Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt anders ist. Hast du denn mal gemesen, ob's damit wirklich signifikant schneller geht? Also ein time curl 'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440tuples=100' mit beiden Methoden (mehrmals ausgeführt). Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau steht schon länger auf meiner Liste. Das könnte man aber allerdings auch mit SQL machen
Re: [vz-dev] Bearbeitung von Gruppenkontexten?
Problem gelöst- Ursache ist natürlich die EntityDefinition. Behelfsweise
nehme ich jetzt einfach das description property zum testen...
On 26.04.2013 11:44, Andreas Goetz wrote:
Hallo Zusammen,
ich versuche gerade mit Hilfe von Gruppenkontexten meine Idee der
virtuellen Kanäle zu realisieren. Bisher ist es mir gelungen, über
das API eine Gruppe anzulegen und Kanäle zuzuordnen:
{
version: 0.2,
entity: {
uuid: c95f53e0-ae51-11e2-bed8-6b20ada53128,
type: group,
title: Group 1,
children: [
{
uuid: 82fb2540-60df-11e2-8a9f-0b9d1e30ccc6,
type: power,
color: lightblue,
public: true,
resolution: 1000,
style: lines,
title: Lieferung },
{
uuid: 8f20eb60-60df-11e2-81a1-3d3ab836429e,
type: power,
color: blue,
public: true,
resolution: 75,
style: lines,
title: Erzeugung }
]
}
}
Jetzt würde ich zu der bestehenden Gruppe gerne ein Attribut als
Rechenregel hinzufügen:
http://localhost/vz/middleware.php/group/c95f53e0-ae51-11e2-bed8-6b20ada53128.json?op=rechenoperationoperation=edit
Gemäß Referenz sollte es möglich sein, Eigenschaften (=properties)
einer Gruppe zu bearbeiten. Leider läufts auf einen Fehler:
{ version: 0.2, exception: { message: Unknown property:
'op', type: Exception, code: 0 } }
Habe ich hier die Referenz falsch verstanden oder bezieht sich die
Möglichkeit Eigenschaften zu bearbeiten nur auf vordefinierte
Eigenschaften?
Viele Grüße,
Andreas
Re: [vz-dev] Performanceoptimierung MeterInterpreter
Ich hab's Dir mal als Pull Request verpackt: https://github.com/jahir/volkszaehler.org/pull/1 vg Andreas On 24.04.2013 18:47, Jakob Hirsch wrote: Andreas Goetz, 24.04.2013 17:31: beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das Frontend kann ja eh nicht mehr darstellen. müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese auch erstmal aus MySQL abgeholt werden. Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist, weil alle rows erstmal von der Platte gelesen werden müssen. Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren. Die untenstehende Methode erledigt das und kann in MeterInterpreter eingefügt werden (siehe unterer Teil nach EmptyIterator). Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist das allerdings auch nicht gerade hochperformant gelöst (mit callbacks und Interface-Klasse). Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt anders ist. Hast du denn mal gemesen, ob's damit wirklich signifikant schneller geht? Also ein time curl 'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440tuples=100' mit beiden Methoden (mehrmals ausgeführt). Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau steht schon länger auf meiner Liste. Das könnte man aber allerdings auch mit SQL machen .
Re: [vz-dev] Performanceoptimierung MeterInterpreter
Ich hab's Dir mal als Pull Request verpackt: https://github.com/jahir/volkszaehler.org/pull/1 vg Andreas On 24.04.2013 18:47, Jakob Hirsch wrote: Andreas Goetz, 24.04.2013 17:31: beim Testen von VZ auf dem eher schwachbrüstigen Raspberry Pi ist mir aufgefallen, dass Anfragen des Frontends nach einer bestimmten Anzahl von Tupeln bei niedrigen Zoomstufen dadurch beantwortet werden, dass der Interpreter durch alle Rows eines Resultsets läuft und diese gem. mit Hilfe von packageSize auf die gewünschte Anzahl Tupel aggregiert. Dabei Ja, damit nur die benötigte Anzahl von Tupeln übertragen werden muß. Das Frontend kann ja eh nicht mehr darstellen. müssen zum einen recht viele Daten verarbeitet werden, zum anderen diese auch erstmal aus MySQL abgeholt werden. Ja. Wobei das Problem dabei, wie bei Datenbanken meistens, die IO ist, weil alle rows erstmal von der Platte gelesen werden müssen. Alternativ lassen sich die Daten jedoch bereits in MySQL aggregieren. Die untenstehende Methode erledigt das und kann in MeterInterpreter eingefügt werden (siehe unterer Teil nach EmptyIterator). Insofern ist es fraglich, ob das so wirklich schneller geht. In PHP ist das allerdings auch nicht gerade hochperformant gelöst (mit callbacks und Interface-Klasse). Ein diff wäre übrigens nett, dann muß man nicht raussuchen, was da jetzt anders ist. Hast du denn mal gemesen, ob's damit wirklich signifikant schneller geht? Also ein time curl 'http://localhost/volkszaehler/middleware.php/data/deine-UUID.json?from=136675440tuples=100' mit beiden Methoden (mehrmals ausgeführt). Abgesehen davon ist die aktuelle Implementierung sowieso nicht ganz korrekt. Statt einer festen Anzahl von Rows pro Tupel müßte man sinnvollerweise feste Zeiträume zusammenfassen. Der entsprechende Umbau steht schon länger auf meiner Liste. Das könnte man aber allerdings auch mit SQL machen .
Re: [vz-dev] SolaranaLyzer - Daten aus der Api
Wäre interessant zu sehen mit welchem Request der SA die Daten abholt. Kannst Su das z. B. in /var/log/apache2/access.log sehen? Von meinem iPhone gesendet Am 01.05.2013 um 10:46 schrieb sollner11 p...@macpat.de mailto:p...@macpat.de: Hallo, ein Schönheitsfehler ist zu verzeichnen: die Daten werden vom Solaranalyzer dargestellt und ausgewertet dabei habe ich wohl ein Problem ... die timestamps wandern werden also nicht immer zur gleichen Sekunde genommen und auch nicht alle 60 sec kann das sein? damit ich nicht zuviel kB poste hier ein Link, wie das aussieht: http://www.photovoltaikforum.com/volkszaehler-org-f131/aggregierung-von-daten-im-vzlogger-t90247.html ganz hinten was kann man da machen? kann ich die aggtime auf tatsächlich z.B. 300 sec setzen, z.B. mit Startwert 00:00:00 00:05:00 00:10:00 usw.? Danke und Gruss warum auch immer Am 21.04.2013 um 11:32 schrieb sollner11 p...@macpat.de mailto:p...@macpat.de: ok, Daten kommen fein im Minutentakt läuft einwandfrei Raspi langweilt sich ;-) Danke nochmal. Das ist die Darstellung der middleware. Die Daten die eingeliefert werden und in der DB gespeichert sind immer Roh-werte X zum Zeitpunkt Y. Wenn Du Dir die Daten in der DB Anschaust siehst du deine Zählerstände keine Leistung. passt und wäre ok Die middleware macht dann aus Zählerstandsänderung in eine Zeitraum die Leistungsanzeige. @all und es gibt keine Möglichkeit die in der DB abgelegten Zählerstände auch als Zählerstände per Api rauszubekommen? Danke und Gruss
Re: [vz-dev] Welche 2-Richtungs-Zähler verbaut EON in Leipzig?
On 08.05.2013 22:00, Udo1 wrote: Siehe Betreff. Danke Udo Wieso EON? Ist der Netzbetreiber nicht Netz Leipzig?
[vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ power meter?
Cross-post von volkszaehler-users
Hallo,
für meine Monitoring App http://github.com/andig/vzmon versuche ich die
Erzeugung des Tages (Mitternacht bis jetzt) auszusummieren. Für Kanäle vom
Typ Power klappt das wunderbar:
http://ip/middleware.php/data/kanalid.json?fomr=todayto=nowtuples=1,
dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:
Kanal:
http://ip/middleware.php/channel.json
{version:0.2,channels:[
{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,type:electric
meter,active:true,color:gold,public:true,resolution:1000,style:steps,title:Erzeugung
2.8.0},
Daten:
http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=todayto=nowtuples=1
{version:0.2,
data:
{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,
from:137349300,
to:137356350,
average:0,
consumption:0,
rows:236}}
Consumption bleibt hier 0 obwohl rows=236 und größer werdende Zählerstände
erfasst sind??
Mit 1 Tupeln:
http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=todayto=nowtuples=1
0
{version:0.2,data:{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,from:137349300,to:137356350,min:
[137349990,57.878],max:
[137356200,16237.989],average:3645.213,consumption:71385.42,rows:236,tuples:
[[137349990,57.878,23],
[137352060,1248.973,23],...
Wird tuples komplett weggelassen so stimmt die ermittelte consumption nach
erster Analyse.
Meine Frage: funktioniert consumption bei diesem Kanaltyp anders oder ist
das evtl. ein Bug in der Ermittlung der Consumption bei diesem Kanaltyp?
Viele Grüße,
Andreas
Re: [vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ power meter?
Hallo Zusammen,
es handelt sich um einen Fehler in der MW aufgrund Aggregation von
Tupeln und Skippen des ersten Records.
Vollständiger Patch hier: https://github.com/andig/volkszaehler.org
Nebenbei gibts noch neue Features (database section im
CapabilitiesController) und Performanceverbesserung (Packageaggregation
in MySQL statt PHP).
@Justin: ich kann leider keinen Pull Request stellen da der alte (den
wir jetzt löschen können) noch aktiv ist. Könntest Du den Weg freimachen?
Danke,
Andreas
On 12.07.2013 12:10, Andreas Goetz wrote:
Cross-post von volkszaehler-users
Hallo,
für meine Monitoring App http://github.com/andig/vzmon
http://github.com/andig/vzmon versuche ich die Erzeugung des Tages
(Mitternacht bis jetzt) auszusummieren. Für Kanäle vom Typ Power
klappt das wunderbar:
http://ip/middleware.php/data/kanalid.json?fomr=todayto=nowtuples=1,
dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:
Kanal:
http://ip/middleware.php/channel.json
{version:0.2,channels:[
{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,type:electric
meter,active:true,color:gold,public:true,resolution:1000,style:steps,title:Erzeugung
2.8.0},
Daten:
http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=todayto=nowtuples=1
{version:0.2,
data:
{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,
from:137349300,
to:137356350,
average:0,
consumption:0,
rows:236}}
Consumption bleibt hier 0 obwohl rows=236 und größer werdende
Zählerstände erfasst sind??
Mit 1 Tupeln:
http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=todayto=nowtuples=10
{version:0.2,data:{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,from:137349300,to:137356350,min:
[137349990,57.878],max:
[137356200,16237.989],average:3645.213,consumption:71385.42,rows:236,tuples:
[[137349990,57.878,23],
[137352060,1248.973,23],...
Wird tuples komplett weggelassen so stimmt die ermittelte consumption
nach erster Analyse.
Meine Frage: funktioniert consumption bei diesem Kanaltyp anders
oder ist das evtl. ein Bug in der Ermittlung der Consumption bei
diesem Kanaltyp?
Viele Grüße,
Andreas
[vz-dev] Bug: CapabilitiesController ignoriert section parameter
Bei dem Versuch, den CapabilitiesController um Statusinformationen zur
Datenbank zu erweitern ist mir aufgefallen, dass der
CapabilitiesControllerdie übergebene section nicht verarbeitet
(section=null).
So liefert
http://../middleware.php/capabilities.json?section=configuration immer
alle sections zurück.
Vermutung: analog DataController muss die section per
$this-view-request-getParameter('section'); ermittelt werden da sie
nicht direkt in im get-Aufruf übergeben wird.
Wenn gefixt liesse sich dann auch die Datenbankgröße gezielt abfragen:
if (is_null($section) || $section == 'database') {
$conn = $this-em-getConnection(); // get dbal connection
from EntityManager
$sql = 'SELECT ('.
'SELECT count(1) '.
'FROM data'.
') AS rows, ('.
'SELECT sum(data_length + index_length) '.
'FROM information_schema.TABLES '.
'WHERE table_schema = ?'.
') AS size';
$res = $conn-fetchArray($sql,
array(Util\Configuration::read('db.dbname')));
$capabilities['database'] = array(
'rows' = $res[0],
'size' = $res[1]
);
}
Wer kann meine Vermutung bestätigen und wohin darf ich den Patch schicken?
vg
Andreas
Re: [vz-dev] Bug: CapabilitiesController ignoriert section parameter
Mein Fehler. Natürlich muss der Aufruf so lauten:
http://localhost/vz/middleware.php/capabilities/database.json
ergibt
{version:0.2,capabilities:{database:{rows:70990,size:5858562}}}
Damit kann ich den Patch für die neue database Section stellen. Wohin damit?
vg
Andreas
On 28.07.2013 12:51, Andreas Goetz wrote:
Bei dem Versuch, den CapabilitiesController um Statusinformationen zur
Datenbank zu erweitern ist mir aufgefallen, dass der
CapabilitiesControllerdie übergebene section nicht verarbeitet
(section=null).
So liefert
http://../middleware.php/capabilities.json?section=configuration immer
alle sections zurück.
Vermutung: analog DataController muss die section per
$this-view-request-getParameter('section'); ermittelt werden da sie
nicht direkt in im get-Aufruf übergeben wird.
Wenn gefixt liesse sich dann auch die Datenbankgröße gezielt abfragen:
if (is_null($section) || $section == 'database') {
$conn = $this-em-getConnection(); // get dbal connection
from EntityManager
$sql = 'SELECT ('.
'SELECT count(1) '.
'FROM data'.
') AS rows, ('.
'SELECT sum(data_length + index_length) '.
'FROM information_schema.TABLES '.
'WHERE table_schema = ?'.
') AS size';
$res = $conn-fetchArray($sql,
array(Util\Configuration::read('db.dbname')));
$capabilities['database'] = array(
'rows' = $res[0],
'size' = $res[1]
);
}
Wer kann meine Vermutung bestätigen und wohin darf ich den Patch
schicken?
vg
Andreas
Re: [vz-dev] Fwd: [vz-users] MW consumption für Kanäle vom Typ power meter?
Hallo Zusammen,
ich habe die ganzen Optimierungen in einen Patch verpackt:
https://github.com/volkszaehler/volkszaehler.org/pull/47
Viele Grüße,
Andreas
On 25.07.2013 13:53, Andreas Goetz wrote:
Hallo Zusammen,
es handelt sich um einen Fehler in der MW aufgrund Aggregation von
Tupeln und Skippen des ersten Records.
Vollständiger Patch hier: https://github.com/andig/volkszaehler.org
Nebenbei gibts noch neue Features (database section im
CapabilitiesController) und Performanceverbesserung
(Packageaggregation in MySQL statt PHP).
@Justin: ich kann leider keinen Pull Request stellen da der alte (den
wir jetzt löschen können) noch aktiv ist. Könntest Du den Weg freimachen?
Danke,
Andreas
On 12.07.2013 12:10, Andreas Goetz wrote:
Cross-post von volkszaehler-users
Hallo,
für meine Monitoring App http://github.com/andig/vzmon
http://github.com/andig/vzmon versuche ich die Erzeugung des Tages
(Mitternacht bis jetzt) auszusummieren. Für Kanäle vom Typ Power
klappt das wunderbar:
http://ip/middleware.php/data/kanalid.json?fomr=todayto=nowtuples=1,
dann consumption auslesen. Für Kanäle vom Typ Power Meter klappts nicht:
Kanal:
http://ip/middleware.php/channel.json
{version:0.2,channels:[
{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,type:electric
meter,active:true,color:gold,public:true,resolution:1000,style:steps,title:Erzeugung
2.8.0},
Daten:
http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=todayto=nowtuples=1
{version:0.2,
data:
{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,
from:137349300,
to:137356350,
average:0,
consumption:0,
rows:236}}
Consumption bleibt hier 0 obwohl rows=236 und größer werdende
Zählerstände erfasst sind??
Mit 1 Tupeln:
http://ip/middleware.php/data/5b340280-9248-11e2-bf0b-adb29ee33b6f.json?from=todayto=nowtuples=10
{version:0.2,data:{uuid:5b340280-9248-11e2-bf0b-adb29ee33b6f,from:137349300,to:137356350,min:
[137349990,57.878],max:
[137356200,16237.989],average:3645.213,consumption:71385.42,rows:236,tuples:
[[137349990,57.878,23],
[137352060,1248.973,23],...
Wird tuples komplett weggelassen so stimmt die ermittelte consumption
nach erster Analyse.
Meine Frage: funktioniert consumption bei diesem Kanaltyp anders
oder ist das evtl. ein Bug in der Ermittlung der Consumption bei
diesem Kanaltyp?
Viele Grüße,
Andreas
Re: [vz-dev] Neues Projekt Ferrariszählerkopf
Hallo Zusammen, ich lese selber einen Ferrarisstromzähler per Fotodiode und TIA aus- ziemlich aufwändige Schaltung für ein einfaches Problem :/ Empfehlen kann ich http://www.zabex.de/site/gaswasserstrom.html da die Lösung dank Fototransistor wesentlich weniger störanfällig ist. Prinzipirll stelle ich mir vor mein aktuelles Setup aus Raspi + Erweiterungsplatinie durch Raspi + Arduino für die Messwerterfassung mittels Analogeingängen zu ersetzen und dann mit weniger Bauteilen mehr Zähler (also auch Strom und Gas) erfassen zu können. Im VZ landen die Daten mittels eigenen Skriptes. FAST scheint eine sehr spannende Alternative zu sein- was kosten denn die Dinger? vg Andreas 2013/8/21 Franz Datzer franz.dat...@datzer.net Servus Jens, auf wiki.volkszaehler.org bist Du sicher schon über diese Seite http://wiki.volkszaehler.org/**hardware/controllers/** ferrariszaehler_lesekopfhttp://wiki.volkszaehler.org/hardware/controllers/ferrariszaehler_lesekopf gestolpert. Leider noch nicht fertig. Udo arbeitet noch dran. Ich habe für meinen Ferraris folgende Lösung gefunden und nutze diese aktuell: http://www.fastforward.ag Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von Udo geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern wertet das Zählwerk aus. Das Funktioniert auch soweit nur mit den Nachkommastellen hapert es. Für das Stromauge sind Sourcen auf Git-Hub verfügbar die ich auf einem raspi nutze. Allerdings nicht per vzlogger sondern mit einem shell-script. Das Stromauge sollte auch mit einem Balgengaszähler funktionieren, soweit bin ich aber noch nicht. Also einen Interessenten (allerdings ohne technische Kenntnisse) hast Du auf jeden Fall. Gruß Franz Jens Schmelkus schrieb: Hallo Zusammen, Mein Name ist Jens Schmelkus und ich studiere in München Maschinenbau. Vor kurzem bin ich auf die Volkszaehler-page gestoßen und habe seitdem ein neues Projekt. :) Ich habe die Technischen Möglichkeiten Bauteile und Platinen zu Ätzen, Löten,Fräsen etc. Mein Ziel ist es unser Haus mit einem Logger für je Wasser, Gas und Strom auszustatten und an meinen Linux- Bladeserver anzuschließen. Der Stromzähler ist noch ein Antiker Ferraris-Zähler. Daher meine Frage. Wie steht es um die Entwicklung des Ferrariszählerkopfes ? Gibt es schon Target Dateien oder Schaltpläne die ich ausprobieren könnte ? Dankeschön schonmal. Mit freundlichem Gruß Jens
[vz-dev] Fwd: Neues Projekt Ferrariszählerkopf
Hallo Zusammen, ich lese selber einen Ferrarisstromzähler per Fotodiode und TIA aus- ziemlich aufwändige Schaltung für ein einfaches Problem :/ Empfehlen kann ich http://www.zabex.de/site/gaswasserstrom.html da die Lösung dank Fototransistor wesentlich weniger störanfällig ist. Prinzipirll stelle ich mir vor mein aktuelles Setup aus Raspi + Erweiterungsplatinie durch Raspi + Arduino für die Messwerterfassung mittels Analogeingängen zu ersetzen und dann mit weniger Bauteilen mehr Zähler (also auch Strom und Gas) erfassen zu können. Im VZ landen die Daten mittels eigenen Skriptes. FAST scheint eine sehr spannende Alternative zu sein- was kosten denn die Dinger? vg Andreas 2013/8/21 Franz Datzer franz.dat...@datzer.net Servus Jens, auf wiki.volkszaehler.org bist Du sicher schon über diese Seite http://wiki.volkszaehler.org/**hardware/controllers/** ferrariszaehler_lesekopfhttp://wiki.volkszaehler.org/hardware/controllers/ferrariszaehler_lesekopf gestolpert. Leider noch nicht fertig. Udo arbeitet noch dran. Ich habe für meinen Ferraris folgende Lösung gefunden und nutze diese aktuell: http://www.fastforward.ag Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von Udo geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern wertet das Zählwerk aus. Das Funktioniert auch soweit nur mit den Nachkommastellen hapert es. Für das Stromauge sind Sourcen auf Git-Hub verfügbar die ich auf einem raspi nutze. Allerdings nicht per vzlogger sondern mit einem shell-script. Das Stromauge sollte auch mit einem Balgengaszähler funktionieren, soweit bin ich aber noch nicht. Also einen Interessenten (allerdings ohne technische Kenntnisse) hast Du auf jeden Fall. Gruß Franz Jens Schmelkus schrieb: Hallo Zusammen, Mein Name ist Jens Schmelkus und ich studiere in München Maschinenbau. Vor kurzem bin ich auf die Volkszaehler-page gestoßen und habe seitdem ein neues Projekt. :) Ich habe die Technischen Möglichkeiten Bauteile und Platinen zu Ätzen, Löten,Fräsen etc. Mein Ziel ist es unser Haus mit einem Logger für je Wasser, Gas und Strom auszustatten und an meinen Linux- Bladeserver anzuschließen. Der Stromzähler ist noch ein Antiker Ferraris-Zähler. Daher meine Frage. Wie steht es um die Entwicklung des Ferrariszählerkopfes ? Gibt es schon Target Dateien oder Schaltpläne die ich ausprobieren könnte ? Dankeschön schonmal. Mit freundlichem Gruß Jens
Re: [vz-dev] Neues Projekt Ferrariszählerkopf
PS.: es lohnt sich auch hier querzulesen: http://www.photovoltaikforum.com/volkszaehler-org-f131/welcher-ir-schreib-lesekopf-und-woher-zu-beziehen-t92007.html 2013/8/21 Andreas Goetz cpui...@gmx.de Hallo Zusammen, ich lese selber einen Ferrarisstromzähler per Fotodiode und TIA aus- ziemlich aufwändige Schaltung für ein einfaches Problem :/ Empfehlen kann ich http://www.zabex.de/site/gaswasserstrom.html da die Lösung dank Fototransistor wesentlich weniger störanfällig ist. Prinzipirll stelle ich mir vor mein aktuelles Setup aus Raspi + Erweiterungsplatinie durch Raspi + Arduino für die Messwerterfassung mittels Analogeingängen zu ersetzen und dann mit weniger Bauteilen mehr Zähler (also auch Strom und Gas) erfassen zu können. Im VZ landen die Daten mittels eigenen Skriptes. FAST scheint eine sehr spannende Alternative zu sein- was kosten denn die Dinger? vg Andreas 2013/8/21 Franz Datzer franz.dat...@datzer.net Servus Jens, auf wiki.volkszaehler.org bist Du sicher schon über diese Seite http://wiki.volkszaehler.org/**hardware/controllers/** ferrariszaehler_lesekopfhttp://wiki.volkszaehler.org/hardware/controllers/ferrariszaehler_lesekopf gestolpert. Leider noch nicht fertig. Udo arbeitet noch dran. Ich habe für meinen Ferraris folgende Lösung gefunden und nutze diese aktuell: http://www.fastforward.ag Das Stromauge arbeitet mit einer OCR - Einheit die nicht wie der von Udo geplante Lesekopf die Umdrehungen der Drehscheibe auswertet sondern wertet das Zählwerk aus. Das Funktioniert auch soweit nur mit den Nachkommastellen hapert es. Für das Stromauge sind Sourcen auf Git-Hub verfügbar die ich auf einem raspi nutze. Allerdings nicht per vzlogger sondern mit einem shell-script. Das Stromauge sollte auch mit einem Balgengaszähler funktionieren, soweit bin ich aber noch nicht. Also einen Interessenten (allerdings ohne technische Kenntnisse) hast Du auf jeden Fall. Gruß Franz Jens Schmelkus schrieb: Hallo Zusammen, Mein Name ist Jens Schmelkus und ich studiere in München Maschinenbau. Vor kurzem bin ich auf die Volkszaehler-page gestoßen und habe seitdem ein neues Projekt. :) Ich habe die Technischen Möglichkeiten Bauteile und Platinen zu Ätzen, Löten,Fräsen etc. Mein Ziel ist es unser Haus mit einem Logger für je Wasser, Gas und Strom auszustatten und an meinen Linux- Bladeserver anzuschließen. Der Stromzähler ist noch ein Antiker Ferraris-Zähler. Daher meine Frage. Wie steht es um die Entwicklung des Ferrariszählerkopfes ? Gibt es schon Target Dateien oder Schaltpläne die ich ausprobieren könnte ? Dankeschön schonmal. Mit freundlichem Gruß Jens
Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Ich hatte ähnliche Probleme- Grund dabei war allerdings 1s Connect Time für MySQL. Warum gehst Du für die Abfragen eigentlich nicht über die Middleware? Dann klappts auch für alle Sensortypen! vg Andreas 2013/9/14 Florian Knodt f.kn...@yotaweb.de Auch kann es helfen ein explain vor den SQL-Befehl zu setzen und sich die Analyse anzusehen - da sieht man recht schnell ob Teile ohne Index ablaufen, was meist in langsamen Abfragen endet. -- Mit freundlichen Grüßen || Sincerely yours Florian Knodt ·· Im Teich 11 ·· 56648 Saffig www.adlerweb.info · www.56648.de · @adlerweb
Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Hallo Sven, sowas in der Form sollte helfen: http://host/middleware.php/data/8f20eb60-60df-11e2-81a1-3d3a387429e.json?from=now vg Andreas 2013/9/15 Sven peitz sven.pe...@gmx.net Hallo, leider kann ich derzeit nicht weiter testen, weil mein Provider den Zugriff wegen zu hoher SQL Last gesperrt hat. ;-( [X] MySQL-Last (Wartezeit auf Festplattenzugriff) [X] MySQL-Last lesend (SELECT-Statements) [X] Kontinuierlich hohe Last Also sind die 6 Sekunden verursacht durch Auslastung des Servers. Dem Vorschlag kann ich jetzt nicht folgen. SQL ist nicht mein täglich Brot ;-) Select value where channel order by id desc limit 1 Aber den Vorschlag über die Middleware zu gehen würde ich gerne aufgreifen wenn ich wüsste wie. Eigentlich brauche ich ja nur den zuletzt in der Datenbank eingetragenen Wert zur ID. Ich muss jetzt aber erst mal warten bis der Zugriff wieder frei ist. Gruß Sven Am 14.09.2013 11:40, schrieb Thorben Thuermer: On Sat, 14 Sep 2013 11:07:20 +0200 Sven peitz sven.pe...@gmx.net sven.pe...@gmx.net wrote: für mein neues Verbrauchs oder Vergleichsanzeige Projekt der aktuellen PV Einspeisung und Bezug vom EVU frage ich in einem PHP script die Volkszähler Datenbank ab. [...] $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id) FROM data WHERE channel_id LIKE '14')); auch zu beachten, was genau in data.value steht ist vom channel-type abhaengig... diese loesung funktioniert nur, wenn leistungswerte geloggt werden. Diese Anfrage dauert ca. 6-7 Sekunden. Hat jemand eine Idee wie man dieses beschleunigen kann? die anfrage ohne subquery formulieren? (subqueries sind fuer nicht sql-er zwar oft intuitiver, aber meist nicht effizient.) select value where channel order by id desc limit 1 Gruß Sven - Thorben
Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Hallo Thorben, 2013/9/16 Thorben Thuermer r...@constancy.org On Mon, 16 Sep 2013 14:01:31 +0200 Jakob Hirsch j...@plonk.de wrote: Sven peitz, 2013-09-14 11:07: $result1=mysql_query(SELECT value FROM data WHERE id = (select max(id) FROM data WHERE channel_id LIKE '14'));... Allerdings sollte man nicht ohne Grund direkt auf der DB arbeiten. Das Vorgehen wie von Andreas Götz ist auch deutlich einfacher (Abfrage mit from=now). from=now... funktioniert doch aber wie gehabt nur bei erfassung absoluter staende. ansonsten war die methode doch from=x seconds ago...? also so, dass im im angegebenen zeitraum (mit now = nur aktuelle sekunde) genug werte erfasst sind, damit der interpreter in der middleware daraus etwas berechnen kann. also bei s0-zaehlern mindestens zwei impulse, etc... oder wurde da middleware-seitig was geandert? - Thorben Das sollte funktionieren da die MW (schon immer?) mittels zweier SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des angefragten Zeitraumes ermitteln und from... to... entsprechend erweitern. Für now() gäbe es also immer den aktuellen und letzten Timestamp und damit die Möglichkeit einen aktuellen Periodenverbrauch zu berechnen. vg Andreas
Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Hi Sven,hast Du den aktuellen Stand aus dem Git? Wenn ja- um welchen
Sensortyp handelt es sich?
vg
Andreas
2013/9/17 Sven peitz sven.pe...@gmx.net
Am 16.09.2013 20:45, schrieb Andreas Goetz:
Hallo Rainer,
2013/9/16 Rainer Gauweiler volkszaeh...@moppl.inka.de
Hallo zusammen,
Am 16.09.2013 16:41, schrieb Andreas Goetz:
Hallo Thorben,
2013/9/16 Thorben Thuermer r...@constancy.org mailto:
r...@constancy.org
On Mon, 16 Sep 2013 14:01:31 +0200
Jakob Hirsch j...@plonk.de mailto:j...@plonk.de wrote:
Sven peitz, 2013-09-14 11:07:
$result1=mysql_query(SELECT value FROM data WHERE id = (select
max(id)
FROM data WHERE channel_id LIKE '14'));...
Allerdings sollte man nicht ohne Grund direkt auf der DB
arbeiten. Das
Vorgehen wie von Andreas Götz ist auch deutlich einfacher
(Abfrage mit
from=now).
from=now...
funktioniert doch aber wie gehabt nur bei erfassung absoluter
staende.
ansonsten war die methode doch from=x seconds ago...?
also so, dass im im angegebenen zeitraum (mit now = nur aktuelle
sekunde)
genug werte erfasst sind, damit der interpreter in der middleware
daraus etwas berechnen kann.
also bei s0-zaehlern mindestens zwei impulse, etc...
oder wurde da middleware-seitig was geandert?
- Thorben
Das sollte funktionieren da die MW (schon immer?) mittels zweier
SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
angefragten Zeitraumes ermitteln und from... to... entsprechend
erweitern. Für now() gäbe es also immer den aktuellen und letzten
Timestamp und damit die Möglichkeit einen aktuellen Periodenverbrauch zu
berechnen.
Tut bei mir nicht und tat es noch nie:
{version:0.2,data:{uuid:*snip*,average:0,consumption:0,rows:0}}
Wir hatten da auch auf dem Raspi Probleme und haben damals den Zeitraum
erweitert, damit sicher Daten da waren.
Aber gab es nicht auch kürzlich einen Patch der das Verhalten gebaut
hat? Meine Installation hier ist ca ein Jahr alt.
Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist der
Code noch nicht im Repository angekommen, sondern steht noch in meinem Pull
Request: https://github.com/volkszaehler/volkszaehler.org/pull/47
Das Problem ist, dass die MW ohne diese Fixes je nach Sensortyp auch mal
3 Tuple braucht um etwas sinnvolles zu liefern. Mit Pull Request sind es
immer genau zwei Tupel die benötigt werden, damit klappt dann auch die
Abfrage per now. now - x seconds ist keine allgemeingültige Lösung da
man ja nicht wissen kann wann ein Sensor Daten liefert...
vg
Andreas
Hallo,
vielen Dank für eure Antworten,.
seit eben ist mein sql Zugang beim Provider wieder frei und ich kann
weiter testen.
Ein from=now bringt bei mit folgendes:
{version:0.2,data:{uuid:**snip**,average:0,consumption:0,rows:0}}
Ein select value from data where channel_id=14 order by timestamp desc
limit 1;
ist wirklich schnell und bring den aktuellen Wert zu Tage.
Ich hoffe mein Provider fühlt sich damit nicht wieder überlastet.
Ein from=3seconds%20ago funktioniert auch und ist schnell.
Mal sehen was geschickter Weise zu verwenden ist.
Viele Grüße
Sven
Re: [vz-dev] SQL Abfrage aktueller Verbrauch sehr langsam
Hi Sven,
hast Du den aktuellen Stand aus dem Git? Wenn ja- um welchen Sensortyp
handelt es sich?
vg
Andreas
2013/9/17 Sven peitz sven.pe...@gmx.net
Am 16.09.2013 20:45, schrieb Andreas Goetz:
Hallo Rainer,
2013/9/16 Rainer Gauweiler volkszaeh...@moppl.inka.de
Hallo zusammen,
Am 16.09.2013 16:41, schrieb Andreas Goetz:
Hallo Thorben,
2013/9/16 Thorben Thuermer r...@constancy.org mailto:
r...@constancy.org
On Mon, 16 Sep 2013 14:01:31 +0200
Jakob Hirsch j...@plonk.de mailto:j...@plonk.de wrote:
Sven peitz, 2013-09-14 11:07:
$result1=mysql_query(SELECT value FROM data WHERE id = (select
max(id)
FROM data WHERE channel_id LIKE '14'));...
Allerdings sollte man nicht ohne Grund direkt auf der DB
arbeiten. Das
Vorgehen wie von Andreas Götz ist auch deutlich einfacher
(Abfrage mit
from=now).
from=now...
funktioniert doch aber wie gehabt nur bei erfassung absoluter
staende.
ansonsten war die methode doch from=x seconds ago...?
also so, dass im im angegebenen zeitraum (mit now = nur aktuelle
sekunde)
genug werte erfasst sind, damit der interpreter in der middleware
daraus etwas berechnen kann.
also bei s0-zaehlern mindestens zwei impulse, etc...
oder wurde da middleware-seitig was geandert?
- Thorben
Das sollte funktionieren da die MW (schon immer?) mittels zweier
SQL-Queries den jeweils letzten und nächsten Datenpunkt außer des
angefragten Zeitraumes ermitteln und from... to... entsprechend
erweitern. Für now() gäbe es also immer den aktuellen und letzten
Timestamp und damit die Möglichkeit einen aktuellen Periodenverbrauch zu
berechnen.
Tut bei mir nicht und tat es noch nie:
{version:0.2,data:{uuid:*snip*,average:0,consumption:0,rows:0}}
Wir hatten da auch auf dem Raspi Probleme und haben damals den Zeitraum
erweitert, damit sicher Daten da waren.
Aber gab es nicht auch kürzlich einen Patch der das Verhalten gebaut
hat? Meine Installation hier ist ca ein Jahr alt.
Du hast Recht. Was ich geschrieben habe stimmt zwar, allerdings ist der
Code noch nicht im Repository angekommen, sondern steht noch in meinem Pull
Request: https://github.com/volkszaehler/volkszaehler.org/pull/47
Das Problem ist, dass die MW ohne diese Fixes je nach Sensortyp auch mal
3 Tuple braucht um etwas sinnvolles zu liefern. Mit Pull Request sind es
immer genau zwei Tupel die benötigt werden, damit klappt dann auch die
Abfrage per now. now - x seconds ist keine allgemeingültige Lösung da
man ja nicht wissen kann wann ein Sensor Daten liefert...
vg
Andreas
Hallo,
vielen Dank für eure Antworten,.
seit eben ist mein sql Zugang beim Provider wieder frei und ich kann
weiter testen.
Ein from=now bringt bei mit folgendes:
{version:0.2,data:{uuid:**snip**,average:0,consumption:0,rows:0}}
Ein select value from data where channel_id=14 order by timestamp desc
limit 1;
ist wirklich schnell und bring den aktuellen Wert zu Tage.
Ich hoffe mein Provider fühlt sich damit nicht wieder überlastet.
Ein from=3seconds%20ago funktioniert auch und ist schnell.
Mal sehen was geschickter Weise zu verwenden ist.
Viele Grüße
Sven
Re: [vz-dev] Nach update auf git Version können keine Kanäle hinzugefügt werden.
Gefunden:
in lib/Controller/DataController Zeile 84:
ändere
if ($json['data']) {
in
if (isset($json['data'])) {
Ich schiebe einen Patch nach.
vg
Andreas
2013/9/18 Andreas Götz cpui...@gmail.com
Den Fehler dürfte ich eingebaut haben- autsch! Schaus mir nachher an.
Viele Grüße,
Andreas
Am 18.09.2013 um 06:05 schrieb Sven peitz sven.pe...@gmx.net:
Am 18.09.2013 00:25, schrieb Thorben Thuermer:
On Tue, 17 Sep 2013 23:56:05 +0200 Sven peitz sven.pe...@gmx.net
wrote:
Am 17.09.2013 23:18, schrieb Sven peitz:
gerade mal ein Update gemacht.
Jetzt funktioniert zwar die Abfrage from =now wie sie soll, aber ich
kann keine Kanäle mehr anlegen im GUI/webinterface
Der Button Kanal Hinzufügen lässt sich nicht anklicken und alle
vorher gespeicherten Kanäle zeigt er nicht an.
OK das Problem liegt am Browser, der muss unsichere Scripte zulassen..
dann kann man Kanäle anlegen.
was auch immer unsichere scripte sind?
vlt. lag es auch an alten scripte im cache und ein gruendlicher reload
hilft?
Das mit dem reload(restart) könnte der Schlüssel gewesen sein ;-)
Was aber komisch ist, vzlogger produziert jetzt einen Fehler
POST /middleware.php/data/*snip*.json HTTP/1.1 400 302 -
vzlogger/0.3.3 (libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25
libssh2/1.4.2 librtmp/2.3)
Andere per curl gesendete Daten laufen aber
POST /middleware.php/data/*snip*.json HTTP/1.1 200 192 - -
Woran mag das liegen?
ich vermute die erklaerung im status-text oder body der 404-antwort.
wenn es mit curl funktioniert, kommt der 404 wohl nicht von apache,
sondern vom php-script.
im zweifelsfall vzlogger unter strace -s 999 laufen lassen,
oder die requests mit wireshark/tcpflow/tcpdump mitschneiden...
Gruß
Sven
- Thorben
vzlogger sammelt in der queue und nach dem abschicken kommt es zu
folgendem Fehler
Im Log von vzlogger findet sich folgendes:
Sep 18 05:58:17][chn2] CURL Error from middleware: 'ErrorException':
'Undefined index: data'
[Sep 18 05:58:17][chn2] Waiting 30 secs for next request due to previous
failure
[Sep 18 05:58:17][chn0] CURL Error from middleware: 'ErrorException':
'Undefined index: data'
[Sep 18 05:58:17][chn0] Waiting 30 secs for next request due to previous
failure
[Sep 18 05:58:17][chn1] CURL Error from middleware: 'ErrorException':
'Undefined index: data'
[Sep 18 05:58:17][chn1] Waiting 30 secs for next request due to previous
failure
[Sep 18 05:58:19][mtr0] Updating interval to 2
[Sep 18 05:58:19][chn0] Adding reading to queue (value=3422328.50
ts=1379476699.086)
[Sep 18 05:58:19][chn0] Buffer dump (size=1 keep=300): {3422328.5000,}
Gruß
Sven
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo Zusammen, ich habe mal auf Basis von https://github.com/frasermac/xively-visualizer/eine kleine Visualisierung für alle öffentlichen Kanäle des VZ zusammengedübelt. Wenn man das auf demo.volkszaehler.org zeigen lässt hätten wir damit ein schönes Frontend mit deutlich weniger Code (und ein paar weniger Fähigkeiten) als das richtige Frontend. Das könnte eine schöne Basis für eigene Weiterentwicklungen der Community sein. Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas einbringen kann und das sich vielleicht generell etwas interaktionsfreudiger gitb als die aktuelle Struktur: - mehr Committer - mehr Unterrepositories die eine Zusammenarbeit erlauben - schnellere Bearbeitung von requests - Nutzung der github Issues Wie siehts aus? vg Andreas 2013/9/24 Patrik Karisch patrik.kari...@gmail.com Hi Am 23. September 2013 20:15 schrieb W3ll Schmidt w3llschm...@gmail.com: Haste mal überflogen? http://sqlite.org/speed.html Das sqlite generell schneller ist, ist sowieso klar. Besonders auf dem RPi dürften die Faktoren noch größer sein, da dieses nicht für MySQL geeignet ist. Mir ging es eher darum, ob wirklich Doctrine signifikante Performanceeinbußen hervorruft, oder ob es einfach nur der MySQL ist. LG Patrik
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo, 2013/9/24 W3ll Schmidt w3llschm...@gmail.com Am 24. September 2013 14:35 schrieb Patrik Karisch patrik.kari...@gmail.com: geäußert. Auch W3ll Schmidt ist mit noch eine Antwort schuldig, warum seine Repos nicht in der Volkszählergruppe auf GitHub sind ^-^ LG Patrik Ähmm, ehrlich? Naja- vielleicht etwas sehr unglücklich formuliert- von schulden kann man sicher nicht sprechen. Aber es ist aus meiner Erfahrung schon so, dass VZ sich relativ unnahbar darstellt. Das sage ich trotz eigenem Git Account und seit mehreren Jahren aktiv betriebenen Open Source Projekten. Jetzt scheint es ein paar neue Leute zu geben die sich ebenfalls engagieren möchten. Die Frage ist in welchem Rahmen und mit welchen Rechten- oder ob überhaupt Interesse besteht. Die eher verhaltene Diskussion zeigt vielleicht auch, dass die Maintainer mit dem Stand von VZ eigentlich ganz zufrieden sind und tatsächlich gar keinen großen Änderungsbedarf sehen? vg Andreas
[vz-dev] Entitydefinition: Wo sind die Einheiten?
Hallo Zusammen, ich beschäftige mich jetzt seit einiger Zeit mit der Visualisierung von VZ-Daten (Stichwort VZmon App). Jetzt bin ich darüber gestolpert, dass wir zwar allerlei Präsentationsparameter (steps, color) in den Entities speicher, bzgl. der physischen Eigenschaften aber ziemlich blank sind, u.a. fehlen hier ganz banal die Einheiten. Da ich mich mit den Doctrine Entity Definitionen nicht gut genug auskenne um dafür eine Erweiterung zu bauen bin ich auf Hilfe angewiesen. Gibts dafür Interesse/ Unterstützung? vg Andreas
[vz-dev] JSONP exception handling
Hallo Zusammen, wenn in der MW eine Exception auftritt wird diese vom JSON view an den Aufrufer zurückgesandt (z.B. invalid uuid). Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das JSONP Skript von remote gar nicht erst ausgeführt wird. Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? Das Frontend wäre von dieser Änderung nicht betroffen- hier werden Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen habe. +1 für den Patch von mir- was meint Ihr? vg Andreas PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen.
Re: [vz-dev] JSONP exception handling
Hallo Patrick, das kann alles sein. Da wir Clients mit JSON(P) haben würde ich jetzt aber gerne erstmal das Problem lösen. CORS zusätzlich zu implementieren ist eine nette Aufgabe die ich ebenfalls übernehmen würde. vg Andreas 2013/9/26 Patrik Karisch patrik.kari...@gmail.com Servus, Eine gnereller Responsecode von 200 widerspricht aber grob REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, dann benötigt es kein JSONP mehr. Am 26.09.2013 13:33 schrieb Andreas Goetz cpui...@gmail.com: Hallo Zusammen, wenn in der MW eine Exception auftritt wird diese vom JSON view an den Aufrufer zurückgesandt (z.B. invalid uuid). Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das JSONP Skript von remote gar nicht erst ausgeführt wird. Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? Das Frontend wäre von dieser Änderung nicht betroffen- hier werden Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen habe. +1 für den Patch von mir- was meint Ihr? vg Andreas PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen.
Re: [vz-dev] JSONP exception handling
Moin, das ging tatsächlich verblüffend einfach- deshalb hab ich mir die Freiheit genommen die 5 geänderten Teilen in einen Pullrequest zu packen: The following changes since commit 1670af32d3986887f754ad785628b003243cf3cf: Fix JSONP exception handling and add CORS support Also fixed an artifact in AggregatorInterpreter (2013-09-26 20:42:29 +0200) are available in the git repository at: htto://github.com/volkszaehler/volkszaehler.org for you to fetch changes up to 1670af32d3986887f754ad785628b003243cf3cf: Fix JSONP exception handling and add CORS support Also fixed an artifact in AggregatorInterpreter (2013-09-26 20:42:29 +0200) Wie siehts denn mit VZ_VERSION aus- wollen wir auf 0.3 gehen? Damit könnte ich das Dokuupdate im Wiki sauber einem Releasestand zuordnen? vg Andreas 2013/9/26 Thorben Thuermer r...@constancy.org On Thu, 26 Sep 2013 16:26:19 +0200 Patrik Karisch patrik.kari...@gmail.com wrote: Eine gnereller Responsecode von 200 widerspricht aber grob REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, dann benötigt es kein JSONP mehr. OK, wir bekommen dann also zwei patches, einen von Andreas um bei jsonp fehlermeldungen als 200/OK auszuliefern, einen von Patrick fuer das viel elegantere CORS; desweiteren bringt Patrick allen unseren (l)usern bei, ihren webserver entsprechend zu konfigurieren, und kuemmert sich um alle anfallenden support-anfragen diesbezueglich. - Thorben Am 26.09.2013 13:33 schrieb Andreas Goetz cpui...@gmail.com: Hallo Zusammen, wenn in der MW eine Exception auftritt wird diese vom JSON view an den Aufrufer zurückgesandt (z.B. invalid uuid). Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das JSONP Skript von remote gar nicht erst ausgeführt wird. Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? Das Frontend wäre von dieser Änderung nicht betroffen- hier werden Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen habe. +1 für den Patch von mir- was meint Ihr? vg Andreas PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen.
Re: [vz-dev] Entitydefinition: Wo sind die Einheiten?
Wieder was gelernt- das reicht tatsächlich, also nix neues benötigt, danke! 2013/9/27 Thorben Thuermer r...@constancy.org On Tue, 24 Sep 2013 18:04:32 +0200 Andreas Goetz cpui...@gmail.com wrote: ich beschäftige mich jetzt seit einiger Zeit mit der Visualisierung von VZ-Daten (Stichwort VZmon App). Jetzt bin ich darüber gestolpert, dass wir zwar allerlei Präsentationsparameter (steps, color) in den Entities speicher, bzgl. der physischen Eigenschaften aber ziemlich blank sind, u.a. fehlen hier ganz banal die Einheiten. soweit ich das sehe, stehen die einheiten hier (als unit): https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Definition/EntityDefinition.json das sind dann wohl die statischen eigenschaften des entity-typs, und in der datenbank stehen nur die speziellen der jeweiligen instanz? Da ich mich mit den Doctrine Entity Definitionen nicht gut genug auskenne um dafür eine Erweiterung zu bauen bin ich auf Hilfe angewiesen. Gibts dafür Interesse/ Unterstützung? ansonsten auch keine weitere erfahrung damit. vg Andreas - Thorben
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo Torben, 2013/9/27 Thorben Thuermer r...@constancy.org On Tue, 24 Sep 2013 14:35:02 +0200 Patrik Karisch patrik.kari...@gmail.com wrote: Bis jetzt hat sich weder Justin noch Steffen dazu geäußert. damit da mal was zu gesagt wird: justin ist der initiator des projekts, eine antwort von ihm fehlt hier irgendwie, er sagte mir er hat leider gerade keine zeit dafuer/anderes zu tun. steffen ist schon laenger nichtmehr gross im projekt aktiv. Am 24. September 2013 14:07 schrieb Andreas Goetz cpui...@gmail.com: Damit sowas geht bräuchten wir aber ein Repository in dem ich sowas einbringen kann und das sich vielleicht generell etwas interaktionsfreudiger gitb als die aktuelle Struktur:... wenn jemand meint, dass wir mehr brauchen und dass er einer davon ist, wuerde ich vorschlagen justin zu kontaktieren. Dh. außerhalb dieser Liste per Mail? - schnellere Bearbeitung von requests ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet werden/sein sollten. Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne commit, sondern auch ohne Test- weil's einfach niemanden interessiert. Vielleicht könnte ein -dev Zweig helfen solche Probleme wie den eingeführten Fehler abzumildern. ersichtlich ist worum es ueberhaupt geht (commit messages und kommentare helfen!), bin ich auch erstmal skeptisch. wobei aber wohl auch momentan ein allgemeines weiterkommen wichiger ist, als der eine oder andere neue bug. (ein schoenes beispiel war, wie justin zuletzt relativ hektisch Du meinst nach 6 Wochen ist Hektik aufgekommen ;? diesen germerged hatte: https://github.com/volkszaehler/volkszaehler.org/pull/47 und da prompt ein bug drin war, der die api unbrauchbar gemacht hat http://www.mail-archive.com/volkszaehler-dev@lists.volkszaehler.org/msg01921.html und der bei einer kurzen review (justin ist kein programmierer), oder einem test woanders als beim autor, aufgefallen waehre. Korrekt- hat aber keine gemacht :/ (was aber dann ja auch schnell behoben war!) https://github.com/volkszaehler/volkszaehler.org/pull/49 ) So isses. Und um hier aktiv etwas beizutragen: ich habe immer noch einen Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin- die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen... und das problem, dass die aenderungen schnell unuebersichtlich werden, und man sich schwerer tut grosse pull requests zu mergen, als kleinere fixes fuer einfache probleme. Ich bin auch kein Git Experte, hatte aber das Problem dass Github alle meine Commits in den schon bestehenden PR gepackt hat- kleiner ging erstmal nicht... (siehe den herrn hirsch, der herumlurkt und kleine aber wichtige commits blitzartig merged ;) ) ich denke es waehre da sinnvoll aenderungen vorher kurz zu diskutieren, zB hier (oder in den github issues?) und zu einem konsens zu kommen. Mehr als die Sachen per Mail hier anzupreisen kann ich wohl nicht tun. Oder doch? es gab es ja zB den thread Feedback benötigt: vzlogger / aggregation / random meter / sml-pull / s0-meter ( http://article.gmane.org/gmane.network.volkszaehler.devel/1572 ) der leider recht schleppend verlief. die letzte meldung von justin dazu war... http://volkszaehler.org/pipermail/volkszaehler-dev/2013-August/003005.html On Wed, 28 Aug 2013 23:51:03 +0200 Justin Otherguy jus...@justinotherguy.org wrote: korrekt (leider). Die Patches lassen sich nicht g'schwind(TM) mergen. Scheitert an magischen git-Kräften (und der alternativ benötigten Zeit). Falls mir Jemand beispringen möchte: das ist eine gute Gelegenheit! ;-) darauf hatte sich niemand gemeldet... ich werde mir das sonst mal anschauen. - Nutzung der github Issues habe anscheinend nicht die rechte das einzustellen... werde justin mal anhauen, wenn er nicht selber mitliest. - Thorben Logger ist leider nicht mein Thema :( vg Andreas
[vz-dev] Unittests für die Middleware
Hallo Zusammen, unter https://github.com/andig/volkszaehler.org/tree/unittest/test steht ein erster Satz Unit Tests bereit. Getestet werden können damit v.a. die verschiedenen Meter (z.B. DataMeterTest). Das Ganze ist als work in progress zu betrachten, ängst nicht alle Tests sind imlementiert und der Code ist sicher auch nicht so elegant wie die MW selbst. Aktuell baue ich weitere Tests auf um eine Datenaggregation zur Performanceoptimierung einzubauen. Kommentare bitte direkt mittels git issues. vg Andreas
[vz-dev] HUGE performance improvement for grouped queries
Hallo Zusammen! Um der Performance meiner VZ Installation auf dem Raspi etwas nachzuhelfen habe ich Aggregation von Daten als neues Feature zum VZ hinzugefügt. Anstatt wie bei vzcompress2 Daten zu löschen werden diese in einer separaten Tabelle aggregiert- in der aktuellen Version auf Tagesebene. Wenn die MW jetzt Abfragen nach aggregierten Daten stellt, wie z.B. from=1.1.2000 to=now group=month dann werden die SQL statements so umgebaut, dass die Daten aus der Agrgegationstabelle kommen statt aus der Datentabelle. Da hier _deutlich_ weniger Daten liegen gehts natürlich schneller. Bisher nicht implementiert ist ein automatisches Tuning eingehender Anfragen. Wenn z.B. das Frontend obenstehende Anfrage mit tuples=200 ausführt, wird es ohne vzcompress immer noch sehr lange dauern. Denkbar wäre eine Automatik einzubauen die je nach Aggressivität eine Gruppierung nach Tag oder Stunde hinzuschaltet. Added data aggregation: 1. create aggregate table using misc/sql/aggregation.sql 2. run initial aggregation using misc/sql/aggregation.sql 3. set $config['aggregate'] = true in etc/volkszaehler.conf.php 4. setup CRON to run delta aggregation using misc/sql/aggregation.sql https://github.com/andig/volkszaehler.org/tree/aggregate Jetzt würde ich mich über Feedback und vor allem Tests freuen! Gruss, Andreas
Re: [vz-dev] Pfad von doctrine / doctrine Version
Moin *, On 14.10.2013 08:51, jus...@justinotherguy.org wrote: Hi Rainer, Am 13.10.2013 um 16:47 schrieb Rainer Gauweiler: Wir sind darüber gestolpert, dass doctrine manchmal durch einen Symlink eingebunden wird, manchmal durch eine Angabe in der Konfig-Datei. Der Installer tut das eine, die Anleitung zur manuellen Installation beschreibt das andere. Gibt es was, was man bevorzugen sollte? ich persönlich hab mich schon ein paar Mal über die (fehlenden) Links geärgert; mir gefällt die Idee mit dem direkten Verweis auf das lokale Verzeichnis in der Config sehr gut. Und spricht etwas dagegen, das debian-Paket zu verwenden? Dann hätte man auch aktuelle Updates. Zumindest in der Theorie: $ cat /etc/debian_version 7.2 $ dpkg -l | grep doctrine ii doctrine 1.2.4-1all Tool for object-relational mapping in PHP Ist eben Debian - wir verwenden doctrine in Version 2; ansonsten wäre ich mehr als dafür. Gruss, J. Mit aktuellen Doctrine Versionen wird das ganze noch schlimmer das die GIT Repositories jetzt aufgeteilt sind. Einfacher wäre die Installation via composer. Wenn Interesse besteht kann ich einen Patch bereitstellen, die Unit Tests laufen alle auch mit Doctrine 2.4, einem Upgrade sollte also nichts im Weg stehen. vg Andreas
Re: [vz-dev] Auslagern von Initialisierungscode?
Hallo Justin Thorben, hallo *,
2013/10/20 Thorben Thuermer r...@constancy.org
On Sun, 20 Oct 2013 14:02:04 +0200 Andreas Goetz cpui...@gmail.com
wrote:
Hallo Justin,
warum nicht auf vz-dev?
Behoben- hiermit an die größere Runde.
im git gibt es mehrere Dateien die alle eine Initialisierung der Umgebung
brauchen (Pfade und Class Loaders):
- middleware.php
- misc/tools/doctrine.php
...
Spricht etwas dagegen, die Initialisierung in eine gemeinsam genutzte
Datei
auszulagern? Ich dachte an sowas wie bootstrap.php, vielleicht im lib
Verzeichnis, wollte vor einem PR aber gerne Eure Meinung abholen.
absolut vernuenftig.
wuerd' mir eben den code anschauen, was da die redundanten teile sind,
aber leider wenig zeit.
Gibts darüber hinaus Interesse an Unterstützung für composer.json?
sag' doch nochmal was die vorteile waehren...
Gute Frage. Ich bin kein Experte, habe im Rahmen der Unit Tests aber gute
Erfahrungen damit gemacht. So war die Installation von Doctrine mit Hilfe
der folgenden composer.json in wenigen Sekunden erledigt:
{
config: {
vendor-dir: lib/vendor
},
require: {
doctrine/orm: 2.4.*
},
autoload: {
psr-0: {
: src/
}
}
}
und dann
composer install
Ich habe Continuous Integration als neues Feature auf der Liste, also die
Überwachung der Builds mittels Unit Tests nach jedem Checkin:
https://travis-ci.org/andig/volkszaehler.org/builds
Dafür müssen bei Travis auch die Abhängigkeiten installiert werden (anders
laufen ja die Tests nicht)- die einfachste Lösung dafür die ich gefunden
habe war composer, es sind aber sicher auch andere denkbar.
Aber zurück zur Frage- wenn wir den Initialisierungscode in einer Datei
zusammenschieben- wo soll er hin? Aktuell liegt er bei mir in
lib/bootstrap.php neben Router.php, sieht dort aber nicht wirklich schön
aus, schon wegen der Gross/Kleinschreibung.
Wäre die Datei neben middleware.php vielleicht besser aufgehoben? misc/
scheint keine gute Idee zu sein?
Freue mich auf Eure Vorschläge,
Andreas
Re: [vz-dev] Aggregationsmode DELTA
Moin, 2013/10/28 Thorben Thuermer r...@constancy.org ... Im Ergebnis führt das dazu, dass das FE hässliche Rampen an den Stellen anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren Intervallen) wieder auf Daten übergegangen wird. beschraenkt sich das problem nicht drauf, jeweils die erste UND die letzte null drinzulassen? wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, in welchem zeitraum die naechste aenderung stattgefunden hat, und verteilt sie halt auf den gesamten zeitraum seit dem letzten wert. Schon getestet- tut es leider nicht. Das Problem ist so gross, wie Tupel zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 0 und x auf x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und y) auf y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von x/2 bis y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel aggegiert werden desto größer die Abweichung. In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen Hinweis bekommen wird dass zwischendurch die 0 steht und die Daten ausgedünnt sind. vg Andreas
Re: [vz-dev] Aggregationsmode DELTA
Ich denke jetzt nochmal laut...
2013/10/28 Andreas Goetz cpui...@gmail.com
Moin,
2013/10/28 Thorben Thuermer r...@constancy.org
...
Im Ergebnis führt das dazu, dass das FE hässliche Rampen an den
Stellen
anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren
Intervallen)
wieder auf Daten übergegangen wird.
beschraenkt sich das problem nicht drauf, jeweils die erste UND die letzte
null drinzulassen?
wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, in
welchem zeitraum die naechste aenderung stattgefunden hat,
und verteilt sie halt auf den gesamten zeitraum seit dem letzten wert.
Schon getestet- tut es leider nicht. Das Problem ist so gross, wie Tupel
zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 0 und x
auf x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und
y) auf y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von
x/2 bis y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel
aggegiert werden desto größer die Abweichung.
Das Problem ist dass wir im Moment (wenn das FT tupels=xyz übergibt) Pakete
schnüren. Seit dem entsprechenden Patch macht das die Datenbank:
$sql = 'SELECT MAX(aggregate.timestamp) AS timestamp,
SUM(aggregate.value) AS value, COUNT(aggregate.value) AS count '.
'FROM ('.
'SELECT timestamp, value, @row:=@row+1 AS row '.
' FROM data WHERE channel_id=?' . $sqlTimeFilter .
') AS aggregate '.
'GROUP BY row DIV ' . $packageSize .' '.
'ORDER BY timestamp ASC';
In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen
Hinweis bekommen wird dass zwischendurch die 0 steht und die Daten
ausgedünnt sind.
Was spräche denn jetzt dagegen, stattdessen äquidistante Stücke zu
schneiden, also nach timestamp DIV $packageSize zu gruppieren? und den
entsprechenden Timestamp im Select hochzuzählen? Das Ganze noch mit IFNULL
Statements ergänzt sollten wir in der Lage sein, fehlende (Null-)Werte zu
ergänzen. Performance to be tested.
Dann besteht natürlich wieder die Gefahr, dass wir zwischen zwei
Zählerwerten eine Null erfinden falls sich da kein weiterer Messwert
anfindet- Tuples darf also nicht granularer werden als Messwerte wirklich
vorliegen.
Wär hätte Lust einen Prototyp zu bauen und Performance zu testen??
vg
Andreas
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
Hallo *, 2013/9/27 Thorben Thuermer r...@constancy.org - schnellere Bearbeitung von requests ich sehe noch das problem, inwieweit aenderungen vorher reviewed/getestet werden/sein sollten. Das gehört doch aber zum Problem. PR47 lag 6 Wochen rum- nicht nur ohne commit, sondern auch ohne Test- weil's einfach niemanden interessiert. das ist aber kein problem des maintainers, sondern der community. da gibt es nicht die resourcen/uebersicht, weder bei justin noch bei mir zB., alles selbst zu testen. Ich engagiere mich gerade bzgl. der PRs zum Einsatz von Composer. Leider ist mein Eindruck dass die Arbeit daran ziemlich für die Tonne ist da/wenn die Maintainer keine Kommentare abgeben. Und um hier aktiv etwas beizutragen: ich habe immer noch einen Satz Unit Tests rumliegen mit dem ich überhaupt erst soweit gekommen bin- die Sache ist nämlich tatsächlich recht filigran. Bisher gabs nur von keiner Seite Interesse die irgendwo aufzunehmen oder zu pflegen... ich wollte schonmal dazu sagen: was genau hindert dich daran, den test-code zu commiten und einen pull-request zu stellen? das waehre auch schnell gemerged, da eindeutig sinnvoll, und kein (wenig?) vorhandener code veraendert wird. Genau das habe ich vor ca. 6 Wochen gemacht und vor 3 Wochen die letzten offenen Anmerkungen behoben. Seitdem ruht der Request und die Bits setzen langsam Staub an. Für mich als Contributer demotivierend... ... denke nicht, siehe community-problem. siehe auch der naechste punkt. (auch sprach ich von pull-requests, die manchmal reinkommen ohne dass es hier einen thread dazu gibt, die liegen dann noch laenger rum ;) ) Ich bin mir nicht sicher wie's aktuell aufgesetzt ist- aber gehen die git Notifications auch and die Entwickler-ML? Im Moment bleibe ich bei meiner Einschätzung- VZ ist von Entwicklerseite sehr schwer zugänglich. Voraussetzung für den Aufbau einer entsprechenden Community ist aus meiner Sicht mehr Agilität. vg Andreas
Re: [vz-dev] Ausschließlich MySQL (und Kompatible)?
Hallo Zusammen, wird wohl heute mein Emailtag... 2013/11/14 Thorben Thuermer r...@constancy.org andi hat halt seine optimierungen nur gegen mysql gemacht und getestet, und den fall anderer dbms dabei kaputtgemacht. das ist auch nicht weiter tragisch oder verwunderlich, da eh 99% der user mysql einsetzen. zumal im Code der vor mir da war exlpizit dokumentiert ist dass nur MySQL unterstützt wird. Die GroupBy Anfragen funktionieren ebenfalls nur mit MySQL... loesungen, in order of preference: - code fixen so dass er ueberall funktioniert - die optimierungen nur bei mysql aktivieren (eh fraglich, ob die bei anderen dbms was bringen!) - support fuer andere dbms verwerfen, da eh irrelevant PS: Wie sieht es denn mit Issues bei Github aus? Ich fände es ganz praktisch, wenn man da Fehler melden könnte. Da hat man dann auch den Bezug zu Bugfixes. JUSTIN!!! +1 +1 +1 von mir. - T. On Wed, 13 Nov 2013 22:33:13 +0100 Robert Ewald robert...@jtro.de wrote: Hallo allerseits, ... Ich versuche es jedenfalls gerade mit SQLite. Es werden zwar erfolgreich Daten erfasst und in der Datenbank gespeichert, aber die Weboberfläche meldet Fehler. Der Grund ist folgendes Statement: SET @row:=... Das ist MySQL-spezifisch und dürfte bei keiner anderen Datenbank funktionieren. Die Jungs von SQLite haben lokale Variablen als Anzeichen ineffizienter Abfragen verworfen und bei Postgresql heißt es schlichtweg anders. Und es ist auch ganz einfach zu lösen: die übergeordnete Schleife mit false deaktivieren, dann wird die Aggregation wieder in PHP statt MySQL gemacht. Ist halt langsamer... vg Andreas
Re: [vz-dev] VZ Codebasis, Unit-Tests, und so
2013/11/12 Robert Ewald robert...@jtro.de Genau erklärt wird alles hier: http://getcomposer.org/doc/00-intro.md Vorteile: * vereinfachte Installation von Abhängigkeiten, inklusive von deren Abhängigkeiten * ein sehr gut getesteter Autoloader, der auch für den eigenen Code verwendet werden kann * 3rd-Party-Software wandert in einen eigenen Ordner im Projekt Abgesehen davon, dass sich Composer zum defacto Standard für PHP Paketmangement zu entwickeln scheint (+/- PEAR) scheint es z.B. von Doctrine (http://www.doctrine-project.org/downloads/) auch keine Pakete der aktuellen 2.4er Version mehr zu geben. Der einzige offzielle Installationsweg scheint mittlerweile Composer zu sein. vg Andreas
Re: [vz-dev] Falsche Darstellung von Stromzählerwerten
Hallo Andreas, 2013/11/21 Andreas Tauscher t...@geuka.net ... b) Wenn keine Spannung gemessen wird. Sollte innerhalb einer bestimmten Zeit (berechnet aus einer genügend kleinen Grundlast) kein weiterer Messpuls auftauchen, dann wird bis zum nächsten Puls auch alles als 0 geplottet. Andreas Der Ansatz interessiert mich. Ich hatte bisher immer versucht, das Problem im Code der Middleware zu lösen, was aber spätestens dann scheitert wenn Tuple aggregiert werden und die (evtl. wenigen) Nullen in der Datenbank eingedampft werden. Wo/ an welcher Stelle hast Du das denn gelöst? Würde wenn es funktioniert gerne einen Patch für das Frontend daraus entwickeln. vg Andreas
Re: [vz-dev] Native Tablet App als Frontend
Je nachdem was Du willst könntest Du vielleicht auch Beiträge liefern zu - https://github.com/andig/vzmon/ oder - https://github.com/andig/vzvis/ HTML gehört die Zukunft ;) vg Andreas 2013/11/27 Julian Vollmer julianvoll...@gmail.com Hallo, Im Rahmen meiner Masterarbeit denke ich gerade über eine Native Tablet App (mir wäre iOS lieber) nach. Ich hatte gerade eine kleine Unterhaltung mit r00t^home für mich klang das nicht sehr begeistert. [19:42] julianvollmer Hallo, hat sich schon mal jemand Gedanken um eine Tablet-UI gemacht ? im Rahmen meiner Masterarbeit bin ich am überlegen ob ich eine native iOS iPad app für die middleare schreibe. [19:43] julianvollmer sorry, ich meine natürlich das frontend ... [19:47] r00t^home viele leute benutzen das frontend schon auf tablets [19:47] r00t^home ansonsten, viel spass mit deinem Spielzeug Aber vielleicht gibt es ja andere Entwickler die Lust haben darüber mal nachzudenken. Meine Meinung nach ist das Frontend auf Tablets nicht wirklich bedienbar. Eine kurze Rückmeldung, oder ein erscheinen im IRC, von Leuten die daran generell Interesse hätten wäre erfreulich. Beste Grüße Julian
Re: [vz-dev] Middleware, Data, Rows und Anzahl der Rows und Tuples
Zweiter Anlauf.
2013/12/3 René Hézser r...@hezser.de
Ist nur ein Wert in der DB vorhanden, wird z.B. das hier zurück gegeben:
{version:0.3,data:{uuid:79585050-5a7f-11e3-93c6-b94baa5526ce,from:138588872,to:138588872,average:0,rows:1}}
Wenn nur ein Wert vorhanden ist passt das auch da die MW genau(!) 1 Wert
verschluckt.
Hast Du mal probiert was passiert wenn 1 Wert in der DB steht?
Wie wäre es mit einem Parameter last oder so, der den letzten Datensatz
raw ausgibt, ohne zu rechnen?
Gruß
René
Bitte vorher nochmal testen, dann schaue ich was sich tun lässt.
vg
Andreas
Re: [vz-dev] Middleware, Data, Rows und Anzahl der Rows und Tuples
Dein Tool muss doch eh Zeitstempel setzen- also einfach den aktuellen nehmen, der kann ja noch nicht benutzt sein. Oder merken ob das Tool schonmal was getan hat- dann ist der Fall ja auch klar... 2013/12/3 René Hézser r...@hezser.de Wenn nur ein Wert vorhanden ist passt das auch da die MW genau(!) 1 Wert verschluckt. Hast Du mal probiert was passiert wenn 1 Wert in der DB steht? Wie wäre es mit einem Parameter last oder so, der den letzten Datensatz raw ausgibt, ohne zu rechnen? Bei mehr als einem Wert passt es. Rows ist zwei und der Zeitstempel ist richtig. Nur was mache ich für den Fall dass nur einer da ist? Mein Tool zum hochladen von Werten in die Datenbank liest via REST aus, wann der letzte Datensatz eingestellt wurde. Wird dieser nicht ausgegeben, versucht es natürlich mit demselben Zeitstempel und UUID hinzuzufügen. Und da kommt von der Middlware korrekterweise eine Duplicate Key Exception. Gruß René
Re: [vz-dev] [vz-users] Gaszähler Startwert
Hallo Bernd, hallo vz-dev, 2013/12/6 Bernd Gewehr be...@gewehr.net Hallo! Ich habe mir den Anfangswert in die Tabelle der Zählwerte mit einem frühen timestamp des Gaszählerkanals geschrieben und eine SQL Routine, die per Event alle 5 Minuten aufgerufen wird, dazu verwendet, die Summe aus den Zählwerten zu bilden und in einen neuen Kanal mit aktuellem Timestsmp zu schreiben. Ups. Das können sicher nur Leute mit Bastelaffinität. Dies funktioniert gut! Ich wünsche mir allerdings, dass im Volkszähler Projekt die Anzeige von absoluten Zählerständen in Zukunft irgendwann einmal vernünftig realisiert wird. Die Idee finde ich nicht uncharmant. Je nachdem welchen Zählertyp Du hast sollte das eigentlich heute schon möglich sein. Wenn es sich um ein Meter handelt das also Verbräuche speichert dann kann man natürlich den Startverbauch in einen Timestamp vor dem ersten echten Zählerwert schreiben. Damit die MW den wirklich berücksichtigt braucht es zusätzlich noch 1(!) weiteren Wert+Timestamp davor da der erste verschluckt wird. Dieser sollte soweit vorher liegen dass eine vernünftige Durchschnittsleistung berechnet wird- anderenfalls kann das im FE sehr blöd aussehen. Bei Countern ist es egtl. kein Problem- hier wird ja ohnehin der echte Zählerwert gespeichert, passt also. Bei Sensoren wiederrum die nur Momentanwerte speichern ließe sich das analog Meter implementieren. Jetzt käme es mal auf einen Test und Feedback an, dann liesse sich das Ganze durchaus auch über den Channel Controller implementieren, z.B. indem man eine neue Eigenschaft hasTotal definiert die über Channel Updates in Form von Tupeln gespeichert werden. Damit könnte Clients die obige nicht ganz triviale Logik verfügbar gemacht werden. vg Andreas
Re: [vz-dev] [vz-users] Gaszähler Startwert
Hallo *,
...
Ich wünsche mir allerdings, dass im Volkszähler Projekt die Anzeige von
absoluten Zählerständen in Zukunft irgendwann einmal vernünftig realisiert
wird.
Die Idee finde ich nicht uncharmant.
Je nachdem welchen Zählertyp Du hast sollte das eigentlich heute schon
möglich sein. Wenn es sich um ein Meter handelt das also Verbräuche
speichert dann kann man natürlich den Startverbauch in einen Timestamp vor
dem ersten echten Zählerwert schreiben. Damit die MW den wirklich
berücksichtigt braucht es zusätzlich noch 1(!) weiteren Wert+Timestamp
davor da der erste verschluckt wird. Dieser sollte soweit vorher liegen
dass eine vernünftige Durchschnittsleistung berechnet wird- anderenfalls
kann das im FE sehr blöd aussehen.
Ich habe das Ganze mal in einen Unit Test verpackt- wer Interesse hat
sollte es mit dem Code unten und den Unit Tests in Git nachvollziehen
können. Die Funktion setTotal funktioniert so, dass sie
1) den aktuellen Gesamtverbaucht ermittelt
2) ausrechnet wieviel dazu muss um den Wunschwert zu erreichen
3) den ersten Wert der Datenbank um den dazu Anteil erhöht
4) und den ersten Wert aktualisiert
Der Ablauf dafür mit den Unittestfunktionen sieht so aus:
function testSetTotal() {
$this-getTuples(1, 1.1.2030);
echo(\nold consumption: {$this-json-data-consumption}\n);
// new desired total consumption
$total = 75; // kWh
$delta = $total - $this-json-data-consumption / 1000; // kWh
$rowCount = $this-json-data-rows;
if ($rowCount) {
// we have starting timestamp + at least one valid tuple- get
tuple range
$ts1 = $this-json-data-from;
$ts2 = ($rowCount 2) ? $this-json-data-tuples[1][0] :
$this-json-data-to;
// add consumption of first tuple
$delta += $this-json-data-tuples[0][1] * ($ts2 - $ts1) /
3.6e9; // kWh
// update tuple to match desired total
$url = self::$context . '/' . self::$uuid .
'.json?operation=editts=' . $ts2 . 'value=' . ($delta *
self::$resolution); // kWh * res
$this-getJson($url);
// verify total consumption
$this-getTuples(1, 1.1.2030, '', 1);
echo(new consumption: {$this-json-data-consumption}\n);
$this-assertFromTo($ts1, $this-json-data-to);
$this-assertEquals($total * 1000,
$this-json-data-consumption); // compare Wh
}
else {
echo(Not enough tuples\n);
}
}
Um die Funktion setTotal jetzt produktiv einsetzen zu können braucht es:
- eine Erweiterung des Datenkontext da editieren aktuell nicht möglich ist
- eine Idee wo/wie die Funktion den Anwendern angeboten werden soll:
a) Evtl. als kleines Zusatztool für die Kommandozeile?
b) als Funktion des channel Kontext?
c) als Funktion des channel Kontext?
d) als neuer totals Kontext?
Bei Countern ist es egtl. kein Problem- hier wird ja ohnehin der echte
Zählerwert gespeichert, passt also.
Tatsächlich scheint auch das nicht ganz zu funktionieren da die MW immer
nur die Differenzen ausgibt. Auch hierfür wäre es also notwendig 1
zusätzlichen Tuple mit Wert 0 als allerersten Tuple zu schreiben.
Bei Sensoren wiederrum die nur Momentanwerte speichern ließe sich das
analog Meter implementieren.
Jetzt käme es mal auf einen Test und Feedback an, dann liesse sich das
Ganze durchaus auch über den Channel Controller implementieren, z.B. indem
man eine neue Eigenschaft hasTotal definiert die über Channel Updates in
Form von Tupeln gespeichert werden. Damit könnte Clients die obige nicht
ganz triviale Logik verfügbar gemacht werden.
Wer probierts aus und gibt Feedback ob/wie die Funktion implementiert
werden soll?
vg
Andreas
Re: [vz-dev] Fehler: vz und Temperaturen unter -10°
Versuch bitte erstmal rauszufinden welche Werte der Sensor eigentlich liefert- ein Fehler der Middleware ist hier ziemlich unwahrscheinlich. vg Andreas 2013/12/8 Heiko Baumann h...@gmx.de Hallo zusammen, nachdem es jetzt bei uns leider ziemlich kalt wird, ist mir ein Darstellungsproblem im Frontend aufgefallen. Fällt die Temperatur unter -10°, werden z.B. -1,5° anstelle von -11.5° angezeigt (siehe Screenshot). Erst dachte ich, das wäre ein Fehler im Frontend, aber leider stehen auch die Werte falsch in der DB: mysql select *, from_unixtime(timestamp/1000) from data where timestamp1385517696591 and timestamp1385517998592 and channel_id=10; +-++---+---+ ---+ | id | channel_id | timestamp | value | from_unixtime(timestamp/1000) | +-++---+---+ ---+ | 6816491 | 10 | 1385517696592 | -9.94 | 2013-11-27 03:01:37 | | 6816638 | 10 | 1385517779731 |-1 | 2013-11-27 03:03:00 | | 6816772 | 10 | 1385517855444 | -1.01 | 2013-11-27 03:04:15 | | 6816916 | 10 | 1385517937645 | -1.02 | 2013-11-27 03:05:38 | +-++---+---+ ---+ 4 rows in set (0.00 sec) Datensatz 6816638 müsste eigentlich -10 als Value haben, 6816772 -10.1 usw. Die Temperatursensoren gehen lt. Hersteller bis -55°C. Woran könnte das liegen? Ich verwende einen raspi mit Udos Hardware und Henriks 1wirevz. Danke und schöne Grüße Heiko
Re: [vz-dev] Fehler: vz und Temperaturen unter -10°
Die Frage geht an die Loggerexperten Udo und Rainer- entweder indem Du direkt die Schnittstelle ausliest oder im vzlogger (nutzt Du den?) mal das Loggig so erhöhst dass die Daten sichtbar werden. Genauer weiss ich es leider nicht, sry.. 2013/12/8 Heiko Baumann h...@gmx.de Am 08.12.2013 13:44, schrieb Andreas Goetz: Versuch bitte erstmal rauszufinden welche Werte der Sensor eigentlich liefert- ein Fehler der Middleware ist hier ziemlich unwahrscheinlich. Hi Andi, du meinst also dass der Sensor bei -10° falsche Werte liefert? Hm, dann müsst ich den Außenfühler mal auswechseln. In den Specs steht halt Temperaturbereich -55° bis +125°C. Wär dann ja schon arg bitter wenn er bei exakt -10,0°C streikt... Hab ich noch eine andere Möglichkeit, die gelieferten Werte außerhalb der DB auszulesen und nachzuprüfen? Danke! LG Heiko 2013/12/8 Heiko Baumann h...@gmx.de Hallo zusammen, nachdem es jetzt bei uns leider ziemlich kalt wird, ist mir ein Darstellungsproblem im Frontend aufgefallen. Fällt die Temperatur unter -10°, werden z.B. -1,5° anstelle von -11.5° angezeigt (siehe Screenshot). Erst dachte ich, das wäre ein Fehler im Frontend, aber leider stehen auch die Werte falsch in der DB: mysql select *, from_unixtime(timestamp/1000) from data where timestamp1385517696591 and timestamp1385517998592 and channel_id=10; +-++---+---+---+ | id | channel_id | timestamp | value | from_unixtime(timestamp/1000) | +-++---+---+---+ | 6816491 | 10 | 1385517696592 | -9.94 | 2013-11-27 03:01:37 | | 6816638 | 10 | 1385517779731 |-1 | 2013-11-27 03:03:00 | | 6816772 | 10 | 1385517855444 | -1.01 | 2013-11-27 03:04:15 | | 6816916 | 10 | 1385517937645 | -1.02 | 2013-11-27 03:05:38 | +-++---+---+---+ 4 rows in set (0.00 sec) Datensatz 6816638 müsste eigentlich -10 als Value haben, 6816772 -10.1 usw. Die Temperatursensoren gehen lt. Hersteller bis -55°C. Woran könnte das liegen? Ich verwende einen raspi mit Udos Hardware und Henriks 1wirevz. Danke und schöne Grüße Heiko
Re: [vz-dev] [vz-users] Gaszähler Startwert
Leider lässt sich das im Moment nicht sinnvoll implementieren da die Performance dann gen Süden geht da bei jedem Aufruf über alle Werte je Kanal summiert werden muss (1 Messwer je Minute x 24h x 1 Jahr = 500k Werte). Eine Lösung dafür wäre eine Aggregationstabelle mit der gruppierte Abfragen und Abfragen mit tuples=1 (wie wir sie hier brauchen) dramatisch beschleunigt werden können. Code ist weitgehend fertig, kommt aber ohne Tester nicht ins git. Wer Interesse und Lust am Basteln hat darf sich melden ;) vg Andreas 2013/12/7 Andreas Götz cpui...@gmail.com Ich war gedanklich eher bei der Frage wo sie in die MW gehört ;) Viele Grüße, Andreas Am 07.12.2013 um 23:25 schrieb Rainer Gauweiler volkszaeh...@moppl.inka.de: Hallo, Am 07.12.2013 14:02, schrieb Andreas Goetz: - eine Idee wo/wie die Funktion den Anwendern angeboten werden soll: Im Frontend links oben wo aktuell die Verbrauchswerte stehen. Da ist Platz und dann kann man den Zählerstand leicht mit eigenen Aufzeichnungen vergleichen oder gezielt zu einem gewissen Zeitpunkt sich anzeigen lassen. Gruss Rainer
[vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Hallo Zusammen, die VZ Admins bzw. Committer arbeiten derzeit daran, die verschiedenen Patches zur Performanceoptimierung in das VZ Hauptrepository einzubringen. Leider muss dazu die bestehende VZ Infrastraktur einmalig einer Änderung unterzogen werden die nicht durch ein einfaches git pull zu beheben ist. Wenn Ihr in den nächsten Tagen also vorhaben solltet Eure VZ-Installation mal wieder auf den aktuellen Stand zu bringen beachtet bitte folgende Punkte um die Installation möglichst unterbrechungsfrei durchzuführen: 1. Installiert die Composer Paketverwaltung $ mkdir composer $ cd composer $ curl -sS https://getcomposer.org/installer | php $ sudo cp composer.phar /usr/local/bin/composer Windowsnutzer laden sich den Installer unter http://getcomposer.org/download/ herunter. Zum testen: composer self-update Wenn das erfolgreich funktioniert seid Ihr das das Git Update vorbereitet. 2. Aktualisiert Eure Installation Dafür macht ihr wie immer in Eurem VZ Verzeichnis ein git pull ACHTUNG: nach diesem Schritt ist die Middleware zunächst nicht mehr erreichbar da die Abhängigkeiten (Doctrine etc) nicht gefunden werden. Deshalb jetzt schnell die Abhängigkeiten installieren: composer install sollten Hinweise über veraltete Software kommen könnt Ihr auch noch ein optionales composer update nachschieben. Nach diesem Schritt ist die Middleware wieder erreichbar da die notwendigen Bibliotheken jetzt verfügbar sind. 3. Performanceoptimierung einschalten Wenn Ihr MySQL nutzt (in der neuen Version werden auch SQlite und PostgreSQL zusätzlich unterstützt, allerdings ohne Vollständigkeitsgarantie) dann könnt Ihr die neuen Features wiefolgt aktivieren. Hilfstabelle anlegen: php misc/tools/aggregate.php create Hilfstabelle befüllen: php misc/tools/aggregate.php -m full -l day -l hour run Und den Prozess für die Aktualisierung noch automatisien: crontab -e und die folgenden Zeilen hinzufügen: * 2 * * * /usr/bin/php aggregate.php -m delta -l day run 9 * * * * /usr/bin/php aggregate.php -m delta -l hour run Damit ist's dann getan- ab jetzt sollte Euer VZ rennen. Wir melden uns wieder an dieser Stelle wenn die Änderungen drin sind. Die Ungeduldigen finden bis dahin im dev Zweig unter github.com/andig/volkszaehler den aktuellen Stand zum spielen. Euch allen ein Frohes Fest, Schöne Bescherung und Viel Spass beim auspacken der Geschenke! Euer Andreas
Re: [vz-dev] Volkszaehler Performance Verbesserungen - z.B. für RaspberryPi
Hallo Zusammen, es ist vollbracht: https://github.com/volkszaehler/volkszaehler.org/pull/80 Also ab jetzt ein wenig Vorsicht beim aktualisieren! Frohes Fest, Andreas 2013/12/14 Andreas Goetz cpui...@gmail.com Hallo Zusammen, ich betreibe VZ seit etwa einem Jahr. Bei mir zeichnet ein kleiner RasPi 5 Kanäle auf und hat mittlerweile ca. 30 Datensätze geschrieben. Mit der Performance der Middleware wie sie mit meiner Monitoring App VZmon (https://github.com/andig/vzmon/) oder vom Frontend zu beobachten war war ich völlig unzufrieden. Eine Jahresansicht im Frontend z.B. brauchte 30 Sekunden- indiskutabel. Ich habe daher Middleware und Frontend in den relevanten Bereichen grundlegend angepasst. Das Ergebnis: die Jahresansicht generiert mir das Frontend jetzt in 2 Sekunden, selbst wenn alle 5 Kanäle eingeblendet sind. Leider besteht momentan keine Chance die Entwicklungen in den offiziellen Zweig zu bekommen. Voraussetzungen dafür sind Tests, Tests und Tests. Daher meine Frage und Bitte: wer das Thema spannend findet und die Entwicklungen testen möchte sollte sich hier melden. Die Entwicklungen stehen unter https://github.com/andig/volkszaehler.org/tree/dev bereit. Wenn Interesse besteht gebe ich einen kurzen Einführungskurs. Fürs erste wäre es allerdings hilfreich wenn sich nur Interessenten mit ein wenig Entwicklungsknowhow meldeten da der Supportaufwand sonst zu gross wird. Viele Grüße, Andreas
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Moin, 2013/12/27 René Hézser r...@hezser.de Nach der Anleitung (also als Punkt 4) habe ich noch in der volkszaehler.conf.template.php $config['aggregation'] = true; gesetzt. Ist die Aggregation nur dann aktiv? Gruß René So isses. Sonst würde der Eintrag ja nicht soviel Sinn machen :/ Und er wirkt auch nur dann wenn die Tabelle befüllt wird... vg Andreas
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
2013/12/27 W3ll Schmidt w3llschm...@gmail.com Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!! Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
Re: [vz-dev] AVM Steckdose Wattanzeige
@all: Ihr habt mich angefixt. Jetzt hab ich auch so ein Ding :) @Berthold: woher kommt Dein Skript? Aus der AVM Doku jedenfalls nicht?! vg Andreas 2013/12/27 Thomas Gauweiler th.gauwei...@googlemail.com Hallo Thorben, ich gebe Dir recht, aber ich wäre schon froh, wenn die vorhandene Doku passend wäre. Ich denke inzwischen, dass sich die Doku zur AHA auf die Firmware ab 5.9 bezieht. Verwendbar ist die Steckdose über die Oberfläche der Fritz!Box schon ab 5.0. Infos dazu sind vermutlich inoffiziell über das FHEM-Projekt geflossen. Mir persönlich reicht es, wenn ich die Form des Verbrauchs erkenne, die genauen Verbrauchszahlen brauche ich nicht. Da ich daraus aber einen Mechanismus ableiten möchte, brauche ich den Zugang via Skript. Gruß __ /homas
Re: [vz-dev] AVM Steckdose Wattanzeige
Hi, 2013/12/27 Thomas Gauweiler th.gauwei...@googlemail.com @Andreas: Ihr habt mich angefixt. Warum sollte es Dir anders ergehen als mir :-) Und welche Fritz OS Version hast Du? ist eine 7270v3 74.05.50. Nach dem Update jetzt 74.05.53. Der Fehler 'Luacgi not readable filename=/webservices/homeautoswitch.lua' ist nach wie vor da :( Gruß __ /homas Also telfonieren wir im neuen Jahr mal mit AVM. So schwer kann das ja nicht sein die 3 Parameter zu dokumentieren. Mannmannmann... vg Andreas
Re: [vz-dev] AVM Steckdose Wattanzeige
Ich hab jetzt mal auf die Laborversion FRITZ!OS 06.01-27185 BETA umgestellt. Damit funktioniert nach ersten Versuchen auch homeautoswitch.lua wie erwartet. Prinzipiell bringt mich das auf die Frage ob wir VZ nicht um sowas wie Trigger bzw. Aktoren erweitern sollten (if Leistung xy für Zeitraum z then Call URL/ execute Script). Die Frage ist wieweit das vom Webserver aus sinnvoll ist. Der Charme besteht ja aktuell u.a. darin dass keine aufwendigen Serverkomponenten benötigt werden... vg Andreas 2013/12/27 Andreas Goetz cpui...@gmail.com Hi, 2013/12/27 Thomas Gauweiler th.gauwei...@googlemail.com @Andreas: Ihr habt mich angefixt. Warum sollte es Dir anders ergehen als mir :-) Und welche Fritz OS Version hast Du? ist eine 7270v3 74.05.50. Nach dem Update jetzt 74.05.53. Der Fehler 'Luacgi not readable filename=/webservices/homeautoswitch.lua' ist nach wie vor da :( Gruß __ /homas Also telfonieren wir im neuen Jahr mal mit AVM. So schwer kann das ja nicht sein die 3 Parameter zu dokumentieren. Mannmannmann... vg Andreas
Re: [vz-dev] AVM Steckdose Wattanzeige
So... seit ein paar Stunden läuft die Steckdose stabil. Leider hätte ich fast den Kühlschrank abgeschossen da ich vergessen hatte sie auch ein zu schalten :O Datenerfassung funktioniert mit kleinem fritzdect Tool aus meinem dev Repository und folgendem Skript über cron: pi@prodpi ~ $ cat ./fritzdect.sh #!/bin/bash POWER=`/usr/bin/php /home/pi/volkszaehler.org/misc/tools/fritzdect.php -a 087610103568 -c getswitchpower -d 1e3` COUNTER=`/usr/bin/php /home/pi/volkszaehler.org/misc/tools/fritzdect.php -a 087610103568 -c getswitchenergy` if [ $COUNTER = ]; then echo ERROR echo Power: $POWER Consumption: $COUNTER else echo Power: $POWER Consumption: $COUNTER /home/pi/volkszaehler.org/misc/tools/vzclient -u 2a148630-... add data value=$POWER /home/pi/volkszaehler.org/misc/tools/vzclient -u 7ff0ff00-... add data value=$COUNTER fi Aus Spass zeichne ich erstmal beide Werte auf um zu sehen was mehr Spass macht. Vmtl. ist Power sinnvoller da genauer, Counter könnte aber dazu dienen fehlende Werte zu korrigieren. Da brauchts noch einen intelligenten Algorithmus. vg Andreas PS.: Läuft leider nur mit der Laborversion von Fritz... 2013/12/28 NetFritz netfr...@gmx.de Am 28.12.2013 12:15, schrieb Andreas Goetz: 2013/12/28 Udo1 u...@gmx.net Am 28.12.2013 11:04, schrieb Andreas Goetz: z then Call URL/ execute Script oder Setze/Rücksetze GPIO-Pin xyz Gruß Udo Eher nicht weil zu speziell. Und dafür gibts ja schon Kommandozeilentools, das würde also reichen. Bevor wir da was bauen brauchts allerdings wirklich eine gute Archtikturidee. Kann/soll/darf man das vom Apachen aus machen? Performance?? Wird spannend.. vg Andreas PS.: Habe jetzt hier ein kleines Tool zum auslesen/ setzen der FritzDECT mit Laborversion... Hallo Hier habe ich vor ein Paar Tagen mal was gefunden. http://www.tdressler.net/ipsymcon/fritz_aha.html Ich habe mir vor ein Paar Tagen eine Fritz546e Steckdose zugelegt und dann auf meine FB 7270v2 die FRITZ!OS 06.01-27185 BETAhttp://192.168.2.1/home/pp_fbos.lua?sid=02870eb059eae589installiert. Gruß NetFritz
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Moin Heiko,
2014/1/9 Heiko Baumann h...@gmx.de
Ergänzung:
http://vz/middleware.php/capabilities/database.json
liefert mir:
{version:0.3,capabilities:{database:{
data_rows:6420892,data_size:592134144,aggregation_
enabled:1,aggregation_rows:58082,aggregation_ratio:110.549}}}
... also ist das doch offenbar richtig aktiviert
Erstmal sind Daten drin. Ob die für die Kanäle drin sind die bei Dir
langsam sind sieht man daran nicht.
2014/1/9 Heiko Baumann h...@gmx.de
...
Jedenfalls steht in volkszaehler.conf.php was von administration
credentials - ich gehe mal davon aus, dass ich für den user root mein
login-PW eintrage.
Ganz sicher nicht?! Da kommt ein DB-User mit CREATE/DROP Privilegien rein
falls Dein normaler DB-User die nicht hat.
Die Timezone (Europe/Berlin) ist rauskommentiert - soll das so sein?
Eher nicht.
Tja und dann kommt also noch als letzte Zeile
$config['aggregation']=true;
mit rein. Speichern, aber selbst nach reboot kann ich keine Beschleunigung
erkennen.
Reboot ist nicht nötig. Woran machst Du keine Beschleunigung das fest?
Bestimmte Abfrage? Nutzung des Frontends?
Die aggregate-Tabellen wurden erzeugt und sind befüllt, hat bei 500MB data
doch ganz schön gedauert.
Macht nix. Für Deltabefüllung gibts ja dann den entsprechenden Modus
womit's auch fix geht.
Woran könnte es liegen, dass die Performanceoptimierungen bei mir nicht
greifen?
S.o.
vg
Andreas
Danke!
LG Heiko
PS: Habe im wiki mal die hier weiter oben im Thread genannten Schritte
ergänzt, weil das aktuelle Image ja noch vom August ist...
Am 27.12.2013 18:22, schrieb Andreas Goetz:
2013/12/27 W3ll Schmidt w3llschm...@gmail.com
Super Arbeit, läuft aum Raspi wie 'Schmidts Katze' !!!
Das hört man doch gerne ;) Hat sich die Arbeit gelohnt :))
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Hallo Heiko,
jetzt hatte ich extra den Schlepptop hochgefahren um Dich mit Diagnosetipps
zu versorgen und schon rennt die Mieze?! Aber lieber so als anders ;)
Viel Spass mit dem Tier,
Andreas
PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja debug=1 im
Querystring ;)
2014/1/9 Heiko Baumann h...@gmx.de
Bin jetzt echt am Grübeln - vielleicht läuft die Optimierung ja doch
schon? hmmm... ahhh.. moment, ich schau einfach mal ins mysql.log.
Tatsächlich: da wird fleissig auf die aggregate-Tabelle zugegriffen:
140109 20:37:15 70465 Connect vz@localhost on volkszaehler
70465 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
'9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
70465 Query SELECT MIN(timestamp) FROM (SELECT
timestamp FROM data WHERE channel_id='15' AND timestamp'1389209549459'
ORDER BY timestamp DESC LIMIT 2) t
70465 Query SELECT MAX(timestamp) FROM (SELECT
timestamp FROM data WHERE channel_id='15' AND timestamp'1389295949459'
ORDER BY timestamp ASC LIMIT 2) t
70465 Query SELECT aggregate.type, COUNT(aggregate.id)
AS count FROM aggregate INNER JOIN entities ON aggregate.channel_id =
entities.id WHERE uuid = '9a7ed6c0-f2dc-11e2-b13e-b9abb50897a8' GROUP BY
type HAVING count 0 ORDER BY type DESC
70465 Query SELECT
UNIX_TIMESTAMP(FROM_UNIXTIME(MIN(timestamp)
/ 1000, %Y-%m-%d)) * 1000 FROM aggregate WHERE channel_id='15' AND
type='3' AND timestamp='1388227905662'
70465 Query SELECT
UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp)
/ 1000, %Y-%m-%d), INTERVAL 1 day)) * 1000 FROM aggregate WHERE
channel_id='15' AND type='3' AND timestamp'1389296017384'
70465 Query SELECT SUM(count) FROM (SELECT COUNT(1)
AS count FROM data WHERE channel_id = '15' AND ( timestamp =
'1388227905662' AND timestamp '138818520' OR timestamp =
'138827160' AND timestamp = '1389296017384') UNION SELECT SUM(count)
AS count FROM aggregate WHERE channel_id = '15' AND type = '3' AND
timestamp = '138818520' AND timestamp '138827160') AS agg
...also alles richtig und muss damit leben, dass Schmidts Katze bei mir
nicht mag...?
... das war dann wohl auch ein Hauptgrund für die Lahmheit: jetzt hab ich
das mysql-logging abgedreht, und siehe da... miau ;)
Das Logging kostet einfach zu viel Performance auf der kleinen Kiste...
Also: Logging zugedreht... tata 11 Sek. für die Jahresansicht
eines Temperatur-Channels (allerdings nur Werte aus dem 2. Halbjahr) - das
ist cool..
Sieht gut aus, vielen Dank!!
Schönen Abend...
Heiko
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Moin,
2014/1/9 Heiko Baumann h...@gmx.de
Am 09.01.2014 21:26, schrieb Andreas Goetz:
Hallo Heiko,...
PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja debug=1 im
Querystring ;)
Hm, wie kann ich das dem Server beim Starten mit übergeben?
Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!
(/etc/init.d/mysql start debug=1 oder wie? Nee funktioniert nicht. Aber
so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann SET
GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
sowas in 1sec...
Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
gestellt, dann nur einen sichtbar gemacht. Logging an, auf Jahresansicht
geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
das angehängte Log.
Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
Browser, mit debug=1. Dann schauen was/wo das wie lange dauert.
Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
s0-Ereignissen erzeugt.
d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
Minute?
Also doch alles ok?
Es ist lngsam- aber anscheinend nicht Problem der Aggregation.
Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im log
fällt mir auf, dass das sehr häufig vorkommt:
911 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
'90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
911 Query START TRANSACTION
911 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389302896063', '1', 14)
911 Query UPDATE properties SET value = '1' WHERE id
= 71
911 Query UPDATE properties SET value = '1' WHERE id
= 69
911 Query UPDATE properties SET value = '1000' WHERE
id = 67
911 Query commit
Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler). Was
mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
Liefert bei mir z.B.
+-+--+---+--
++-+-++
| id0 | uuid1| type2 | id3 | pkey4 |
value5 | class6 | entity_id7 |
+-+--+---+--
++-+-++
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 71 | active
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 70 | color
| navy| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 69 | public
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 67 | resolution
| 1000| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 72 | style
| steps | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 68 | title
| Strom-Ferienwohnung | channel | 14 |
+-+--+---+--
++-+-++
6 rows in set (0.00 sec)
Muss das wirklich vor jedem Insert sein?
Und danach werden _immer_ die Werte für resolution, active und public
geupdatet (Unnötig, sind die alten Werte)
Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.
Was mich wundert sind Property Updates denn diese sind wirklich völlig
sinnlos. War das auch mit alten VZ-Versionen (also noch vor Einführung
Composer mit Doctrine 2.0) schon so? Die würde ich gerne loswerden...
Da die Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last 4kWh,
PV-Wechselsrichter gern auch mal 12kWh), könnt ich mir vorstellen, dass das
ziemlich viel unnötige Queries auslöst.
@ Hendrik, liest du vielleicht mit? s0vz ist ja dein Baby, oder..? ;)
Da liegt m.E. das Grundproblem. s0vz scheint nicht wie vzlogger eine
eingebaute Datenaggregation zu haben bevor es an die Middleware geht. Das
Thema gabs auch in anderen Threads schon.
Aus meiner Sicht ist das das Hauptproblem für die Perfprobleme wenn s0
ordentlich Impulse liefert. Da müsste allerdigns der Autor ran, C ist nicht
meine Welt...
vg
Andrea
Re: [vz-dev] ACHTUNG: Inkompatible Änderungen im Volkszahler Repository
Hi Heiko,
schau doch mal ob Du mit diesem PR hier
https://github.com/volkszaehler/volkszaehler.org/pull/95 die überflüssigen
SQLs für die properties Tabelle loswerden kannst.
Löst aber nicht die (wichtigeren...) Probleme mit s0vz.
vg
Andreas
2014/1/10 Andreas Goetz cpui...@gmail.com
Moin,
2014/1/9 Heiko Baumann h...@gmx.de
Am 09.01.2014 21:26, schrieb Andreas Goetz:
Hallo Heiko,...
PS.: Logging brauchst Du egtl auch nicht- dafür gibts ja debug=1 im
Querystring ;)
Hm, wie kann ich das dem Server beim Starten mit übergeben?
Davon war nicht die Rede. Mit Querystring meine ich das Ding im Browser in
der URL hinter dem Fragezeichen. Einfach bei der Abfrage mit angeben!!
(/etc/init.d/mysql start debug=1 oder wie? Nee funktioniert nicht. Aber
so: im laufenden Betrieb einfach eine mysql-shell aufmachen und dann SET
GLOBAL general_log = 'ON', danach dann mit ... 'OFF' wieder ausschalten).
Beim 2. Nachdenken- 11s für 180 Werte (=Tage) ist _viel_ zu langsam.
Kannst Du mal die Queries für diese eine Abfrage abschauen? Bei mir geht
sowas in 1sec...
Ok, was ich gemacht hab: startseite vz, erst mal alle Channels unsichtbar
gestellt, dann nur einen sichtbar gemacht. Logging an, auf Jahresansicht
geklickt, gewartet bis der Graph angezeigt wurde, dann logging aus. Ergibt
das angehängte Log.
Viel zu kompliziert. 1 Kanal, nur den Middlewarerequest anschauen. Im
Browser, mit debug=1. Dann schauen was/wo das wie lange dauert.
Ok, der aggregate-Teil dauert wohl nur 3 Sekunden, der Rest wird von
s0-Ereignissen erzeugt.
d.h. Dein Raspi ist von endlosen S0-Ereignnisse zugemüllt? Wieviele pro
Minute?
Also doch alles ok?
Es ist lngsam- aber anscheinend nicht Problem der Aggregation.
Kleine Anmerkung zu den s0-Ereignissen - ist aber andere Baustelle: im
log fällt mir auf, dass das sehr häufig vorkommt:
911 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
'90da22c0-f2dc-11e2-a59d-e9b55d71b128') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
911 Query START TRANSACTION
911 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389302896063', '1', 14)
911 Query UPDATE properties SET value = '1' WHERE
id = 71
911 Query UPDATE properties SET value = '1' WHERE
id = 69
911 Query UPDATE properties SET value = '1000'
WHERE id = 67
911 Query commit
Das ist offenbar ein s0-Eintrag (value=1 im channel 14, Stromzähler).
Was mich wundert: warum muss der aufwändige join vorher ausgeführt werden?
Liefert bei mir z.B.
+-+--+---+--
++-+-++
| id0 | uuid1| type2 | id3 | pkey4
| value5 | class6 | entity_id7 |
+-+--+---+--
++-+-++
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 71 | active
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 70 | color
| navy| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 69 | public
| 1 | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 67 | resolution
| 1000| channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 72 | style
| steps | channel | 14 |
| 14 | 90da22c0-f2dc-11e2-a59d-e9b55d71b128 | power | 68 | title
| Strom-Ferienwohnung | channel | 14 |
+-+--+---+--
++-+-++
6 rows in set (0.00 sec)
Muss das wirklich vor jedem Insert sein?
Und danach werden _immer_ die Werte für resolution, active und public
geupdatet (Unnötig, sind die alten Werte)
Den Join braucht Doctrine, das scheint auch mit Query Cache nicht weg
optimierbar zu sein da es immer einen aktuellen Stand aus der DB haben
will, die Abfrage ist auch schnell.
Was mich wundert sind Property Updates denn diese sind wirklich völlig
sinnlos. War das auch mit alten VZ-Versionen (also noch vor Einführung
Composer mit Doctrine 2.0) schon so? Die würde ich gerne loswerden...
Da die Stromzähler ja mitunter heftig feuern (Wärmepumpe unter Last 4kWh,
PV-Wechselsrichter gern auch mal 12kWh), könnt ich mir vorstellen, dass das
ziemlich viel unnötige Queries auslöst.
@ Hendrik, liest du vielleicht mit? s0vz ist ja dein Baby, oder..? ;)
Da liegt m.E. das Grundproblem. s0vz scheint nicht
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas 2014/1/12 Volker v...@gmx.de Hallo, ich habe gerade die aktuelle Version vom VZ geholt (git://github.com/ volkszaehler/volkszaehler.org.git). Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der Version die ich am 3.1. installiert habe. Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden gar keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist. Der Wert aktuell in der Statistik war eigentlich schon immer fehlerhaft , wenn keine neuen Impulse nach kamen, aber die Darstellung jetzt ist schon etwas schräg ;) Gruß Volker -- Volker Troyke Homepage: www.troyke.de E-Mail : v...@gmx.de
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hi Volker, 2014/1/12 Volker v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal reinschauen... Schon immer falsch ist der aktuell Wert aus der Statistik nach Abschalten des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert der dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert als der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig gewesen wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller Wert eigentlich 0 stehen. S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch faken, für alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min eine 0 loggen könntest, dann wäre die Sache eindeutig. Gruß Volker Was mich wundert ist dass nicht auch andere Anwender das Problem der Nullwerte haben und schon immer hatten? vg Andreas Am 12.01.2014 13:19 schrieb Andreas Goetz: Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas 2014/1/12 Volker v...@gmx.de mailto:v...@gmx.de Hallo, ich habe gerade die aktuelle Version vom VZ geholt (git://github.com/__volkszaehler/volkszaehler.org.__git http://github.com/volkszaehler/volkszaehler.org.git). Dabei ist mir aufgefallen, dass die Darstellung fehlerhaft ist. Zum Vergleich im Anhang screenshot eines Kanals mit der aktuellen und der Version die ich am 3.1. installiert habe. Der Kanal hat die Besonderheit, dass zeitweise über mehrere Stunden gar keine S0-Impulse kommen, weil das Gerät schlicht abgeschaltet ist. Der Wert aktuell in der Statistik war eigentlich schon immer fehlerhaft , wenn keine neuen Impulse nach kamen, aber die Darstellung jetzt ist schon etwas schräg ;) Gruß Volker -- Volker Troyke Homepage: www.troyke.de http://www.troyke.de E-Mail : v...@gmx.de mailto:v...@gmx.de -- Volker Troyke Homepage: www.troyke.de E-Mail : v...@gmx.de
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hi, 2014/1/12 Volker v...@gmx.de Hi Andreas, das mit der Statistik war schon immer so. Die S0 Impulse schreibt ein AVR-Netio ein mal pro Minute in die Datenbank, aber ich vermute eben nicht, wenn gar kein Impuls kam. 0-Werte werden in der Datenbank so nicht auftauchen. Da muss ich mir das Teil mal ansehen, ob ich dem beibringen kann die Updates auch zu machen, wenn gar kein Impuls kam... Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ja ok wenn aber zwischen dem vorletzten Datenbankeintrag und dem letzten einige Minuten oder Stunden Zeit vergangen ist, muss der Verbrauchswert _dazwischen_ aber auch sehr klein oder fast 0 sein. korrekt. Nicht 0 aber nahe dran. Bei der aktuellen middleware wird der vorletzte und letzte Datenbankeintrag einfach mit einer Geraden auf der Höhe des letzten Verbrauchswerts verbunden. Das klingt falsch. Darstellung steps? Mal schauen ob lines einen Unterschied macht. Und das stimmt so nicht. Der Verbrauchswert in der Statistik stimmt jedoch. Ich kann Dir eine SQL-Dump der letzen 3 Jahre zukommen lassen, das sind aber gezippt 18MB. Ich habe Dir den Link als PM geschickt. Angekommen, danke! Das mit dem git reset habe ich versucht, die Darstellung ändert sich irgendwie nicht. Ist das richtig git reset feb7ca2b5fe3aa3023e7e640a6aaf4fd207ad95f um den letzten merge rückgängig zu machen? Du musst die Nummer des Commits eingeben auf den Du kommen willst- also den davor. Im master Zweig ist der letzte vom 3. Januar (siehe git log): commit 7431faf4c6ebe7b18349919a02ed90a9fca3fac3 Author: andig cpui...@gmx.de Date: Wed Jan 1 18:52:20 2014 +0100 Allow --eval to access arrays by index Also git reset 7431faf4c6ebe7b18349919a02ed90a9fca3fac3 bzw. schrittweise von neu nach alt an diesen Zeitpunkt herantasten. Es wäre wirklich hilfreich wenn Du herausfinden könntest welcher Commit das Problem macht. Egal auf welchen commit ich resette, die Darstellung ist immer falsch. Nur die Version die ich am 3.1. mit dem Install script installiert habe funktioniert... (und alles davor). Dann müsste sich das mittels git reset ebenfalls hinbekommen lassen. Ist leider der einzige Weg den Schuldigen zu finden... vg Andreas Gruß Volker Am 12.01.2014 14:10 schrieb Andreas Goetz: Hi Volker, 2014/1/12 Volker v...@gmx.de mailto:v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Hast Du evtl. eine Kopie der Datenbank per PM für mich? Würde mal reinschauen... Schon immer falsch ist der aktuell Wert aus der Statistik nach Abschalten des Verbrauchers wenn dann keine S0 Impulse mehr nachkommen. Der Wert der dann angezeigt wird liegt irgendwo zufällig zwischen den letzten Wert als der Verbraucher noch lief und 0 (wobei 0 bzw. 1...4W hier richtig gewesen wäre). Das siehst Du gut im Bild vz_ok_tag, da müsste als aktueller Wert eigentlich 0 stehen. S.o.- das kann's nicht. Für den aktuellen Wert liesse sich das noch faken, für alte Werte nicht vernünftig. Eleganter wäre es wenn Du z.B. alle 10min eine 0 loggen könntest, dann wäre die Sache eindeutig. Gruß Volker Was mich wundert ist dass nicht auch andere Anwender das Problem der Nullwerte haben und schon immer hatten? vg Andreas Am 12.01.2014 13:19 schrieb Andreas Goetz: Hallo Volker, kannst Du mal schauen ob dieser Commit hier https://github.com/__volkszaehler/volkszaehler.org/__pull/87 https://github.com/volkszaehler/volkszaehler.org/pull/87 bei Dir schon mit drin inst? Kanns Du genauer beschreiben was schon immer falsch und jetzt schräg bedeutet? Was wäre das erwartete verhalten? vg Andreas 2014/1
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Also... 2014/1/12 Andreas Goetz cpui...@gmail.com Hi Volker, 2014/1/12 Volker v...@gmx.de Hi Andreas, Die Version ist brandaktuell, git pull sagt up-to-date, da sollte merge87 drin sein. Check. Könntest Du evtl. mal testen wie es _genau_ vor diesem Patch war? Git git reset kannst Du auf einen bestimmten Commit zurückgehen. Schräg ist, dass die Grafik nicht mehr auf 0 geht, wenn der Verbraucher aus ist, bzw. auf 1W abgesunken ist. Wird denn bei 0 auch nochmal eine 0 geschrieben? VZ nimmt sonst immer den letzten Wert an- das Verhalten hat sich aber auch nicht geändert. VZ kann ja nicht wissen ob/ dass keine Daten = 0, oder nach welcher zeti dies gelten soll... Ganz krass zu sehen in der Wochengrafik (aktuell) und im der Tagesgrafik von ca. 20:30 bis ca. 21:15 Uhr, da ist der Verbrauch auch eigentlich nahezu 0. Um 21:15 ist vermutlich ein S0-Impuls gekommen, weil hier ein Verbrauch im 1..4W Bereich besteht. Das Verhalten für 20:30 lässt sich erklären: commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a Merge: feb7ca2 ff2ced5 Author: Justin Otherguy jus...@justinotherguy.org Date: Sun Jan 12 03:26:35 2014 -0800 Merge pull request #87 from andig/master-timestampfix Make all interpreters use timestamp at end of period Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt; aber halt anders. gleiches Bild, der 0-Wert wird nur später erreicht. Schau Dir für eine Erklärung gerne mal den PR an. Deshalb zum Vergleich auch die Screenshot der Middleware vom 3.1., da ist es korrekt dargestellt. Die Statistiken sind aber ok (bis auf den aktuell Wert bei abgeschaltetem Verbraucher s.u.). Für die Wochendarstellung ok/aktuell ist die Ursache eine andere. Hier liegts daran, dass auf aggregierte Werte mit geringerer zeitlicher Auflösung (groupy=hour) zurückgegriffen wird. Wenn Dir das nicht gefällt kannst Du mal in der options.js mit der Variable speedupFactor rumspielen. Kleinere Werte bringen bessere Auflösung, sind aber auch langsamer wenn das FE dann kein groupby mehr auswählt... Erklärung nachvollziehbar und Problem gelöst? vg Andreas ...
Re: [vz-dev] s0vz: Überflüssige Updates bei jedem Insert?
Hallo Heiko,
2014/1/12 Heiko Baumann h...@gmx.de
Hm. Ich hab vorhin mit git pull meinen vz geupdatet:
pi@BauratPi /var/www/volkszaehler.org $ sudo git pull
remote: Counting objects: 73, done.
remote: Compressing objects: 100% (70/70), done.
remote: Total 73 (delta 29), reused 34 (delta 3)
Unpacking objects: 100% (73/73), done.
From git://github.com/volkszaehler/volkszaehler.org
ec0c82d..ba113f6 master - origin/master
Updating ec0c82d..ba113f6
Fast-forward
.../Interpreter/CounterInterpreter.php | 27 ++
lib/Volkszaehler/Interpreter/MeterInterpreter.php |3 +-
.../Interpreter/SQL/MySQLAggregateOptimizer.php| 90
+++-
lib/Volkszaehler/Interpreter/SQL/SQLOptimizer.php |3 +-
lib/Volkszaehler/Interpreter/SensorInterpreter.php |3 +-
lib/Volkszaehler/Model/Property.php| 13 ++-
lib/Volkszaehler/View/CSV.php | 52 +++
lib/Volkszaehler/View/JSON.php | 32 ++-
lib/Volkszaehler/View/JpGraph.php |8 +-
lib/Volkszaehler/View/XML.php | 80
++---
misc/tools/vzclient| 16 ++--
test/Tests/DataCounterTest.php |2 +-
test/Tests/DataMeterTest.php |2 +-
13 files changed, 135 insertions(+), 196 deletions(-)
- damit sollten doch alle updates drin sein, oder?
Ja- Commit 8ac2c5039273b590aec2a9890f87400c08b949a8 liegt dazwischen.
Im mysql-log gehts aber nach wie vor extrem wüst zu:
17345 Connect vz@localhost on volkszaehler
17345 Query SELECT e0_.id AS id0, e0_.uuid AS uuid1,
e0_.type AS type2, p1_.id AS id3, p1_.pkey AS pkey4, p1_.value AS value5,
e0_.class AS class6, p1_.entity_id AS entity_id7 FROM entities e0_ LEFT
JOIN properties p1_ ON e0_.id = p1_.entity_id WHERE (e0_.uuid =
'ae9d1b00-f2f5-11e2-8a1f-0dad1c039958') AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
140112 22:33:47 17345 Query START TRANSACTION
17345 Query INSERT INTO data (timestamp, value,
channel_id) VALUES ('1389562426842', '1', 16)
17345 Query UPDATE properties SET value = '1' WHERE id
= 83
17345 Query UPDATE properties SET value = '1' WHERE id
= 81
17345 Query UPDATE properties SET value = '360'
WHERE id = 79
17345 Query commit
17345 Quit
Insofern also alles beim alten. Wie krieg ich die neueste Version?
Ich kann's nicht mehr nachvollziehen:
SELECT e0_.id AS id0, e0_.uuid AS uuid1, e0_.type AS type2, p1_.id AS id3,
p1_.pkey AS pkey4, p1_.value AS value5, e0_.class AS class6, p1_.entity_id
AS entity_id7 FROM entities e0_ LEFT JOIN properties p1_ ON e0_.id =
p1_.entity_id WHERE (e0_.uuid = ?) AND e0_.class IN ('channel',
'aggregator') ORDER BY p1_.pkey ASC
START TRANSACTION
INSERT INTO data (timestamp, value, channel_id) VALUES (?, ?, ?)
COMMIT
Bist Du sicher dass der Code den Du siehst auch wirklich der ist der
ausgeführt wird?
vg
Andreas
Re: [vz-dev] Darstellungprobleme aktuelle VZ-Version
Hallo Volker, über die Wochenansicht muss ich nochmal nachdenken, bei der Tagesansicht ist alles- bis auf Verschiebung um einen TS- ok. 2014/1/12 Volker v...@gmx.de ... commit 380e084c0f8ad538dabdb33de84f8c1ac19d858a Merge: feb7ca2 ff2ced5 Author: Justin Otherguy jus...@justinotherguy.org mailto:jus...@justinotherguy.org Date: Sun Jan 12 03:26:35 2014 -0800 Merge pull request #87 from andig/master-timestampfix Make all interpreters use timestamp at end of period Dabei werden aber einfach die Timestamps um 1 verschoben. M.e. ist die Darstellung ok/aktuell nicht falscher als vorher sondern jetzt korrekt; aber halt anders. gleiches Bild, der 0-Wert wird nur später erreicht. Schau Dir für eine Erklärung gerne mal den PR an. Ich stecke jetzt in den Details nur wenig drin, ich finde nur das die grafische Darstellung falsch ist. Um bei dem Beispiel des Tageswertes zu bleiben: Um ca. 20:15 wird ein Eintrag mit n S0-Impulsen in die Datenbank geschrieben. Der Verbrauch geht danach auf nahezu 0. Um ca. 21:15 wird vermutlich ein einziger S0-Impus in die Datenbank geschrieben. Dann berechnet sich doch der Momentanverbrauch zwischen 20:15 und 21:15 aus der Zeitspanne (hier 1 Stunde) und dem in der Zeit aufgelaufenen Impulsen (hier 1). Die grafisch Darstellung und auch der Cursor zeigt in dem Zeitfenster aber irgendwas von 570W - und das ist schlichweg falsch. Dazu gehören folgende Timestamps (CSV Export und DB-Werte), Uhrzeit habe ich mit ausgerechnet: 1388775808000 591 20:03:28 DB 1388775872000 618,75 20:04:32 22 1388775936000 591 20:05:36 21 138877600 253 20:06:40 9 1388780096000 0,439 21:14:56 1 1388780288000 9 21:18:08 1 1388781888000 20,25 21:44:48 18 Bis 20:04 feuert S0 ordentlcih, Leistung 500. bis 20:06 gehen die Impulse deutlich zurück Leistung 253 (der Abfall) Erst 21:14 kommt wieder was- Leistung annähernd 0. Was jetzt tatsächlich unschön ist ist, dass die Steps einen Timestamp verschoben scheinen, also step-after statt step-before. Der Effekt tritt auf da die MW-Timestamps jetzt korrekt sind, eigentlich ist die Grafik falsch. Ich muss mal schauen ob sich das sinnvoll ändern lässt, zur Not muss der commit wieder raus. vg Andreas
