[Linux Shell-Skript] WLAN-Wetterstation
-
@sborg:
Hallo, tolles Skript das du gemacht hast, und funktioniert(e) bisher immer top. Habe aktuell folgendes Thema:Ich muss den IOB-Slave auf dem das skript läuft neu aufsetzen.
-) Also neuer RasPi neu aufgesetzt,
-) deinen Installer wie beschrieben durchgeführt,
-) auf der Wetterstation die IP addresse auf die des neuen RasPi geändert;-)
./wetterstation.sh --debugausgeführt mit folgendem output
Also meiner Meinung nach funktioniert die Installation am neuen RasPi soweit. Allerdings empfange ich die Daten nicht in den Objekten vom Iobroker.
Wenn ich die IP an der Wetterstation wieder auf den bisher laufenden RasPi stelle, (läuft noch paralell) dann kriege ich wieder daten in den Iobroker aktualisiert....
Hast du einen Tip wo es da hacken kann?
vG Etze
Connection to 192.168.xxx.xxx 8087 port [tcp/*] succeeded! -> ip vom Restapi hab manuell verändert, aber die stimmt
[
{
"id": "0_userdata.0.Wetterstation.Innentemperatur",
"val": 23
},
...deutet darauf hin, dass die Verbindung zum Simple-API funktioniert. Das anschließende JSON, dass die Daten vom SImple-API auch empfangen wurden und unter "XXX" mit dem Wert "YYY" geschrieben wurden.
Also erstmal alles Ok. Wenn es trotzdem nicht funktioniert kann es mal wieder vorgekommen sein, dass die Objekte zwar vorhanden, aber nicht (be)schreibbar sind. Falls nocht nicht geschehen hilft hier einmalig nach der Installation einiob restart -
Es gibt auch ein wetterstation.log (liegt bei mir unter /var/log)
Du kannst auch den Simple-Api-Adapter auf Debug stellen.
Dann sollte die Verbindung des Skripts zum Adapter dokumentiert werden.Achja und mit dem wetterstation.js sind die Datenpunkte auch unter "0_userdata.0.Wetterstation" angelegt worden?
@Boronsbruder
Hallo, danke für den Tipp bzgl debug-level beim Simple API Adapter, daran hatte ich nicht gedacht...Also bei simple Api kommen die Daten vom neuen RasPi auf jedenr fall an... siehe hier einen Auszug...
Das ist nach erstem Check bei beiden RasPi gleich - Egal ob ich den "alten" oder neuen nehmen. Je nachdem welche IP ich bei der Wetterstation als Ziel einsetze diese sendet die daten an den Simple API adapter. Nur wenn ich bei der Wetterstation als ZIEL-IP den neuen RasPi einsetze landen die Daten jeweiligen Objekten.... obwohl die Datensätze natürlich angelegt sind...
@sborg: Den Restart muss ich noch versuchen.....
EDIT: Restart vom IOB bringt keine veränderung -
Hallo an Alle: Bitte macht euch keine weiteren Gedanken, ich habe den Fehler gefunden... Manchmal findet man den Wald vor lauter Bäumen nicht....
In der .conf stand noch der falsche Datenpunkt der Objekte.... jetzt funktionierts. Danke für eure Tipps. und unterstützung. -
Ich habe soeben eine neue Version released. Damit wird zu den Temperaturen wieder eine "0" hinzugefügt und immer zwei Dezimalstellen angezeigt. Seit irgendeinem FW-Release der Stationen/Gateways fiel die führende "0" bei Werten von -0.99°C bis 0.99°C weg.
.62°C --> 0.62°C
-.2°C --> -0.20°CZudem waren "Windrichtung_Text" und "Windrichtung_Text_10min" immer identisch falls die Station/Gateway den Wert schon liefert. Es wurde immer der 10-Minuten Text angezeigt.
Neues Release des Wetterstation WLAN-Skriptes auf GitHub V3.6.1
- ~ Fix führende "0" bei Messwerten hinzugefügt
- ~ Fix Windrichtung-Text ist identisch mit 10-Minuten Text falls die Station den Wert liefert / Issue #86
Wie immer zu finden im GitHub
Update-Routine von Vorgängerversion:
- aktuellen WS-Updater nutzen
./ws_updater.shim Installationsverzeichnis ausführen- Menüpunkt "4" wählen und die Fragen beantworten
Update kann durchgeführt werden, gerade wenn die Station einen 10-Minuten Durchschnittswert der Windrichtung/-geschwindigkeit liefert.
-
@sborg
Hurra!
Heute gab es ein Update zur SImple-Api auf 3.0.7...
Und ratet mal...
Genau! Jetzt wird nur noch wegen falschen Typen rum gekackt...2026-03-27 19:36:20.814 - [33mwarn[39m: javascript.0 (5074) You are assigning a string to the state "0_userdata.0.Wetter.aktuell.temp_gef" which expects a number. Please fix your code to use a number or change the state type to string. This warning might become an error in future versions. 2026-03-27 19:36:20.815 - [33mwarn[39m: javascript.0 (5074) at setState (/opt/iobroker/node_modules/iobroker.javascript/src/lib/sandbox.ts:2661:20) 2026-03-27 19:36:20.815 - [33mwarn[39m: javascript.0 (5074) at Object.<anonymous> (script.js.common.wetter.windchilltemp:47:17) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/src/lib/sandbox.ts:1772:38) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at JavaScript.onStateChange (/opt/iobroker/node_modules/iobroker.javascript/src/main.ts:752:25) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at JavaScript.emit (node:events:519:28) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at JavaScript.emit (node:domain:489:12) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at Immediate._onImmediate (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:11138:53) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at processImmediate (node:internal/timers:484:21) 2026-03-27 19:36:20.818 - [32minfo[39m: javascript.0 (5074) State value to set for "0_userdata.0.Wetter.aktuell.temp_gef" has to be type "number" but received type "string" 2026-03-27 19:36:20.823 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.Regen_Woche" has to be type "number" but received type "string" 2026-03-27 19:36:20.828 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.Sonnenstrahlung" has to be type "number" but received type "string" 2026-03-27 19:36:20.841 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.DP50.1.Temperatur" has to be type "number" but received type "string" 2026-03-27 19:36:20.857 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.DP100.4.Batterie" has to be type "number" but received type "string" 2026-03-27 19:36:35.108 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Innentemperatur" has to be type "number" but received type "string" 2026-03-27 19:36:35.110 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Aussentemperatur" has to be type "number" but received type "string" 2026-03-27 19:36:35.112 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Gefuehlte_Temperatur" has to be type "number" but received type "string" 2026-03-27 19:36:35.120 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Regen_Woche" has to be type "number" but received type "string" 2026-03-27 19:36:35.123 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Sonnenstrahlung" has to be type "number" but received type "string" 2026-03-27 19:36:35.131 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.DP50.1.Temperatur" has to be type "number" but received type "string"Interessant ist hier z.B. dass sogar eines meiner Javascripts mit rum weint...
Bin jetzt mal wieder zurrück auf die 2.8.0 -
@sborg
Hurra!
Heute gab es ein Update zur SImple-Api auf 3.0.7...
Und ratet mal...
Genau! Jetzt wird nur noch wegen falschen Typen rum gekackt...2026-03-27 19:36:20.814 - [33mwarn[39m: javascript.0 (5074) You are assigning a string to the state "0_userdata.0.Wetter.aktuell.temp_gef" which expects a number. Please fix your code to use a number or change the state type to string. This warning might become an error in future versions. 2026-03-27 19:36:20.815 - [33mwarn[39m: javascript.0 (5074) at setState (/opt/iobroker/node_modules/iobroker.javascript/src/lib/sandbox.ts:2661:20) 2026-03-27 19:36:20.815 - [33mwarn[39m: javascript.0 (5074) at Object.<anonymous> (script.js.common.wetter.windchilltemp:47:17) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at Object.callback (/opt/iobroker/node_modules/iobroker.javascript/src/lib/sandbox.ts:1772:38) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at JavaScript.onStateChange (/opt/iobroker/node_modules/iobroker.javascript/src/main.ts:752:25) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at JavaScript.emit (node:events:519:28) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at JavaScript.emit (node:domain:489:12) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at Immediate._onImmediate (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/src/lib/adapter/adapter.ts:11138:53) 2026-03-27 19:36:20.816 - [33mwarn[39m: javascript.0 (5074) at processImmediate (node:internal/timers:484:21) 2026-03-27 19:36:20.818 - [32minfo[39m: javascript.0 (5074) State value to set for "0_userdata.0.Wetter.aktuell.temp_gef" has to be type "number" but received type "string" 2026-03-27 19:36:20.823 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.Regen_Woche" has to be type "number" but received type "string" 2026-03-27 19:36:20.828 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.Sonnenstrahlung" has to be type "number" but received type "string" 2026-03-27 19:36:20.841 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.DP50.1.Temperatur" has to be type "number" but received type "string" 2026-03-27 19:36:20.857 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.Wetterstation.DP100.4.Batterie" has to be type "number" but received type "string" 2026-03-27 19:36:35.108 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Innentemperatur" has to be type "number" but received type "string" 2026-03-27 19:36:35.110 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Aussentemperatur" has to be type "number" but received type "string" 2026-03-27 19:36:35.112 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Gefuehlte_Temperatur" has to be type "number" but received type "string" 2026-03-27 19:36:35.120 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Regen_Woche" has to be type "number" but received type "string" 2026-03-27 19:36:35.123 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.Sonnenstrahlung" has to be type "number" but received type "string" 2026-03-27 19:36:35.131 - [32minfo[39m: simple-api.0 (2141912) State value to set for "0_userdata.0.iot_Klima.DP50.1.Temperatur" has to be type "number" but received type "string"Interessant ist hier z.B. dass sogar eines meiner Javascripts mit rum weint...
Bin jetzt mal wieder zurrück auf die 2.8.0@Boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Jetzt wird nur noch wegen falschen Typen rum gekackt.
Bei mir leider das gleiche Problem. Ich hatte gehofft das es hilft den DP umzustellen auf Zahl oder String. Ändert aber leider nix.
-
@sborg
Hinweis: so wie es aussieht werden noch Daten ohne führende Null gesendet:{ "id": "0_userdata.0.Wetterstation.Regen_Woche", "val": ".787", "value": ".787" } -
@sborg
Hinweis: so wie es aussieht werden noch Daten ohne führende Null gesendet:{ "id": "0_userdata.0.Wetterstation.Regen_Woche", "val": ".787", "value": ".787" }Ich fang mal mit dem letzten Post an...
"Blödes" C&P. Im Einleitungstext hatte ich noch korrekt Temperatur stehen, in sämtlichen Release-Texten dank C&P es dann beim Original vergessen. Ich habe nur die Temps gefixt, aber eigentlich sollte es schon einheitlich sein. Ist nur eine Zeile ersetzen, geht also fix.Müsste eigentlich auch ggf. Windstärke betreffen?
bzgl. bulkMode:
Jepp, dass ist das Problem (GitHub-Issue). Die Inkonsistenz. Warum einmal als "String", und dann ohne ersichtlichen Grund wieder als "Float". Zumindest dachte ich mal "Integer" würde ggf. als String interpretiert werden. Aber bei den Temps gibt es jetzt nur noch Float und mal geht es, dann wieder nicht...
Es gäbe pauschal die Möglichkeit "&type=Number" mit anzugeben, dann knallt es aber wieder, da im Datenstring auch echte Strings ("Windrichtung als Text") vorhanden sind und er dann alles als "Number" behandelt. Muss ich mir mal anschauen, ob es einfach möglich ist den String in Text und Zahl aufzuteilen. -
@sborg
Hinweis: so wie es aussieht werden noch Daten ohne führende Null gesendet:{ "id": "0_userdata.0.Wetterstation.Regen_Woche", "val": ".787", "value": ".787" }@Boronsbruder Ich habe bei mir mal folgende Zeile eingefügt:
IOB_DATA=$(echo "$IOB_DATA" | sed -E 's/=\./=0./g' | sed -E 's/=-\./=-0./g')Direkt vor dem curl, also vor dieser Zeile:
#Daten an den ioB schickenDas Ergebnis:
-
Ich fang mal mit dem letzten Post an...
"Blödes" C&P. Im Einleitungstext hatte ich noch korrekt Temperatur stehen, in sämtlichen Release-Texten dank C&P es dann beim Original vergessen. Ich habe nur die Temps gefixt, aber eigentlich sollte es schon einheitlich sein. Ist nur eine Zeile ersetzen, geht also fix.Müsste eigentlich auch ggf. Windstärke betreffen?
bzgl. bulkMode:
Jepp, dass ist das Problem (GitHub-Issue). Die Inkonsistenz. Warum einmal als "String", und dann ohne ersichtlichen Grund wieder als "Float". Zumindest dachte ich mal "Integer" würde ggf. als String interpretiert werden. Aber bei den Temps gibt es jetzt nur noch Float und mal geht es, dann wieder nicht...
Es gäbe pauschal die Möglichkeit "&type=Number" mit anzugeben, dann knallt es aber wieder, da im Datenstring auch echte Strings ("Windrichtung als Text") vorhanden sind und er dann alles als "Number" behandelt. Muss ich mir mal anschauen, ob es einfach möglich ist den String in Text und Zahl aufzuteilen.@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Müsste eigentlich auch ggf. Windstärke betreffen?
ja, u.a. auch die Windstärke ist ohne führende 0
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Müsste eigentlich auch ggf. Windstärke betreffen?
ja, u.a. auch die Windstärke ist ohne führende 0
@hoschi2007 vielleicht noch eine Anmerkung:
MESSWERTE[$1]=$(echo "scale=3;${MESSWERTE[$1]}*254/10" | bc -l)Soweit ich weiß, bc gibt nie eine führende Null aus. SimpleAPI prüft beim Schreiben:
- Ist der Wert rein numerisch? → number
- Beginnt der Wert mit einem Punkt (.762)? → kein gültiges JSON‑Number‑Format
→ ioBroker speichert es als string Damit hast du den Typwechsel zwischen number und string
Man könnte auch folgenden Ersatz machen:
echo "scale=3;0.03*254/10" | bc -l .762 LC_NUMERIC=C printf "%.3f" "$(echo "scale=3;0.03*254/10" | bc -l)" 0.762 -
@hoschi2007 vielleicht noch eine Anmerkung:
MESSWERTE[$1]=$(echo "scale=3;${MESSWERTE[$1]}*254/10" | bc -l)Soweit ich weiß, bc gibt nie eine führende Null aus. SimpleAPI prüft beim Schreiben:
- Ist der Wert rein numerisch? → number
- Beginnt der Wert mit einem Punkt (.762)? → kein gültiges JSON‑Number‑Format
→ ioBroker speichert es als string Damit hast du den Typwechsel zwischen number und string
Man könnte auch folgenden Ersatz machen:
echo "scale=3;0.03*254/10" | bc -l .762 LC_NUMERIC=C printf "%.3f" "$(echo "scale=3;0.03*254/10" | bc -l)" 0.762@ETGermany
Dann wäre das Problem ja zu einfach :D{ "id": "0_userdata.0.Wetterstation.Innentemperatur", "val": "23.40", "value": "23.40" }, { "id": "0_userdata.0.Wetterstation.Aussentemperatur", "val": "5.40", "value": "5.40" }, { "id": "0_userdata.0.Wetterstation.Taupunkt", "val": "-3.10", "value": "-3.10" }, { "id": "0_userdata.0.Wetterstation.Gefuehlte_Temperatur", "val": 3.28, "value": 3.28 }Wie du siehst sind immer Vorkommastellen da. Nur werden die ersten 3 als String und die 4. als Float von SimpleAPI interpretiert...
-
@ETGermany
Dann wäre das Problem ja zu einfach :D{ "id": "0_userdata.0.Wetterstation.Innentemperatur", "val": "23.40", "value": "23.40" }, { "id": "0_userdata.0.Wetterstation.Aussentemperatur", "val": "5.40", "value": "5.40" }, { "id": "0_userdata.0.Wetterstation.Taupunkt", "val": "-3.10", "value": "-3.10" }, { "id": "0_userdata.0.Wetterstation.Gefuehlte_Temperatur", "val": 3.28, "value": 3.28 }Wie du siehst sind immer Vorkommastellen da. Nur werden die ersten 3 als String und die 4. als Float von SimpleAPI interpretiert...
@Boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Dann wäre das Problem ja zu einfach :D
Es ist zu einfach... ^^
Alle Fixes für fehlende "0" laufen seit 2 Tagen im Test --> funktioniert
Fehler "has to be number, but received string" ist ebenfalls gefixt und läuft aktuell ohne Fehler seit 2 oder 3 Stunden.
Man, man, man, wenn das wirklich der Fehler war (wovon ich aktuell zu 99,99% ausgehe) ist es zu einfach ;)
Ich habe alles auf Zahl stehen und er meckert selbst mit dem 3er Simple-API nix mehr an.Die (Auf-)Lösung kommt dann mit dem Bugfix-Release 3.6.2 so in ein oder zwei Tagen wenn es denn wirklich läuft.
-
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?
-
@sborg , ich habe gestern auf die 3.6.1 über
ws_updaterupgedatet und seither ist die Kommunikation mit der Wetterstation tot, da beim service laufend die Meldungstandard_in: 1 syntax errorkommt. Neustart vom Service und des Servers blieben leider ohne Erfolg.
Hast du einen Tipp für mich?Edit: Meldungen
latzi@ioBroker:~$ systemctl status wetterstation ● wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; preset: enabled) Active: active (running) since Tue 2026-03-31 16:28:03 CEST; 38s ago Invocation: 04da8be31f714d7889f588dfda62835f Main PID: 636668 (wetterstation.s) Tasks: 5 (limit: 14311) Memory: 2.8M (peak: 4.5M) CPU: 818ms CGroup: /system.slice/wetterstation.service ├─636668 /bin/bash /home/latzi/wetterstation.sh ├─637159 /bin/bash /home/latzi/wetterstation.sh ├─637160 timeout 66 nc -nlvw 1 -p 17550 ├─637161 tail -1 └─637162 nc -nlvw 1 -p 17550 Mär 31 16:28:03 ioBroker wetterstation.sh[636685]: Connection to 10.0.0.210 8087 port [tcp/*] succeeded! Mär 31 16:28:29 ioBroker wetterstation.sh[636803]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[636803]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[636805]: dc: stack empty Mär 31 16:28:29 ioBroker wetterstation.sh[637136]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637139]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637141]: (standard_in) 12: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637143]: (standard_in) 12: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637152]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637158]: (standard_in) 1: syntax errorZurück zur 3.6.0 geht´s wieder ;-)
-
Sieht bisher gut aus, hatte nur noch ein "+" vergessen, sodass bei einem Sonderfall immer noch "number-string-bla-bla" kam. Mittlerweile 24h ohne Fehler --> V3.6.2 sollte ich somit noch vor Ostern releasen können.
Wen es genau interessiert, sollte sich noch mal ganz genau https://forum.iobroker.net/post/1332124 anschauen...
-
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?
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. -
@sborg , ich habe gestern auf die 3.6.1 über
ws_updaterupgedatet und seither ist die Kommunikation mit der Wetterstation tot, da beim service laufend die Meldungstandard_in: 1 syntax errorkommt. Neustart vom Service und des Servers blieben leider ohne Erfolg.
Hast du einen Tipp für mich?Edit: Meldungen
latzi@ioBroker:~$ systemctl status wetterstation ● wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; preset: enabled) Active: active (running) since Tue 2026-03-31 16:28:03 CEST; 38s ago Invocation: 04da8be31f714d7889f588dfda62835f Main PID: 636668 (wetterstation.s) Tasks: 5 (limit: 14311) Memory: 2.8M (peak: 4.5M) CPU: 818ms CGroup: /system.slice/wetterstation.service ├─636668 /bin/bash /home/latzi/wetterstation.sh ├─637159 /bin/bash /home/latzi/wetterstation.sh ├─637160 timeout 66 nc -nlvw 1 -p 17550 ├─637161 tail -1 └─637162 nc -nlvw 1 -p 17550 Mär 31 16:28:03 ioBroker wetterstation.sh[636685]: Connection to 10.0.0.210 8087 port [tcp/*] succeeded! Mär 31 16:28:29 ioBroker wetterstation.sh[636803]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[636803]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[636805]: dc: stack empty Mär 31 16:28:29 ioBroker wetterstation.sh[637136]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637139]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637141]: (standard_in) 12: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637143]: (standard_in) 12: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637152]: (standard_in) 1: syntax error Mär 31 16:28:29 ioBroker wetterstation.sh[637158]: (standard_in) 1: syntax errorZurück zur 3.6.0 geht´s wieder ;-)
@Latzi
Dürfte eigentlich nicht sein, wenn es aber mit der 3.6.0 geht, muss es ja so sein.
Der Fehler kommt eigentlich immer wenn er keine/falsche Daten hat. Ich würde sagen, warte noch einen Augenblick auf die 3.6.2, denn die muss wegen der Number/String-Problematik vom 3er Simple-API dann genutzt werden. An der Version kann es eigentlich nicht liegen, sonst hätte sich bestimmt schon der ein oder andere gemeldet.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@Latzi
Dürfte eigentlich nicht sein, wenn es aber mit der 3.6.0 geht, muss es ja so sein.
Der Fehler kommt eigentlich immer wenn er keine/falsche Daten hat. Ich würde sagen, warte noch einen Augenblick auf die 3.6.2, denn die muss wegen der Number/String-Problematik vom 3er Simple-API dann genutzt werden. An der Version kann es eigentlich nicht liegen, sonst hätte sich bestimmt schon der ein oder andere gemeldet.An der Version kann es eigentlich nicht liegen, sonst hätte sich bestimmt schon der ein oder andere gemeldet.
So sehe ich das auch. Hab jetzt 3 Mal die 3.6.1 versucht und jedesmal das gleiche Verhalten. Ich bleib bis zum Release der 3.6.2 mal auf der 3.6.0. Beim simple-api bin ich schon auf 3.0.7 und hab die angemeckerten DP's auf mixed umgestellt - seither ist Ruhe.
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
649
Online32.7k
Benutzer82.6k
Themen1.3m
Beiträge