[vz-dev] Absoulter Verbrauch in Volkszaehler speichern

[Sven Anders]

Am 13.12.2011 13:47, schrieb Jakob Hirsch:
> Hi,
>
> Steffen Vogel, 2011-12-06 01:32:
>>>> Wie wäre es, wenn für den MeterInterpreter nur
>>>> immer den relativen Verbrauch speichern und diesen dann alle 100 Impulse
>>>> summieren? Allso immer 100 Datensätze für die Impulse gefolgt von einem
>>>> Datensatz mit dem absoluten Verbrauch?
>
> Ich bin jetzt den Thread nochmal durchgegangen. Bevor wir irgendwelche
> krummen Sachen bauen, die unnötig komplex sind: Wozu brauchen wir das
> nochmal? Ich hab nur  "Zählerwechsel" und "Downtime von Technik" gefunden.

Wozu brauchen wir das nochmal:

Es gibt halt 3 verschiedene Arten von Zählererfassung, ich mach das mal 
(weil es so schön plastisch ist, anhand von Wasserzählern).

* Zähler die die Geschwindigkeit im Wasserrohr messen (z.B. in Litern 
pro Sekunde). Wenn man das oft genug macht und erfasst, kann man daraus 
auch ablesen wieviel Liter zwischen zwei Zeitpunkten verbraucht werden 
(Mathematik: Ein Integral darüber bilden). [Das ganze ist für 
Wasserzähler eher theoretisch, aber bei manche Stromzähler z.B. Flukso 
funktionieren intern so]. In VZ: SensorInterpreter

* Zähler die pro Liter (oder auch 10/ 100 l) einen Impuls absetzen. In 
VZ: MeterInterpreter

* Zähler bei den man ablesen kann, wieviel Liter seit dem Einbau 
verbraucht wurden: In der VZ Middelware/Frontend: z.Zt nicht abbildbar, 
wird z.T. im Conroler umgesetzt, indem auf MeterInterpreter umgesetzt wird.


Egal welche Zählererfassungsmethode wir benutzen, habe ich alsBenutzer 
immer noch mehrere Use-Cases:

* Ich möchte wissen, wieviel ich in einem Zeitraum verbraucht habe. 
(VZ:Erledigt)

* Wo Spitzenwerte sind (das ist wieder die Geschwindigkeit im 
Wasserrohr). (VZ:Erledigt durch Kurvendarstellung)

* Ich möchte für einen bestimmten Zeitpunkt Zählerstände ablesen können, 
dabei sollte es möglichst egal sein, mit welcher Art von Technik (s.o.) 
die Zählerstände berechnet werden. (VZ: Keine Lösung)


Für mich sieht das große Bild so aus: Wir müssen sowieso das eine in das 
andere abbilden können, ich bin mir deshalb nicht mehr so sicher, ob der 
Interpreter Ansatz da eine große Hilfe ist.

Das Problem, was ich z.Zt am Inpreter Ansatz sehe, ist das wir auf Lange 
sicht für jede Messform (Wasser, Wärme, Gas, Strom etc.) in der 
Definition ein Dreierpack hätten.

Hinzu kommt (zu den Punkten Zählerwechsel, Downtime) noch ein weiterer 
Punkt: "Cacheing". Moderne Zähler liefern so viele Daten, das wir sie in 
der GUI unmöglich für große Zeiträume aus den Rohdaten anzeigen können.

Beispiel: Ein Zähler liefert alle 3 Sekunden einen Verbrauchsewert. 
Macht bei einer 2 Jahres - Ansicht: 60/3*60*24*365*2= 21 Millionen Werte 
die Summiert (für den Zählerstand), Maximum, Minimum und vereinfacht 
werden müssen (eine Grafik hat vielleicht 1024*768 Punkte oder so). Der 
VZ skaliert hier noch nicht. Trotzdem kann man die Daten in Rohform in 
die Mysql-DB packen, das sind pro Tag und Zähler (Annahme ein Byte für 
die Zeitdiffrenz zum letzen Zählerstand und zwei Bytes für die Anzahl 
Impulse) gerade mal 86 kByte, könnte man also z.B. in ein Blob packen. 
Wenn der Benutzer eine geringe Auflösung wählt, werden diese Werte 
benutzt. Ansonsten nur die vereinfachten Werte.

Darauf gehst du ja weiter unten ein.

>
> "Downtime" hab ich nicht verstanden, aber Zählerwechsel ist durchaus ein
> Thema. Aber ich denke, wir sollten für solche seltenen Ereignisse nicht
> übermäßig kompliziert behandeln. Für's Erste ist es durchaus zumutbar,
> bei einem Zählerwechsel zwei getrennte Channels zu betrachten, das ist
> primär für Zeiträume unschön, die über den Wechsel drüber gehen. Später
> können wir die beiden Channels über einen Aggregator zusammenfassen, so
> daß er sich wie ein einziger anfühlt. Das ist sicher um einiges
> eleganter (und für andere Sachen nützlicher) als direkt in den Channels
> Spezialbehandlung einbauen zu müssen.


Downtime meint einfach, das die Infrastruktur nicht zur Verfügung steht 
z.B. wegen eines Stromausfalls oder eines defekten Rechners.

Im Falle einer Meter oder Sensor Interpreter Schnittstelle muss man bei 
einer Downtime Werte nacherfassen, damit der richtige Zählerstand heraus 
kommt.

>
> Wir brauchen sowieso noch mehr virtuelle Channels, die Daten aus anderen
> Channels verarbeiten, z.B. für die Erfassung von Eigenverbrauch bei
> PV-Anlagen. Für die Verarbeitung vieler Impulse kann man
> Reducer-Channels benutzen, die (kontinuierlich oder per cron) von einem
> anderen Channel gefüttert werden. Das Hauptproblem dabei dürfte sein,
> das im Frontend sinnvoll benutzbar zu machen (möglichst automatisch).
> Dafür werden wir wohl auch Relationen zwischen Channels abbilden müssen.
>
> Aber eins nach dem anderen. :)
> Wenn ich's mal die Tage geschafft habe, Udo's eHZ-Kopf bei mir zu
> installieren, würde ich mich mal an dem CounterInterpreter versuchen.

Hört sich gut an. Ich mache gerne mit. Für mich ist halt der 
CounterIntrepreter z.Z. am wichtigsten, da mein Papa halt Zählerstände 
in der GUI braucht.

Gruß
Sven


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2321 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20111213/3edf38f2/attachment.bin>