[vz-dev] Absoulter Verbrauch in Volkszaehler speichern

[karlheinz.es at gmx.de]

Hi,

habt ihr das Problem des absoluten Verbrauchs bereits gelöst? Ich kenne 
folgende folgende Vorgehensweise:
- Beim Erfassen/Übertragen gibt es ein Kennzeichen für Differenz- oder 
Absolutwert (Zählerstand)
- Der Zählerstand wird bei jedem Erfassen/Übertragen automatisch 
berechnet u. in die DB eingetragen. D.h. bei einer Differenzübertragung 
wird anhand des letzten Datensatzes der Zählerstand + Differenz 
berechnet und ebenfalls in den neuen Datensatz eingetragen. Wenn jemand 
nachträglich übers Frontend einen Zählerstand hinzufügt, wird geprüft, 
ob zeitlich nachfolgende Werte existieren und überschreibt nach einer 
entsprechenden Warnung, den Zählerstand aller nachfolgenden Datensätze.
Einen großen Vorteil hat diese doppelte Speicherung von Differenz u. 
Absolutwert: Der Verbrauch zwischen zwei Punkten kann ganz einfach durch 
den ersten u. letzten Datensatz über den Absolutwert errechnet werden.
Beim Anzeigen von Aggregatfunktionen (z.B. Summenbildung per Monat) ist 
dennoch der Verbrauchswert zum Summieren vorhanden.
Was mir heute im Frontend fehlt, ist die Verbrauchsanzeige von 
Monaten/Wochen in einem anschaulichen Balkendiagramm im Vergleich zu 
einem Vorgänger-/Vorjahreszeitraum. Lässt sich da was machen?

Gruß
Karlheinz

------- Original Nachricht --------
Betreff: Re: [vz-dev] Absoulter Verbrauch in Volkszaehler speichern
Von: Steffen Vogel <info at steffenvogel.de>
An: volkszaehler.org <volkszaehler-dev at lists.volkszaehler.org>
Datum: Dienstag, 6. Dezember 2011 01:53:01
> Am Dienstag, den 06.12.2011, 01:32 +0100 schrieb Steffen Vogel:
>> Leider fällt mir gerade noch keine gut Mögllichkeit ein, wie wir die
>> absoluten Zählerstände von den Relativen unterscheiden könnten.
>> Wir haben die der "data" Tabelle derzeit 3 Spalten:
>> - channel_id
>> - timestamp
>> - value
> Ich bin gerade noch auf eine Alternative gekommen:
>
> Wir haben ja bereits in der Übertragung zum Frontend folgendes Format
> für einen Datensatz:
>
> tuples": [
>      [
>          1323086404066,
>          7.3,
>          1
>      ],
>
> Also [ timestamp, value, tuple_count ]. Der letzte Wert ist vielleicht
> etwas irritierend. Er enthällt nur die Anzahl der Tuple die benutzt
> wurden um diesen Wert zu bestimmen (Wir müssen ja meist mehrere Tuple
> zusammenfassen um das JS Frontend nicht zu überlasten).
>
> Ich kann mir gut vorstellen, dass wir dieses Feld auch in die Datenbank
> aufnehmen. Momentan macht das noch wenig Sinn, da in der Datenbank ja
> immer nur einzellne Pulse liegen;  der Wert also immer 1 wäre.
>
> Aber für die Zukunft haben wir noch ein weiteres Problem:
> Was passiert wenn ich mit die Daten meines SML Zählers über das ganze
> Jahr betrachten will: 365*24*60*60/3 = 7632000 Impulse, die wir
> verarbeiten müssten =>  Aua :(
>
> Wir kommen daher wohl nicht darum umher ähnliches wie rrdtool zu machen:
> Dort ist die Größe der Datenbank konstant. Ältere Daten werden zeitlich
> schlechter aufgelöst.
>
> Wir könnten also wöchtenlich alte Daten zusammenfassen und auch so in
> Datenbank speichern. Also eigentlich nichts anderes, wie wir es bereits
> derzeit für das Frontend machen. Nur dass wir die Daten in der Datenbank
> ablegen.
>
> Um das zu realisieren sollten wir auch den "Grad" der Kompression (das 3
> Feld des JSON-Ausschnitts von oben) in das Datenbank-Schema aufnehmen.
>
> Das könnten wir aber auch misbrauchen und mit einem speziellen Wert
> (z.B. "-1") kennzeichnen, dass es sich um ein Datensatz mit dem
> aktuellen Zählerstand und nicht um einen gewöhnlichen Impuls handelt.
>
> Das ist eigentlich etwas getrickst. Mir würde die erste Variante
> ("Schattenzähler") besser gefallen.
>
> viele Grüße
>
> Steffen
>
>
>
> _______________________________________________
> volkszaehler-dev mailing list
> volkszaehler-dev at lists.volkszaehler.org
> https://volkszaehler.org/mailman/listinfo/volkszaehler-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20111220/f03db722/attachment.html>