File: /~heha/basteln/PC/Wetterstation/telemet.zip/todo.txt

Meine Güte, das schöne .C-Programm ist total verhunzt!
Natürlich sollte das Programm als Dämon und nicht als cron-Job laufen!
Jedesmal einen Prozess starten - wer will das schon?

Und Zeitangaben in Deutsch gibt's halt nur unter Windows gratis.

Das Programm sollte m.E. die HTML-Seite selbständig alle 10 Sekunden
aktualisieren; ein wenig textueller und grafischer "Schnulli"
verbessert die Les- und Erfassbarkeit.
Die Messwerte sollten mit "Temperatur" beginnend erscheinen!

Etwa:
Uhrzeit (lokal):	Fr., 28. Juni 2002, 01:45:20   [Bild mit Analoguhr]
Temperatur:		27,5 °C
Luftdruck:		980 hPa = 1020 mbar, schwach steigend [Bild]
Windgeschwindigkeit:	0,38 m/s = 1,1 km/h = Windstärke 1 = Leichter Zug
Windrichtung:		210° Süd-Südwest [Bild mit Windrose]
Regenmenge:		0 mm  in der Zeit von ... bis ... (aus "Laufzeit")
pH-Wert des Regens:	7  = neutral/basisch/sauer
Lichtintensität:	0 Lux = Nacht/Dämmerung/trüb/taghell/Sonnenschein
Radioaktivität:		0 µSv/h (zul. Grenzwert = ... µSv/h)

Zahlenangaben mit Komma statt Punkt.
[Englische Version mit Umrechnung in Fahrenheit.]
Ermittlung der Zeitgrenzen der "Regenmenge" mittels "Laufzeit" sowie
 Resynchronisation bei Wertewechseln.

Außerdem sollte das Programm die Wetterdaten binär (float) speichern,
mit NANs für unbekannte oder nicht plausible Messwerte.
Dabei bietet sich m.E. ein RIFF-ähnliches Dateiformat an, mit Chunks für:
* Jahr (x)
* Monat (12)
* Tag (28..31)
* Stunde (24)
* Messwert (60 bei Mittelung "pro Minute")
Jeder Chunk wird durch seine tatsächliche Länge und eine Zusammenfassung
"eingerahmt".

Alternativ mit weniger Verschachtelungstiefe:
* Jahr (x)
* Tag (365..366)
* Messwert (1440)

Speicherplatzbedarf bei 1 Byte und 8 FLOATs pro Messwert: 20 MByte/Jahr
bei 10 Bytes (statt der FLOATs) viel weniger: 5 MByte/Jahr!

Achtung! Mittelwertbildung erfolgt für Regenmenge durch Summation,
für die Windrichtung (unter Weglassung von NANs) über eine kartesische
Transformation! (Bewertet oder unbewertet mit Windgeschwindigkeit?)

Chunks und Messwerte werden stets hinten angefügt und die Summarys
und Längen-DWORDs vorn aktualisiert.
Ein Auswerteprogramm kann so einfach Summarys von ganzen Tagen, Monaten
usw. abgrasen, auch wenn das Programm nicht durchgehend lief und die
Daten nicht kontinuierlich vorliegen.

Beispieldatei, die am 27.6.2002, 16.30 gestartet wurde, Schnappschuss 17.01:
2002.tenki	<- Vorschlag für Dateiname
semaphor	<- Zugriffs-Aufwärtszähler (ungerade=Zugriff verboten)
MESSWERT	<- Summary Jahr 2002
chunksize	<- Länge über alle eingelesenen Monate
 06		<- Juni (1. Monat mit Daten)
 MESSWERT	<- Summary Juni 2002
 chunksize	<- Länge über alle eingelesenen Tage
  27		<- Siebenschläfer 2002
  MESSWERT	<- Summary Siebenschläfer 2002
  chunksize	<- Länge über alle eingelesenen Stunden
   16		<- nachmittags
   MESSWERT	<- Summary der Stunde 16.00 bis 16.59 am Siebenschläfer 2002
   chunksize	<- Länge über alle eingelesenen Minuten
    30		<- Minute 30
    MESSWERT	<- Summary über 6 Einzelmessungen
    31		<- Minute 31
    MESSWERT	<- weitere Einzelmessungen (vielleicht auch mal 5)
    59		<- Minute 59, zwischen 32 und 58 sei Linux abgestürzt
    MESSWERT	<- weitere...
   17		<- fünf Uhr nachmittags (17.01 mit dem ersten Ergebnis erzeugt)
   MESSWERT	<- z.Z. alles NAN
   chunksize
    00
    MESSWERT	<- letzter Messwert
<- hierhin müssen alle offenen <chunksizes> stets zeigen!
   Oder aber eine spezielle (große) Konstante markiert "offene Chunks".
   (0x7FFFFFFF)

Wie weit eine Aktualisierung der Summarys reichen soll, ist noch unklar.
Am einfachsten erst bei Abschluss einen Blocks.
(Dann kann die Summary auch am Blockende stehen!)
Oder man beschränkt die Aktualisierung auf "1 Stufe nach oben",
d.h. die Jahreszusammenfassung wird erst mit dem Monatsabschluss aktualisiert.
Im Beispiel wären damit die Messwerte "Jahr" und "Monat" = NAN;
"Tag" wäre nicht NAN, weil bereits eine Stunde abgeschlossen ist.

Eine prozessübergreifende Semaphore muss sicherstellen, dass während des
(minütlichen) Schreibens der Datei kein Auswerteprozess lesend darauf
zugreift.
Ohne Semaphore funktioniert's aber auch, wenn das Leseprogramm (ungepuffert!)
*1 zuerst das Semaphorbyte liest
*2 wiederholt [goto *1] (nach sleep(0)) falls ungerade
*3 Daten ausliest
*4 zuletzt das Semaphorbyte nochmals liest
*5 wiederholt [goto *2] falls ungleich
Das hat den Vorteil, dass das Schreibprogramm uneingeschränkten Vorzug hat.
Detected encoding: ANSI (CP1252)4
Wrong umlauts? -