Neu im Test: Klimalogger

[wupperbayer]

Hallo Carsten,

habe jetzt mal den Hinweis sowohl auf die Seite als auch in die ZIP-Datei gepackt.

Nochmal zu deinem Vorschlag: Auch ein ZIP-Archiv zu erstellen ist, jedenfalls so wie ich das verstanden habe, absolut nutzlos, wenn die Auslese-Zeit 5 Minuten beträgt. Selbst, wenn die Dateien klein sind - was will man damit? Man hat dann, wenn man z.B. die Daten von vier Stunden wiederherstellen will, 48(!) Dateien einzulesen und zu konvertieren, da ja in jeder history.drf nur ein Datensatz enthalten ist.

Und dafür habe ich noch keine Lösung, ich suche aber auch schon eine. Denn so wie bisher ist es nicht sehr ausfallsicher, da gebe ich dir Recht.

Gruß

Sebastian

[carstenk]

Ja, klar, bei kurzen Ausleseintervallen bringt ZIP nix. Das einzige, was da Sinn machen würde wäre, das history file längere Zeit wachsen zu lassen und nur in längeren Abständen zu sichern.

Wenn ich das richtig verstanden hatte, hat dein Konverter kein Problem mit überlappenden Daten bzw. Zuwachs, du willst lediglich verhinden, dass die Export/Konvertierungsvorgänge wegen der alten Daten immer länger dauern, oder?

Die Gefahr ist aber doch bei so kurzen Ausleseintervallen nicht gegeben, da wandern doch nur ne Handvoll Daten ins Log. Was spricht dagegen, das history file einen/mehrere Tage lang wachsen zu lassen und es dann erst bei einer Größe von einigen 100 Kbyte zu sichern? Die Abfrage der Grösse könnte AutoIt gleich beim Start mit FileGetSize machen und in Abhängigkeit davon die History sichern. Das wäre auch ne einigermaßen saubere Kontrolle über die Konvertierungszeiten.

Ich bin mir im Übrigen nicht ganz sicher, ob ich alle Eventualitäten deines Konverters bedacht habe, aber warum rufst Du den Konverter nicht am Ende des AutoIt Skriptes mit dem exportierten Dateinamen auf? Dann findet die Konvertierung automatisch nach dem erfolgreichen Export statt, und man muss sich nicht mehr auf bestimmte Import/Export Zeiten verlassen für die Dateiüberwachung. Auslesen>Export>Konvertierung>WsWin Überwachung.
Ich persönlich packe mir das AutoIt Skript in den normalen Windows Task Scheduler. Der Vorteil ist: Die Programme sind nur so lange am Laufen, wie sie benötigt werden, das ist nicht nur resourcenschonender, es verringert auch das Risiko, dass sich nach einiger Zeit was 'verklemmt'. Notfalls kann man die Programme duch den Taskscheduler auch mit Gewalt beenden lassen, wenn ein Timeout erreicht ist.
Mit dem was Du jetzt aus AutoIt weisst, kannst Du natürlich auch versuchen, die Datarecorder Fernsteuerung direkt aus Delphi zu machen. Ich weiss allerdings auch nicht, welche Komponenten dafür ggfs. nötig sind.

Unsere Ansprüche sind da auch einfach etwas verschiedenen - ich will durch (seltenes) automatisches Auslesen des Klimaloggers lediglich sicherstellen, dass keine Daten im Speicher überschrieben werden und ich eine zusammenhängende History kriege. Du willst damit quasi den Echtzeitbetrieb erreichen, also eine Online Darstellung der Messdaten. Da ist natürlich alleine der sehr zähe Importvorgang schon hinderlich.

Auf Dauer wäre es für dich (und andere;-) dann vermutlich schon lohnender, das Klimaloggerprotokoll selbst zu fahren. Da könntest Du gezielt im Bruchteil einer Sekunde die aktuellen Daten auslesen. Abgesehen von dieser für mich noch ominösen Synchronisation ist das nicht so sonderlich schwer, denke ich.
Du kannst Dich ja bei Gelegenheit mal mit Schnittstellenprogrammierung in Delphi befassen. Genauer gesagt, beim Klimalogger eigentlich eher Portprogrammierung, es werden ja nur Portbits an der RS232 getoggelt. Eine allgemeine RS232 Komponente oder DLL für Delphi, die lediglich Rx/Tx in Verbindung mit Flusskontrole erlaubt, reicht da nicht aus.

- Carsten

[wupperbayer]

Hallo Carsten,

