[vz-dev] Fwd: Re: Offene Enden

[Steffen Vogel]

Am Montag, den 24.05.2010, 13:00 +0200 schrieb Peer Janssen:
> Moin!
> 
> Steffen Vogel schrieb:
> > Wir sollten bedenken, das die Wahl des Speicherformats (z.B. pro Puls
> > eine Zeile in der DB) ja auch zugleich andere Messgrößen (z.B.
> > Temperatur, Luftdruck etc.) vom Prinzip her ausschließt.
> > 
> > Ich finde wir sollten uns auf impulsbasierte Zähler beschränken. Diese
> > haben neben der Auswertung und der Speicherung auch die Tatsache
> > gemeinsam, dass hier Mengen gemessen werden. Damit verbunden könnten wir
> > in Zukunft Kosten, Hochrechnungen usw. berechnen.
> > Das unterscheidet sie von Messgrößen wie zB. der Temperatur.
> 
> Oinspruch!
> 
> Ich möchte mit der API Radioaktivitätswerte anzeigen. Das ist ein bissel 
> ein Gimmick, solange nix Schlimmes passiert ... kann aber im umgekehrten 
> Fall sehr bedeutsam werden.
> Das benötigt einen INT Zählwert (16 Bit) pro Minute.

Bei Radioaktivitätswerten denke ich sofort an Gaigerzähler. Das sind
doch auch nur Impulszähler. Oder irre ich mir hier?

> 
> Damit verbunden sollten Wetterdaten sein, die zur Auswertung ggf. 
> ebenfalls erforderlich sind. (Weil die Luft-Radioaktivität immer etwas 
> steigt, wenn es regnet: der Regen wäschst das Zeugs aus der Luft, sodass 
> die Aktivität am Boden dann leicht erhöht ist. Wegen sowas will man bei 
> Regenfall mit normaler Hintergrund-Radioaktivität natürlich keinen 
> besonderen Alarm schlagen.)
> 
> Wetter- und Temperaturdaten wiederum sind auch gerade im Zusammenhang 
> mit Heiz- und Stromkosten sehr relevant! Man kann Korrelationen fahren, 
> die wahrscheinlich höchst interessant sein werden, wenn die Daten 
> erstmal über längere Zeit vorliegen (und eine Möglichkeit, solche Daten 
> mit anderen Leuten (freiwillig) zu poolen, sollte dann noch mehr 
> Erkenntnisse bringen):
> 
> Temperatur => Stromverbrauch, Heizverbrauch
> Wind => Temperatur im Haus
> usw.

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. Vielleicht wäre eine klare Definition des Projektziels
angebracht. 

> 
> All das um zu sagen, dass man den Sensortyp definieren können sollte. Es 
> wäre gut, wenn sich das irgendwie verallgemeinern ließe. Dann könnte ein 
> AVR NET-IO verschiedene Sensoren nutzen und beim Hochfahren 
> (Einschalten) die lokal eingestellten Sensorname-, Sensortyp- und 
> Messbereichs- und Auflösungsdaten zur jeweiligen Sensornummer ankündigen.

Das habe ich in meinem Backendkonzept schon angdacht. Hier gibt es eine
abstrakte Klasse "Meter" die Kindklassen "ElectricMeter", "WaterMeter"
und "GasMeter" implementieren dann den Rest.

Da du hier die Temperatur und Drucksensoren noch angesprochen hast:
Im Prinzip wäre es hier möglich unter der abstrakten "Meter" Klasse noch
zwei Kindklassen "PulseMeter" und "ValueMeter" zu implementieren. Diese
verschiedenen Ansätze zu kombinieren halte ich jedoch für fragwürdig. Es
wären zwei Tabellen nötig => mehr SQL Queries => langsamer. 

> 
> Überhaupt wäre eine Warn-API nützlich. Mit der man Schwellenwerte 
> einstellen kann. Z.B. Temperatur zu hoch / Luft zu trocken => Pflanzen 
> und Hamster drohen einzugehen. Plötzlicher hoher Stromverbrauch => Gerät 
> kaputt => Brandgefahr.
> Das könnte gegen absolute Schwellenwerte gehen oder als schnelle Sprünge 
> gegen gleitende Mittelwerte usw. Benachrichtigung dann über E-Mail, 
> und/oder vielleicht sogar über das angeschlossene Gerät (z.B. über 
> Status-Code beim Loggen, der zur Aktivierung der am AVR NET-IO 
> angeschlossenen LED/Klingel/Sirene auffordert und eine Quittierung 
> verlangt), wenn die nächsten Daten geliefert werden.
> Test-Button auf der Website.

Das hatte ich mir auch schon überlegt. Die Kindklassen "SMS" und "Mail"
würden entweder in regelmäßigen Abständen Bericht erstatten. Oder wie du
es angesprochen hast durch ein Event System vor Peaks und Ausfällen
warnen.

Ich ertappe mich immer wieder selbst wie ich in Gedanken versinke und
schnell mal über mögliche Funktionen des Projekts usw. nachdenke. Die
von dir angesprochene Quittierung ist auch eine Funktion die meiner
Meinung nach jetzt noch nicht näher besprochen werden muss.
Trotzdem finde ich es gut bereits im Vorfeld mit einem breiten Blickfeld
an die Sache herran zugehen.

Event und Reportsystem, die Ausgabe über Mail und SMS sind alles nette
Gimmicks die wir jedoch auf einen späteren Zeitpunkt zurückstellen
sollten. Ich finde es nur wichtig sie jetzt schon im Kopf zu haben. Da
wir sonst später eventuell Probleme mit der Implementation bekommen
könnten.

> 
> > Die ursprüngliche Version für jeden Puls einen Eintrag in der Datenbank
> > abzulegen finde ich gut. Das ermöglicht es uns die größtmögliche
> > Auflösung der Daten abzubilden.
> 
> Größtmögliche Auflösung => Größtmöglicher Speicherverbrauch. Auf einem 
> privaten Server wahrscheinlich kein Problem, aber auf einem 
> Community-Sammelserver?

Ja :( Das könnte echt ein Problem werden. Ich habe hier mal eine kleine
Hochrechnung und eine Vergleich zur Momentmethode gemacht:

Pulsmethode:

Ein Puls besteht aus:
 * Timestamp mit msec Auflösung: 8byte
 * Zähler ID: 1byte sollten für einen "mein.volkszähler" genügen. für
die "volkszaehler.org" Variante braucht hier vielleicht einen größeren
Datentyp

Macht also mit Overhead so um die 10byte pro Puls.
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.

Momentmethode:

Eine Momentaufnahme besteht aus:
* Timestamp mit sec Auflösung: 4byte
* Zähler ID: 1byte
* Wert: ca 4byte

Macht mit Overhead also auch so um die 10byte pro Momentaufnahme.
Gehen wir davon aus, dass wir alle 10 eine Aufnahme machen, brauchen wir
pro Tag

24 * 60 * 60 = 86400 sec
86400 sec / 10sec = 8640 Momentaufnahmen

Das ist relativ vergleichbar mit der Impulsmethode. Ich schätze den
Speicherbedarf ähnlich ein. Jedoch verlieren wir hier die genauen
Messergebnisse.

Wie seht ihr das?

gruß Steffen

PS: ich sitz immer noch im hackcenter ;)

-- 
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/8bd810a2/attachment.pgp