Monatsrückblick Januar/Februar 2026 ist online!

[metaxa]

Leider soeben entdeckt: Die neuen DP werden auch wieder angemeckert von Simple

simple-api.0
2026-04-02 20:19:12.107	info	State value to set for "0_userdata.0.Wetterstation.Regen_Total" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:12.063	info	State value to set for "0_userdata.0.Wetterstation.Regen_Stunde" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:12.019	info	State value to set for "0_userdata.0.Wetterstation.Regen_Event" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.974	info	State value to set for "0_userdata.0.Wetterstation.Windboeen_max" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.923	info	State value to set for "0_userdata.0.Wetterstation.Regen_Jahr" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.879	info	State value to set for "0_userdata.0.Wetterstation.Regen_Monat" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.835	info	State value to set for "0_userdata.0.Wetterstation.Regen_Woche" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.791	info	State value to set for "0_userdata.0.Wetterstation.Regen_Tag" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.749	info	State value to set for "0_userdata.0.Wetterstation.Regenrate" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.699	info	State value to set for "0_userdata.0.Wetterstation.Wind_max" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.655	info	State value to set for "0_userdata.0.Wetterstation.Wind" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.604	info	State value to set for "0_userdata.0.Wetterstation.Gefuehlte_Temperatur" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.558	info	State value to set for "0_userdata.0.Wetterstation.Aussentemperatur" has to be type "number" but received type "string"

simple-api.0
2026-04-02 20:19:11.493	info	State value to set for "0_userdata.0.Wetterstation.Innentemperatur" has to be type "number" but received type "string"

[SBorg]

@metaxa
Danke, ist angekommen. Wenn man sich schon den Sprit bald nicht mehr leisten kann, ist wenigstens noch/wieder der Kaffee erschwinglich ;)

Zum Problem: es gibt eine neue "sub" auf GitHub. Einfach austauschen und Service neustarten (sudo systemctl restart wetterstation). Behebt sämtliche Fehler.

[SBorg]

@Boronsbruder sagte:

über Browser geht aber problemlos.

Und das coolste ist, da friert anscheinend die gesamte SimpleApi ein.
Nach dem ich die Authenifizierung deaktiviert hab, sind nämlich von meinem 2. "Wettersation"-Service der noch auf 3.6.1 lief die Fehler aufgetaucht. Davor passierte einfach nix...

Aber sonst scheint bei mir die 3.6.2 mit Simple 3.0.7 zu laufen.

Muss ich mir mal bei Gelegenheit zu Gemüte führen. Ich nutze keine Authentifizierung, deswegen fällt mir das nicht auf. Eventuell braucht es einen zusätzlichen curl-Parameter.

[metaxa]

@SBorg sagte:

Zum Problem: es gibt eine neue "sub" auf GitHub. Einfach austauschen und Service neustarten (sudo systemctl restart wetterstation). Behebt sämtliche Fehler.

Herzlichen Dank, jetzt ist scheinbar alles im Lot! Tolle Arbeit von dir

[SBorg]

@Rushmed sagte:

Ich habe mit den Daten aus der InfluxDB geprüft ob zu den jeweiligen Zeiten in denen der Reset hätte stattfinden sollen Daten in der DB ankamen.
Das sieht zu allen Ereigissen die bisher auftraten gut aus. Es kamen in dem Zeitraum immer mehrere Pakete an.

Ich habe das am DP "Wetterstation.Zeitstempel" geprüft. Reicht der aus um ein valides Datenpaket zu erkennen?

"Leider schade", denn das wäre zumindest ein Grund gewesen. Ohne ein valides Datenpaket gibt es auch keinen Zeitstempel, genügt also völlig zur Kontrolle.
Eventuell liegt es doch an der CPU-Last. Ziehen wir es doch mal 3 Minuten vor. Ändere mal in der "sh"

  #Mitternachtjobs
   if [ $(date +%H) -ge "23" ] && [ $(date +%M) -ge "58" ] && [ -z $MIDNIGHTRUN ]; then

auf -ge "55" zum testen. Dann rutschen zwar ggf. einige Werte von 23:55 Uhr bis 23:59 Uhr in den Folgetag, dürfte aber verschmerzbar sein und ist ja auch nur erstmal zum testen.

[Rushmed]

@SBorg Danke ich hab' die Startzeit angepasst.
Im Station Log sehe ich dass tatsächlich oft knapp über fünf Minuten zwischen zwei Datenpaketen liegen. Meistens aber weniger als eine Minute.
Kann ich statt das Intervall nur vorzusiehen auch die Länge erhöhen?
Ich hatte noch keinen Datenpaketabstand von mehr als sechs Minuten im Log.

