Das Wetterstationen Forum

Moin.

Nach dem FW Update von2.23 auf 2.31 kommt mit jeder Abfrage von weewx der Fehler: Kann das jemand bestätigen?

weewx version = 4.10.2
Treiber = user.gw1000 v0.5.0b5 von gjr80

war bei mir das Gleiche - mit gw1000.py 0.4.2 - habe jetzt auf 06.0b2 umgestellt, den ich bereits in einer Parallelinstanz einsetzte - und der Fehler ist nicht mehr da - weder beim GW1100 noch beim GW2000.
Das Neueste ist wohl v.0.6.0b5:
https://raw.githubusercontent.com/gjr80 ... /gw1000.py

Danke für den Tip, Gyvate.
Werde es heute abend installieren.

Edit:
Einfach die 0.6.0b3 rübergebügelt, Logeinträge sind weg.

0.6.0b5 hat aber wohl noch einen Bug, der in speziellen Situationen auftritt:
Zeile 1611 in gw1000.py, da ist das so drin:

if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['dateTime']:

waszu einem Fehler führen kann, so funktionierts wohl:

if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['datetime']:

mitschke hat geschrieben: ↑27 Jan 2024, 20:08 0.6.0b5 hat aber wohl noch einen Bug, der in speziellen Situationen auftritt:
Zeile 1611 in gw1000.py, da ist das so drin:

if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['dateTime']:

waszu einem Fehler führen kann, so funktionierts wohl:

if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['datetime']:

richtig, dieser Fehler wurde heute im weewx Forum beschrieben ...

die 6C Geschichte liegt wohl an einem neuen Marker im lokalen Ecowitt Gateway API bei der CMD_GW1000_LIVEDATA API response, der bislang nicht dokumentiert ist - je nach Behandlung einer solchen Situation gibt es dann Probleme.
Da 6C sozusagen "ganz hinten" in der API Antwort steht, ist der Treiber"abbruch" wohl nicht tragisch, da alle anderen bislang genutzen Daten (hoffentlich) bereits ins Loop geschaufelt wurden.

Damit man solche Einträge nicht mehr bekommt, gibt eine Option in der weewx.conf -> log_unknown_fields = False
seit der Version 6 ist dieser auf default "False". früher "True" d.h. solche Einträge werden ausgeblendet!

Werner hat geschrieben: ↑27 Jan 2024, 20:39 Damit man solche Einträge nicht mehr bekommt, gibt eine Option in der weewx.conf

Code: Alles auswählen

[GW1000]
    #wh32 = True
    #ignore_legacy_wh40_battery = True
    #show_all_batt = False
    log_unknown_fields = False

-> log_unknown_fields = False
seit der Version 6 ist dieser auf default "False". früher "True" d.h. solche Einträge werden ausgeblendet!

Guter Hinweis, aber ob eine nicht dokumentierte und daher nicht verarbeitete API Response für den Marker 6C unter "log_unknown_fields" fällt, ist mir noch nicht ganz klar.
Dazu müsste ich den Quellcode durchackern ...
Die 6C hat ja auch noch ein Nachspiel - der Ball ist z.Zt. bei Ecowitt
Es gibt ja auch zwei bisher (ausser bei mir) nicht öffentlich dokumentierte Marker in der API Response zu CMD_READ_DATA, die sich auf die Regenmesserpräferenz bzw. auf die Solarkompensation beziehen.

Es gibt ja auch zwei bisher (ausser bei mir) nicht öffentlich dokumentierte Marker in der API Response zu CMD_READ_DATA, die sich auf die Regenmesserpräferenz bzw. auf die Solarkompensation beziehen.

Die sind doch dokumentiert in V1.6.8
x7A rain priority
x7B Radiation compensation
Wer meinen modifizierten GW1000 Treiber nutzt, kann diese Daten auch auswerten.

ich weiss, dass sie in 1.6.8 stehen - aber 1.6.8 wurde nie veröffentlicht - nur 1.6.4 ist über die Ecowitt Website zu beziehen.
In unserem WiKi (und in wxforum.net) habe ich 7A und 7B dokumentiert

in Garys v. 0.6.0b2 Treiber sind 7A und 7B als rain_priority und temp_comp enthalten.

Nur zu Info am Rande, Gary hat seine gw1000.py vor paar Stunden modifiziert.
In der Zeile 36 als Version 0.6.0b6 deklariert.