Die Gefahr ist aber doch bei so kurzen Ausleseintervallen nicht gegeben, da wandern doch nur ne Handvoll Daten ins Log. Was spricht dagegen, das history file einen/mehrere Tage lang wachsen zu lassen und es dann erst bei einer Größe von einigen 100 Kbyte zu sichern? Die Abfrage der Grösse könnte AutoIt gleich beim Start mit FileGetSize machen und in Abhängigkeit davon die History sichern. Das wäre auch ne einigermaßen saubere Kontrolle über die Konvertierungszeiten.

Gute Idee! Werde ich mal einbauen, aber nicht mehr heute

Ich persönlich packe mir das AutoIt Skript in den normalen Windows Task Scheduler. Der Vorteil ist: Die Programme sind nur so lange am Laufen, wie sie benötigt werden, das ist nicht nur resourcenschonender, es verringert auch das Risiko, dass sich nach einiger Zeit was 'verklemmt'.

Nun ja, ob man jetzt mit dem Script den Konverter aufruft oder umgekehrt, ist meiner Meinung nach Jacke wie Hose. Und der Teil, der das Script aufruft, ist eigentlich auch nicht mehr als der Windows Task Scheduler, nur eben - wiederum meiner Meinung nach - etwas "feinfühliger" einzustellen - ich kann mich da aber auch irren. Nur: Die Zeiten sind doch so oder so fest, ob nun per Task Scheduler oder per Konverter, oder nicht?

Außerdem wollte ich den anderen Usern eine Möglichkeit bieten, die NUR auf von mir bereitgestellten Programmen basiert (und dem Data Recorder, natürlich). Aber das ist "Geschmackssache".

Du willst damit quasi den Echtzeitbetrieb erreichen, also eine Online Darstellung der Messdaten. Da ist natürlich alleine der sehr zähe Importvorgang schon hinderlich.

Stimmt, unsere Ansprüche könnten unterschiedlicher kaum sein Zum Testen hab ich mal auf http://www.8ung.at/wupperbayer/wetter/current.html die Seite hochgeladen, sollte sich alle 5 Minuten aktualisieren.
Und wenn ich den PC einfach laufen lasse, ist mir fast egal, wie lange der Auslesevorgang dauert. Das einzige Problem ist, dass die Daten natürlich aktueller sein könnten. Aktuell ist die Differenz 2 Minuten (messen->ins EEPROM schreiben) + 2 Minuten (Auslesen + Konvertieren) + 30 Sekunden (Erstellen der HTML-Dateien und "Puffer" für den FTP-Client), also etwa 4 1/2 Minuten. Das ist schon fast ein ganzes Messintervall, also eigentlich zu viel.

Schnittstellenprogrammierung in Delphi befassen. Genauer gesagt, beim Klimalogger eigentlich eher Portprogrammierung, es werden ja nur Portbits an der RS232 getoggelt. Eine allgemeine RS232 Komponente oder DLL für Delphi, die lediglich Rx/Tx in Verbindung mit Flusskontrole erlaubt, reicht da nicht aus.

