Das Wetterstationen Forum

Ich hatte es jetzt schon multiple Male das das Programm sich beim Backfill aufhängt. Immer nur dann wenn es gerade eine Allsensors-Datei verarbeitet. Die anderen Dateien gehen mühelos durch.

Das sieht dann so aus:
Das bleibt dann für ewig so, hab schon mal ein paar Stunden gewartet, da passiert nix mehr.

Ich weiß langsam nicht was ich noch machen soll, bisher hat es nur geholfen die Datei rauszunehmen von der SD-Karte, dann fehlen aber Daten von meinen Bodensensoren usw. Das kann ja keine dauerhafte Lösung sein?! Vor allem da es mittlerweile irgendwann in jedem Monat passiert. Manchmal geht es dann nach ein paar Restarts durch, doch irgendwann hilft dann auch das nicht mehr.

bei mir und vielen anderen geht das problemlos - welche Firmwareversion des GW3000 hast Du denn ?

Kannst Du den Header und ein paar Zeilen der 202507AllSensors_A.csv posten - am Besten die ganze Datei als Anhang - ggf. steht dort ein Byte quer

Gyvate hat geschrieben: 24 Jul 2025, 07:57 bei mir und vielen anderen geht das problemlos - welche Firmwareversion des GW3000 hast Du denn ?

Kannst Du den Header und ein paar Zeilen der 202507AllSensors_A.csv posten - am Besten die ganze Datei als Anhang - ggf. steht dort ein Byte quer

Ich habe die neueste Firmware drauf. Wenn da ein Byte querhängt, passiert das aber leider bei mir regelmäßig...

Ich habe die Datei mal hochgeladen:
Ich sehe zudem gerade das der GW3000 irgendwann eine 202507B.csv erstellt hat es gibt aber nur eine 202507Allsensors_A, eventuell ist das das Problem?

EDIT: Ich habe die Daten (202507A und 202507B) mal zusammengebracht, leider hilft das auch nicht. Also kann es vermutlich nur an der Allsensors-Datei liegen..

Laut Excel gibst 8 Duplikate bei der Time Spalte.
Vielleicht liegst schon daran, das doppelte Zeitwerte drin sind. Sowas mag WsWin zum Beispiel auch nicht gerne.

Wetterchen hat geschrieben: 24 Jul 2025, 14:20 Laut Excel gibst 8 Duplikate bei der Time Spalte.
Vielleicht liegst schon daran, das doppelte Zeitwerte drin sind. Sowas mag WsWin zum Beispiel auch nicht gerne.

Ich habe die doppelten Zeitwerte mal herausgelöscht in der Tabelle, auch das hilft nicht.

Was sagt die MXDiags Datei ?
Unterschiedliche A, B, C ..... Zahlungen sind nicht unbedingt falsch. s. WiKi

Gyvate hat geschrieben: 24 Jul 2025, 16:29 Was sagt die MXDiags Datei ?
Unterschiedliche A, B, C ..... Zahlungen sind nicht unbedingt falsch. s. WiKi

Es geht einfach nur bis: GetHistoricDataSdCard: Processing file 202507Allsensors_A.csv

Danach kommt, als ich das Programm beendet habe, vermutlich der normale Vorgang beim Beenden:

[....]
2025-07-24 14:56:39.662 GetHistoricDataSdCard: Starting Historic Data Process
2025-07-24 14:56:39.760 This Cumulus MX instance is running the latest release version
2025-07-24 14:56:39.847 GetHistoricDataSdCard: Sort the files into base files and extra files
2025-07-24 14:56:39.847 GetHistoricDataSdCard: Adding extra file 202507B.csv
2025-07-24 14:56:39.847 GetHistoricDataSdCard: Adding extra file 202507A.csv
2025-07-24 14:56:39.847 GetHistoricDataSdCard: Adding base file 202507Allsensors_A.csv
2025-07-24 14:56:39.847 GetHistoricDataSdCard: Processing file 202507A.csv
2025-07-24 14:56:55.951 GetHistoricDataSdCard: Processing file 202507B.csv
2025-07-24 14:56:56.160 GetHistoricDataSdCard: Processing file 202507Allsensors_A.csv
2025-07-24 16:54:39.470 Cumulus terminating
2025-07-24 16:54:39.470 Cumulus closing
2025-07-24 16:54:39.470 Stopping timers
2025-07-24 16:54:39.470 Stopping extra sensors...
2025-07-24 16:54:39.470 Extra sensors stopped
2025-07-24 16:54:39.470 Stopping station...
2025-07-24 16:54:39.470 No data read this session, today.ini not written
2025-07-24 16:54:39.470 SaveWindData: Attempting to save the wind speeds array
2025-07-24 16:54:39.478 SaveWindData: Saved the wind speeds array
2025-07-24 16:54:39.478 Closing connection
2025-07-24 16:54:39.478 Station stopped
2025-07-24 16:54:39.478 Releasing lock file...
2025-07-24 16:54:39.478 Station shutdown complete