Edit:

  #Mitternachtjobs
   if [ $(date +%H) -ge "23" ] && [ $(date +%M) -ge "55" ] && [ -z $MIDNIGHTRUN ]; then
        rain               #Jahresregenmenge
        firmware_check     #neue Firmware
        reset_zaehler      #Sonnenscheindauer, Solarenergie zurücksetzen (enthällt auch Speicherung Werte VorJahr)
        minmaxavg365d      #Min-/Max-/Avg-Aussentemperatur vor einem Jahr
        metsommer          #meteorologischer Sommer Durchschnittstemperatur und Regenmenge
        MELDUNG "Mitternachtjobs durchgef%C3%BChrt"
   fi
   if [ $(date +%H) -eq "0" ] && [ $(date +%M) -le "3" ]; then
       unset MIDNIGHTRUN
       if [ $(date +%Z) == "CEST" ]; then ZULU=22; else ZULU=23; fi
   fi

Wenn ich diese Zeile richtig verstehe ist das Prüfintervallende fest bei 00:03.

   if [ $(date +%H) -eq "0" ] && [ $(date +%M) -le "3" ]; then

Dann wurde es ja mit der früheren Startzeit auch verlängert und sollte dann passen.

Ich beobachte das.

[SBorg]

@Rushmed
Gelegentlich über 5 Minuten würde das Problem erklären. Ich hatte es nur wegen der CPU-Last vorgezogen.
Hier wäre es jetzt aber trotzdem ratsam den Zeitraum vorzuziehen (eventuell sogar noch 1-2 Minuten vorher).
Und ja, siehst du richtig. Die Routine endet um 0:03 Uhr. Nur den Zeitraum zu verlängern bringt hier nichts.

Beispiel (mit Standardwerten 23:58 Uhr bis 0:03 Uhr):

• Paket kommt um 23:57 Uhr --> nix passiert
• Paket kommt um 0:02 Uhr --> nix passiert (die Mitternachtsroutinen sollen nur um 23:58/59 Uhr einmalig laufen

Verlängerst du nun nur den Zeitraum nach hinten, passiert dann genau dasselbe. Wann die Routine beendet wird ist nicht maßgeblich, denn die senkt nur die CPU-Last. Damit muss nicht bei jedem Datenpaket alles geprüft werden. Zudem wird noch festgestellt ob gerade Sommer-/Winterzeit ist (nötig für InfluxDB). Das muss auch nur einmalig am Tag erfolgen und nicht bei jedem Datenpaket.
Auch das vorzeitige "beenden" des aktuellen Tages ist (IMHO) nicht wirklich sooo wichtig. In 5 Minuten wird sich die Temperatur kaum ändern und der Niederschlag landet dann halt auf dem nächsten Tag. In meinen Augen alles verschmerzbar, da die Tolleranzen der Heim-Wetterstationen eh nicht gerade klein sind.
Ich würde es mal mit 23:54 Uhr und 0:10 Uhr versuchen, dann sollte es auch mit einem 6-Minuten Intervall funktionieren, wobei mir 5 Minuten komisch vorkommen. Bei mir sind es idR. ~35-40 Sekunden und vielleicht eine handvoll Pakete pro Tag die als nicht valide verworfen werden.

[Rushmed]

@SBorg Ok, danke. Ich hab' das Intervall angepasst.
Kann ich irgendwie nachvollziehen ob invalide Datenpakete ankommen und verworfen werden?

[SBorg]

Die Solarenergie ist mir noch durch die Lappen "bei String/Number-Problematik" geflutscht:
https://github.com/SBorg2014/WLAN-Wetterstation/issues/90
Passiert aber nur nach Nullstellung bis der Wert >=1 ist, also so 20-30 Meldungen pro Tag. Fix läuft bereits im Test.

[SBorg]

@Rushmed sagte:

Kann ich irgendwie nachvollziehen ob invalide Datenpakete ankommen und verworfen werden?

Mittels kleinem Hack ja.
Ändere in der "sh" mal bei ~#251

 #Kommunikation herstellen und Daten empfangen
  get_DATA

  #KOM-Fehler?

in

 #Kommunikation herstellen und Daten empfangen
  get_DATA

 if [ "$?" -eq "1" ]; then MELDUNG "Datenpaket verworfen"; fi

  #KOM-Fehler?

Dann loggst du 0_userdata.0.Wetterstation.Info.Meldungen zB. mittels History. Da kommt normalerweise nur stündlich ein Alive, dass das Skript noch läuft.

[Rushmed]

@SBorg Danke für den "Hack". Damit wird mir ja sogar die Ausführung des Mitternacht Jobs angezeigt.
Vll. wäre es eine Überlegung wert die Funktion per Config de-/aktivierbar für alle mit ein zu bauen.

In den Meldungen kam nicht bzgl. invalider Pakete an. Lt. Router ist die Wlan Verbindung zur WS exzellent. Jetzt kanns wohl nurnoch an der Verbindung Station <> Sensor liegen.

Auf jeden Fall funktionierte gestern der Mitternachts Job schon 23:55 Uhr dank der Anpassungen.

Danke.