FOSHKplugin

[Michl80]

Hi Oliver,

wahrscheinlich haben wir uns missverstanden. Mir ging es nicht darum, dass die Weiterleitung gar nicht funktioniert, sondern die neue Zusatzfunktion in v0.10 -> # v0.10: Awekas Current weather report conditions - partly (Zeile 823 in der foshkplugin.py).
So wie ich das lese kann man damit eine "Wettermeldung (klar, bewölkt, etc.)", die man aktuell manuell eingeben muss, direkt an AWEKAS mitsenden.
Oder hab ich das falsch verstanden?

VG Michael

[olicat]

Hi!

So wie ich das lese kann man damit eine "Wettermeldung (klar, bewölkt, etc.)", die man aktuell manuell eingeben muss, direkt an AWEKAS mitsenden.

Ah, jetzt verstehe ich Dich. Und es ergibt auch Sinn. Danke fuer die Aufklaerung.
Also:
Einige Wetterconditions werden auch jetzt bereits innerhalb der Funktion forwardDictToAwekas zu Awekas uebertragen:
Gewitter (19), Drizzle (23), leichter Regen (10), Regen (11), starker Regen (12), Sturm (20) sowie clear (0)

Zusaetzlich hatte ich noch eine anderweitig genutzte Funktion namens WeatherCondition um die Awekas-conditions erweitert.
Dabei wuerden Gewitter (19), Drizzle (23), leichter Regen (10), Regen (11), starker Regen (12), Sturm (20), Schnee (14), Nebel (7) und clear (0) gemeldet.¹
Es kaemen also eigentlich nur Schnee (14) und Nebel (7) hinzu.

Allerdings kommt diese neue Funktion tatsaechlich noch nicht beim Versand zu Awekas zum Einsatz.
Diese Wetter-conditions sind bei mir etwas aus dem Fokus geraten, weil ich den Sinn dieser Meldungen zu Awekas nicht verstanden habe.
Inwiefern vermisst Du (welche?) Meldungen der Bedingungen zu Awekas?
Ich hatte auch schon mal die conditions regnerisch (4), wechselhaft (3), sonnig (2) und klar (1) implementiert - wurde dann jedoch von einem Awekas-Moderator angemault, dass derartige Meldungen NICHT automatisiert zu erfolgen haetten - daraufhin hatte ich diese Meldungen deaktiviert.
Insofern ist da mein Enthusiasmus etwas gebremst ...

¹Natuerlich werden dafuer die noetigen Sensoren vorausgesetzt - etwa ein WH57 zur Gewittererkennung, ein LDS01 zur Schnee-Messung, ein Windmesser zur Sturm- und ein Regenmesser zur Regenerkennung sowie ein T/H-Sensor fuer die Nebelerkennung.

Oliver

[Michl80]

Hi!

So wie ich das lese kann man damit eine "Wettermeldung (klar, bewölkt, etc.)", die man aktuell manuell eingeben muss, direkt an AWEKAS mitsenden.

Ah, jetzt verstehe ich Dich. Und es ergibt auch Sinn. Danke fuer die Aufklaerung.
Also:
Einige Wetterconditions werden auch jetzt bereits innerhalb der Funktion forwardDictToAwekas zu Awekas uebertragen:
Gewitter (19), Drizzle (23), leichter Regen (10), Regen (11), starker Regen (12), Sturm (20) sowie clear (0)

Zusaetzlich hatte ich noch eine anderweitig genutzte Funktion namens WeatherCondition um die Awekas-conditions erweitert.
Dabei wuerden Gewitter (19), Drizzle (23), leichter Regen (10), Regen (11), starker Regen (12), Sturm (20), Schnee (14), Nebel (7) und clear (0) gemeldet.¹
Es kaemen also eigentlich nur Schnee (14) und Nebel (7) hinzu.

