Griaseichallemidananda,
ich hatte es hier im Portal schon mal angekündigt: Derzeit basteln wir an einem perl-deamon zum Auslesen der WS500 und Füttern einer mySQL-Datenbank unter Linux.
Ich möchte mal einen kleinen Zwischenbericht abgeben.
Das Ansprechen der WS500 via Kernel-Modul klappt schon mal. Sep 16 20:17:42 server kernel: usb 1-2: new full speed USB device using uhci_hcd and address 22
Sep 16 20:17:42 server kernel: ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
Sep 16 20:17:42 server kernel: /usr/src/linux/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM
Sep 16 20:17:42 server kernel: usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
Ein kleines perl-Progrämmchen zum Lesen der Daten und Speichern derselben in ein Textfile haben wir auch schon mal auf die Reihe gebracht.
Soweit wir die Angaben von DuffyDuc und j_k verstanden haben läuft die Kommunikation zur WS500 wie folgt ab:
Man sende 3 Bytes in Richtung WS500 und bekommt als Rückmeldung eine Anzahl von mind. 1 Byte bis max. 47 Bytes
Die Anfragen laufen immer wie folgt ab
FE nn FC
wobei das zweite Byte nn wie folgt festgelegt ist:
30 == Konfiguration schreiben
31 == nächster Datensatz
32 == Konfiguration lesen
33 == aktueller Datensatz
34 == Firmware abfragen
BTW, bitte korrigiert mich, wenn ich da den absoluten Stiefel versapfe! :D
Was ich noch nicht ganz geschnallt habe, ist der Unterschied zwischen "31" und "33".
Kann das mir mal einer erklären? ;)
Pfiadseich,
Django
HI,
beim Auslesen des aktuellen Datensatzes erhalte ich z.B. folgende Werte:
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
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 BA 3F 04 3C 00 64 46 02 C3 C9 00 C6 3F 03 B4 12 FC
Also immer 44 Bytes zurück.
Was schon sonderbar ist, ist die Tatsache, dass die Kommunikation sehr sehr eigenartig verläuft. An und ab erhalte ich lediglich ein A0zurück, egal was ich zur Station schicke. Na ja, mal sehen und weiter testen.
Pfiadseich,
Django
hi,
Sodala, nun mal eine Datei mit ausgelesenen "next records"
Na, dann werd' ich mich mal an die Konvertierung und an den MySQL-Import machen, aber nicht mehr heute, sondern eher morgen. n8 zusammen! 8)
ciao,
Django
Hi Django,
was für ein Elan!
>Also immer 44 Bytes zurück.
Plus Escape-Bytes; danach 44
FC0A ist dein Satzende -> das 0A hatte ich noch nie in dieser Form. Falls dann nur 0A übrigbleibt ist also gar nix gekommen! Das 0A kommt von woanders her (Vermutung)!
Keine Bytes oder komische Kommunikation ist ein Markenzeichen der WS500; Manchmal kommt nach einer Initialisierung nichts zurück. Status abfragen und falls Q_Bytes=0 das ganze von vorne!
> MySQL-Import
In welcher Form?? j_k und Rainer Krienke haben sich ja schon auf ein Datenbank-Format geeinigt, das universell ist.
Die Krönung wäre noch ein einheitliches Importformat (ascii).
Stefan
Griaseichallemidananda!
Ich hab' mich gerade mal daran gemacht, die "next Records" von heute Morgen mal etwas genauer unter die Lupe zu nehmen.
Ein Datensatz beginnt immer mit fe31 und endet mit fc0a.
fe3180002f1b000000000000000000000000000000000000000000000000012826043000083d03bb3801083403bafc0a
Nicht immer aber immer öfter. Und das genau ist das was mich strutzig macht. Warum gibt es da plötzlich Datensätze die länger sind als die 48 Bytes. Ist das ein Konvertierungsfehler von mir im Nachgang, oder spuckt die WS500 die Datensätze so in der Tat aus?
Pfiadseich,
Django
ZitatWarum gibt es da plötzlich Datensätze die länger sind als die 48 Bytes
Ein Datensatz kann durchaus mehr als 48 Byte haben, schau dir meine Erklärungen zum Escape Handling an.
Ein Datensatz endet immer mit FC , woher das 0A kommt musst du selber herausfinden, das kommt mit großer Sicherheit nicht von der WS.
Griasde,
Zitat von: "j_k"Ein Datensatz kann durchaus mehr als 48 Byte haben, schau dir meine Erklärungen zum Escape Handling an.
Hmmmm, im Moment steh' ich ein bisserl auf'm Schlauch. Wo find' ich diese Erklärung? :roll:
ZitatEin Datensatz endet immer mit FC , woher das 0A kommt musst du selber herausfinden, das kommt mit großer Sicherheit nicht von der WS.
Das kommt beim Abspeichern der Datensätze in die Textdatei von dem perl-script zustande. Kann ich ja mal vergessen, muss mich darüber nicht sorgen. ;)
Das Datum und die Uhrzeit des Datensatzes, hmm, wo oder wie ist den das eigentlich versteckt? In der MySQL steht ja z.B. im Feld
datetime ==
2006-08-20 13:56:25.
Das muss ich doch wahrscheinlich irgendwie zurückrechnen, oder?
Pfiade,
Django
HI DuffyDuc!
Zitat von: "DuffyDuc"was für ein Elan!
Ja mei, hab' grad eben ein wenig Zeit, weil mein Kleinster - der Ruben - wieder im Krankenhaus ist :( und mir sonst nix G'scheids einfällt. :D
ZitatPlus Escape-Bytes; danach 44
FC0A ist dein Satzende
Soweit ist's mir heute Morgen auch schon klar gewesen.
Zitat-> das 0A hatte ich noch nie in dieser Form. Falls dann nur 0A übrigbleibt ist also gar nix gekommen! Das 0A kommt von woanders her (Vermutung)!
Wie ich schon geschrieben hatte, kommt das von dem perl-script, das nimmt letztendlich den datensatz in Empfang und schreibt diesen im Moment einfach in 'ne Textdatei. Da macht er dann einfach der
Zeilenvorschub unter Unix (LF). Dieser fällt ja später weg, wenn ich die Daten direkt in die MySQL pumpe.
ZitatKeine Bytes oder komische Kommunikation ist ein Markenzeichen der WS500;
Das hatte ich schon leidlich erfahren. Zum einen durch Lesen hier im Portal und zum anderen durch die vielen Test' mit j_k's ws300.
ZitatManchmal kommt nach einer Initialisierung nichts zurück. Status abfragen und falls Q_Bytes=0 das ganze von vorne!
Mit Initialisierung meinst Du die ersten drei Bytes in Richtung WS, oder?
ZitatIn welcher Form?? j_k und Rainer Krienke haben sich ja schon auf ein Datenbank-Format geeinigt, das universell ist.
Genau das nehme ich ja auch her. Die Daten dort sind bereits umgerechnet soweit ich das bis jetzt vorgefunden habe.
ZitatDie Krönung wäre noch ein einheitliches Importformat (ascii).
Wie meinst Du denn das. Zumindestens für die WS300 stehen dort die Werte im Klartext, also ASCII (siehe beigefügte Graphik).
Die Darstellung und Aufbereitung der Messwerte wird dann mittels eines php-scriptes erfolgen. Das sollte dann, sofern die Datenbank "genormt" verwendet wird, dann mühelos auch für andere WS'en verwendbar sein. So zumindestens die interne Feature-/Releaseplanung.
Ach ja, weil ich vorhin meine selfmade-USB-Verlängerung getestet hatte, hier mal die syslog-Meldung beim Anstecken der WS500:
Sep 16 20:17:42 server kernel: usb 1-2: new full speed USB device using uhci_hcd and address 22
Sep 16 20:17:42 server kernel: ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
Sep 16 20:17:42 server kernel: /usr/src/linux/drivers/usb/serial/ftdi_sio.c: Detected FT8U232AM
Sep 16 20:17:42 server kernel: usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0ttyl,
Django
HI j_k!
Zitat von: "j_k"... schau dir meine Erklärungen zum Escape Handling an.
Okidoki, hab's gefunden und hoffentlich auch verstanden.
Die Kennzeichnung der Kommandos erfolgt durch 2 Byte am Anfang (FE 31) und das EndByte (FC)
escape handling = 0xf8
Um Werte zu markieren die gleich der Bytes FC FE und F8 sind wird dem jeweiligen Byte das "Escape" Byte F8
vorangestellt und der eigentliche Wert um 1 erhöhtWo Du mir noch helfen könnest wär' das Thema mit den Datums-/Uhrzeitstempel. Da tippe ich im Moment noch etzwas arg im Dunkeln. Werd' mir mal die
interface.cpp noch genauer zur Brust nehmen und versuchen das herauszufinden.
ttyl,
Django
HI!
Bevor ich mich nun im Wald verlauf', würde ich gerne noch folgendes abstimmen:
FE 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?
Hab' ich das soweit richtig verstanden, oder befinde ich mich auf dem Holzweg?
edit: Weiß von Euch zufällig jemand, wie ich den User alhood hier aus dem Portal erreichen kann? Ich hätte da noch 'n paar Fragen an ihn.
ciao,
Django
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 == 12362Mit
" == 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 ... :roll:
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 = 2472Datensätze in der Station gespeichert, würde ich langsam mal auslesen :D
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! :lol:
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. :x
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 :
12362 / 5 = 2472
Datensätze in der Station gespeichert, würde ich langsam mal auslesen :D
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.
ZitatStatus:
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 FCDie 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-ByteDie 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! :lol:
DAnnn werd' ich mal weitertesten!
ciao,
Django
HI,
so, der erste Versuch ist fast fertig, na ja, bis auf die "leidige" Doku. Das Auslesen der Konfiguration wird mit Hilfe eines scriptes vorgenommen.
Was ich j_k noch fragen wollte: Das Thema escape-handling trifft ja letztendlich immer zu, oder? auch bei der Konfiguration. Könnte doch ja auch sein, dass die Dropouts bzw. die Höhenangabe die Werte FC, FE oder F8 beinhalten.
Ich denke mal, da muss ich dann noch ein wenig mehr Gehirnschmalz hineinstecken.
ciao,
Django
HI DuffyDuc,
Zitat von: "DuffyDuc"Ascii-Datei und FTP-Upload. Ein Cron schreibt dann die Werte in die mySQL.
Du schreibst in eine Textdatei. Gut, hast Du dort dann die reinen Hex-werte noch stehen, oder sind das schon die umgerechneten Werte in "Klartext"?
Hast Du da ev. mal 'n Codeschnipsel - also ein paar Zeilen dieser Ausgabedatei - für mich? Wir haben heute mal unsere Köpfe zusammengesteckt und es wird wohl so werden, dass man zum einen direkt in eine MySQL schreiben kann zum anderen aber auch ein Textfile generiert werden wird. Damit man ev. so wie Du es machst, vorgehen kann.
ciao,
Django
Sers (oder so ähnlich),
ich benutzte ws2500tomysql (Perl) von Rainer Krienke.
Das Format ist im Download von ws2500 beschrieben. Da ist alles dabei. Das Datenbankschema ist ja bekannt, da haben j_k und RK sich geeinigt :-) .
Das Importfile würde ich persönlich etwas anders aufbauen:
-den Kopf nicht beachten
-zeilenorientiert (nicht Block)
das sähe dann etwas so aus:
## THS(Temp/humidity),StationID,SensID,DropOuts,Date,Time,Temperatur(°C),Humidity(%),New(1)
## PR(Pressure),StationID,SensID,DropOuts,Date,Time,Pressure-relativ(hPa),New
## RS(Rain),StationID,SensID,DropOuts,Date,Time,Counter(1),OneCount(mm/1000),Rain(mm/1000),Tol(1),New(1)
## WS(Wind),StationID,SensID,DropOuts,Date,Time Speed(Km/h),Direction(°),Variance(°),New(1)
## LS(Light),StationID,SensID,DropOuts,Date,Time Light(lux),Factor(1),Flag(1),Duration(h),New(1)
## PS(Pyranometer),StationID,SensID,DropOuts,Date,Time,Energy(W/m),Factor(1)
## Datetime in GMT
##----------------------------------------------------------------------------------------------------------
THS,1,1,0,17.09.2006,10:00:00,15.0,57.0,1
THS,1,17,0,17.09.2006,10:00:00,25.6,41.0,1
IS,1,1,0,17.09.2006,10:00:00,937.0,1
RS,1,1,0,17.09.2006,10:00:00,1341,295,395301,35,1
WS,1,1,0,17.09.2006,10:00:00,0.0,0,0,1
LS,1,1,0,17.09.2006,10:00:00,45,1,1,5,1
PS,1,1,0,17.09.2006,10:00:00,10,1
Die zweite Möglichkeit wären Loadfiles, die man ohne Prüfung in die Datenbank lädt. Das ist am einfachsten.
Da brauchts nicht mal ein DBI.
Ich schreibe für meine WS300 auch noch ein WSWin-File (import) raus. Sehr gewöhnungsbedürftig. Ist eher an ein csv-Format angelehnt (mit "verschlüsselten" (numerisch) Spaltenüberschriften, die auch die Zeilenlänge festlegen).
;;9;25;10;26;33;34;35;36;38
17.09.2006;10:17;20.2;62.0;25.9;47.0;923.0;0;0.0;0;0
Stefan
HI,
jo, mit Jochens Hilfe bin ich nunmehr schon fast am Ziel. Das Auslesen klappt nun fast zu 99%, eine Textdatei mit denm Messwerten wird auch schon angelegt. Was noch fehlt ist die Fütterung der MySQL sowie die Optiemierung der RRD-Nutzungsroutinen.
+---------------------------------------+
| Datensatz-Nummer (Alter): 4 |
+---------------------------------------+
| Regenmenge: 194 Impulse |
| Wind: 0 km/h |
| Windrichtung: 330 ° |
| Windschwankung: 0 ° |
| Luftdruck: 973hpa |
| Sonnenscheindauer: 150 Stunden. |
| Wetterstatus: 2 |
+---------------------------------------+
| Temperatur 0= 19.4°C |
| Feuchte 0 = 63% rel. |
+---------------------------------------+
| Temperatur 1= 0°C |
| Feuchte 1 = 0% rel. |
+---------------------------------------+
| Temperatur 2= 0°C |
| Feuchte 2 = 0% rel. |
+---------------------------------------+
| Temperatur 3= 0°C |
| Feuchte 3 = 0% rel. |
+---------------------------------------+
| Temperatur 4= 0°C |
| Feuchte 4 = 0% rel. |
+---------------------------------------+
| Temperatur 5= 0°C |
| Feuchte 5 = 0% rel. |
+---------------------------------------+
| Temperatur 6= 0°C |
| Feuchte 6 = 0% rel. |
+---------------------------------------+
| Temperatur 7= 0°C |
| Feuchte 7 = 0% rel. |
+---------------------------------------+
| Temperatur 8= 0°C |
| Feuchte 8 = 0% rel. |
+---------------------------------------+
| Temperatur 9= 9.6°C |
| Feuchte 9 = 89% rel. |
+---------------------------------------+Zitatich benutzte ws2500tomysql (Perl) von Rainer Krienke.Das Format ist im Download von ws2500 beschrieben. Da ist alles dabei. Das Datenbankschema ist ja bekannt, da haben j_k und RK sich geeinigt :-) .
O.K. na dann werd' ich mir doch mal dieses Programm zur Brust nehmen. Mal sehen wie er das gemacht hat. Die MySQL-Datenbankdefinition kenne ich ja nunmehr hinreissen, die verwende ich ja auch.
ZitatDas Importfile würde ich persönlich etwas anders aufbauen:
-den Kopf nicht beachten
-zeilenorientiert (nicht Block)
Die csv-Datei, die im Moment geschrieben wird sieht dabei wie folgt aus, Die Feldbezeichnungen sind dann entsprechend der Eingangs notierten Tabelle in Verwendung:
Fri Sep 22 23:25:19 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Fri Sep 22 23:30:28 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Fri Sep 22 23:35:22 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Fri Sep 22 23:40:25 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Fri Sep 22 23:44:55 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Fri Sep 22 23:50:21 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Fri Sep 22 23:55:21 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Sat Sep 23 00:00:24 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;
Sat Sep 23 00:05:27 2006;194;0;330;0;973;150;2;19.4;63;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;9.6;89;So, aber nun ist's erst mal genug. Werd' mir mal 'ne Mütze schlaf genhmigen. Und wenn alles klappt, dann kann ich ja das Djangosche-jochen-perl-script nächstes Wochenende - ein bisschen dauerts noch, muss heute Vormittag dann ins Krankenhaus - auf die Menschheit loslassen. ;)
n8 zusammen!
Django
HI,
mal 'ne ganz andere Frage: Welchen Luftdruck sollte man denn in die Datenbank schreiben? Den relativen, oder den absoluten?
Ich denke mal, den auf den Ort, sprich auf Höhe über NN.) wäre doch wohl vernünftiger, oder?
ciao,
Django
Hi Django,
wie du willst; hat alles seine Vor- und Nachteile.
Genauso mit Wipcount oder Menge.
Schon mal Gedanken über die Zeit gemacht? Die sollte nämlich GMT sein. Sonst gibt's kleine Problem bei der Zeitumstellung (DST). Einmal ein Lücke oder doppelte Werte.
Stefan
HI Stefan,
Zitat von: "DuffyDuc"
wie du willst; hat alles seine Vor- und Nachteile.
Genauso mit Wipcount oder Menge.
Schon klar, werd' wahrscheinlich beide werte bereitstellen und via Einstellungsfestlegung kann man dann auswählen, wo was abgespeicheert werden.
ZitatSchon mal Gedanken über die Zeit gemacht?
Ähhhn nö nocht nicht so ganz im Detail, bis jetzt zumindestens. Werd' aber dann wohl UTC als Basis nehmen (wollen).
Danke schon mal für den Tip.
So, dann werd' ich mich mal weiter an
$sonne machen. Denn da klappt ja noch 'was grundsätzlich ganz und gar nicht! Da bekomme ich derzeit nur "Schwachsinnswerte". :cry:
Ciao,
Django
Griaseichallemidananda!
Also irgendwie beiß ich mir gerade gewaltig die Beisserchen aus. Wie die Sonnenscheindauer in dem Datensatz verschlüselt ist, ist mir im Moment noch völlig unklar.
Auf dem Display der WS500 konnte ich vorhin ablesen:
Sonnenscheindauer: 12:30 h und Gesamt 22 h
Frage ich die Station ab bekomme ich folgende Ausgabe:
Der empfangene Datensatz lautet:
fe, 33, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, e3, 3c, 0, f0, 0, 5, 43, 3, 5, d9, 0, d1, 3a, 3, b8, 2, fc,
bzw.:
254, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 227, 60, 0, 240, 0, 5, 67, 3, 5, 217, 0, 209, 58, 3, 184, 2, 252,
+-------------------------------------------------------+
+ aktueller Datensatz |
+-------------------------------------------------------+
| Regenmenge: 240 Impulse |
| Wind: 5 km/h |
| Windrichtung: 335 ° |
| Windschwankung: 15 ° |
| Luftdruck (rel.): 1011.85 hPa |
| Luftdruck (abs.): 949 hPa |
| Sonnenscheindauer: 1489 Stunden |
| Wetterstatus: 2 |
+-------------------------------------------------------+
| Temperatur 0= 20.9°C |
| Feuchte 0 = 58% rel |
+-------------------------------------------------------+
| Temperatur 1= 0°C |
| Feuchte 1 = 0% rel |
+-------------------------------------------------------+
| Temperatur 2= 0°C |
| Feuchte 2 = 0% rel |
+-------------------------------------------------------+
| Temperatur 3= 0°C |
| Feuchte 3 = 0% rel |
+-------------------------------------------------------+
| Temperatur 4= 0°C |
| Feuchte 4 = 0% rel |
+-------------------------------------------------------+
| Temperatur 5= 0°C |
| Feuchte 5 = 0% rel |
+-------------------------------------------------------+
| Temperatur 6= 0°C |
| Feuchte 6 = 0% rel |
+-------------------------------------------------------+
| Temperatur 7= 0°C |
| Feuchte 7 = 0% rel |
+-------------------------------------------------------+
| Temperatur 8= 0°C |
| Feuchte 8 = 0% rel |
+-------------------------------------------------------+
| Temperatur 9= 22.7°C |
| Feuchte 9 = 60% rel |
+-------------------------------------------------------+Folgende Bytes beinhalten, nach unbestätigten Gerüchten (wo sonst auch - es ist sonst kein Platz mehr unausgefüllt), die Sonnenscheindauer:
fe, 33, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, e3, 3c, 0, f0, 0,
5, 43, 3,
5,
d9, 0, d1, 3a, 3, b8, 2, fc,
Bzw. das ganze nochmals "dezimal":
254, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 227, 60, 0, 240, 0,
5, 67, 3,
5,
217, 0, 209, 58, 3, 184, 2, 252,
So, 0x05 0xD9 ergibt, wenn ich mich nicht irre: 1497
oder die 0x05 = 5 und 0xD9 = 217
Die Werte der WS lauten aber: 12:40 bzw. 22 Std. :x
Seh' ich da den Wald vor lauter Bäume nicht, oder was ist los?
Leider kann ich gerade das Logging von WeatherProfesional der WS500 nicht gegenchecken, da ich mir erst wieder 'nen Windows-Rechner besorgen gehen muss.
Vielleicht kann ja da mal jemand vergleichen, was die WS500 anzeigt und was via USB zur Software übertragen wird.
edit:
In der Bedienungsanleitung zur WS500 hab' ich gefunden:
ZitatDie Wetterstation WS 500 ermittelt in Verbindung mit dem Kombisensor KS
500 die Sonnenscheindauer. Der vom Kombisensor empfangene Helligkeits-
wert wird anhand der – an der Basisstation – eingestellten Schwelle bewertet:
Empfangene Helligkeit größer als Schwellenwert Sonne scheint
Empfangene Helligkeit kleiner als Schwellenwert Sonne scheint nicht
Die Sonnenscheindauer wird mit jedem empfangenen Telegramm um drei Minuten
(entspricht der Zeit zwischen zwei Datentelegrammen) erhöht, sofern Sonnenschein
erkannt wurde.
Das würde also bedeuten, dass das kleinste Delta dann 3 Minuten wäre und ein bit ev. diese drei Minuten repräsentieren könnte, oder? Na, mal sehen ...
Pfiadseich!
Django
Hi Django,
die Tabelle in PG:
CREATE TABLE sunshine
(
savetime timestamptz(0) NOT NULL,
suncounter int4,
counteramount int4,
isshining bool,
newflag bool,
CONSTRAINT sunshine_pkey PRIMARY KEY (savetime)
)
Deshalb dachte ich der Wert ist nur ein Counter wie bei rain.
1497/60=22,95
Vielleicht springt er bei 1380 auf 23 Std
Eine andere Möglichkeit 22,95 zu interpretieren wäre
22 Tage und 22 Std 48 min. Aber eher nicht!
Habe eben mal in meine PG geschaut und eine Überraschung erlebt: obwohl nur ein WS300 speichert WP immer auch einen Datensatz zu sunshine, winddirection und "allen Sensoren"!! Also 1Mio Datensätze Schrott.
Stefan
Habedieehere DuffyDuc!
Zitat von: "DuffyDuc"Deshalb dachte ich der Wert ist nur ein Counter wie bei rain.
Das mit dem Faktor dachte ich mir auch. In der Anleitung steht ja was von 3 Minuten als kleinstes Meßintervall beim Sonnenschein. Aber weder mit dem Faktor 3 oder 20(20 Meßwerte pro Stunde) komme ich da auf einen grünen Zweig. Geschweige denn die Gesamtanzahl der gemessenen Stunden.
Hab' heute Abend mal noch zwei Werte ermittelt:
Feld-Nummer: 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Verwendung : T9 T9 F9 RA IN WI ND *1 *1 SONNE TI TI FI DRUCK WW END
14:21 Tag 24 ges. 00 DD 3B 00 FO 00 00 03 00 06 48 00 EA 35 03 B6 33 FC
14:21 Tag 0 ges. 00 B2 4D 00 F0 00 00 02 00 06 48 00 DE 3B 03 B6 03 FCIch hab' mal die ersten Bytes des jeweiligen current-Datatelegramms gelöscht. Also wenn in dem Datatelegramm die Gesamtsonnenscheindauer codiert übertragen wird, dann in dem Byte Nummero 43 "WW - WetterWilli". Denn das ist das einzigste, das sich nach dem Löschen der Sonnenscheindauer verändert hat.
Werd' mal morgen die Station in den Keller stellen und mein script mitlaufen lassen. Wenn die Funkverbindung dann nicht abreisst, dann sollten wir zumindestens mal alle 5 Minuten das Teil hochzählen sehen, wenn denn dann mal die Sonne scheint.
ZitatHabe eben mal in meine PG geschaut und eine Überraschung erlebt: ... Also 1Mio Datensätze Schrott.
Tja ein Grund mehr, das selbst in die Hand zu nehmen. Sollte ich das ev. konfigurierbar machen, was abgespeichert werden soll und was nicht?
Pfiade,
Django
Griaseichallemidananda!
So ich hab' mich mal heute ein wenig mit der WS500 weiter beschäftigt. Ich hatte eigentlich erwartet, dass der Sonnenscheinzähler genauso wie der Regenzähler zurückgesetzt wird, wenn man einen reset der Sonnenwerte an der Station macht. Dem schein aber vermutlich nicht so zu sein (siehe codeschnipsel).
Ich hab' die Werte mal wieder etwas eingedampft, damit es verständlicher wird:Feld-Nummer: 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
Verwendung : T9 T9 F9 RA IN WI ND *1 *1 SONNE TI TI FI DRUCK WW END
14:21 Tag 24 ges. 00 DD 3B 00 FO 00 00 03 00 06 48 00 EA 35 03 B6 33 FC
14:21 Tag 0 ges. 00 B2 4D 00 F0 00 00 02 00 06 48 00 DE 3B 03 B6 03 FC Sonnenscheindauer an der Station auf 0 gesetzt
00:00 Tag 0 ges. 00 80 56 00 F0 00 00 06 00 06 48 00 D8 3B 03 B4 03 FC
01:27 Tag 1 ges. 00 CC 40 00 F0 00 02 30 03 06 A2 00 DB 3A 03 B4 03 FC
01:30 Tag 1 ges. 00 CC 41 00 F0 00 29 2E 02 06 A5 00 DD 3A 03 B4 03 FC
01:33 Tag 1 ges. 00 CC 41 00 F0 00 29 2E 02 06 A5 00 DD 3A 03 B4 03 FC
01:36 Tag 1 ges. 00 D2 3F 00 F0 00 2C 33 03 06 A8 00 DA 3A 03 B4 03 FC
01:51 Tag 1 ges. 00 DC 3D 00 F0 00 0E 36 03 06 B7 00 DD 3A 03 B4 03 FC
01:54 Tag 1 ges. 00 DA 3D 00 F0 00 2F 35 03 06 BA 00 DE 3A 03 B4 03 FC
01:57 Tag 1 ges. 00 DB 3D 00 F0 00 05 33 03 06 BD 00 DE 3A 03 B4 03 FC
02:00 Tag 2 ges. 00 DA 3E 00 F0 00 2C 35 03 06 C0 00 DE 3A 03 B4 03 FC
02:03 Tag 2 ges. 00 D9 3E 00 F0 00 26 35 03 06 C3 00 DE 3A 03 B4 03 FC
Wie in der Anleitung steht, wird wenn die Sonne scheint immer um "3" weitergezählt.
So, wie es aussieht zählt das Teil einfach stur weiter. Das Byte 37 (lowbyte von Sonne) erhöhrt sich immer um 3 (Minuten).
06 48 00:03 06 4B 00:06 06 4E 00:09 06 52 00:12
06 55 00:15 06 58 00:18 06 5B 00:21 06 5E 00:24
06 62 00:27 06 65 00:30 06 68 00:33 06 6B 00:36
06 6E 00:39 06 72 00:42 06 75 00:45 06 78 00:48
06 7B 00:51 06 7E 00:54 06 82 00:57 06 85 01:00
06 88 01:03 06 8B 01:06 06 8E 01:09 06 92 01:12
06 95 01:15 06 98 01:18 06 9B 01:21 06 9E 01:24
06 A2 01:27 06 A5 01:30 06 A5 01:33 06 A8 01:36
06 AB 01:39 06 AE 01:42 06 B2 01:45 06 B5 01:48
06 B7 01:51 06 BA 01:54 06 BD 01:57 06 C0 02:00
06 C3 02:03
Na komisch, was macht dann der Zähler wenn FF FF erreicht ist? Oder springt er am Monatsende automatisch auf "Null" zurück? Na mal sehen, das dauert ja nicht mehr allzulange bis zum 01.10.
Pfiadseich,
Django
HI,
so, ich hab' mir gerade nochmals den aktuellen Datensatz des "Original" sprich von WP angesehen und diesen mit ws500.pl verglichen.
Das stimmt 1:1 überein. Also das Auslesen klappt schon mal sehr gut. Was mich nach wie vor irritiert ist die eigentümliche Verwendung des 16bit Sonnenschein-3-Minutenzählers.
Warum wird dieser nicht wie der Regenzähler bei einem Reset auf der WS500 auf "0" zurückgesetzt? Ist schon sehr seltsam das Teil! :roll:
Nun gut, dann werd' ich hald einfach den Zähler beim Sonnenschein ebenso verwenden wie beim Regen.
ttyl,
Django
Griaseichallemidananda!
Sodalla, die letzten Tage war ich ein wenig fleißig und stehe sozusagen kurz vor dem Durchbruch. :D
Das Auslesen der WS500 unter LINUX mit (m)einem perl-script klappt nunmehr schon fast zu 99%. Warum keine 100%? Ganz einfach! ;) Die Programmdokumentation ist noch nicht so, dass ich da jemanden als "Betatester" gebrauchen wollte.
Auch das Füttern der Krienke'schen MySQL klappt auch zuverlässig. Es gibt da aber noch den ein oder anderen Punkt, wo ich noch einen kleinen Klärungsbedarf sehe.
Ich werd' die paar Dinge noch mit Rainer abklären. Wenn alles klappt, dann sollte der Veröffentlichung von ws500.pl (0.1.0) bis Ende Oktober dann nichts im Wege stehen.
Ach ja, ich beschränke mich nur auf das Auslesen der Station. :wink: Die Datenaufbereitung erfolgt dann mittels Rainer Krinke's ws2500 bzw. mittels ein paar definierter RRD-PNG's direkt aus ws500.pl heraus.
So aber nun genug gelabert, anbei die versprochenen Bildchen:
Pfiadseich!
Django
HI,
Ich hab' mal zu den beiden Tabellen rain und light je 'n Bildchen gemacht. Ich hoffe mal, die Datenstruktur passt soweit, oder?
ciao,
Django
Zitatdie Datenstruktur passt soweit, oder?
Das musst du schon selbst beantworten, aber wenn du nach der
ZitatKrienke'schen
Anleitung gehst passt es schon.
Beim Regen ist es aber z.b. nicht nötig alle 5 min den selben Zählerstand zu speichern, nur wenn wirklich regen ist dann wäre ein Datenbankeintrag nötig.
PS: hatt es heute 10 Uhr 32 wirklich innerhalb 5 Min 4,7 mm Regen bei euch gegeben?
Griasdebou!
Zitat von: "j_k"Beim Regen ist es aber z.b. nicht nötig alle 5 min den selben Zählerstand zu speichern, nur wenn wirklich regen ist dann wäre ein Datenbankeintrag nötig.
O.K., hat mir Rainer auch schon geschrieben. Werd' das entsprechend berücksichtigen und in meinem perl-script einbauen.
ZitatPS: hatt es heute 10 Uhr 32 wirklich innerhalb 5 Min 4,7 mm Regen bei euch gegeben?
Ja und wie es geregnet hat, das War' ein richtig kleiner Platzregen. :regen:
Aber Spaß beiseite, ich hatte da 'nen kleinen Eimer Wasser über die Station geschüttet. Wie soll ich sonst den ganzen DB-Kram testen? Immer auf Regen und Sonnenschein zu warten ist nicht so der Hit. 8)
ciao,
Django
HI,
nachdem ich's ja schon mal hier (http://www.wetterstationen.info/phpBB/viewtopic.php?p=61449#61449) verraten hatte, hab' ich mich auch mal parallel an ws2500 zum Darstellen der ausgelesenen Werte herangewagt.
Ein paar Kleinigkeiten fehlen noch (sunshine-werte und last counters), aber im Prinzip läuft das Vorhaben "Daten der ws500 unter LINUX auslesen und darstellen" nunmehr schon. Den ganz unerschrockenen und/oder ungläubigen kann ich ja mal einen kleinen Einblick gewähren => ws500 + ws2500 (http://ws500.dynalias.org/wetter/).
Was fehlt nun definitiv noch:
° Dokumentation von ws500.pl
° Den RRD-Teil werd' ich wahrscheinlich wieder aus ws500.pl rauswerfen (oder soll ich den drinnen lassen)
° shunshine-Handling in ws2500
° Letzte Werte für WI,RA,PR in ws2500
Hmmm, irgendwelche Wünsche?
Nun gut, also bis demnaächst ...
ttyl,
Django
Griaseichallemidananda,
gut Ding will Weile haben. Tja das dachte ich mir. Aber irgendwann muss es doch auch mal losgehen. :lol:
Das Ergebnis von ws500.pl findet man hier => ws500 + ws2500 (http://wetter.nausch.org).
Das benötigte Programmpaket ist in der Fußnote vermerkt, oder einfach diesem Verweis folgen =>ws500.pl (http://omni128.de/ws500/ws500-0.1.2.tar.bz2)
Bei Unklarheiten, Verbesserungsvorschlägen einfach melden. Wichtig: vom 19. Mai bis 22. Juli können keine Anfragen beantwortet werden, später natürlich wieder! :)
Also dann viel Spaß damit!
Pfiadseich,
Django
Hoi Django,
auch hier nochmal vielen Dank für die prompte Lieferung!
Rudimentär steht die wetter.cgi-Lösung bereits, die wohl voraussichtlich bis Herbst auch so laufen wird.
Dann soll unser Azubi mal ein schönes PHP-Frontend zur Datenbank basteln, das etwas einfacher und komfortabler im Handling ist, als die wetter.cgi, die zwar hervorragend programmiert ist und klasse Ergebnisse bringt, deren Anpassung für Perl-Laien wie mich jede Menge Stolpersteine birgt.
Kurzum, im Spätjahr gibt es zum Thema Webfrontend unter PHP von mir einen Beitrag, damit ich hier nicht nur fertige Lösungen schnorre. :D
Wer bis dahin Unterstützung zum Thema WS500 und Linux braucht, dem stehe ich gerne so gut ich kann hilfreich zur Seite.
Herzlichst
Rüdiger
Griaseichallemidanada!
Nachdem ich mir, wie vielleicht einige hier mitbekommen haben, eine vernünftige Wetterstation gekauft habe, wird meine ws500-Wettersteite alsbald in den Ruhestand geschickt.
In der HTML-Seite hatte ich bis dato mein perl-script-paket zum Download angeboten. Heruntergeladen wurde es bis dato sage und schreibe 23x. Ich hoffe ja doch, dass es dem ein oder anderen gelungen ist, die Software erfolgreich einzusetzen.
Da ich aber die Seite in den nächsten Wochen vom Netz nehmen werde, wollte ich eigentlich die SW hier zum Download einstellen. Aber leider ist die Erweiterung bz2 im Portal verboten. So bleibt mir nichts weiter übrig, als den Download hier als link anzugeben.
Also, das perl-Programm zum Auslesen der ws500 und zum Schreiben der wetterdaten in eine mySQL-Datenbank findet Ihr zukünftig hier => http://omni128.de/ws500/ws500-0.1.2.tar.bz2
Vielleicht findet sich ja auch jemand, der das Projekt weiterführen kann und will. Mal sehen ... :hehe:
Wenn jemand Fagen und Probleme hat, dann kann er sich natürlich an mich weiterhin wenden.
Also macht'ses guad, in diesem Sinne!
Pfiadseich,
Django
Hallo Django,
Vielen Dank für Dein Skript!
Ich benutze es in Verbindung mit einer WS550. Bei der Verwendung von wetter.cgi hapert es noch, aber die Daten wandern wenigstens in die Datenbank. Mit dem Rest werde ich mich aber noch beschäftigen.
Gruß
Zotti
Hi
Ich lese dieses Forum intensiv und es hat mir mir auch sehr geholfen. Ich bin momentan damit beschäftigt eine Schnittstelle zu programieren mit der die Daten der WS300Pc, WS444PC und der WS500 in Werner Kerns WSwin eingelesen weden können. Im laufe der Programmierung habe ich festgestellt das sich das byte 43 wirklich je nach Vorhersagebild ändert. Diese Erkenntnis wollte ich euch nicht vorenthalten.
macht weiter so
Trix
Griadebou!
Zitat von: "Zotti"Bei der Verwendung von wetter.cgi hapert es noch, aber die Daten wandern wenigstens in die Datenbank. Mit dem Rest werde ich mich aber noch beschäftigen.
Also die wetter.cgi, die mir von Rainer Krienke an die sunshine-Thematik der ws500 angepasst wurde beinhaltet eigentlich alle Änderungen.
Frag' einfach mal Rainer, ob er's Dir auch gibt. Den Konfigurationsteil findest Du ja schon mal anbei.
Pfiade,
Django
Hallo zusammen,
ich habe das Perl-Script für die Verwendung mit der WS444PC angepaßt. Es scheint auch schon zu funktionieren, nur in den Logs fällt die Meldung
Thu Jan 1 18:39:07 2009: get_NEXT_RECORD()
Thu Jan 1 18:39:07 2009: historische Wetterdaten in die MySQL-Datenbank eingetragen
Thu Jan 1 18:39:07 2009: checking next record...()
Thu Jan 1 18:39:08 2009: Fehler: Framelaenge: 4
...
Thu Jan 1 18:39:10 2009: checking next record...()
Thu Jan 1 18:39:10 2009: Fehler: Framelaenge: 4
Thu Jan 1 18:39:10 2009: USB-RS232-Port wird geschlossen...
auf. Handelt es sich hierbei wirklich um einen Fehler, oder bedeutet die Meldung lediglich, dass keine neuen Records zur Verfügung stehen oder nicht alle Sensoren vorhanden sind?
Gruß
Peter
Hi Peter,
glaube, das ist der Fortschritt (WS444).
Die schickt die 4 Byte zurück, die WS300 schickt nix.
Schau mal im Debugmodus, ob die neuesten Daten kommen und passe dann das Skript an (Zeile 520).
Was die WS444 genau schickt, weiß Trix besser. Kommt evtl. was in der Form FE 31 00 00 FC
Stefan
Griasdebou!
Zitat von: "PumpkinEater"Es scheint auch schon zu funktionieren, ...
Tauchen werte in der mysql oder in der csv-Datei auf?
Zitat
nur in den Logs fällt die Meldung
Thu Jan 1 18:39:08 2009: Fehler: Framelaenge: 4
auf. Handelt es sich hierbei wirklich um einen Fehler,
Uff, wie war das gleich nochmals, ist schon so lange her?
Wir wohl dadurch geloggt:
write_Log ("Fehler: Framelaenge: ".$framelaenge);Zitatoder bedeutet die Meldung lediglich, dass keine neuen Records zur Verfügung stehen oder nicht alle Sensoren vorhanden sind?
Also so auf's gerate Wohl hin, vermute ich mal, dass das Datenformat ein wenig anders aussieht. Ich vermute mal, dass das Script mit den empfangenen Daten nix anzufangen weiss, damnach tauchen in der mysql bzw. der csv-Datei keine Werte auf, oder?
cu,
Django
Hallo Django,
die Werte in der mysql-Datenbank und in der csv-Datei sehen eigentlich ganz gut aus (s.u.)
Die Logmeldung tritt ja beim Ausgeben der historischen Datensätze auf. Ich vermute, dass die historischen Daten nur solange gespeichert werden, bis sie einmal ausgelesen wurden. Wenn danach regelmäßig die aktuellen Werte abgerufen werden, werden keine historischen Daten mehr gespeichert.
Wenn man dann trotzdem nochmal auf die historischen Daten zugreift, gibt's dann die Fehlermeldung (soweit meine Theorie ;-))
Gruss
Peter
wetterdaten.csv:
----------------
2009-01-03 05:45:11;66;66;0;0;0;1034;1020;0;-1.9;66;19.6;48;
2009-01-03 05:50:16;66;66;0;0;0;1034;1020;0;-1.9;66;19.7;48;
2009-01-03 05:55:21;66;66;0;0;0;1034;1020;0;-2;65;19.7;48;
2009-01-03 06:00:26;66;66;0;0;0;1034;1020;0;-2;66;19.7;48;
2009-01-03 06:05:30;66;66;0;0;0;1033;1019;0;-2;66;19.7;48;
2009-01-03 06:10:34;66;66;0;0;0;1033;1019;0;-2;66;19.7;48;
2009-01-03 06:15:38;66;66;0;0;0;1033;1019;0;-2;65;19.7;48;
2009-01-03 06:20:42;66;66;0;0;0;1034;1020;0;-2.1;65;19.7;48;
2009-01-03 06:25:47;66;66;0;0;0;1034;1020;0;-2.1;65;19.7;48;
ws300.log:
----------
Sat Jan 3 07:28:17 2009: naechste Konfig-Abfrage: Sat Jan 3 07:33:17 2009
Sat Jan 3 07:29:45 2009: entering next_record()
Sat Jan 3 07:29:46 2009: ----------------------------------------------------
USB-RS232-Port wird geoeffnet...
Sat Jan 3 07:29:46 2009: checking next record...()
Sat Jan 3 07:29:47 2009: get_NEXT_RECORD()
Sat Jan 3 07:29:47 2009: historische Wetterdaten in die MySQL-Datenbank eingetragen
Sat Jan 3 07:29:47 2009: checking next record...()
Sat Jan 3 07:29:47 2009: Fehler: Framelaenge: 4
Sat Jan 3 07:29:47 2009: checking next record...()
Sat Jan 3 07:29:48 2009: Fehler: Framelaenge: 4
Sat Jan 3 07:29:48 2009: checking next record...()
Sat Jan 3 07:29:48 2009: Fehler: Framelaenge: 4
Sat Jan 3 07:29:48 2009: checking next record...()
Sat Jan 3 07:29:49 2009: Fehler: Framelaenge: 4
Sat Jan 3 07:29:49 2009: checking next record...()
Sat Jan 3 07:29:49 2009: Fehler: Framelaenge: 4
Sat Jan 3 07:29:49 2009: checking next record...()
Sat Jan 3 07:29:50 2009: Fehler: Framelaenge: 4
Sat Jan 3 07:29:50 2009: USB-RS232-Port wird geschlossen...
----------------------------------------------------
Sat Jan 3 07:29:50 2009: naechste Record(next)-Abfrage: Sat Jan 3 07:34:50 2009
;-)
Hi,
wusste doch, da gibt's einen Unterschied:
http://www.wetterstationen.info/phpBB/viewtopic.php?t=12152&start=0
Stefan
Hi
Ja es gibt die Möglichkeit, daß die WS444PC ein Telegramm mit 4 Byte zurück gibt.
Ist der Speicher der Station leer und man fragt den nächsten Historiendatensatz mit (&h) "FE 31 FC" ab, antwortet die Station mit "FE 31 00 FC".
Das bedeutet, daß kein Eintrag im Speicher ist.
Das Komische ist aber scheinbar: das machen nicht alle Stationen.?
Gruß Steffen
Update: Das war ein Fehler von mir. FE 31 10 FC kommt auch bei mir zurück.
Zitat von: "Trix"Hi
Ist der Speicher der Station leer und man fragt den nächsten Historiendatensatz mit (&h) "FE 31 FC" ab, antwortet die Station mit "FE 31 00 FC".
Danke für die Infos. Damit kann ich das Programm dann so abändern, dass in diesem Fall keine Fehlermeldung erzeugt wird. Bei mir (WS444PC) kommt in diesem Fall übrigens "FE 31
10 FC" zurück.
Gruß
Peter
Noch eine Frage zur Speicherung der Regenmengen in der Datenbank:
Zitat
# Regenwerte in der Datenbank ablegen
if( $regen_db == 1 ) {
$sql="INSERT INTO $dbdatabase.rain VALUES ('','$newmysqltime','1','40','$regen','$regen_menge','1')";
sqlquery($sql);
}
Warum werden die Regenwerte nur gespeichert, wenn sich die Werte ändern? (bei den Temperatur/Feuchte-Werten wird das ja nicht so gemacht).
Damit gibt es verschiedene Zeitmarken, an denen die einzelnen Wetterdaten gespeichert werden. Wäre es nicht besser, zu bestimmten Zeiten *alle* Wetterdaten zu speichern, unabhängig davon, ob sich die Werte geändert haben?
Gruß
Peter
Gruß
Peter
Hallo Leute,
@Django: Prima arbeit. Danke.
Ich habe leider mit meiner WS 500-2 massive Probleme mit der USB-Verbindung.
Das Perl-Programm fnktioniert ca 1 Minute. Danach kommt es nur noch zu der Fehlermeldung "Verbindung zur WS500 gestoert!"
Wenn ich die Station vom USB-Port trenne und neu einstöpsele, dann geht es weiter. (Wieder ca. 1 Minute).
Ab und an, ist es auch hilfreich ws500.pl abzuschiessen und neu zu starten.
Passiert das bei Euch auch? Wie geht Ihr damit um?
Ist es ein Hardware-Defekt, oder eher ein Timing-Problem?
Lieben Dank schon mal im voraus.
PS:
Hier der Log im debug Mode:
Konfiguriere USB-RS232-Port (/dev/ttyUSB0) ...
+-------------------------------------------------------+
+ Die Einstellungen zur Datenkommunikation lauten: |
+-------------------------------------------------------+
| Baudrate : 19200 |
| Datenbits : 8 |
| Stopbits : 1 |
| Parity : even |
| Handshake : none |
| RTS : 1 |
+-------------------------------------------------------+
Der empfangene Datensatz lautet:
bzw.:
Der empfangene Datensatz lautet:
bzw.:
Der empfangene Datensatz lautet:
bzw.:
Der empfangene Datensatz lautet:
bzw.:
Der empfangene Datensatz lautet:
bzw.:
Der empfangene Datensatz lautet:
bzw.:
1.Warnung: Verbindung zur WS500 gestoert!
Moegliche Ursachen koennten sein:
° USB Verbindung wurde unterbrochen
° Station gerade in Sync-Modus
Verbindungsaufbau erfolgt automatisch erneut in einer Minute!
Hallo hotmaz,
ich bin zwar nicht einer der ewähnten Fachleute, aber ich gebe trotzdem mal meinen Senf dazu:
Werden denn überhaupt in der ersten Minute schon Daten übertragen? Ich vermute, die USB-Schittstelle wird gar nicht erst erkannt oder initialisiert.
Fragen, die vielleicht weiterhelfen:
- Gibt es ein /dev/ttyUSB0 (oder /dev/ttyUSB1)?
- Was sagt lsusb? Dort sollte etwas wie
"Future Technology Devices International, Ltd"
auftauchen.
- Was sagt "cat /proc/bus/usb/devices" ?
Dort sollte ein Eintrag zu finden sein, das auf die Wetterstation hindeutet, mit dem Hinweis "Driver=ftdi_sio"
- Was steht in der /var/log/messages? Gibt es dort Einträge zur ftdi_sio mit einer Medlung "FTDI USB Serial Device converter now attached to ttyUSB0" (wobei statt ttyUSB0 auch ttyUSB1 o.ä. möglich wären, falls Du schon andere Geräte am USB-Port hast, die einen FTDI-Chip beherbergen.
Gruß
Peter
Hi Peter,
In der ca. ersten Minute werden die Daten korrekt gelesen und auch im csv-Datei abgelegt.
Dann kommt es zu der erwähnten Fehlermeldungen.
syslog sieht soweit so gut aus. Das Gerät wird zuverlässig als WS 500 erkannt und an /dev/ttyUSB0 gebunden.
(Aber ich will ja nicht alle paar Minuten am Kabel rütteln :) )
Gruß,
hotmaz
Hi hotmaz,
hmm, dann habe ich auch keine Idee mehr. Unter Windows (möglichst am selben Rechner) funkioniert die Station einwandfrei, oder?
Hast Du unter Linux evt. "brltty" installiert? Diese Software versteht sich scheinbar nicht so gut mit FTDI:
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/175182
Falls es also installiert ist, könntest Du es evt. mal deinstallieren - aber so richtig glaube ich nicht daran, dass dies die Ursache ist. Hast Du noch anderen USB-Geräte am Rechner angeschlossen, die evt. das ttyUSB0-Device "feindlich" übernehmen?
WIe auch immer, viel Erfolg bei der weiteren Fehlersuche.
Gruß
Peter
Griasde,
Zitat von: "PumpkinEater"Warum werden die Regenwerte nur gespeichert, wenn sich die Werte ändern?
Datenökonomie. Wenn ich mich richt erinnere hatte ich das ganz am Anfang so gemacht, aber die Geeks hier überzeugten mich dann, dass das so besser wäre. Was ich dann auch so übernommen hatte, Denn warum in der Datenbank 'n Haufen NULL-Werte anhäufen?
Kannst das Script ja jederzeit bei Bedarf abändern, ist ja sozusagen "Deins". ;)
Pfiade,
Django
HI!
Zitat von: "hotmaz"@Django: Prima arbeit. Danke.
Bittschön! :D
ZitatIch habe leider mit meiner WS 500-2 massive Probleme mit der USB-Verbindung.
Das ist natürlich ärgerlich. Das die USB-Verbindung ab und an abriss hatte ich damals auch, aber das Ganze fing sich dann binnen ein paar Minuten wieder. Warum? Wenn ich ehrlich sein darf, ich hatte es aufgegeben.
Ich hatte das Timingverhalten des FTDI-Treibers in Verdacht.
Da mir die Sensoren der WS500 aber seinerzeit mehr als suspekt waren, hatte ich diese schließlich verkauft und mir 'was G'scheids geholt. Leider kann ich so weder das Script noch den treiber weiter testen oder gar entwickeln, leider.
ZitatIst es ein Hardware-Defekt, oder eher ein Timing-Problem?
Ich tippe da auf letzteres.
Pfiade,
Django
Griaseich,
bin gerade dabei die Doku von ws500.pl etwas zu ergänzen.
Dazu bräuchte ich noch 'n bisserl Input. Könnte mir einer mal sagen, wie die Station "erkannt" wird?
Ausgabe der Station bei cat /proc/bus/usb/devices?
und lsusb?
muchos gracias!
Pfiadseich!
Django
Hi Django,
cat /proc/usb/devices liefert folgendes:
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0403 ProdID=e0e9 Rev= 2.00
S: Manufacturer=ELV AG
S: Product=ELV WS 500
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 44mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
und lsusb:
Bus 003 Device 004: ID 0403:e0e9 Future Technology Devices International, Ltd
VG
muchos gracias!
Hallo zusammen,
ich habe noch mal eine Frage zur verwendeten Datenbankstruktur und zur MySQL-Abfrage der Daten: Die Wetterdaten werden ja in verschiedenen mysql-Tabellen gespeichert und nicht in einer zentralen. Wenn ich nun aber auf meiner Webseite eine Liste bestehend aus Zeit, Temperatur, Wind und Regen erstellen möchte, so muss ich eine SQL-Abfrage basteln, die parallel auf die verschiedenen DB-Tabellen zugreift. Als MySQL-Laie habe ich mal folgendes probiert:
$query = "SELECT DATE_FORMAT(th_sensors.datetime,'%e.%m.%Y') as date,DATE_FORMAT(th_sensors.datetime,'%H:%i:%s') as time,th_sensors.T,th_sensors.H,th_sensors.sensid,th_sensors.ok, pressure.datetime, pressure.P, rain.diff
FROM th_sensors, rain, pressure, wind
WHERE th_sensors.datetime = pressure.datetime &&
th_sensors.datetime = rain.datetime &&
wind.datetime = pressure.datetime &&
th_sensors.datetime >= \"$from_date\" AND th_sensors.datetime <= \"$to_date 23:59:59\" AND th_sensors.sensid = \"9\" AND th_sensors.ok = \"1\"";
Das funktioniert soweit ganz gut, ist aber aufwendig und etwas unübersichtlich. Außerdem werden nur dann Werte zurückgegeben, wenn für den Zeitpunkt in *allen* DB-Tabellen Einträge gespeichert werden. Wenn z.B. für einen Zeitpunkt kein Luftdruck-Wert vorliegt, gibt's dann auch keine Temperaturwerte für diese Zeit. Ich habe bereits versucht, in der Abfrage im "WHERE"-Teil die UND-Vernüpfungen herauszunehmen und nur noch das Zeitinvall bezogen auf die Tabelle th_sensors zu verwenden, was aber nicht funktioniert.
Frage zur Datenbankstruktur: Warum wird hier nicht nur eine zentrale Tabelle mit allen Wetterwerten verwendet? Welche Vorteile hat die Verwendung von mehreren Tabellen? Die Struktur ist ja hier im Forum abgestimmt worden. Ich vermute, dass es daher gute Gründe für diese Struktur gibt (cih möchte das Rad nicht neu erfinden und möglichst auf einen Quasi-Standard aufsetzen).
Kann man die obige SQL-Abfrage noch etwas besser schreiben?
Vielen Dank schon mal für Eure Tipps.
Gruß
Peter
Hi PumpkinEater,
Das Zauberwort für Dein Problem heißt Leftjoin oder Outerjoin, dass heisst, wenn du ein join über Tabelle A und B machst, die Abfrage auch dann antworten liefert, wenn zu einem Satz in A kein Satz in B enthalten ist.
Wie das in mySQL gemacht wird, weiß ich jetzt leider nicht.
Ich weiß nicht wie es jetzt ist, aber mySQL hatte früher massive Performanz-Probleme mit exzessive Join-Abragen.
Es spräche aber auch nichts dagegen das Skript so zu erweitern, dass neben der bisherigen Daten, redundant für Deine Zwecke eine Tabelle mit allen Daten in einer Reihe gefüllt wird.
Gruß,
Maz
Hi Django, Duffy, r_k,
weiß jemand, wie die Werte bei Wetterstatus auszuwerten sind?
Soweit ich die Diskussion überblicke, ist das ein Indikator für Wetterwilli.
Aber wie werte ich das für meine Anwendungen aus?
Gruß
Maz
Hi maz,
glaube trix hat das irgendwo ergründet.
Stefan
Griasdebou!
Zitat von: "hotmaz"weiß jemand, wie die Werte bei Wetterstatus auszuwerten sind?
Nope, ich hatte das mal "erkannt" in den Datentelegrammen, jedoch nie weiter verfolgt. Und nun ohne eineWS500 kann ich da leider nix mehr zu beisteuern. Leider.
ZitatSoweit ich die Diskussion überblicke, ist das ein Indikator für Wetterwilli.
Richtig!
ZitatAber wie werte ich das für meine Anwendungen aus?
Na, im Zweifelsfalle, so wie ich es damals gemacht hatte, trial and error! ;)
Pfiade,
Django
Griasdebou!
Zitat von: "PumpkinEater"Die Wetterdaten werden ja in verschiedenen mysql-Tabellen gespeichert und nicht in einer zentralen.
Richtig, der sogenannten
Krinke'schen MySQL-Datenbankdefinitionstabelle[/b].
ZitatWenn ich nun aber auf meiner Webseite eine Liste bestehend aus Zeit, Temperatur, Wind und Regen erstellen möchte, so muss ich eine SQL-Abfrage basteln, die parallel auf die verschiedenen DB-Tabellen zugreift.
Jepp, soweit richtig erkannt. Das ist dann auch realtiv leicht gemacht, wenn man weiss wie's geht. ;)
ZitatFrage zur Datenbankstruktur: Warum wird hier nicht nur eine zentrale Tabelle mit allen Wetterwerten verwendet? Welche Vorteile hat die Verwendung von mehreren Tabellen?
Erste Frage: Ganz einfach, weil ich damals überzeugt wurde auf ein bereits existierenedes Schemata aufzusetzen um dann für die Visualisierung auf vorhandene Möglichkeiten aufsetzen zu können.
Zweite Frage: Nächste Frage. :lol: Nein, ich kann dann sehr einfach auf abgeschlossene Bereich zugreifen und diese Ändern und auch neue Datentabellen anfüren und das während des Betriebes ohne die bereits bestehende Tabelle anfassen zu müssen, wenn ich weitere Sensoren dazupacken will.
ZitatKann man die obige SQL-Abfrage noch etwas besser schreiben?
Mangels Daten in (m)einer Tabelle, versuche ich es mal etwas abstrakt zu formulieren. Doch zuvor eine kleine Bitte. Könntest Du mir mal einen kleinen Extrakt Deiner Datenbank zukommen lassen? So 1 Tag wär' O.K., Ich könnte dann ein wenig damit spielen - geht z.B. via
PHPmyAdmin sehr einfach.
Aber nun zu meinem Versprechen:
SELECT a.speed, a.angle, b.sundur FROM wind a, wind b where a.stationid = b.stationid where datetime REGEXP '2009.';Sollte Dir z.B. die Windgeschwindigkeit, Windrichtung und Sonnenscheindauer auswerfen, obwohl diese aus unterschiedlichen Tabellen kommen. Ist ein Wert davon = "0", dann wirft er entsprechen auch diese "0" aus. Soweit zur Theorie, habe hier keine Daten zum Testen; eventuell kannst Du mir aber mal ein paar exportieren und zukommen lassen, dann wird die Testerei einfacher.
Pfiade,
Django
Zitat von: "hotmaz"
Das Zauberwort für Dein Problem heißt Leftjoin oder Outerjoin, dass heisst, wenn du ein join über Tabelle A und B machst, die Abfrage auch dann antworten liefert, wenn zu einem Satz in A kein Satz in B enthalten ist.
Danke für den Tipp. Ich werde mich mal damit beschäftigen.
Gruß
Peter