Speicherung auf SD Karte funktioniert nicht richtig - GW3000A

[LE-Wetter]

@ Mike97,
der Zeitstempel in der X-CSV sieht so aus wie im Bild, er meckert zwar beim einlesen, kann man aber ignorieren

17360756763051.jpg (122.33 KiB) 494 mal betrachtet

[Gyvate]

Hi!

Wenn mir mal jemand den Speicherinhalt der SD-Karte als ZIP zustellen könnte, würde ich mir das bzgl. EWCSVmerge mal ansehen.
Mein GW3000 kommt erst Ende Januar an.

Oliver

Im WiKi ist ein einfach kopierbarer Auszug beider CSV Dateien
https://www.wetterstationsforum.info/wi ... 6210_3g_4g

[olicat]

Hi!

Das CSV-Format der modernen Konsolen GW3000 und WS6210 haben offenbar ein paar Aenderungen erhalten, die EWCSVmerge bis einschliesslich v0.4 NICHT verarbeiten kann.

Die neuen Konsolen nutzen ein anderes Datumsformat (2025-01-01 00:00 statt 2023/9/1 0:11) und enthalten bei fehlenden Werten (etwa bei nicht vorhandenen Sensoren) nicht mehr nur "--" sondern auch "--.-" (Temperaturwerte) und "---" (bei AQIN CO2(ppm)).
Gerade Letzteres halte ich fuer einen falschen Ansatz, den Ecowitt beheben sollte. Man sollte da schon einer definierten Festlegung auf EIN "nicht-vorhanden-Flag" folgen.

Eine neue Version von EWCSVmerge2 v0.5 sollte mit diesen Aenderungen an den CSVs umgehen koennen.
Bitte mal testen. Danke!

Auffaellig ist uebrigens ein moeglicher weiterer Fehler:
Obwohl die neuen Konsolen 16 WH51 unterstuetzen werden (offenbar) nur die Kanaele 1-8 in den CSVs gespeichert. Die LDS01 werden offenbar von den CSVs auch noch nicht erfasst.

Gruss, Oliver

[LE-Wetter]

Das ist natürlich Murks, wenn jedes Mal an der Struktur gefeilt wird.
Eigentlich eine csv-Struktur für alle - wenn aber alle Sensoren 8x belegt werden, dann würde das eine ellenlange csv ergeben. Dagegen wäre die Speicherung des Taupunktes und der gefühlten Temperaturen, die ja nur gerechnete Werte sind entbehrlich, das heißt, für jeden Sensortyp (Temp.) würden dann schon 16 Plätze frei werden. Auch die Aufsummierung der Regendaten ist vollkommen entbehrlich, das kann jedes (Excel)Programm alleine rechnen

[Gyvate]

Hi!

Das CSV-Format der modernen Konsolen GW3000 und WS6210 haben offenbar ein paar Aenderungen erhalten, die EWCSVmerge bis einschliesslich v0.4 NICHT verarbeiten kann.

Die neuen Konsolen nutzen ein anderes Datumsformat (2025-01-01 00:00 statt 2023/9/1 0:11) und enthalten bei fehlenden Werten (etwa bei nicht vorhandenen Sensoren) nicht mehr nur "--" sondern auch "--.-" (Temperaturwerte) und "---" (bei AQIN CO2(ppm)).
Gerade Letzteres halte ich fuer einen falschen Ansatz, den Ecowitt beheben sollte. Man sollte da schon einer definierten Festlegung auf EIN "nicht-vorhanden-Flag" folgen.

Eine neue Version von EWCSVmerge2 v0.5 sollte mit diesen Aenderungen an den CSVs umgehen koennen.
Bitte mal testen. Danke!

Auffaellig ist uebrigens ein moeglicher weiterer Fehler:
Obwohl die neuen Konsolen 16 WH51 unterstuetzen werden (offenbar) nur die Kanaele 1-8 in den CSVs gespeichert. Die LDS01 werden offenbar von den CSVs auch noch nicht erfasst.

Gruss, Oliver

Das CSV-Format der moderneren Konsolen (WS6210, GW3000) in von dem der HP25x0 Konsole verschieden - und die HP350x war ja auch bereits aus der Reihe gesprungen.

Einen "None" = Nicht-Vorhanden-Wert unterschiedlich abzubilden (einmal --.- und einmal ---) ist natürlich nicht hilfreich. Ich habe diese Inkonsistenzen mal bei Ecowitt eingetütet - und wir werden wahrscheinlich bei einheitlich --.- landen.
Ebenfalls die fehlenden WH51 9-16 und LDS-01 1-4 Werte.

[olicat]

Hi!

