Wetterstationsforum.info - Archiv

Habedieehre!

Zitat von: "Django"(Was kommt denn da zuerst. Der älteste Datensatz, oder der jüngste?

Also ich hab' mir mal einen Datensatz etwas genauer angekuckt. Dabei bin ich zu folgendem Ergebnis gekommen. Zur besseren erklärung nummerieren wir mal die Bytes von "links nach rechts" beginnend mit "1" der Reihe nach durch.

Byte 01 == FE == Initialisierung der Kommunikation
Byte 02 == 31 == Code für die Abfrae des nächsten Datensatzes
Byte 03 == FE == koa Ahnung
Byte 04 == FE == koa Ahnung
Byte 05 == FE == Highbyte des Zeitstempels
Byte 06 == FE == Lowbyte des Zeitstempels
Das wäre dann z.B.:FE 31 80 00 30 63  == 12387
FE 31 80 00 30 5E  == 12382
FE 31 80 00 30 59  == 12377
FE 31 80 00 30 54  == 12372
FE 31 80 00 30 4F  == 12367
FE 31 80 00 30 4A  == 12362
Mit " == 12387" hab' ich mal den Hex-Wert nach dezimal umgewandelt. Man sieht sehr schön, dass das immer mit 5 hochzählt. Daraus folgere ich, dass der erste Datensatz den ich bekomme, der "älteste" ist und je weiter die Datenübertragung voranschreitet, um so "jünger" werden die Datensätze.
So weit so gut, aber wie interpretiere ich nun diese Zahl? Sind das 12362 Minuten, gerechnet von jetzt ab, also 206 Stunden und 2 Minuten? Das würde bedeuten, dass bei max. 3000 Datensätzen, die die WS500 speichern kann, der max. Zeitstempel gleich 3A98 wäre, oder etwa nicht?

j_k, nun bist Du gefragt, hab' ich das soweit richtig überrissen, oder wie ermittelt man den Zeit- und Datumsstempel des Datensatzes sonst?

Pfiade,
Django

HI,

so zur vorgerückter Stunde hätte ich noch 'ne doofe Frage.

j_k, du hast in der Beschreibung ws300_daten.txt geschrieben:

ZitatWS 500 WS777
---------------------
NEXT_RECORD 47 Byte
           Alter T1 T1 F1 T2 T2 F2 T3 T3 F3 T4 T4 F4 T5 T5 F5 T6 T6 F6 T7 T7 F7 T8 T8 F8 T9 T9 F9 RA IN Wi ND *1 *1 *2 *2 T0 T0 F0 Druck
FE 31 80 80 00 77 00 9C 43 00 AB 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7D 3F 00 16 00 2F 36 03 0D A4 00 AC 3E 03 F0 FC

CURRENT_RECORD (44 Byte) ist gleich aufgebaut aber ohne Alter Datensatz

Das mit den 47 Bytes und den 44 Bytes kann ich so bestätigen, sieh Dateianhänge. Nur was mich irritiert ist folgendes. Wenn der Zeitstempel wirklich mit zwei Bytes dargestellt wird, dann müsste doch der CURRENT_RECORD 45 Bytes lang sein oder? Denn 47 - 2 = 45, nach Adam Rieße uind Eva Zwerg. Warum sind es aber dann ein Byte weniger. Das kapier ich nun gar nicht. Vielleicht liegts ja an der Uhrzeit ...  

j_k vielleicht kannst Du mir das ja mal erklären?

So, n8!
Django

So viele Beiträge....

Zitatdatetime == 2006-08-20 13:56:25.
Das muss ich doch wahrscheinlich irgendwie zurückrechnen, oder?

Na sicher , die Station speichert als Zeitstempel nur wie alt dein Datensatz von der aktuellen Zeit aus gesehen ist.

ZitatFE 33 FC == aktuelle IST-Werte der Station abfragen
FE 31 FC == historische Werte, also die letzten abgespeicherten Messwerte von der WS holen. (Was kommt denn da zuerst. Der älteste Datensatz, oder der jüngste?

Der älteste kommt immer zuerst und wird beim auslesen auch gleich in der station gelöscht.

ZitatSo weit so gut, aber wie interpretiere ich nun diese Zahl? Sind das 12362 Minuten, gerechnet von jetzt ab, also 206 Stunden und 2 Minuten? Das würde bedeuten, dass bei max. 3000 Datensätzen, die die WS500 speichern kann, der max. Zeitstempel gleich 3A98 wäre, oder etwa nicht?

genau so ist es, deine rechnung geht allerdings nur beim speicherintervall von 5 min auf.
Du hasst also :
12362 / 5 = 2472
Datensätze in der Station gespeichert, würde ich langsam mal auslesen  

Zitatdann müsste doch der CURRENT_RECORD 45 Bytes lang sein oder? Denn 47 - 2 = 45, nach Adam Rieße uind Eva Zwerg. Warum sind es aber dann ein Byte weniger. Das kapier ich nun gar nicht.

Im NEXT_RECORD: FE 31 80 80 00 77
ist nach der Kennzeichnung 80 80 drin ( wobei ich noch nicht weiß was das ist), die 2 Byte und der Zeitstempel fehlen im CURRENT_RECORD, wären 47 - 4 = 43 Byte.
Im  CURRENT_RECORD ist aber noch 1 Byte am Ende bevor FC kommt eingefügt wo die Wettervorhersage übermittelt wird, daher 44 Byte.
Allerdings solltest du dich nicht mit der festen Anzahl von Bytes herumschlagen, spätestens wenns kalt :kalt: wird musst du das "Escape Handling" beachten. Beispiel:
-0,1 Grad im Datensatz: FF FF
-0,2 Grad im Datensatz: FF F8 FF
-0,3 Grad im Datensatz: FF FD
-0,4 Grad im Datensatz: FF F8 FD
-0,5 Grad im Datensatz: FF FB
und bei
-0,8 Grad im Datensatz: FF F8 F9

Das kann dir also bei allen Werten passieren ( außer bei der Feuchte), also kann ein Datensatz im ungünstigsten Fall auch mal 64 Byte haben(wenn ich richtig gerechnet hab).

Moin Django,

>Mit Initialisierung meinst Du die ersten drei Bytes in Richtung WS, oder?

Nö, das openport und die Sequenz für den COM-Port. Danach mach ich immer eine Statusabfrage ($FE $32 $FC). Die WS500 antwortet dann nicht immer.

Status:
     S1 S2 S3 S4 S5 S6 S7 S8 S9 Ti AltAltWipWip
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--
FE 32 00 00 00 00 00 00 00 00 11 05 03 02 01 27 FC


Importdatei:
Die meisten Provider lassen keinen direkten mySQL-Zugriff zu!! Also die Station steht bei mir und wird ausgelesen aber die Daten können nicht direkt übertragen werden. Ascii-Datei und FTP-Upload. Ein Cron schreibt dann die Werte in die mySQL. Bei 1und1, Strato und ... kannst du nur aus der DMZ auf mySQL zugreifen.
Für die, die ihren eigenen Server betreiben ist das natürlich kein Problem.

Stefan

HI j_k!

Zitat von: "j_k"So viele Beiträge....

Na es gab' ja auch viel zu tun, zu berichten und zu fragen!

ZitatNa sicher , die Station speichert als Zeitstempel nur wie alt dein Datensatz von der aktuellen Zeit aus gesehen ist.

Dachte ich's mir schon. Nur wie weiss ich denn, welche Uhrzeit in der Station aktuell ist. Gehst Du davon aus, dass die Uhrzeit in der WS die gleiche ist, wei auf dem Rechner? Beim current_record ist ja bekanntlicherweise keine Uhrzeit dabei. Und aus mir unerfindlichen Gründen hat man es auch versäumt, 'nen DCF77-Empfänger in der Station zu verbauen.

ZitatDer älteste kommt immer zuerst und wird beim auslesen auch gleich in der station gelöscht.

Das hatte ich mir bei meinen gestrigen Überlegungen schon so richtig zurechtgelegt (und das in meinem fortgeschrittenen Alter von 55 )

Zitatgenau so ist es, deine rechnung geht allerdings nur beim speicherintervall von 5 min auf.
Du hasst also :

Code Auswählen Erweitern

12362 / 5 = 2472
Datensätze in der Station gespeichert, würde ich langsam mal auslesen  

O.K., dann werd' ich heute mal die Messwerte nach /dev/null kopieren. Der Laptop ist nicht da, und vom Server über die CAT6-Verkabelung zum Wohnzimmer mag der USB nicht. Der USB-Extender ist aber schon bestellt.

ZitatIm  CURRENT_RECORD ist aber noch 1 Byte am Ende bevor FC kommt eingefügt wo die Wettervorhersage übermittelt wird, daher 44 Byte.

O.K. hab' verstanden!

ZitatAllerdings solltest du dich nicht mit der festen Anzahl von Bytes herumschlagen, ...
... also kann ein Datensatz im ungünstigsten Fall auch mal 64 Byte haben(wenn ich richtig gerechnet hab).

Mach' ich schon nicht, ich wollt' erst mal das ganze Prinzip verstehen. Denn das grundlegende "wie-mach-mas-denn" steht ja schon. Im Moment feilen wir an den Details. Und ich hoffe, ich kann die nächsten Tage meine perl-Kenntnisse noch ordendlich erweitern, damit wir das script hier auch mal online stellen können.

ttyl,
Django

Habedieehreoidewuaschdhaud!

Zitat von: "DuffyDuc"Nö, das openport und die Sequenz für den COM-Port. Danach mach ich immer eine Statusabfrage ($FE $32 $FC). Die WS500 antwortet dann nicht immer.

Aha, Du initialisierst also den COM-Port, frägst ddie Konfiguration der WS500 ab, frägst vermutlich dann den current record ab und dann die next_records. So zumindestens steht's bei mir im Moment im script.

Zitat

Code Auswählen Erweitern

Status:
     S1 S2 S3 S4 S5 S6 S7 S8 S9 Ti AltAltWipWip
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--
FE 32 00 00 00 00 00 00 00 00 11 05 03 02 01 27 FC

Hmmm, was war/ist denn hier wieder "S", "Ti" und "Alt"? Wip ist wohl die Anzahl der Wippenschläge, Alt ev die Meereshöhe, oder?

ZitatImportdatei:
Die meisten Provider lassen keinen direkten mySQL-Zugriff zu!!

Na, entweder nutze ich dann hierzu meinen ws500.dynalias.org oder ich schiebe später die Daten alle 5 minuten hinauf zum ISP. Das mache ich zumindestens jetzt schon, mit den dynamisch erstellten (NewsClipper) Seiten auf meiner homepage.

ZitatAlso die Station steht bei mir und wird ausgelesen aber die Daten können nicht direkt übertragen werden. Ascii-Datei und FTP-Upload. Ein Cron schreibt dann die Werte in die mySQL.

Darf ich mal fragen, wie Du das machst, IMHO nicht mit 'nem Tux, oder?

Pfiade,
Django

Hi,

ganau lese zuerst die Konfiguration:

S1-S9 sind die Sensoren:
Wert : 10 -> Sensor vorhanden
Wert - 10 > 0 = Dropouts

Ti : Speicherintervall
Alt: Stationshöhe
Wip : Wipcount

S9 (11)= 1 Dropout
Ti=5min
Alt=770m
Wip=295

     S1 S2 S3 S4 S5 S6 S7 S8 S9 Ti AltAltWipWip
0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16
|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--
FE 32 00 00 00 00 00 00 00 00 11 05 03 02 01 27 FC

Stefan

HI,

so hab' mir mal den current-Datensatz etwas genauer angekuckt. (da ja bei j_k's ws300 die Anzeige bei mir nicht stimmte - so vermutete ich 'nen Fehler in der Zuordnung)

Aktuell habe ich folgende Messwerte "auf der WS stehen":
Innen: 23,8 °C
Innen: 57 %
Außen: 17,3 °C
Außen: 72%
Luftdruck: 950 hPa
Regen: 0
Sonnenschein: 2:30
Wind: Südwest (215°); 0 kmh

Ich lehne mich mal bei meinen folgenden Überlegungen an die ws300_daten.txt von j_k an:

Die ersten 29 Bytes sind klar und die umgerechneten 17,3 °C in 173(dec) in AD(hex) sind klar, ebenso die 72% Luftfeuchtigkeit in 48(hex). Die restlichen aktuellen werte sind auch schnell gefunden, die meisten zumindestens.
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
     T1 T1 F1 T2 T2 F2 T3 T3 F3 T4 T4 F4 T5 T5 F5 T6 T6 F6 T7 T7 F7 T8 T8 F8 T9 T9 F9
FE 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 AD 48

30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
RA IN WI ND *1 *1 SONNE TI TI FI DRUCK WW ABSCHLUSS-CODE
00 02 00 00 2C 00 00 96 00 EE 39 03 B6 01 FC
Fange ich nun ganz links bei diesem Musterdatensatz an zu zählen an, dann ist:Byte 01      = FE (Kommunikation mit der WS starten)
Byte 02      = 33 d.h. aktuellen Datensatz abholen
Byte 03 - 05 = Fühler 1 Temperatur (03 und 04) und Feuchte (05)
Byte 06 - 08 = Fühler 2 Temperatur (06 und 07) und Feuchte (08)
Byte 09 - 11 = Fühler 3 Temperatur (09 und 10) und Feuchte (11)
Byte 12 - 14 = Fühler 4 Temperatur (12 und 13) und Feuchte (14)
Byte 15 - 17 = Fühler 5 Temperatur (15 und 16) und Feuchte (17)
Byte 18 - 20 = Fühler 6 Temperatur (18 und 19) und Feuchte (20)
Byte 21 - 23 = Fühler 7 Temperatur (21 und 22) und Feuchte (23)
Byte 24 - 26 = Fühler 8 Temperatur (24 und 25) und Feuchte (26)
Byte 27 - 29 = Kombiaußenfühler Temperatur (27 und 28) und Feuchte (29)
Byte 30 - 31 = Regen (Berechnung mir noch unklar!
              {unbedingt klären})
Byte 32 - 33 = Windgeschwindigkeit (in m/s? Berechnung mir noch unklar!
              {unbedingt klären})
Byte 34 - 35 = Windrichtung (35){Winkel = Wert *5 in °} und Schwankung (36)
              {Winkel = Wert *5 in °}
Byte 36 - 37 = Sonnenscheindauer in Minuten
Byte 38 - 40 = Innenfühler Temperatur (38 und 39) und Feuchte (40)
Byte 41 - 42 = Luftdruck (absolut) in hPa
Byte 43      = ? ist das die Wetterwilli-Kodierung?
Byte 44      = FC Abschluss-Byte
Das bedeutet erst mal, der Datensatz, wie ihn j_k in seiner Datei beschrieben hatte scheint zu stimmen. Also muss ich mir keinen weiteren Gedanken bzgl. der falschen Darstellung bei ws300 machen. Ich dachte immer das ist eine falsche Zuordnung vom Datenfeld. Auch das Thema Sonnenscheindauer ist wohl nun geklärt. Was mich nun noch interessiert ist die genaue Werteumrechnung für Byte 30 - 31, Byte 32 - 33 sowie Byte 43. Die Angabe von Byte entspricht hier natürlich nur auf Bezug zu diesem o.g. Datensatz. In der späteren Doku, an der ich nebenbei schreibe wird dies als Feld-Nummer bezeichnet, ich glaube das ist dann klarer.

Soweit so gut, dann werd' ich mir mal später den Konfigurations-Datensatz nochmals ansehen. Damit ich zum einen das richtig verstehe und zum anderen das dann auch in die Doku übernehmen kann. Aber ich sehe gerade DuffyDuc hat da ja schon ein paar wertvolle Tips gegeben.

Nu' denn, dann mal bis später ...

ttyl,
Django

HI!

Zitat von: "DuffyDuc"ganau lese zuerst die Konfiguration:

Jepp, das ist schon eingebaut. Zumal ja die Angaben des eingestellten Wippenfaktors wie auch der Höhe für die Berechnung der Regenmengen bzw. des relativen Luftdrucks benötigt werden.

Aktuell habe ich folgenden Satz ausgelesen:00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
     T1 T2 T3 T4 T5 T6 T7 T8 T9 DD HOEHE WIPPE ABSCHLUSS-CODE
FE 32 00 00 00 00 00 00 00 00 10 05 01 F7 01 27 FC
Die Beschreibung der Bytes, und diesesmal sind es auch immer genau die Datensatzfelder ist dann, wie Du schon richtig gesagt hattest:
Byte 00      = FE (Kommunikation mit der WS starten)
Byte 01      = 32 d.h. aktuelle Konfiguration auslesen
Byte 02      = Fühler 1 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 03      = Fühler 2 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 04      = Fühler 3 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 05      = Fühler 4 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 06      = Fühler 5 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 07      = Fühler 6 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 08      = Fühler 7 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 09      = Fühler 8 vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 10      = Kombiaußenfühler vorhanden? (00 == nein, 10 == ja >10 == Dropouts
              (Wert - 10 == Anzahl der Dropouts)
Byte 11      = Intervall der abgespeicherten Datensätze  
Byte 12 - 13 = Standort der Station über NN in mtr.
Byte 14 - 15 = Faktor == Wert /1000 für die Berechnung der Regenmenge pro Wippenschlag
Byte 16      = FC Abschluss-Byte
Die Regenmenge errechnet sich dann wie folgt: Wippenschläge * Faktor in mm Niederschlag. In meinem Falle sind das dann 0,295mm (01 27 == 295)

Soweit so gut, nun ist's erst mal Schluss für heute. wer'd die Tage mit Basti noch ein wenig perl-Intensivierungscrashkurs machen und dann geht's hoffentlich bald an die Übertragung in die MySQL-DB. Sobald's was neues gibt, werd' ich mich melden!

n8 zusammen!

Django

HI,

also die Kommunikation mit der WS läuft mittlerweilen sehr stabil. Bis jetzt hab' ich keinen Aussetzer mehr! Nein nicht ich, ich meine natürlich das Programm!

DAnnn werd' ich mal weitertesten!

ciao,
Django