Und anderen Leuten verschwendete Zeit zu ersparen: Sonderlich granular ist LogLevel nicht, ich habe eigentlich nur 3 mögliche Werte gefunden:
Alles unter 30 produziert ein Log mit keinem Inhalt, 30 das bekannte Log, bei 50 wird die Sync-Routine komplett mit den SCLs ausgeführt und die einzelnen Abschnitte feiner mit "===" strukturiert, drüber passiert dann nix mehr, ne weitere Detaillierung scheint es nicht zu geben. Es sei denn der Programmierer war ein Spaßvogel und ausgerechnet "42" ergäbe einen speziellen Loglevel...
Unter 30 könnte eventuell nur bei Fehlern Logeinträge produzieren.
Den LogToFile value habe ich dann auch noch eben probiert, der schaltet aber wirklich nur mit 0 das Log aus und mit 1 das Log ein. Werte drüber werden vom Datarecorder selbst wieder beim Beenden auf 0 gesetzt.
- Carsten
Klimalogger von TFA
Moderatoren: Werner, Tex, weneu
-
wupperbayer
Re: LogLevel Datarecorder Software
Der Loglevel veranlasst dann den Klimalogger, von 5-minütger auf sekündliche Aktualisierung umzustellen, ohne, dass dabei mehr Strom verbraucht wirdcarstenk hat geschrieben:Es sei denn der Programmierer war ein Spaßvogel und ausgerechnet "42" ergäbe einen speziellen Loglevel...
Aber Spaß beiseite, klingt ja recht gut, was da bisher rausgekommen ist. Aber mal ne Frage als User, der nicht soo tief in der I/O-Materie steckt: Scheint es sinnvoll (vom Aufwand/Nutzen her), das Auslesen direkt in WsWIN zu integrieren? Das wäre für mich die einzig praktikable Lösung neben meiner, da ich die Daten des Klimaloggers gerne mal ins Internet stellen würde, und das geht natürlich nur, wenn das Auslesen automatisch geht.
Klar geht das auch so, aber ne Integration wäre natürlich schon irgendwie elegant, vor allen Dingen, wenn das dann auch schneller ginge.
-
carstenk
Klimalogger Interface in WsWin
Das muss natürlich Werner entscheiden, aber ich kenne die Problematik aus einem anderen Bereich, mit einer sehr ähnlichen Softwarekomponente und Protokollsupport für verschiedene Hardware.
Zunächst mal ist der Aufwand so einer Einbindung schon beträchtlich, zum einen, weil das Protokoll nicht wirklich sauber und robust implementiert ist, dann weil es nicht offiziell dokumentiert ist, und dann natürlich, weil der Klimalogger halt doch nur eines von vielen Geräten ist.
Als Programmierer würde ich lieber einen universellen Ansatz wählen, wie z.B. die Dateiüberwachung in Verbindung mit externen Tools, als für jedes vorstellbare Gerät eine individuelle Anbindung. Aus Sicht des Autors ist so eine gehackte Anbindung ein erhebliches Risiko, weil man immer nur sicherstellen kann, das sowas auf dem eigenen Testrechner läuft. Womöglich hat man nach einem vielversprechenden Anfang mit zunehmender Verbreitung des Gerätes immer mehr Scherereien wegen Inkompatibilitäten (wer garantiert schon dafür, dass der Hersteller des Klimaloggers das Protokoll nicht mal ändert - immerhin wurde das Gerät schonmal von 3 auf 5 Kanäle aufgebohrt). Den Support dafür dann später wieder einzustellen gibt immer viel Unmut bei den Benutzern.
Man sieht ja, dass Werner durchaus schon ein paar Ambitionen in die Richtung entwickelt hat, aber sein Instinkt sagt ihm da sicherlich auch 'Vorsicht'. Letztlich weckt sowas dann natürlich auch Begehrlichkeiten bei den Benutzern anderer Geräte. Der Markt ist ja mittlerweile unüberschaubar. Und der Klimalogger ist ja noch nicht mal 'ne richtige' Wetterstation.
Aus technischer Sicht wäre eine Art 'Plugin' Infrastruktur für solche Anbindungen sicherlich sinnvoll, also eine simple Übergabeschnittstelle. Ob die Dateiüberwachung da die einzig sinnvolle Möglichkeit ist, wage ich zu bezweifeln. Genauso ginge zusätzlich auch eine Option zum Aufruf eines externen Programs zur Datenkonvertierung.
Als Benutzer des Programs wäre ich prinzipiell eher daran interessiert, Programmfeatures auszubauen oder zu stabilisieren, als jedes mögliche exotische Protokoll zu unterstützen. Vielleicht weniger elegant, aber deutlich flexibler. Du hast ja selbst gesehen, wie schnell man z.B. mit AutoiT eine Automatisierung gebastelt hatte. Die direkte Unterstützung des Klimalogger Historyformates ist schon sehr nützlich. Prinzipiell gilt - wenn der Hersteller des Gerätes eine Software anbietet, sollte man die nach Möglichkeit auch nutzen.
Vielleicht ist der Ansatz mit AutoIt ja auch für andere Geräte ne gute Idee - es wird in Zukunft eher mehr als weniger Wetterstationstypen geben, die Skripte sind auch von Benutzern mit geringer Programmiererfahrung schnell erstellt oder zumindest angepasst. Werner könnte im Download- oder Forumsbereich eine Plattform für den Austausch solcher Tools anbieten nach dem Motto 'User helfen Usern'.
- Carsten
Zunächst mal ist der Aufwand so einer Einbindung schon beträchtlich, zum einen, weil das Protokoll nicht wirklich sauber und robust implementiert ist, dann weil es nicht offiziell dokumentiert ist, und dann natürlich, weil der Klimalogger halt doch nur eines von vielen Geräten ist.
Als Programmierer würde ich lieber einen universellen Ansatz wählen, wie z.B. die Dateiüberwachung in Verbindung mit externen Tools, als für jedes vorstellbare Gerät eine individuelle Anbindung. Aus Sicht des Autors ist so eine gehackte Anbindung ein erhebliches Risiko, weil man immer nur sicherstellen kann, das sowas auf dem eigenen Testrechner läuft. Womöglich hat man nach einem vielversprechenden Anfang mit zunehmender Verbreitung des Gerätes immer mehr Scherereien wegen Inkompatibilitäten (wer garantiert schon dafür, dass der Hersteller des Klimaloggers das Protokoll nicht mal ändert - immerhin wurde das Gerät schonmal von 3 auf 5 Kanäle aufgebohrt). Den Support dafür dann später wieder einzustellen gibt immer viel Unmut bei den Benutzern.
Man sieht ja, dass Werner durchaus schon ein paar Ambitionen in die Richtung entwickelt hat, aber sein Instinkt sagt ihm da sicherlich auch 'Vorsicht'. Letztlich weckt sowas dann natürlich auch Begehrlichkeiten bei den Benutzern anderer Geräte. Der Markt ist ja mittlerweile unüberschaubar. Und der Klimalogger ist ja noch nicht mal 'ne richtige' Wetterstation.
Aus technischer Sicht wäre eine Art 'Plugin' Infrastruktur für solche Anbindungen sicherlich sinnvoll, also eine simple Übergabeschnittstelle. Ob die Dateiüberwachung da die einzig sinnvolle Möglichkeit ist, wage ich zu bezweifeln. Genauso ginge zusätzlich auch eine Option zum Aufruf eines externen Programs zur Datenkonvertierung.
Als Benutzer des Programs wäre ich prinzipiell eher daran interessiert, Programmfeatures auszubauen oder zu stabilisieren, als jedes mögliche exotische Protokoll zu unterstützen. Vielleicht weniger elegant, aber deutlich flexibler. Du hast ja selbst gesehen, wie schnell man z.B. mit AutoiT eine Automatisierung gebastelt hatte. Die direkte Unterstützung des Klimalogger Historyformates ist schon sehr nützlich. Prinzipiell gilt - wenn der Hersteller des Gerätes eine Software anbietet, sollte man die nach Möglichkeit auch nutzen.
Vielleicht ist der Ansatz mit AutoIt ja auch für andere Geräte ne gute Idee - es wird in Zukunft eher mehr als weniger Wetterstationstypen geben, die Skripte sind auch von Benutzern mit geringer Programmiererfahrung schnell erstellt oder zumindest angepasst. Werner könnte im Download- oder Forumsbereich eine Plattform für den Austausch solcher Tools anbieten nach dem Motto 'User helfen Usern'.
- Carsten