[Linux Shell-Skript] WLAN-Wetterstation
-
Ich habe wie auch bei der 3.6.1 Version folgenden Fehler:
● wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; preset: enabled) Active: active (running) since Wed 2026-04-01 16:24:50 CEST; 2min 39s ago Invocation: 6958c126da05409dbcd6ba0bb71f55ff Main PID: 185201 (wetterstation.s) Tasks: 5 (limit: 16903) Memory: 2.9M (peak: 8.5M) CPU: 1.842s CGroup: /system.slice/wetterstation.service ├─185201 /bin/bash /home/martin/wetterstation/wetterstation.sh ├─186705 /bin/bash /home/martin/wetterstation/wetterstation.sh ├─186706 timeout 126 nc -nlvw 1 -p 1080 ├─186707 tail -1 └─186708 nc -nlvw 1 -p 1080 Apr 01 16:27:15 iobroker wetterstation.sh[186313]: dc: stack empty Apr 01 16:27:15 iobroker wetterstation.sh[186441]: Runtime error (func=(main), adr=8): Parameter number mismatch Apr 01 16:27:15 iobroker wetterstation.sh[186644]: (standard_in) 1: syntax error Apr 01 16:27:15 iobroker wetterstation.sh[186648]: (standard_in) 1: syntax error Apr 01 16:27:15 iobroker wetterstation.sh[186651]: (standard_in) 1: syntax error Apr 01 16:27:15 iobroker wetterstation.sh[186654]: (standard_in) 12: syntax error Apr 01 16:27:15 iobroker wetterstation.sh[186657]: (standard_in) 12: syntax error Apr 01 16:27:15 iobroker wetterstation.sh[186660]: jq: parse error: Expected value before ',' at line 1, column 2 Apr 01 16:27:15 iobroker wetterstation.sh[186663]: (standard_in) 12: syntax error Apr 01 16:27:15 iobroker wetterstation.sh[186678]: (standard_in) 1: syntax errorDie 3.6.0 läuft einwandfrei.
Bemerkt hatte ich das Problem, dass die Aussentemperatur sich nicht geändert hatte. Luftdruck lieferte Werte.Ich setze das Gateway GW3000 ein. Der ioBroker läuft komplett im Stable.
Edit:
Hier das Protocoll von der 3.6.0martin@iobroker:~/wetterstation/save$ sudo systemctl status wetterstation ● wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; preset: enabled) Active: active (running) since Wed 2026-04-01 16:29:22 CEST; 3min 10s ago Invocation: 3c9d1f9a50504c49869cc3fe1789903c Main PID: 187189 (wetterstation.s) Tasks: 5 (limit: 16903) Memory: 2.8M (peak: 8.6M) CPU: 1.733s CGroup: /system.slice/wetterstation.service ├─187189 /bin/bash /home/martin/wetterstation/wetterstation.sh ├─188516 /bin/bash /home/martin/wetterstation/wetterstation.sh ├─188517 timeout 126 nc -nlvw 1 -p 1080 ├─188518 tail -1 └─188519 nc -nlvw 1 -p 1080 Apr 01 16:29:22 iobroker systemd[1]: Started wetterstation.service - Service für ioBroker Wetterstation. Apr 01 16:29:22 iobroker wetterstation.sh[187206]: Connection to 192.168.178.100 8087 port [tcp/*] succeeded! martin@iobroker:~/wetterstation/save$Sieht fast identisch aus. Mir ist gerade ein Unterschied 3.6.0 vs. 3.6.1/2 eingefallen, den ich gar nicht berücksichtigt habe. >3.6.0 wird nun auch der Befehl "awk" benutzt. Der ist aber nicht immer bei allen Distris installiert (und ich prüfe aktuell auch nicht ob er vorhanden ist; habe ich schlichtweg vergessen).
Einfach mal in der Shellawk --versioneingeben: "command not found" --> Fehler gefunden Fix dafür:sudo apt install gawk -
-
Sieht fast identisch aus. Mir ist gerade ein Unterschied 3.6.0 vs. 3.6.1/2 eingefallen, den ich gar nicht berücksichtigt habe. >3.6.0 wird nun auch der Befehl "awk" benutzt. Der ist aber nicht immer bei allen Distris installiert (und ich prüfe aktuell auch nicht ob er vorhanden ist; habe ich schlichtweg vergessen).
Einfach mal in der Shellawk --versioneingeben: "command not found" --> Fehler gefunden Fix dafür:sudo apt install gawkawk --version
Das war es leider nicht:
martin@iobroker:~$ awk --version mawk 1.3.4 20250131 Copyright 2008-2024,2025, Thomas E. Dickey Copyright 1991-1996,2014, Michael D. Brennan random-funcs: srandom/random regex-funcs: internal compiled limits: sprintf buffer 8192 maximum-integer 9223372036854775808 martin@iobroker:~$ -
Hallo,
seit dem 12.3.26 werden meine Zählerständen nachts oft nicht zurückgesetzt.
Ich habe natürlich nichts gemacht. Das Update auf 3.6.1 habe ich auch erst am 23.3.26 eingespielt.Evtl. hat das mit der Auslastung des PI zu tun aber so wie ich das Script verstehe soll der Reset 23:58 Uhr stattfinden. Das ist noch deutlich vor der CPU Auslastung die bei mir ab 00:05 Uhr beginnt.
Das sollte doch nicht kollidieren, oder?
Hi,
das Problem mit "oft" ist, es ist also kein rudimentäres Problemchen, dass wäre meist einfacher zu finden. Und ja, genau so ist es, ab 23:58 Uhr werden die Zähler resettet. Dies geschieht aber nicht automatisch wie bei einem Cron-Job, sondern benötigt einen Trigger. Dies ist der Empfang eines Datenpakets. Sollte also, aus welchen Gründen jetzt auch immer, zwischen 23:58 Uhr und 0:03 Uhr kein valides Datenpaket empfangen worden sein, wird auch der Reset nicht durchgeführt. Die CPU-Last sehe ich hier nicht als Grund dafür. IdR. kommt alle 30 Sekunden ein Datenpaket an. Wenn also alles glatt läuft wird der Reset zwischen 23:58 Uhr und 23:59 Uhr ausgeführt. Je nach dem was noch beteiligt ist (zB. InfluxDB) dauert das Ganze aber keine 10 Sekunden, selbst auf einem älteren PI.
Die Probleme können aber auch einfach von außerhalb kommen ("...ging doch immer und ich habe nichts geändert" ;) ). Der Nachbar hat eine neue Wärmepumpe und die macht irgendwas um Mitternacht und stört für ein paar Minuten die 868MHz Funkverbindung Mast --> Display/Gateway
So etwas sollte natürlich nie sein, aber wir leben ja alle "in der idealen Welt", oder??? [IRONIE /OFF]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.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?
-
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
Könntest höchstens mal ohne gestarteten Service im Debug-Modus mittels./wetterstation.sh --debugprobieren. Ev. sieht man ja mehr, denn die 3.6.2 hat auch keine großartigen Änderungen mehr zur 3.6.1hab mit 3.6.2 identes Problem, awk ist installiert.
Hier der output von
./wetterstation.sh -- debugbei 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 -
Es scheint ab der SimpleApi 3.0.6 zu haken. Mit der 3.0.5 geht die Authentifizierung noch.
-
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.
@Boronsbruder
Nein, bei mir ist die Authentifizierung nicht aktiviert. -
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 einexport LC_NUMERIC=Ceinfügen:#!/bin/bash ### Subroutinen V3.6.2 -------------------------------------------------------- export LC_NUMERIC=C #Bezeichnung der DatenpunkteService restarten, dann denke ich funktioniert es wieder ;)
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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.
-
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 einexport LC_NUMERIC=Ceinfügen:#!/bin/bash ### Subroutinen V3.6.2 -------------------------------------------------------- export LC_NUMERIC=C #Bezeichnung der DatenpunkteService restarten, dann denke ich funktioniert es wieder ;)
-
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 einexport LC_NUMERIC=Ceinfügen:#!/bin/bash ### Subroutinen V3.6.2 -------------------------------------------------------- export LC_NUMERIC=C #Bezeichnung der DatenpunkteService restarten, dann denke ich funktioniert es wieder ;)
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 einexport LC_NUMERIC=Ceinfügen:#!/bin/bash ### Subroutinen V3.6.2 -------------------------------------------------------- export LC_NUMERIC=C #Bezeichnung der DatenpunkteService restarten, dann denke ich funktioniert es wieder ;)
Perfekt, nun läuft´s tadellos! Herzlichsten Dank @sborg
-
Das ganze entstand aus diesem Thread.
Damit ist es möglich mit einem Linux-Client die Daten einer WLAN-Wetterstation und/oder mit Hilfe eines Gateways und Zusatzsensoren zu empfangen, aufzubereiten und im ioBroker zur Verfügung zu stellen. Optional können die Daten auch bei AWEKAS.at, OpenSenseMap, Windy und wetter.com zur Verfügung gestellt werden.
Mein Dank geht an @Latzi für das testen in der Entwicklungsphase und dessen Unterstützung bei der Verfassung der WiKi-Artikel.
Aktuelle Version auf GitHub:
Neue Versionen im Thread sind ab V2.15.0 (Juli 2022) unterschiedlich farblich gekennzeichnet:- Beta-Releases haben dann eine rote Versionsnummer
- stabile Releases haben dann eine grüne Versionsnummer
Projektseite (inkl. WiKi): https://sborg2014.github.io/WLAN-Wetterstation/
Da es sich um keinen Adapter handelt, ist dies eine "Vorschaltseite" von GitHub. Nicht das wer auf die Idee kommt von der URL im ioBroker installieren zu wollen ;)
Zum Download/WiKi geht es dann weiter per View on GitHubBisher geteste Stationen:
- BRESSER
- WLAN Farb-Wetter Center mit 5-in-1 Profi-Sensor V (1) @pandor
- WLAN Comfort Wetterstation mit 7-in-1 Profi-Sensor (1)
- ChiliTec Funk Wetterstation 12in1 @tege0
- DNT Weatherscreen PRO @Petersilie
- Ecowitt
- GW1000
- GW2000A
- GW3000A @MartyBr
- WS2910 @Nashra
- WS3800A @hoschi2007
- WS3900 @Mike77
- ELV WS980WiFi @sonystar
- Eurochron EFWS2900 @Latzi, @ilovegym, @SBorg (baugleich mit Ambient Weather WS-2902, Chilitec CTW-902, Sainlogic 10 in 1)
- Froggit
- Gateway/USB-Dongle DP1500/DP2000 @Boronsbruder
- HP1000SE Pro @Stormbringer
- WH3000 SE @ToxSox, @crunchip
- WH4000 SE @unltdnetworx, @Glasfaser, @Negalein, @Boronsbruder
- WH6000 Pro @Mugel80
- Renkforce WH2600
- Sainlogic
- Ventus W830 @CiroCool, @Rushmed
(1) Abfrage per DNS-Server wie bspw. PiHole oder dnsmasq
Bisher unterstütze Zusatzsensoren per Station oder mittels DP1500/DP2000/GW1000/GW2000A - Gateway:
- bis zu 8 Stück DP35/WN34 Wassertemperatur-Sensoren
- ein DP40/WH32 (bzw. WH26) Außentemperatur- und Luftfeuchtigkeitssensor
- bis zu 8 Stück DP50/WH31 Temperatur-/Luftfeuchtigkeit-Sensoren
- ein DP60/WH57 Blitzsensor
- bis zu 4 Stück DP70/WH55 Wasserleckage-Sensoren
- bis zu 16 Stück DP100/WH51 Bodenfeuchte-Sensoren
- bis zu 4 Stück DP200/WH43 PM2.5 Feinstaub-Sensoren
- ein DP250/WH45 5-In-1 CO2 / PM2.5 / PM10 / Temperatur / Luftfeuchte Innenraumsensor
- ein DP300/WS68 Solarunterstütztes Anemometer mit UV-Lichtsensor
- ein WH31 (bzw. WH25) Sensor
- ein WH40H Sensor
- ein WS80 Sensor
- ein WS90 "Wittboy" Sensor
- BRESSER (1)
- bis zu 4 Stück(2) BRESSER Thermo-/Hygro-Sensor 7 Kanal #7009999
Für den WFC01 hat @Rand nun hier und folgende ein kleines Javascript gebaut, um diesen auch auslesen zu können.
(1) nicht alle Bresser-Stationen unterstützen Zusatzsensoren! siehe hier
(2) durch das verwendete Wunderground-Protokoll limitiertDie mögliche Anzahl der Zusatzsensoren ist nicht durch das Skript begrenzt, sondern wird vom Display und/oder Gateway bestimmt.
Es besteht ferner auch die Möglichkeit Stationen (wie bspw. Sainlogic Profi Wlan Wetterstation FT0300) einzubinden die nicht per WS View[+] App konfiguriert werden können und nur ein Web-Interface bieten, dass keine Angabe eines eigenen Wetterdienst-Servers zulässt. Hierfür kann man den Umweg eines eigenen DNS-Servers wie dnsmasq oder Pi-hole gehen. Für Pi-hole hat @XxJooO freundlicherweise hier im Forum eine ausführliche Doku erstellt: klick mich
Wäre schön wenn sich weitere User mit entsprechenden Modellen melden bei denen es funktioniert (auch wenn es baugleiche sein sollten, so ist man sich wenigstens sicher ;) )
Update von einer Vorgängerversion (bei Nutzung per systemd):
Im Installationsverzeichnis
./ws_updater.shausführen.
Alternativ (falls die aktuell installierte Version kleiner als V2.12.0 ist): im Installationsverzeichnisbash <(curl -s https://raw.githubusercontent.com/SBorg2014/WLAN-Wetterstation/master/ws_updater.sh)ausführenUpdate von einer Vorgängerversion (bei Nutzung als cronjob):
Am besten das laufende Skript mit
pkill -9 wetterstation.shstoppen, wetterstation.sh und -.sub ersetzen (-.conf und -.js nur nach Aufforderung nötig; conf dann neu konfigurieren / js ersetzen und einmalig ausführen), dann entweder- direkt am Linux-Client
./wetterstation.sh & - oder per Putty oä.
nohup ./wetterstation.sh &(erzeugt dabei eine Datei nohup.out) - oder reboot des Systemes (Skript wird dann per cronjob wieder gestartet)
jeweils im Installationsverzeichnis ausführen. Sonst befindet sich ggf. noch das alte Skript im RAM und läuft munter bis zum nächsten Reboot weiter ;)
Beispiele einer grafischen Umsetzung:
@Glasfaser: View / zum Beitrag
@crunchip: Grafana / zum Beitrag
Wetterstation-Statistik (JS-Addon)
Statistikmodul als Javascript. Liefert diverse Statistiken:
Javascript für eine HTML-Tabelle vorheriger Monatswerte ( @liv-in-sky ) :
zum ThreadNeues Projekt PimpMyStation (14.11.2020)
Kein Support per PM/Chat !
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
-
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" -
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"@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.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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.
ü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
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. -
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?
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 ]; thenauf
-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. -
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 ]; thenauf
-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.@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 fiWenn ich diese Zeile richtig verstehe ist das Prüfintervallende fest bei 00:03.
if [ $(date +%H) -eq "0" ] && [ $(date +%M) -le "3" ]; thenDann wurde es ja mit der früheren Startzeit auch verlängert und sollte dann passen.
Ich beobachte das.
-
@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 fiWenn ich diese Zeile richtig verstehe ist das Prüfintervallende fest bei 00:03.
if [ $(date +%H) -eq "0" ] && [ $(date +%M) -le "3" ]; thenDann wurde es ja mit der früheren Startzeit auch verlängert und sollte dann passen.
Ich beobachte das.
@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.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
570
Online32.8k
Benutzer82.6k
Themen1.3m
Beiträge