Hallo,
wer von euch nutzt auch den Klimalogger von TFA? http://www.wetterstationen.info/klimalo ... eratur.php
Es gäbe nämlich hier eine Möglichkeit, die Daten dieses Loggers (wenn auch nicht vollautomatisch) in WSWIN auszuwerten.
Vor ich hier Näheres sage, möchte ich aber erstmal abwarten, ob überhaupt Bedarf besteht.
@Werner
Sebastian Luhn hat (nach einigen Hinweisen von mir ) ein Tool geschrieben, das die Loggerdaten in eine ws_newdata.csv wandeln kann.
Ich bin noch ein Laie, habe mir besagten TFA Klimalogger und zwei Funksensoren zugelegt und versuche gerade (vergeblich), die Daten irgendwie in WSWIN zu bekommen. Dazu habe ich mir zunächst die Testversion heruntergeladen. Gern würde ich das Programm auch kaufen. Die sehr mühhselige Konvertierung der Daten über die mitgelieferte Software und Excel ist auf Dauer jedoch kein Zustand.
Steht das Angebot noch, auch wenn es bisher offenbar nur einen Interessenten gibt? Wie könnte ich an besagtes Tool gelangen?
das nächste Update beherrscht die Binären-Klima-Logger-Daten
z.B. history.drf direkt (über Konvertieren) - wenn der Logger die Daten automatisch abholen würde, wäre damit auch Datei-Überwachung möglich.
Sebastians Konverter mag (Ausnahme Mebus) bald überflüssig sein, aber er hat mit der Automatisierung der Loggerauslese ja schon ein neues Betätigungsfeld gefunden. Das kleine Hilfsprogramm zur Fernbedienung der Datarecorder Software braucht zwar noch ein bißchen Feinschliff, aber es funktioniert schon.
Rein interessehalber arbeite ich zwar noch an der Decodierung des Übertragungsprotokolls, aber der Aufwand dafür dürfte sich nicht lohnen, wenn man mit dem vergleichsweise simplen Automationstool schneller zu Potte koppt. Außerdem ist AutoIt auch ein praktikabler Ansatz für viele andere Stationen mit nicht dokumentierten Protokollen.
Da wäre es schon eher sinnvoll, wenn WsWin solche AutoIt Scripte selbsttätig aufrufen könnte, statt über unzählige low-level Kommunikationsprotokolle zu grübeln.
Ähm, Werner, 'weisst Du zufällig', ob das Format der History files selbst erhackt wurde, oder gab's dazu 'offizielle' Info von TFA?
Der Hintergrund meiner Frage ist, dass ich mich mit der Analyse des seriellen Protokolls des Klimaloggers befasse und das Format der binären History Datei mir ggfs. Aufschlüsse über das Protokoll geben könnte.
Wenn es erlaubt und nicht zuviel Aufwand ist, kannst Du mal grob die Struktur der Datei beschreiben?
carstenk hat geschrieben:Das kleine Hilfsprogramm zur Fernbedienung der Datarecorder Software braucht zwar noch ein bißchen Feinschliff, aber es funktioniert schon.
Feinschliff erfolgt
Ich habe jetzt auch eine Fernsteuerung für die Fernsteuerung in mein Programm eingebaut. Sprich, man kann z.B. einstellen, dass das Skript jede Stunde aufgerufen wird und dann die Daten automatisch konvertiert und in WsWIN eingelesen werden.
Alle Interessierten können sich hier über mein Tool informieren.
Mit freundlichen Grüßen
Sebastian Luhn
PS: Ich weiß nicht, ob das schön aussieht, wenn ich im ersten Post von mir direkt auf die eigene Seite verweise... aber da hier ja über mein Tool gesprochen wird, ist das vielleicht verzeihlich
Ich weiß nicht, ob das schön aussieht, wenn ich im ersten Post von mir direkt auf die eigene Seite verweise... aber da hier ja über mein Tool gesprochen wird, ist das vielleicht verzeihlich
Ich denke, das ist schon in Ordnung. Ich hätte sowieso jetzt eben einen Beitrag zu deinem Projekt gebracht, aber das ist ja jetzt bereits von dir erledigt.
Du hast Recht, Werner, das serielle Protokoll des Klimaloggers sieht wirklich dem der WS3600 sehr ähnlich. Ich hatte das schonmal überschlagen, war aber damals von der Erwähnung von TX Daten in die Irre geführt worden, über Tx und Rx fliesst beim Klimalogger nämlich garnichts. Nun ist mittlerweile aber wohl klar, dass diese Daten bei der 3600 offenbar auch keine Bedeutung für das Protokoll an sich haben und vernachlässigt werden können. Womöglich dienen die bei der 3600 nur zu ner automatischen Erkennung der Station in einer Autodetect Routine, Versorgung eines Pegelwandlers o.ä.. Es könnte sogar sein, dass die Dump Routine für die 3600 mit dem Klimalogger kompatibel ist, werde ich mal ausprobieren und hoffen, dass das schlimmste, was passieren kann, ein Vollreset für den Klimalogger wird...
schalte beim Datenlogger einmal die LOG-Funktion ein:
Datei DataRecorder.xml
<LogToFile value="1" />
was <LogLevel value="30" /> bewirkt habe ich nicht getestet.
Es wird dann für jeden Tag eine LOG__*.txt -Datei erzeugt mit solchen
Einträgen:
18:27:59_965_878: ===========================
18:27:59_965_878: Request Read RingBuffer Start
18:27:59_965_878: Synchronizing with weather station
18:28:01_434_878: Synchronizing Try 2
18:28:03_168_878: Reading from 0xB, 2 bytes
18:28:03_168_878: Reading block from 0xB, 2 bytes
18:28:03_168_878: Reading from 0x51, 16 bytes
18:28:03_168_878: Reading block from 0x51, 16 bytes
18:28:03_200_878: Reading from 0x64, 32659 bytes
18:28:03_200_878: Reading block from 0x64, 1800 bytes, 32659 bytes left
18:28:06_996_878: Reading block from 0x76C, 1800 bytes, 30859 bytes left
18:28:10_512_878: Reading block from 0xE74, 1800 bytes, 29059 bytes left
18:28:14_106_878: Reading block from 0x157C, 1800 bytes, 27259 bytes left
Hatte diese Einträge in der XML Datei schon gesehen, aber noch nicht ausprobiert. Scheint aber schonmal die halbe Miete zu sein, dieser Debug Mode.
Interessant ist, auch aus der Übereinstimmung mit der 3600, dass man scheinbar so auch auf die aktuellen Daten zugreifen kann (wenn man weiss, wo die stehen), nicht nur auf die Log Daten. Im Klimalogger wird ein 32kByte EEPROM verwendet. Ich vermute, dass die Station dort neben den Logwerten in einem separaten Bereich auch div. Betriebsparameter und evtl. auch aktuelle Messungen unterbringt.
Der Logspeicher scheint bei 109 Byte über 0 anzufangen. Zu Anfang fragt der Rekorder vermutlich Anzahl Kanäle, Pointer des Ringbuffers, vielleicht auch das Speicherintervall ab, je nachdem, ob da absolute Zeitmarken oder relative verwendet werden. Interessanterweise liest die Software aber trotzdem immer den kompletten Speicher aus, statt ggfs. über die Pointer zu erfahren, welche Daten wirklich aktuell sind.
Werd mich mal weiter damit beschäftigen. Heute ist mein Logger mit 1min/5ch das erste mal vollgelaufen, so dass ich erstmal weiss, wieviel Speicher der überhaupt für einen Datensatz verwendet. Werde das Auslesen gleichmal im Debug Modus machen.
Die Zeitmarken im Debugfile sind auch interessant, weil die durch die hohe Auflösung evtl. mit den Zeitmarken des PortMon korreliert werden können.
Hmm, und was am Ende des Auslesevorganges in's Log geschrieben wird, erklärt dann eigentlich alles...
-----snip-----
...
13:42:37_631_B60: Reading block from 0x77EC, 1800 bytes, 2059 bytes left
13:42:44_762_B60: Reading block from 0x7EF4, 259 bytes, 259 bytes left
13:42:45_803_B60: EEPROM Flags (4), full (1)
13:42:45_823_B60: Ring buffer config: NrOfTransmitters (5), Start(0x64), End(0x7FF8), ByteSize(32660), DatasetSize(20), DatasetCount(1633)
13:42:45_873_B60: Read configuration: LastReadDateTime (18-02-06 04:42:00), LastReadIndex(1502), LastNrOfTransmitters(5)
13:42:45_873_B60: LastReadDateTime (20-02-06 11:09:00) not equal to stored last read datetime (18-02-06 04:42:00), parsing whole ring buffer
13:42:45_873_B60: Searching for end marker from 0x64 to 0x7FF8
13:42:45_883_B60: Possible end marker at buffer position 900 is VALID: datetime after end marker (19-02-06 10:53:00) is less than the datetime before end marker (20-02-06 14:04:00)
13:42:45_883_B60: Using bytes after end marker at EEPROM address (0x3FC) for parsing
13:42:45_893_B60: Using bytes from start (0x64), to before end marker (0x3E7), bytes (900) for parsing
13:42:46_094_B60: Parsed 1632 datasets
13:42:46_094_B60: Calculating and writing new ring buffer configuration
13:42:46_094_B60: Found valid LastReadDateTime (20-02-06 14:04:00) with LastReadIndex 44
13:42:47_375_B60: Cleaned parsed datasets, removed 0 invalid datasets, removed 0 read double datasets, removed 0 double datasets
13:42:47_566_B60: Append history file finished 1632 dp, 180 ms
13:42:47_616_B60: 1632 valid datasets appended, last parsed dataset datetime is 20-02-06 14:04:00
13:42:47_616_B60: Using new LastReadDateTime (20-02-06 14:04:00), LastReadIndex (44), LastNrOfTransmitters(5) for next read
13:42:47_616_B60: Synchronizing with weather station
13:42:49_719_B60: Writing to 0x51, 16 bytes
13:42:49_769_B60: Write configuration: LastReadDateTime (20-02-06 14:04:00), LastReadIndex(44), LastNrOfTransmitters(5)
13:42:49_769_B60: Writing to 0x9, 2 bytes
13:42:49_789_B60: Request finished
-----snip------
Und wo wir gerade dabei sind: Der Parameter LogLevel im XML Konfigurationsfile des Datarecorders macht das, was man erwartet, er aktiviert unterschiedliche Detailstufen des DebugLogs.
Ich habe noch nicht viele ausprobiert, aber scheinbar geht das teilweise runter bis auf die Bitebene der Loggeransteuerung, da finden sich dann z.B. solche Sachen wie:
Try 1
15:39:11_799_CD4: Dummy buffer io written
15:39:11_799_CD4: Looking for valid SclLow
15:39:11_899_CD4: Found valid SclLow, waiting for SclHigh
15:39:11_909_CD4: Scl is SclLow, unchanged 1 times 5 ms
15:39:11_919_CD4: Scl is SclLow, unchanged 2 times 5 ms
15:39:11_919_CD4: Scl changed to SclHigh after 2 waits for 5 ms
15:39:11_929_CD4: Scl is SclHigh, unchanged 1 times 5 ms
15:39:11_939_CD4: Scl is SclHigh, unchanged 2 times 5 ms
Was mir momentan noch ein bißchen 'Sorgen' macht sind diese teilweise mehreren Synchronisationsversuche der Software mit der Wetterstation.
Bin mir noch nicht ganz im klaren darüber, welche Auswirkungen das ggfs. auf eigenen Code haben könnte. Wenn es nur darum, zu Beginn der Kommunikation einen Sync des Bitshake Protokolls hinzukriegen, ist es wohl halb so wild. Wenn da irgendein Timing während der gesamten Kommunikation eingehalten werden muss, könnte es hakliger werden.
Da ich aber nach dem Start keine weiteren Syncversuche im Log sehe, außer im 'Ruhemodus' des Datarecorders, nehme ich das erstmal nicht an.
) ein Tool geschrieben, das die Loggerdaten in eine ws_newdata.csv wandeln kann.