Da ich gerade gemerkt habe, dass Delphi mit den richtigen eingebundenen Units verdammt viel kann, sollte das eigentlich auch gehen (das Programmieren von "fremden" GUIs geht auch, nur muss man da das Windows SDK nehmen, und dessen Dokumentation ist zwar nicht schlecht, aber es fehlt irgendwie ein "Crashkurs" oder so was. Außerdem sind alle SDK-Beispiele in C++, da muss man erst mal Umdenken, auch wenn's relativ schnell geht).

Gruß

Sebastian

EDIT: Jetzt klappt auch http://www.8ung.at/wupperbayer/wetter/.

Dazu gleich mal ne Frage: Habe mir WsWIN vorgestern gekauft und heute die Vollversion erhalten. Trotzdem behauptet er auf der index.html, die Version wäre eingeschränkt. Auf der current.html behauptet er dies nicht. Warum? Hab die Version einfach drüberinstalliert, da ich nicht erst alle Monatsdaten ex- und dann wieder importieren wollte.

EDIT2: Hat sich erledigt.

[bk4]

Hallo,

mich würde interessieren, ob der Klimalogger auch mit anderen Funksensoren zusammenarbeitet. Bei Lacrosse wird ein technisch ähnliches Gerät angeboten (WS8610), und als Sensor ist eine Box abgebildet, die mir für eine Montage im freien wesentlich besser gefiele als das Teil von TFA. Sie trägt die Aufschrift "Remote Thermo Hygro 433 MHz" und ähnelt stark dem Thermosensor meines alten TFA Funkthermometers von 1998.

Grüße
Bernd

[carstenk]

Ja, das Protokoll der TFA Klimaloggersensoren ist kompatibel mit den älteren Sensoren, die Du erwähnst. Such dich mal hier durch die Klimalogger threads, da wirst Du fündig.

Ich kenne übrigens beide Gehäusearten, und wenn es in deinem Fall nicht gerade Gründe gegen das längliche Format beim TFA Logger gibt, würde ich lieber die Original TFA Sender mit dem Schweizer Sensor und Display nehmen - die haben nämlich den besseren Sensor.
Das kleine quadratische Gehäuse ist eher noch liederlicher verarbeitet. Beim TFA Sender hat immerhin die Batterieklappe eine Schraube und umlaufende Gummidichtung. Das Gehäuse ist nur unten offen, und falls dort mal Wasser reingeraten sollte, läuft es auch sofort unten wieder raus. Bei dem Sender, den Du (ELV?) gesehen hast, sind die Batteriekontakte direkt auf der Platine im Batteriefach angebracht. In meinen Augen ist das ein großes Korrosionsrisiko für die Platine.

Zur Langzeitstabilität der TFA Sender mit dem sehr genauen digitalen Sensor kann ich nix sagen, aber die Sensoren in den älteren Sendern  machen gerne mal Ärger, gerade die Hygrosensoren zeigen irgendwann falsche oder statische Werte an. Auch dazu gibts div. Bemerkungen im Forum.




- Carsten

[MSE29]

N'Abend!

Wollte, nach dem der Klimalogger einige Zeit viele Daten gesammelt hat, die Daten der mit DataRecorder exportierten *.txt-Datei mit OpenOffice auswerten. Beim Importieren der Text-Datei, fragt OpenOffice auch ordnungsgemäß nach welcher Art (in diesem Fall das Semikolon) getrennt werden soll. Nach Bestätigung der Angaben wird die Text-Datei entsprechend nach OpenOffice importiert. Alle Daten sind in den jeweiligen Zeilen und Spalten. Mit Ausnahme der Temperaturwerte ist alles richtig formatiert. Diese Angaben werden merkwürdigerweise im Datumsformat ausgegeben. Nach versuchtem Umformatieren in das 0,0-Zahlenformat werden irrsinnig lange Zahlen angezeigt. Nun die Frage: Wie bekomme ich vernünftige Temperaturwerte nach OpenOffice importiert?

MfG
MSE29

[carstenk]

Hab leider keine Erfahrung mit OpenOffice. Wenn man CSV Daten mit MS Excel einfach öffnet, werden auch fast immer einzelne Spalten falsch formatiert, und das lässt sich auch durch eine spätere abweichende Zellenformatierung oft nicht mehr hinbiegen. Für solche Fälle hat EXCEL eine spezielle Import Funktion, bei der man für jede Spalte bereits während des Imports das Format wählen kann, ebenso wie Dinge wie Trennzeichen, etc. Schau doch mal in der OpenOffice Doku, ob es dort auch eine separate Importfunktion gibt. Vielleicht wird die auch automatisch aufgerufen, wenn Du die Datei in *.csv umbenennst und mit OO öffnest.


- Carsten

[wneudeck]

Hallo mse29,
Ich bin zwar kein OpenOffice-Experte, aber ich vermute, dass es am Dezimalzeichen liegt.
Wenn in der Ausgangsdatei das Dezimalzeichen ein Punkt ist, ersetze ihn mal versuchsweise durch ein Komma.(suche - ersetzen)
Dann sollte sich die Datei richtig importieren lassen.
Ob dies ein praktikabler Weg ist, ist die andere Frage.
Beispiel:
Ausgangsdatei:
02.05.2006;18:10;20.6;18.8;20.0
Nach Suchen - Ersetzen so:
02.05.2006;18:10;20,6;18,8;20,0

[MSE29]

Hallo!

Habe jetzt beide vorgeschlagenen Tipps praktisch umgesetzt.
Beim Ersetzen der Kommas (nach neuer Orthografie ist hier fast alles erlaubt), was einige Sekunden in Anspruch nimmt, wird alles richtig importiert. Nur die Datumsspalte muss nachträglich umformatiert werden, da das Datum mit 2 Kommas geschrieben wird. Ist aber auch lediglich ein Schönheitsfehler, da statt Punkt eben Komma.
Habe auch die Text-Datei ganz simpel per Dateinamenänderung von *.txt in *.csv umgewandelt und dann nach OpenOffice importiert. Datumsformat wird beibehalten, einzig die geraden Temperaturwerte werden richtig angezeigt, die Dezimalzahlen bleiben immer noch im bescheuerten Datumsformat.
Und nochmals vielen Dank für die schnelle Hilfestellung

MfG
MSE29

[MSE29]

PS:
Im Anhang die Auswertung des Klimaloggers per OpenOffice. Im Nachhinein nach PDF exportiert.

MfG
MSE29