[vz-dev] Fwd: Re: Offene Enden

[Peer Janssen]

Steffen Vogel schrieb:
>>> 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.

Geigerzähler. Siehe hier: 
http://user.baden-online.de/~pjanssen/radioaktivitaetsmessung.html

 > Das sind
> doch auch nur Impulszähler.

Genau.
Andere Daten aber nicht unbedingt.

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

Ist es: Das Volk zählt selbst.

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

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.

Wer schaut sich -- nach einer Weile, wenn das anfängliche Interesse 
wieder schwächer wird -- schon jeden Tag seine Daten an?! Also muss die 
ganze Bot-Familie einen mal an die Schulter tippen, wenn da was nicht 
klappt. Andernfalls müsste man sich dauernd und regelmäßig darum 
kümmern. Das macht auf Dauer niemand.

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

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.

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

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.

> 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 ;)

Nutze die Möglichkeit der Kontakte vor Ort!

Viel Spaß noch
Peer