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.

Code:

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!

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:

Code:

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!

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.

Code:

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

Griasde,

j_k hat folgendes geschrieben:

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?

Zitat:

Ein 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!

DuffyDuc hat folgendes geschrieben:

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.

Zitat:

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

Zitat:

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

Zitat:

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

Zitat:

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

Zitat:

Die 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:

Code:

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

ttyl,
Django

HI j_k!

j_k hat folgendes geschrieben:

... schau dir meine Erklärungen zum Escape Handling an.

Okidoki, hab's gefunden und hoffentlich auch verstanden.

Code:

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öht

Wo 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!

Django hat folgendes geschrieben:

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

Code:

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:

Zitat:

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

Zitat:

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

Zitat:

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?

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

Zitat:

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?

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

Code:

12362 / 5 = 2472

Datensätze in der Station gespeichert, würde ich langsam mal auslesen

Zitat:

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.

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!

j_k hat folgendes geschrieben:

So viele Beiträge....

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

Zitat:

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

Zitat:

Der ä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 )

Zitat:

genau so ist es, deine rechnung geht allerdings nur beim speicherintervall von 5 min auf. Du hasst also : Code: 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.

Zitat:

Im 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!

Zitat:

Allerdings 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