[vz-dev] Fwd: Re: Offene Enden

Mon May 24 15:49:09 CEST 2010

Am Montag, den 24.05.2010, 14:34 +0200 schrieb Peer Janssen:
> > 
> > Hört sich sehr interessant an. Diese Daten zu aggretieren macht hier
> > sicherlich Sinn. Ich frage mich nur ob das denn eigentlich noch Ziel des
> > Projekts ist.
> 
> Ist es: Das Volk zählt selbst.

Ja zählt, aber das Messen von Strahlung und Temperatur würde ich nicht
unter den Begriff "zählen" fassen.

> 
> Nun, wenn man beim Loggen keine Rückmeldung erhält, weiß man letztlich 
> nicht, ob die Daten auch registriert wurden.
> 
> Zumindest ein "OK" oder "Fehler: Kein Platz mehr in der Datenbank" 
> "Fehler: UUID nicht registriert" usw. sollte jetzt schon geliefert 
> werden, damit man die Daten ggf. lokal (zwischen-)speichern kann (RAM / 
> SD-Karte / lokaler Server).
> 
> Dann ist der Schritt zu einem Daten/Warn-Rückkanal nicht mehr groß, da 
> man nur noch die Statusmeldung etwas erweitern müsste, aber die sonstige 
> Infrastruktur schon da ist.
> Eine rote LED (wahlweise ein kleiner Summer), die ein evtl. 
> Serverproblem anzeigt, ist doch super! Sonst merkt man das doch nicht.

Joa die Idee find ich gut. Flusko verwendet wohl ein RESTful API.
Vielleicht sollte man sich hier wirklich auf einen Standard einigen und
diesen gemeinsam vorrantreiben.

> Um die Daten mit vertretbarem Aufwand zu finden, muss man sie aber auch 
> noch indizieren.
> Man könnte sie natürlich auch anders zusammenfassen, z.B. alle Werte 
> eines Tags in einen Blob tun, und dazu für jeden Tag gewisse Mittelwerte 
> usw., um mehrtägige Daten auch anzeigen zu können, ohne alle Blobs 
> auspacken zu müssen.
> 
> Man könnte auch frische Daten sehr genau speichern, aber dann nach 
> gewissen Zeiträumen (nach 1 Woche / 1 Monat / 1 Jahr) die Daten 
> kompakter speichern, um die Datenmenge zu reduzieren, aber trotzdem noch 
> Rechnungen und Strompreise langfristig vergleichen und überprüfen zu können.

rrdtool [1] ist hier das Stichwort. Das ist eine Round Robin Datenbank,
die im Prinzip genau das macht. Das rrdtool Projekt kann die Daten auch
gleich virtualisieren. Sicherlich eine Alternative die für embedded
System interessant ist. Da hier ein großes RDBMS und PHP Interpreter
überflüssig wäre.

Hier [2] noch ein  kleines Zitat:

        Das von Tobias Oetiker entwickelte RRD-Tool stellt mittlerweile
        den Quasi-Standard für die Speicherung von Monitoringdaten dar.
        Es legt seine Daten in so genannten Round-Robin-Datenbanken
        (RRD) ab, die dann von diversen Frontends wie Munin, Orca oder
        Cacti genutzt werden.

        Im Round-Robin-Archiv liegen die erfassten Messwerte auf einer
        begrenzten Anzahl von Speicherplätzen, beginnend um 0 Uhr und
        dann im Uhrzeigersinn bis zum aktuellen Wert von 3,1 um 0:15 Uhr
        (Zeiger). Da der nächste Messwert 0:20 Uhr aber nicht mehr ins
        Archiv passt, wird der Wert von 0 Uhr überschrieben.

        Wäre man nur an den Daten der letzten paar Minuten interessiert,
        wäre dies kein Problem, aber auch hierfür gibt es eine Lösung
        ohne dass man riesige Datenmengen speichern muss. Die Lösung
        heißt Unschärfe, welche über lange Zeiträume akzeptabel ist. Das
        RRD-Tool legt hierzu weitere Archive an, welche die
        Durchnittswerte (oder Min/Max-werte speichert). Sind diese
        Archive erst einmal in einer RRD angelegt, speichert das
        RRD-Tool kontinuierlich die entsprechenden Messwerte ab.

        Der sich daraus ergebende Vorteil ist eine schnelle Datenbank
        mit fester Größe.

> 
> > Justin hat in seinen Demo Daten über einen Tag hinweg 7213 Impulse
> > registriert und gespeichert. Rechnen wir mal grob und großzügig mit 10k
> > pro Tag:
> > 
> > 10000 * 10byte = 100kb pro Tag
> > 100kb * 365 = 36,5mb pro Jahr
> > 
> > Das halte ich für vertretbar.
> 
> Für wen? Vor allem: wie viele?
> Man sollte das auch mal umkehrt rechnen: Der Durchschnittliche 
> Stromverbrauch sollte irgendwo im Web eruierbar sein. Daraus kann man 
> dann die durchschnittlichen Impulszahlen eines Haushalts ausrechnen, 
> sofern diese im Mittel x Zähler verwendet und x Impulse/kWh produziert.
> Dann weiß man auch, wie viele Haushalte mit x GB pro Jahr gemessen 
> werden können.

Ich würde mir hier nicht so viele Gedanken um einen möglichen zentralen
Server machen. Das Projekt ist gestartet worden um gerade diese
zentralen Datenkraken aufzulösen. Und 35 MB/Jahr hab ich auf jedem
meiner Server/Rechner noch frei ;)

> Und die Daten gehen nicht von alleine wieder weg!
> Also wächst die Menge immer weiter an. Bis man sie löscht, oder bis z.B. 
> die Festplatte ausfällt.

Vielleicht macht es hier Sinn seine eigene Round Robin Datenbank auf der
Basis eine RDBMS zu entwickeln. Das wäre mit der impulsbasierten Methode
ebenso wie mit der Momentmethode möglich.

gruß Steffen

[1] http://oss.oetiker.ch/rrdtool/
[2]
http://portal.black-board.net/tutorials/blackboard_debian_server_tutorial/monitoring_mit_munin/#kap_5

-- 
Steffen Vogel
Roonstraße 106
Köln

Cell: +49 (176) 96978528
Web: http://www.steffenvogel.de
Mail & MSN: info at steffenvogel.de
ICQ: 236033
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20100524/3355686b/attachment-0001.pgp 