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
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] [vz-users] Gaszähler Startwert
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
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
