[vz-dev] Zählerstand per middleware holen?

[Rainer Gauweiler]

Hallo Andreas,

falls ich Dein Verfahren falsch verstanden haben sollte, bitte an 
entsprechender Stelle eingreifen :-)

Am 22.03.2014 07:35, schrieb Andreas Goetz:
> - Das JSON API kann das bereits- wenn auch nicht als Kurve so doch zu
> einem Zeitpunkt (Feld "consumption")

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.

Damit addieren sich aber natürlich mit der Zeit Fehler, z.B. weil bei 
einem leistungsChannel(Power/S0) die Messung mal ausfiel. 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.
Ich würde gerne diese Fehler durch regelmäßige Ablesung im Rahmen halten.

Wenn ich Dein jetziges Verfahren richtig verstehe, dann speicherst Du 
einmal am Anfang den Zählerstand und summierst alles hoch, richtig?

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.

> - Das API hat allerdings den Haken, dass der Verbrauch nur über einen
> Zeitraum ermittelt werden kann, dafür aber bei allen Kanaltypen

Mit meinem Verfahren wäre das ja weiterhin möglich. Könnte mit den 
gemessenen Verbräuchen im Zeitraum sogar noch genauer sein.

> - Die Lösung besteht darin die Abfrage ab ts=0 bis Wunschzeitpunkt zu machen

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. Ich 
denke das sollte man effizienter machen. In ein paar Jahren fliegt uns 
das sonst um die Ohren.
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. Damit hätten wir dann die komplette DB 
geladen.

> - Dafür braucht es einen Startzählerstand oder entsprechenden Verbrauchswert

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.

Das jetzige Verfahren kann nur einen Zählerstand und das muss immer der 
erste sein - richtig?

> PS.: Der Nutzen des Zählerstandes als Kurve sehe ich nicht; eine
> Kanalytyo-spezifische API-Erweiterung finde ich keine gute Idee.

Kuve brauche ich auch nicht und meine Variante ist ebenfalls nicht 
Kanaltyp spezifisch.

Bei der jetzigen Variante finde ich es architektonisch ungeschickt, dass 
bei den Werten eines Channels ein Wert eine andere Bedeutung (Energie vs 
Leistung) hat.

Lagert man die Zählerstände aus haben alle Werte die gleiche Bedeutung 
und die Strukturen bleiben sauber.
Verbinden würde ich die beiden Kanäle über eine Eigenschaft in den 
Properties - entsprechend zu hasConsumption.

Gruss
      Rainer