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

[Andreas Goetz]

Hi Rainer!

2014-03-22 11:45 GMT+01:00 Rainer Gauweiler <volkszaehler at moppl.inka.de>:

> 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.
>

Korrekt. Beim Counter heisst das pro Intervall aktueller Wert - letzter
Wert über alle Intervalle, also defacto letzer - erster Wert.


>
> Damit addieren sich aber natürlich mit der Zeit Fehler, z.B. weil bei
> einem leistungsChannel(Power/S0) die Messung mal ausfiel.


Beim Counter erstmal kein Problem, sonst korrekt.


> 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.
>

Kannst Du ja machen- aber regelmäßige Ablesung eines powersensors hins.
Zählerstand ist in der VZ-Logik egtl. ein  separater Kanal.


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

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.


> 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.


S.o. Dafür brauchst Du einen anderen Kanaltyp, außerdem wäre die Lösung
ziemlich spezifisch.

>
>
>  - 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.


Ich sehe leider nicht wie das elegant in die MW passen soll.

 - 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.


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.

Ich denke das sollte man effizienter machen. In ein paar Jahren fliegt uns
> das sonst um die Ohren.
>

Bitte um Beweis ;)


> 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.


Nicht mit Aggregation.


> Damit hätten wir dann die komplette DB geladen.


s.o.


> - 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.
>

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.


> 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.
>

Versteht ich nicht. Das JSON API gibt immer Leistung (bzw Momentanwerte)
aus.

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.
>

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.

Meine Methode nutzt was da ist und bleibt für alle Anwendungsfälle
transparent. Und sie ist seit 4 Monaten fertig ;)


> Gruss
>      Rainer
>
>
>
vg,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-dev/attachments/20140322/86af9538/attachment.html>