Monatsrückblick Januar/Februar 2026 ist online!

[Rushmed]

@SBorg sagte:

Du könntest mal das Logging aktivieren (in der conf auf "true" stellen und den Service restarten). Das gibt zwar paar MB am Tag, aber damit kannst du mal die Kommunikation gegen Mitternacht prüfen. Fällt die bei einem ausgefallenem Reset aus, hast du zumindest schon mal den Grund warum es nicht geht.
Den Reset könnte man auch mittels Cron-Job bspw. um 23:59 Uhr erzwingen. Im Installations-Verzeichnis stehend geht dies mittels . ./wetterstation.sub && reset_zaehler (ja der einzelne Punkt am Anfang ist richtig, genauso wie "sub" anstelle von "sh"). Dies sollte man aber nicht "just-for-fun" einfach mal so machen, denn wie der Name sagt, er stellt damit alles auf "0" zurück.

@sborg Danke für die Antwort.

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?

[Boronsbruder]

Nutzt einer von euch eigentlich die Authentifizierung bei SimpleApi?

Bei mir funktioniert nämlich mit Wetterstation 3.6.2 und SimpleApi 3.07 nichts mehr, wenn Authentifizierung aktiviert ist.

[Latzi]

@SBorg

hab mit 3.6.2 identes Problem, awk ist installiert.

Hier der output von ./wetterstation.sh -- debug bei 3.6.2:

 WLAN-Wetterstation V3.6.2 - (c)2019-2026 by SBorg
 Config-Version: V3.6.2
 Sub-Version   : V3.6.2

 'bc' installiert: [✓]
 'jq' installiert: [✓]

 'dc' installiert: [✓]

 'nc' in der Openbsd-Variante installiert:  [✓]
 'netcat' in Openbsd-Variante aktiv, alles korrekt [✓]


