<div dir="ltr">Hi Rainer!<br><div class="gmail_extra"><br><div class="gmail_quote">2014-03-22 11:45 GMT+01:00 Rainer Gauweiler <span dir="ltr"><<a href="mailto:volkszaehler@moppl.inka.de" target="_blank">volkszaehler@moppl.inka.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hallo Andreas,<br>
<br>
falls ich Dein Verfahren falsch verstanden haben sollte, bitte an entsprechender Stelle eingreifen :-)<br>
<br>
Am 22.03.2014 07:35, schrieb Andreas Goetz:<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Das JSON API kann das bereits- wenn auch nicht als Kurve so doch zu<br>
einem Zeitpunkt (Feld "consumption")<br>
</blockquote>
<br></div>
Ich habe mal ein bisschen in den Code geschaut. Sie macht das über die Summierung der Werte - sehe ich das richtig? Sogar bei einem counterChannel.<br></blockquote><div><br></div><div>Korrekt. Beim Counter heisst das pro Intervall aktueller Wert - letzter Wert über alle Intervalle, also defacto letzer - erster Wert.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Damit addieren sich aber natürlich mit der Zeit Fehler, z.B. weil bei einem leistungsChannel(Power/S0) die Messung mal ausfiel. </blockquote><div><br></div><div>Beim Counter erstmal kein Problem, sonst korrekt.<br> <br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Die Umrechnung von Leistung zum Verbrauch und umgekehrt hängt auch von der Genauigkeit der Ausgabe der Zähler ab, diese ist auch sehr unterschiedlich. Auch darüber können sich Fehler einschleichen die sich dann aufsummieren.<br>

Ich würde gerne diese Fehler durch regelmäßige Ablesung im Rahmen halten.<br></blockquote><div><br></div><div>Kannst Du ja machen- aber regelmäßige Ablesung eines powersensors hins. Zählerstand ist in der VZ-Logik egtl. ein  separater Kanal.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Wenn ich Dein jetziges Verfahren richtig verstehe, dann speicherst Du einmal am Anfang den Zählerstand und summierst alles hoch, richtig?<br></blockquote><div><br></div><div>Nicht ganz. Beim Counter speichere ich by ts=0 eine 0 (wenn gewünscht) bei anderen Typen einen entsprechenden Leistungswert x Periodendauer oder Verbrauch (Meter) der aufsummiert dann den Wunschzähelrstand ergibt.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ich schlage vor, einfach weitere Messpunkte einzuführen und die Summierung dann immer vom Messpunkt aus durchzuführen der zeitlich am nächstem liegt. Das bietet die gleichen Möglichkeiten wie Deine jetzige Methode, korrigiert aber die Fehler die über die Zeit entstehen.</blockquote>
<div><br></div><div>S.o. Dafür brauchst Du einen anderen Kanaltyp, außerdem wäre die Lösung ziemlich spezifisch. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Das API hat allerdings den Haken, dass der Verbrauch nur über einen<br>
Zeitraum ermittelt werden kann, dafür aber bei allen Kanaltypen<br>
</blockquote>
<br></div>
Mit meinem Verfahren wäre das ja weiterhin möglich. Könnte mit den gemessenen Verbräuchen im Zeitraum sogar noch genauer sein.</blockquote><div><br></div><div class="">Ich sehe leider nicht wie das elegant in die MW passen soll. <br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Die Lösung besteht darin die Abfrage ab ts=0 bis Wunschzeitpunkt zu machen<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Was jegliche Optimierung der DB in Bezug auf Hauptspeicherverbrauch eliminiert. Da wird dann praktisch der komplette Channel in den Hauptspeicher geladen, nur um lediglich den ersten Wert zu nutzen. </blockquote><div><br>
</div><div>Hauptspeicher??? Und? Was glaubst Du wenn Du auf 5 Jahre raus zoomst? Genau für solche Zwecke habe ich ja die Aggregation erfunden, das ist rasend schnell und kein Problem für den Speicher. Von Frontend aus wäre es einfach ein separater Request, am API müsste sich nix ändern.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ich denke das sollte man effizienter machen. In ein paar Jahren fliegt uns das sonst um die Ohren.<br></blockquote>
<div><br></div><div>Bitte um Beweis ;)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Würde man jetzt im Frontend noch einführen, dass der aktuelle Zählerstand unten in der Tabelle steht, würden permanent alle Meßpunkte aller Channel geladen werden. </blockquote><div><br></div><div>Nicht mit Aggregation.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Damit hätten wir dann die komplette DB geladen.</blockquote><div><br></div><div>s.o.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">- Dafür braucht es einen Startzählerstand oder entsprechenden Verbrauchswert<br>

<br></div>
Lässt man einen Kanal mitlaufen, der die Zählerstände hat, dann hätte man immer einen nahen Zählerstand und müsste nicht den ersten nehmen.<br></blockquote><div><br></div><div>Davon hält Dich ja nix ab. Zählerstand als Leistung erfassen (wie es August gemacht hat) und schon kannst Du als aktuellen Wert den Zählerstand ablesen.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Das jetzige Verfahren kann nur einen Zählerstand und das muss immer der erste sein - richtig?<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS.: Der Nutzen des Zählerstandes als Kurve sehe ich nicht; eine<br>
Kanalytyo-spezifische API-Erweiterung finde ich keine gute Idee.<br>
</blockquote>
<br></div>
Kuve brauche ich auch nicht und meine Variante ist ebenfalls nicht Kanaltyp spezifisch.<br>
<br>
Bei der jetzigen Variante finde ich es architektonisch ungeschickt, dass bei den Werten eines Channels ein Wert eine andere Bedeutung (Energie vs Leistung) hat.<br></blockquote><div><br></div><div>Versteht ich nicht. Das JSON API gibt immer Leistung (bzw Momentanwerte) aus.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Lagert man die Zählerstände aus haben alle Werte die gleiche Bedeutung und die Strukturen bleiben sauber.<br>
Verbinden würde ich die beiden Kanäle über eine Eigenschaft in den Properties - entsprechend zu hasConsumption.<br></blockquote><div><br></div><div>Dann brauchs einen neuen Interpreter vom Typ "CounterValueInterpreter" der sinnigerweise nur einen einzelnen Wert liefern würde. Dennoch hast Du dann die Probleme durch die komplette Datenerfassung oder musst es manuell machen.<br>
<br></div><div>Meine Methode nutzt was da ist und bleibt für alle Anwendungsfälle transparent. Und sie ist seit 4 Monaten fertig ;)<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Gruss<span class="HOEnZb"><font color="#888888"><br>
     Rainer<br>
<br>
<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">vg,<br>Andreas<br></div></div>