Allerdings kommt diese neue Funktion tatsaechlich noch nicht beim Versand zu Awekas zum Einsatz.
Diese Wetter-conditions sind bei mir etwas aus dem Fokus geraten, weil ich den Sinn dieser Meldungen zu Awekas nicht verstanden habe.
Inwiefern vermisst Du (welche?) Meldungen der Bedingungen zu Awekas?
Ich hatte auch schon mal die conditions regnerisch (4), wechselhaft (3), sonnig (2) und klar (1) implementiert - wurde dann jedoch von einem Awekas-Moderator angemault, dass derartige Meldungen NICHT automatisiert zu erfolgen haetten - daraufhin hatte ich diese Meldungen deaktiviert.
Insofern ist da mein Enthusiasmus etwas gebremst ...

¹Natuerlich werden dafuer die noetigen Sensoren vorausgesetzt - etwa ein WH57 zur Gewittererkennung, ein LDS01 zur Schnee-Messung, ein Windmesser zur Sturm- und ein Regenmesser zur Regenerkennung sowie ein T/H-Sensor fuer die Nebelerkennung.

Oliver

Hi,

ich vermisse erstmal keine Meldung. Ich find den Ansatz, das automatisch zu übertragen einfach gut.
Aber wenn Du dadurch Ärger mit den AWEKAS-Leuten hast ist das natürlich nicht schön.
Bis auf einen Schneemesser, hab ich so ziemlich fast alles an Sensoren.

VG Michael

[olicat]

Hi!

ich vermisse erstmal keine Meldung. Ich find den Ansatz, das automatisch zu übertragen einfach gut.

Das Problem ist, den tatsaechlichen Zustand aufgrund der Messwerte unserer Sensoren korrekt zu bestimmen.
Ich habe leider keinen Wolkenbedeckungssensor, insofern ist die Bestimmung ob sunny sky, partly cloudy, partly cloudy, heavy partly cloudy oder overcast sky fuer mich schwer zu machen (selbst wenn ich raus gucke).
Auch Hagel kann ich nicht bestimmen.
Selbst bei Nebel liege ich nicht immer richtig - ein Spread von 0.1 ist keine Garantie fuer Nebel.

Insofern bleibe ich bei den Dingen, die sich relativ sicher automatisiert (mit unseren Mitteln) feststellen lassen.

Oliver

[Michl80]

Hi!

ich vermisse erstmal keine Meldung. Ich find den Ansatz, das automatisch zu übertragen einfach gut.

Das Problem ist, den tatsaechlichen Zustand aufgrund der Messwerte unserer Sensoren korrekt zu bestimmen.
Ich habe leider keinen Wolkenbedeckungssensor, insofern ist die Bestimmung ob sunny sky, partly cloudy, partly cloudy, heavy partly cloudy oder overcast sky fuer mich schwer zu machen (selbst wenn ich raus gucke).
Auch Hagel kann ich nicht bestimmen.
Selbst bei Nebel liege ich nicht immer richtig - ein Spread von 0.1 ist keine Garantie fuer Nebel.

Insofern bleibe ich bei den Dingen, die sich relativ sicher automatisiert (mit unseren Mitteln) feststellen lassen.

Oliver

Hi,

kann ich gut verstehen.
Das wäre ein spannendes Projekt für eine Integration mittels KI, die dann z.B. anhand der Wetterdaten der Sensoren in Verbindung mit einem Webcambild das Wetter interpretiert.
Damit kenn ich mich aber leider nicht aus.

VG Michael

[Verify193]

Hi, ich bräuchte mal Hilfe. Ich habe das Foshkplugin mit Weiterleitung zu Wunderground und WeeWX/CumulusMX.
Ich möchte gerne die Aufzeichnung der Innentemperatur/ Luftfeuchte des GW2000 verhindern. Dazu wollte ich wenn möglich dies im Forwarder deaktivieren. Geht das und wenn ja wie?

Grüße

[olicat]

Hi!

Aus der Anleitung:

Data fields from the ignore list maintained under "FWD_IGNORE" are not sent for the relevant forward.

Du musst also im betreffenden Forward ein

Code: Alles auswählen

FWD_IGNORE = tempinf