Connection to 10.0.0.210 8087 port [tcp/*] succeeded!
(standard_in) 1: syntax error
(standard_in) 1: syntax error
dc: stack empty
Runtime error (func=(main), adr=8): Parameter number mismatch
(standard_in) 1: syntax error
(standard_in) 1: syntax error
(standard_in) 1: syntax error
(standard_in) 12: syntax error
(standard_in) 12: syntax error
jq: parse error: Expected value before ',' at line 1, column 2
(standard_in) 12: syntax error
(standard_in) 1: syntax error


Messwerteblock: 22,00 5,00 0 5,00 43 67 0,00 3,00 277 961.80 1013.10 0,000 0,000 2,000 0,000 78,000 0.00 0 01.04.2026%2019:56:20 GW1100A_V2.4.4 0 20,00 0,000 0,000 78,000 GW1100A 248 0.087 soilmoisture1 37 soilad1 208 soilmoisture2 38 soilad2 210 lightning_num 0 lightning 20 lightning_time 1774461214000 soilbatt1 1.2 soilbatt2 1.1 wh57batt 2


Nicht alle Werte werden unterstützt (abhängig vom Modell der Wetterstation und dem verwendeten Protokoll)!

 Temperatur Innen               : 22,00 °C
 Temperatur Aussen              : 5,00 °C
 Taupunkt                       : 0 °C
 Gefühlte Temperatur            : 5,00 °C
 Luftfeuchte Innen              : 43 %
 Luftfeuchte Aussen             : 67 %
 Windgeschwindigkeit            : 0,00 km/h
 Windgeschwindigkeit 10min      :  km/h
 Windböengeschwindigkeit        : 3,00 km/h
 Windböe max.                   : 20,00 km/h
 Windrichtung                   : 277 °
 Windrichtung                   : W
 Windrichtung 10min             : 248 °
 Luftdruck absolut              : 961.80 hPa
 Luftdruck relativ              : 1013.10 hPa
 Regenrate                      : 0,000 mm/h
 Regenereignis                  :
 Regenstatus                    : kein Regen
 Regen seit Regenbeginn         : 0,000 mm
 Regen Stunde                   : 0,000 mm
 Regen Tag                      : 0,000 mm
 Regen Woche                    : 2,000 mm
 Regen Monat                    : 0,000 mm
 Regen Jahr                     : 78,000 mm
 Regen Gesamt                   : 78,000 mm
 Sättigungsdefizit              : 0.087 kPa
 Sonnenstrahlung                : 0.00 W/m²
 UV-Index                       : 0
 Zeitstempel                    : 01.04.2026 19:56:20
 Firmware                       : GW1100A_V2.4.4
 Batteriestand:                 : 0
 Gateway-Modell                 : GW1100A

Zusatzsensoren:

  soilmoisture1         : 37
  soilad1               : 208
  soilmoisture2         : 38
  soilad2               : 210
  lightning_num         : 0
  lightning             : 20
  lightning_time        : 1774461214000
  soilbatt1             : 1.2
  soilbatt2             : 1.1
  wh57batt              : 2


Datenstring für ioBroker:



DATA von Wetterstation:
PASSKEY=xxxxxx&stationtype=GW1100A_V2.4.4&runtime=1382909&heap=25092&dateutc=2026-04-01+17:56:20&tempinf=71.96&humidityin=43&baromrelin=29.917&baromabsin=28.402&tempf=41.72&humidity=67&vpd=0.087&winddir=277&winddir_avg10m=248&windspeedmph=0.00&windgustmph=2.24&maxdailygust=12.53&solarradiation=0.00&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&last24hrainin=0.000&dailyrainin=0.000&weeklyrainin=0.079&monthlyrainin=0.000&yearlyrainin=3.106&totalrainin=3.106&soilmoisture1=37&soilad1=208&soilmoisture2=38&soilad2=210&lightning_num=0&lightning=20&lightning_time=1774461214&wh65batt=0&soilbatt1=1.2&soilbatt2=1.1&wh57batt=2&freq=868M&model=GW1100A&interval=60


Debug VAR:
 Installationsverzeichnis: /home/latzi
 IPP: 10.0.0.210:8087   WS_PORT: 17550          WS_POLL: 30             PRE_DP: 0_userdata.0.Wetterstation
 WEB: HTTP              WS_PROT: Ecowitt

Zusatzsensoren:
 DP10/35/40/50/60/70/100/200/250/300: 0 | 0 | 0 | 0 | 1 | 0 | 2 | 0 | 0 | 0
 WH31: 0 || WH40H: 0 || WS80: 0 || WS90: 0
 Bresser: 7009999 [0]

Script-Version: V3.6.2  Config-Version: V3.6.2  Sub-Version: V3.6.2

[Boronsbruder]

Es scheint ab der SimpleApi 3.0.6 zu haken. Mit der 3.0.5 geht die Authentifizierung noch.

[Latzi]

@Boronsbruder
Nein, bei mir ist die Authentifizierung nicht aktiviert.

[SBorg]

Ich denke ich habe den Fehler. Man sieht im Messwerteblock bei den Werten ein Komma anstelle des Punktes.
Bitte mal in der "sub" am Afang ein export LC_NUMERIC=C einfügen:

#!/bin/bash
### Subroutinen V3.6.2 --------------------------------------------------------
export LC_NUMERIC=C

 #Bezeichnung der Datenpunkte

Service restarten, dann denke ich funktioniert es wieder ;)

[Boronsbruder]

@sborg
Also hab mal noch ein bischen getestet. Ab 3.0.6 mit der Authentifizierung über user und password funktionieren die cURL-Aufrufe (so) nicht mehr.

curl -k --data "0_userdata.0.Wetterstation.Windrichtung_Text_10min=S&ack=true" "HTTPS://192.168.116.249:8087/setBulk?user=meinuser&pass=1234"

zum Beispiel friert ein.

https://192.168.116.249:8087/setBulk?0_userdata.0.Wetterstation.Windrichtung_Text_10min=S&ack=true&prettyPrint&user=meinuser&pass=1234

ü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.

[MartyBr]

@SBorg

Der Eintrag hat bei mir den Fehler beseitigt, nun läuft die 3.6.2.

Danke für deine Mühe.

Gruß
Martin

[Latzi]

@SBorg sagte:

Ich denke ich habe den Fehler. Man sieht im Messwerteblock bei den Werten ein Komma anstelle des Punktes.
Bitte mal in der "sub" am Afang ein export LC_NUMERIC=C einfügen:

#!/bin/bash
### Subroutinen V3.6.2 --------------------------------------------------------
export LC_NUMERIC=C

 #Bezeichnung der Datenpunkte

Service restarten, dann denke ich funktioniert es wieder ;)

Perfekt, nun läuft´s tadellos! Herzlichsten Dank @sborg

[metaxa]

@SBorg sagte:

Aktuelle Version auf GitHub: V3.6.2

Herzlichen Dank für die permanente Weiterentwicklung und Pflege dieses Projekts!

Station: WS830

Ich hatte noch eine ältere Version laufen und mich jetzt an deine Lösung mit der neuen Simple drübergetraut. Nach etlichen Versuchen kamen nicht mal mehr flasche Daten an. Nach deiner perfekten Beschreibung in der WIKI
https://github.com/SBorg2014/WLAN-Wetterstation/wiki/Installation
habe ich alles neu eingerichtet und es funktioniert sofort. Damit auch der Umzug zu den UserDP und weg vom JS Ordner.

Ich bekomme laufend Werte, perfekt.

Nur: Die Aussentemp kommt OHNE Kommastellen an, das macht dann meine interne Berechnung leider ungenau. Auf dem Wetterstationsdisplay sehe ich zumindest 1 Kommastelle.
Auch auf der Commandline kommen keine Kommastellen an

Kann ich das irgendwo richtig stellen, konfigurieren?

GLG, mxa

P.S.: Cafespende ist unterwegs

[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.