Einen "None" = Nicht-Vorhanden-Wert unterschiedlich abzubilden (einmal --.- und einmal ---) ist natürlich nicht hilfreich. Ich habe diese Inkonsistenzen mal bei Ecowitt eingetütet - und wir werden wahrscheinlich bei einheitlich --.- landen.

Vielen Dank.
Ich habe sogar drei unterschiedliche "nicht-vorhanden-Flags" gefunden: "--" (wie bisher auch), "--.-" (Temperaturwerte) und "---" (bei AQIN CO2(ppm)).
Ich würde dabei ein einheitliches "--" (wie bisher) präferieren.
Auch würde ich mir EIN einheitliches Format für ALLE CSV-kompatiblen Konsolen wünschen.

Oliver

[Gyvate]

die fehlenden Sensoren (LDS-01) auf der SD-Karte bzw. generelle Unterstüzung werden über Firmwareupgrades nachgereicht: 1.0.7 für WS6210 und 1.0.2 für GW3000.
Beim "Nicht-vorhanden" Zeichen wird noch diskustiert, aber ich nehme an, dass es da in Kürze zu einer einheitlichen Lösung kommt und das dann ebenfalls im Firmwareupgrade korrigiert wird. Ich habe jetzt -- vorgeschlagen. Mal sehen.

Die unterschiedlichen Zeichen(ketten) waren gut gemeint und sollten die verwendeten Stellen vor und nach dem Komma darstellen, aber das ist eben wenig hilfreich und bringt nicht wirklich einen Mehrwert.

[Mike97]

Hi!

Das CSV-Format der modernen Konsolen GW3000 und WS6210 haben offenbar ein paar Aenderungen erhalten, die EWCSVmerge bis einschliesslich v0.4 NICHT verarbeiten kann.

Die neuen Konsolen nutzen ein anderes Datumsformat (2025-01-01 00:00 statt 2023/9/1 0:11) und enthalten bei fehlenden Werten (etwa bei nicht vorhandenen Sensoren) nicht mehr nur "--" sondern auch "--.-" (Temperaturwerte) und "---" (bei AQIN CO2(ppm)).
Gerade Letzteres halte ich fuer einen falschen Ansatz, den Ecowitt beheben sollte. Man sollte da schon einer definierten Festlegung auf EIN "nicht-vorhanden-Flag" folgen.

Eine neue Version von EWCSVmerge2 v0.5 sollte mit diesen Aenderungen an den CSVs umgehen koennen.
Bitte mal testen. Danke!

Auffaellig ist uebrigens ein moeglicher weiterer Fehler:
Obwohl die neuen Konsolen 16 WH51 unterstuetzen werden (offenbar) nur die Kanaele 1-8 in den CSVs gespeichert. Die LDS01 werden offenbar von den CSVs auch noch nicht erfasst.

Gruss, Oliver

Ja das funktioniert, vielen Dank! Die Datei wird zwar nicht direkt nach der üblichen Form benannt aber das ist kein Problem solange der Inhalt stimmt. Umbenennen kann ich das auch selbst.

@Gyvate, perfekt das ist super das die Daten des LDS01 dann auch gespeichert werden. Es dürfte für WsWin zwar keine Verwendung finden können (oder es gibt da einen Trick das direkt in die, dort händisch einzutragenden, Schneehöhen zu importieren). Aber aus der CSV wird sich eine schöne Übersicht bei Excel basteln lassen.

[Gyvate]

@Gyvate, perfekt das ist super das die Daten des LDS01 dann auch gespeichert werden. Es dürfte für WsWin zwar keine Verwendung finden können (oder es gibt da einen Trick das direkt in die, dort händisch einzutragenden, Schneehöhen zu importieren). Aber aus der CSV wird sich eine schöne Übersicht bei Excel basteln lassen.

ich kenne jetzt Wswin nicht gut genug, um darauf eine abschliessende Antwort geben zu können. @Werner kann das bestimmt besser.
Aber ich könnte mir vorstellen, dass Du ein von Wswin akzeptiertes aber von Dir nicht benutztes Feld (Datum - nicht Kalender- ) mit passender Einheit dafür benutzen (sozusagen umwidmen) könntest. Ggf. könntest sogar den Anzeigenamen in Wswin ändern. Aber vielleicht ist ja sogar Schneehöhe oder Hagel irgendwo vorgesehen.
Das weiss der Wswin-Programmierer besser.

[olicat]

Hi!

Die Datei wird zwar nicht direkt nach der üblichen Form benannt aber das ist kein Problem solange der Inhalt stimmt. Umbenennen kann ich das auch selbst.

Was genau meinst Du damit?
Wie sehen Deine Startparameter aus?

Oliver