hinzufügen.
Damit würde die Innentemperatur vom Forward ausgenommen.

Oliver

[olicat]

Hi!

humidityin wäre wohl auch noch in die FWD_IGNORE-Zeile einzutragen, um die Innen-Feuchte auch auszuschließen.
Alle zu ignorierenden Keys müssen mit Komma separiert werden.

Oliver

[Wetterchen]

Hi Oliver,

ich nutze bei einen meiner Stationen deine Foshkplugin Beta 251130 auf ein Raspi Zero W.
Mir ist zuletzt aufgefallen das bei ein Ausfall der Übertragung zum Influx Server das Tool sich dabei selbst überlastet beim Zurückschreiben der Warteschlange (die Daten in FOSHKplugin-queue Ordner).

Das äußert sich so, dass es quasi mit Maximum versucht alle Daten zu pushen und nebenbei versucht die Queue Datei zu löschen, was aber den Zero W ziemlich überlastet wenns zuviele Zugriffe auf einmal werden.
Dann passiert es wohl so, dass sich Foshkplugin dabei innerhalb immer wieder mal neustartet und dabei jede Menge offene Prozesse dergleichen zurücklässt, bis irgendwann der Zero W zusammenbricht und nur noch ein Zwangsneustart hilft oder wenn ich glück habe den Foshkplugin Dienst noch rechtzeitig beenden , damit er alle offenen Prozesse killt.
Das wiederholt sich solange bis der queue Ordner abgearbeitet ist. Danach beruhigt sich das ganze und die ganzen Prozesse (oder Tasks) verschwinden dann soweit von alleine.

Das ist erst seit ca. 2-3 Monaten so, früher war das nicht so problematisch.

Im snd Log sieht das so aus:

Code: Alles auswählen

13.01.2026 17:28:57.904 <OK> FWD-02: wrote queued data of /opt/FOSHKplugin/FOSHKplugin-queue/FWD-02/FOSHKplugin-queued-data-02.260113022605 to WS1100ter@xxx.xxx.xxx.xxx:8086
13.01.2026 17:28:44.023 <OK> FWD-02: wrote queued data of /opt/FOSHKplugin/FOSHKplugin-queue/FWD-02/FOSHKplugin-queued-data-02.260113022550 to WS1100ter@xxx.xxx.xxx.xxx:8086
13.01.2026 17:28:58.127 <WARNING> FWD-02 unable to remove queue file /opt/FOSHKplugin/FOSHKplugin-queue/FWD-02/FOSHKplugin-queued-data-02.260113022550

Beim Abruf von des Dienstes sah das so aus

Code: Alles auswählen

 $ sudo systemctl status fohk1100.service
