[vz-dev] Fwd: Re: Offene Enden

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

Ich hänge mal die hochaktuelle Grafik an, wie sowas aussieht. Zeitraum 
von heute 2010-05-24 Mitternacht bis 12:50:54. Legende: red = data 
points, green = maximum resp. minimum, blue = average. Das senkrechte 
Gitter sind Stunden, das waagerechte jeweils 20 Impulse/Minute. Die 
Punkte sind kleine Striche über 3 Pixel, weil man sonst nicht genug 
sieht. Die HTML-Seite um die Grafik herum holt sich jede Minute neu vom 
(internen) Webserver neu. So hat man eine laufende Anzeige ... und eine 
grobe Tages-Uhr.

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.

Ich habe mal vor einiger Zeit den Temperaturgang IM Kühlschrank (und 
überhaupt in den Räumen) geloggt. Das ist sehr interessant! Erstens war 
ich überrascht, über WIE VIEL Grad die Kühlschrankinnentemperatur 
schwankt. Zweitens sieht man JEDES Öffnen sofort. Jede 
(Wieder-)Abkühlphase ist natürlich mit Stromverbrauch korreliert. Es 
kann prägend für das eigene Verhalten sein, wenn man das mal konkret 
gesehen hat.
Ich überlege mir z.B., Fächer-Unterteilungen (à la Gefrierschrank) in 
den Kühlschrank nachträglich einzubauen, um den Verbrauch zu verringern 
(und die Kühlung zu verbessern).

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 Backend würde das dann speichern (bei erstmaliger Verwendung), 
ignorieren (bei erneutem Einschalten) oder updaten (wenn geändert) bzw. 
die Änderung verweigern, aber dann per E-Mail eine verweigerte Änderung 
benachrichtigen (falls mal einer was falsch gebastelt hat) bzw. eine 
Änderungsgenehmigung per Weblink einholen.

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

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

Peer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: geiger-sample.png
Type: image/png
Size: 12404 bytes
Desc: not available
Url : http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20100524/dbc5c262/attachment.png