Hab das Programm diesmal auch einfach im Hintergrund lange laufen gelassen (siehe Timestamps), wie man sieht tut sich da nichts mehr.

Mike97 hat geschrieben: 24 Jul 2025, 14:57

Wetterchen hat geschrieben: 24 Jul 2025, 14:20 Laut Excel gibst 8 Duplikate bei der Time Spalte.
Vielleicht liegst schon daran, das doppelte Zeitwerte drin sind. Sowas mag WsWin zum Beispiel auch nicht gerne.

Ich habe die doppelten Zeitwerte mal herausgelöscht in der Tabelle, auch das hilft nicht.

Du kannst die Einträge für CMX bzw. im GW3000 meines Wissens nicht löschen. Die bleiben dort, bis es eine nächste Datei gib bzw. Du die Datei löschst.
Du kannst nur heruntergeladene Daten bearbeiten, die aber nicht mehr zurückladen.
Du kannst allerdings durch Ändern einer benutzen EInheit, z.B. m/s anstelle km/h die Erstellung einer neuen Datei ab dem Änderungszeitpunkt erwirken.

Es kann aber gut sein, dass CMX mit gleichen Zeitstempeln nicht zurechtkommt.
Sind diese gleichen Zeitstempel jetzt klassische Zeitstempel oder die neuen EPOCH Zeitstempel ?
Falls nur menschenlesbare Zeitstempel, könnte Mark auf EPOCH umstellen, was für die Sommerzeitumstellung sowieso nötig sein wird.
Daher sollten wir diese Beobachtung im CumulusMX V4 Forum (Original CMX Forum) dokumentieren, so dass sich Mark (Entwickler) seinen Code dahingehend nochmal anschauen kann bzw. eine Testversion mit Loggingpunkten erstellt, so dass man herausfinden kann, woran es bei CMX hakt.

Gyvate hat geschrieben: 25 Jul 2025, 08:54

Mike97 hat geschrieben: 24 Jul 2025, 14:57

Wetterchen hat geschrieben: 24 Jul 2025, 14:20 Laut Excel gibst 8 Duplikate bei der Time Spalte.
Vielleicht liegst schon daran, das doppelte Zeitwerte drin sind. Sowas mag WsWin zum Beispiel auch nicht gerne.

Ich habe die doppelten Zeitwerte mal herausgelöscht in der Tabelle, auch das hilft nicht.

Du kannst die Einträge für CMX bzw. im GW3000 meines Wissens nicht löschen. Die bleiben dort, bis es eine nächste Datei gib bzw. Du die Datei löschst.
Du kannst nur heruntergeladene Daten bearbeiten, die aber nicht mehr zurückladen.
Du kannst allerdings durch Ändern einer benutzen EInheit, z.B. m/s anstelle km/h die Erstellung einer neuen Datei ab dem Änderungszeitpunkt erwirken.

Es kann aber gut sein, dass CMX mit gleichen Zeitstempeln nicht zurechtkommt.
Sind diese gleichen Zeitstempel jetzt klassische Zeitstempel oder die neuen EPOCH Zeitstempel ?
Falls nur menschenlesbare Zeitstempel, könnte Mark auf EPOCH umstellen, was für die Sommerzeitumstellung sowieso nötig sein wird.
Daher sollten wir diese Beobachtung im CumulusMX V4 Forum (Original CMX Forum) dokumentieren, so dass sich Mark (Entwickler) seinen Code dahingehend nochmal anschauen kann bzw. eine Testversion mit Loggingpunkten erstellt, so dass man herausfinden kann, woran es bei CMX hakt.

Ich kann die SD-Karte doch einfach herausnehmen und die Dateien dann bearbeiten, hat gut geklappt. Leider aber nicht das CMX wieder läuft. Es ist übrigens dann passiert, wie im anderen Thread schon beschrieben, als wir ein Gewitter hatten und der GW3000 restartet ist durch das fehlende Internet. Da hat er plötzlich wieder nochmal 8 Werte von 18Uhr irgendwas reingeschrieben, obwohl der Ausfall ab 20:09Uhr war. Das waren die Doppelungen, die betrafen dann natürlich die ganze Zeile. Das kannst du dir aber selbst in der Datei anschauen die ich eingestellt habe, das war am 07.07.

Wie dem auch sei, das hat trotzdem nicht weitergeholfen und CMX bleibt weiterhin hängen. Ich benutze CMX sehr gerne, leider ist das Programm für mich so nicht nutzbar...

ich habe dazu im CMX forum einen Thread eröffnet
https://cumulus.hosiene.co.uk/viewtopic.php?t=23417

Hast Du noch eine Kopie der Originaldatei mit den Doubletten ?
Könnte hilfreich sein.

Du kannst CMX natürlich erst mal weiternutzen - Haken bei der Backfill-Option wegnehmen und speichern und CMX neustarten. Wenn Du nach ecowitt.net postest und API/APP keys und MAC des GW3000 in CMX eingetragen hast, sollten wenigstens die 5-Minuten-Daten nachgeladen werden.

Und der CMX Entwickler hat die Angelegenheit bereits aufgegriffen.