● fohk1100.service - foshkplugin
     Loaded: loaded (/etc/systemd/system/fohk1100.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-12-30 18:55:01 CET; 1 week 6 days ago
 Invocation: 5fa339d5e59d444cb7df0bb2a9d05d31
   Main PID: 15026 (foshkplugin.py)
      Tasks: 358 (limit: 414)
        CPU: 21h 44min 37.608s
     CGroup: /system.slice/fohk1100.service
             └─15026 /opt/FOSHKplugin/.venv/bin/python3 -u /opt/FOSHKplugin/foshkplugin.py

Jan 13 17:29:22 PiZero foshk1100[15026]:   File "/usr/lib/python3.13/threading.py", line 975, in start
Jan 13 17:29:22 PiZero foshk1100[15026]:     _start_joinable_thread(self._bootstrap, handle=self._handle,
Jan 13 17:29:22 PiZero foshk1100[15026]:     ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jan 13 17:29:22 PiZero foshk1100[15026]:                            daemon=self.daemon)
Jan 13 17:29:22 PiZero foshk1100[15026]:                            ^^^^^^^^^^^^^^^^^^^
Jan 13 17:29:22 PiZero foshk1100[15026]: RuntimeError: can't start new thread
Jan 13 17:29:22 PiZero foshk1100[15026]: ----------------------------------------
Jan 13 17:29:32 PiZero foshk1100[15026]: ----------------------------------------
Jan 13 17:29:32 PiZero foshk1100[15026]: Exception occurred during processing of request from ('xxx.xxx.x.xxx', 60374)
Jan 13 17:29:32 PiZero foshk1100[15026]: Traceback (most recent call last):

Darunter zu leiden hat dann auch Weewx weil der Dienst irgendwann einfach keine Daten mehr vom Foshkplugin abrufen kann und einfach "still" stehen bleibt.


Ich habe mir schon ein Zero W 2 eingerichtet mit Version 250818 und damals im Oktober war Flushk wohl so durcheinander das er gar nicht mehr den vorhandenen FWD-03 abarbeiten möchte nach ein Zwangsrestart. - damals habe ich aber noch kein Zusammenhang gesehen.

[olicat]

Hi!

Mir ist zuletzt aufgefallen das bei ein Ausfall der Übertragung zum Influx Server das Tool sich dabei selbst überlastet beim Zurückschreiben der Warteschlange (die Daten in FOSHKplugin-queue Ordner).

Interessantes Problem.
Ich hatte mich auch schonmal ueber die "kann nicht loeschen"-Meldungen gewundert, dies aber nicht weiter verfolgt.
Ein Aufhaengen habe ich hier jedoch noch nicht registriert - ich habe aber auch keinen RaspiW Zero im Produktiveinsatz.
Ich habe mir das jetzt etwas laenger angeschaut und zumindest eine Optimierungmoeglichkeit gefunden, die mit der naechsten Beta kommt.

Hintergrund:
Jeder Datensatz, der nicht zu InfluxDB uebertragen werden kann, wird lokal als Datei im Verzeichnis FOSHKplugin-queue/FWD-xx/ abgespeichert.
Wenn irgendwann InfluxDB wieder erreichbar ist, sendet FOSHKplugin den aktuellen Datensatz und prueft anschliessend, ob derartige Dateien (FOSHKplugin-queued-data-xx.YYMMDDhhmmss) vorliegen, uebertragt diese sequentiell (!) zu InfluxDB und loescht die jeweilige lokale Datei bei Erfolg. Das alles erfolgt in einem Thread.
Soweit ist das vernuenftig gedacht und es sollte auch problemlos funktionieren.
ABER:
Es ist moeglich, dass dieses Nachsenden nicht innerhalb eines normalen Sendeintervalls von der Konsole zu FOSHKplugin fertig wird.
Dann schaut aber FOSHKplugin wieder in das o.a. Verzeichnis und uebertraegt jede einzelne Datei zu InfluxDB und loescht die uebertragene Datei.
Beim naechsten Intervall geschieht das wieder. Schon haetten wir 3 Threads, die eigentlich das Gleiche machen.
Das ist natuerlich nicht ideal.
Also werde ich zukuenftig eine Variable setzen, dass die Queue-Abarbeitung bereits aktiv ist und von weiteren Nachsendungen absehen.
Ist die Queue abgearbeitet wird das Flag zurueckgesetzt. Dann koenten ggf. andere Queue-Abarbeitungen starten.
Ich verspreche mir davon eine deutliche Besserung.

In einem der letzten Updates der letzten 2-3 Monate hatte ich einen Fehler hinsichtlich der Queue-Abarbeitung zu InfluxDB behoben, der manchmal dafuer sorgte, dass keine Daten lokal abgespeichert wurden. Somit war u.U. bei Wiedererreichbarkeit von InfluxDB nicht die gleiche lokale Datenmenge vorhanden, wie es sein sollte (und heute ist).
Womoeglich hat dieser Fix die Lage bei Dir etwas verschlimmert.
Sorry!

Aktuell habe ich einige Baustellen im Code - eine Veroeffentlichung als public-Beta ist im Moment also nicht moeglich. Zumal ich das jetzt hier auch erstmal testen muss.
Bei Bedarf koennte ich Dir aber eine Version fuer eigene Tests zur Verfuegung stellen.

Schoenes Wochenende!

Oliver