NEWS
[Linux Shell-Skript] WLAN-Wetterstation
[Linux Shell-Skript] WLAN-Wetterstation
-
Zwar drei Wochen her, deswegen zur üblichen Info "alle Jahre mal wieder": ich schreibe nichts in die InfluxDB
Der "Null"-Fehler ist nur ein Schönheitsfehler, außer man hat gerade mit der Statistik angefangen. Im 1. Jahr der Statistik wird diese einmalig resettet, da kein kpl. Jahr vorliegt, dies also auch keine Jahresstatistik ist.
Mit einer Änderung am JS/JSC funktioniert mittlerweile das Lesen des Timestamps auf einem "Folder" nicht mehr = ergibt "Null". Da die Funktion aber immer nur am 01.01. ausgeführt wird ist es wohl bisher nie aufgefallen.
Die Änderung ist easy: anstelle getState muss einfach getObject benutzt werden
Neue Version liegt auf GitHub.@Boronsbruder
Das hängt mit https://github.com/SBorg2014/WLAN-Wetterstation/issues/74 zusammen. Fix gibt es aktuell noch keinen, da es sich um einen Designfehler (oder Denkfehler) meinerseits handelt. Am Monatsletzten wird im Grunde keine Auswertung mehr gefahren und Teile mit auf den 01. des Folgemonats gezogen. Da brauche ich Ruhe und Zeit dafür. Beides aktuell absolute Mangelware.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
Zwar drei Wochen her, deswegen zur üblichen Info "alle Jahre mal wieder": ich schreibe nichts in die InfluxDB
Der "Null"-Fehler ist nur ein Schönheitsfehler, außer man hat gerade mit der Statistik angefangen. Im 1. Jahr der Statistik wird diese einmalig resettet, da kein kpl. Jahr vorliegt, dies also auch keine Jahresstatistik ist.
Mit einer Änderung am JS/JSC funktioniert mittlerweile das Lesen des Timestamps auf einem "Folder" nicht mehr = ergibt "Null". Da die Funktion aber immer nur am 01.01. ausgeführt wird ist es wohl bisher nie aufgefallen.
Die Änderung ist easy: anstelle getState muss einfach getObject benutzt werden
Neue Version liegt auf GitHub.@Boronsbruder
Das hängt mit https://github.com/SBorg2014/WLAN-Wetterstation/issues/74 zusammen. Fix gibt es aktuell noch keinen, da es sich um einen Designfehler (oder Denkfehler) meinerseits handelt. Am Monatsletzten wird im Grunde keine Auswertung mehr gefahren und Teile mit auf den 01. des Folgemonats gezogen. Da brauche ich Ruhe und Zeit dafür. Beides aktuell absolute Mangelware.@sborg
Alles easy! Kein Stress wegen sowas! -
Ich brauche eure Hilfe meine Bresser Basis Station hat das zeitliche gesegnet, in dem sich das WLAN Modul verabschiedet hat. Resetten und co geht auch nicht mehr, schaltet man den AP Modus ein, erstellt er auch kein neues Netz mehr.
Also schnell dank A ein neues Set bestellt, und nur die Basis Station in Betrieb genommen.
Diese ist von der Bauform gleich, einzig sie wird jetzt mittels USB C bestrom.Die Inbetriebnahme ist allerdings neu, hierfür wird jetzt ein App WS Link benötigt.
In dieser kann ich Wlan und die wunderground daten setzen.
Lösche ich in der Host-Datei vom pihole den Eintrag für "rtupdate.wunderground.com" schickt die Station die Daten direkt zu Wundergrount.Trage ich in die host wieder meine 192.168.X.159 rtupdate.wunderground.com ein kommen keine Daten bei wunderground an und eigendlich sollte jetzt auch das shell skript laufen.
ping vom Rechner landet auf der 159
Macht es aber nicht:
WLAN-Wetterstation V3.4.0 - (c)2019-2024 by SBorg Config-Version: V3.4.0 Sub-Version : V3.4.0 'bc' installiert: [✓] 'jq' installiert: [✓] 'dc' installiert: [✓] 'nc' in der Openbsd-Variante installiert: [✓] 'netcat' in Openbsd-Variante aktiv, alles korrekt [✓] Connection to 192.168.X.152 8087 port [tcp/*] succeeded! Messwerteblock: Nicht alle Werte werden unterstützt (abhängig vom Modell der Wetterstation und dem verwendeten Protokoll)! Temperatur Innen : °C Temperatur Aussen : °C Taupunkt : °C Gefühlte Temperatur : °C Luftfeuchte Innen : % Luftfeuchte Aussen : % Windgeschwindigkeit : km/h Windgeschwindigkeit 10min : km/h Windböengeschwindigkeit : km/h Windböe max. : km/h Windrichtung : ° Windrichtung : Windrichtung 10min : ° Luftdruck absolut : hPa Luftdruck relativ : hPa Regenrate : mm/h Regenstatus : Regen seit Regenbeginn : mm Regen Stunde : mm Regen Tag : mm Regen Woche : mm Regen Monat : mm Regen Jahr : mm Regen Gesamt : mm Sonnenstrahlung : W/m² UV-Index : Zeitstempel : Firmware : Batteriestand: : Gateway-Modell : Zusatzsensoren: keine Datenstring für ioBroker: DATA von Wetterstation: Debug VAR: Installationsverzeichnis: /home/wetter/wetterstation IPP: 192.168.X.152:8087 WS_PORT: 1080 WS_POLL: 30 PRE_DP: 0_userdata.0.Wetterstation WEB: HTTP WS_PROT: Wunderground Zusatzsensoren: DP10/35/40/50/60/70/100/200/250/300: 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 WH31: 0 || WS90: 0 Bresser: 7009999 [0] Script-Version: V3.4.0 Config-Version: V3.4.0 Sub-Version: V3.4.0 Kommunikationsfehler! Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?ich habe ehrlich keine Idee mehr, es kommen keine Daten am Script an aber wiso?
Das Skript läuft auf Proxmox in einer eigenen VM, Pihole ist eine separate Maschine,
sudo iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 1080Ist auch ausgeführt
-
Ich brauche eure Hilfe meine Bresser Basis Station hat das zeitliche gesegnet, in dem sich das WLAN Modul verabschiedet hat. Resetten und co geht auch nicht mehr, schaltet man den AP Modus ein, erstellt er auch kein neues Netz mehr.
Also schnell dank A ein neues Set bestellt, und nur die Basis Station in Betrieb genommen.
Diese ist von der Bauform gleich, einzig sie wird jetzt mittels USB C bestrom.Die Inbetriebnahme ist allerdings neu, hierfür wird jetzt ein App WS Link benötigt.
In dieser kann ich Wlan und die wunderground daten setzen.
Lösche ich in der Host-Datei vom pihole den Eintrag für "rtupdate.wunderground.com" schickt die Station die Daten direkt zu Wundergrount.Trage ich in die host wieder meine 192.168.X.159 rtupdate.wunderground.com ein kommen keine Daten bei wunderground an und eigendlich sollte jetzt auch das shell skript laufen.
ping vom Rechner landet auf der 159
Macht es aber nicht:
WLAN-Wetterstation V3.4.0 - (c)2019-2024 by SBorg Config-Version: V3.4.0 Sub-Version : V3.4.0 'bc' installiert: [✓] 'jq' installiert: [✓] 'dc' installiert: [✓] 'nc' in der Openbsd-Variante installiert: [✓] 'netcat' in Openbsd-Variante aktiv, alles korrekt [✓] Connection to 192.168.X.152 8087 port [tcp/*] succeeded! Messwerteblock: Nicht alle Werte werden unterstützt (abhängig vom Modell der Wetterstation und dem verwendeten Protokoll)! Temperatur Innen : °C Temperatur Aussen : °C Taupunkt : °C Gefühlte Temperatur : °C Luftfeuchte Innen : % Luftfeuchte Aussen : % Windgeschwindigkeit : km/h Windgeschwindigkeit 10min : km/h Windböengeschwindigkeit : km/h Windböe max. : km/h Windrichtung : ° Windrichtung : Windrichtung 10min : ° Luftdruck absolut : hPa Luftdruck relativ : hPa Regenrate : mm/h Regenstatus : Regen seit Regenbeginn : mm Regen Stunde : mm Regen Tag : mm Regen Woche : mm Regen Monat : mm Regen Jahr : mm Regen Gesamt : mm Sonnenstrahlung : W/m² UV-Index : Zeitstempel : Firmware : Batteriestand: : Gateway-Modell : Zusatzsensoren: keine Datenstring für ioBroker: DATA von Wetterstation: Debug VAR: Installationsverzeichnis: /home/wetter/wetterstation IPP: 192.168.X.152:8087 WS_PORT: 1080 WS_POLL: 30 PRE_DP: 0_userdata.0.Wetterstation WEB: HTTP WS_PROT: Wunderground Zusatzsensoren: DP10/35/40/50/60/70/100/200/250/300: 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 WH31: 0 || WS90: 0 Bresser: 7009999 [0] Script-Version: V3.4.0 Config-Version: V3.4.0 Sub-Version: V3.4.0 Kommunikationsfehler! Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein?ich habe ehrlich keine Idee mehr, es kommen keine Daten am Script an aber wiso?
Das Skript läuft auf Proxmox in einer eigenen VM, Pihole ist eine separate Maschine,
sudo iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 1080Ist auch ausgeführt
anbei noch ein wireshark mitschnitt:
166.txt
166 ist die basisstation und 109 in diesem fall der rechnerich wundere mich ein wenig über den 443
INTEL NUC BOXNUC6I3SYH i3-6100U - Proxmox
Speicher: Transcend MTS800 M.2 SSD 128GB SATA III, MLC
RAM: 40Gig Crucial 8GB DDR4 CT2K8G4SFS824A + 32GB DDR4CT32G4SFD8266
-
anbei noch ein wireshark mitschnitt:
166.txt
166 ist die basisstation und 109 in diesem fall der rechnerich wundere mich ein wenig über den 443
@chka sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ich wundere mich ein wenig über den 443
Da ich es selbst nicht nutze und keine Bresser-Station mein Eigen nenne, kann ich dazu nichts beitragen ob dies normal ist oder nicht.
Zum eigentlichen Problem: so sieht alles richtig aus, es könnte auch "einfach" sein, dass Bresser was am Protokoll geschraubt hat was nun durch die Validierung fällt.
Versuch mal ein./wetterstation.sh --dataim Installationsverzeichnis, der Dienst darf dabei aber nicht laufen[sudo] systemctl stop wetterstation.
Das gibt dann ein RAW-Paket des empfangenen (falls es tatsächlich nur an der Validierung liegt) Datenstrings aus.
Falls das funktioniert muss ich die Validierung ändern und bräuchte den String (Nutzerdaten gerne x-en, aber dabei bitte die Anzahl der "x" zum Originalstring beibehalten und nicht kürzen ) -
@chka sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ich wundere mich ein wenig über den 443
Da ich es selbst nicht nutze und keine Bresser-Station mein Eigen nenne, kann ich dazu nichts beitragen ob dies normal ist oder nicht.
Zum eigentlichen Problem: so sieht alles richtig aus, es könnte auch "einfach" sein, dass Bresser was am Protokoll geschraubt hat was nun durch die Validierung fällt.
Versuch mal ein./wetterstation.sh --dataim Installationsverzeichnis, der Dienst darf dabei aber nicht laufen[sudo] systemctl stop wetterstation.
Das gibt dann ein RAW-Paket des empfangenen (falls es tatsächlich nur an der Validierung liegt) Datenstrings aus.
Falls das funktioniert muss ich die Validierung ändern und bräuchte den String (Nutzerdaten gerne x-en, aber dabei bitte die Anzahl der "x" zum Originalstring beibehalten und nicht kürzen )@sborg hi mit dem port 443 bekomme ich dies hier
sudo ./wetterstation.sh --data
Connection to 192.168.178.152 8087 port [tcp/*] succeeded!Warte maximal 66 Sekunden auf Datenpaket der Wetterstation...
Listening on 0.0.0.0 443
Connection received on 192.168.178.166 60113
yNNh^!lG%Kn@<v,0$(beim nächstenmal
GM3:CS=%ώ#toYyv,0$(
und dann
V$-IyINTEL NUC BOXNUC6I3SYH i3-6100U - Proxmox
Speicher: Transcend MTS800 M.2 SSD 128GB SATA III, MLC
RAM: 40Gig Crucial 8GB DDR4 CT2K8G4SFS824A + 32GB DDR4CT32G4SFD8266
-
@sborg hi mit dem port 443 bekomme ich dies hier
sudo ./wetterstation.sh --data
Connection to 192.168.178.152 8087 port [tcp/*] succeeded!Warte maximal 66 Sekunden auf Datenpaket der Wetterstation...
Listening on 0.0.0.0 443
Connection received on 192.168.178.166 60113
yNNh^!lG%Kn@<v,0$(beim nächstenmal
GM3:CS=%ώ#toYyv,0$(
und dann
V$-Iy -
@chka
Hast du schonmal geprüft, ob der port 1080 nicht durch ein anderen Dienst belegt ist?- Wetterstationskript stoppen
- sudo netstat | grep 1080
Dann sollte keine Ausgabe kommen.
Wenn eine kommt, dann ist der Port belegt.
@boronsbruder Ist leider nicht nötig, die Daten kommen schon an.
@chka
Ich habe es leider schon befürchtet. Sie haben es tatsächlich geändert und senden die Daten nun SSL verschlüsselt, deswegen auch Port 443.Man könnte mittels API die Daten von WU wieder auslesen, dies sind aber wesentlich weniger als die Station liefert.
Pauschal kann man auch den öffentlichen Schlüssel von WU auslesen. Ob der netcat von Linux diesen aber bereitstellen kann müsste erst eruiert werden (und ob dies mit dem Zertifikat dann überhaupt funktionieren kann). Dann könnte man die gesendeten Daten wieder entschlüsseln.
-
@boronsbruder Ist leider nicht nötig, die Daten kommen schon an.
@chka
Ich habe es leider schon befürchtet. Sie haben es tatsächlich geändert und senden die Daten nun SSL verschlüsselt, deswegen auch Port 443.Man könnte mittels API die Daten von WU wieder auslesen, dies sind aber wesentlich weniger als die Station liefert.
Pauschal kann man auch den öffentlichen Schlüssel von WU auslesen. Ob der netcat von Linux diesen aber bereitstellen kann müsste erst eruiert werden (und ob dies mit dem Zertifikat dann überhaupt funktionieren kann). Dann könnte man die gesendeten Daten wieder entschlüsseln.
-
Zwar drei Wochen her, deswegen zur üblichen Info "alle Jahre mal wieder": ich schreibe nichts in die InfluxDB
Der "Null"-Fehler ist nur ein Schönheitsfehler, außer man hat gerade mit der Statistik angefangen. Im 1. Jahr der Statistik wird diese einmalig resettet, da kein kpl. Jahr vorliegt, dies also auch keine Jahresstatistik ist.
Mit einer Änderung am JS/JSC funktioniert mittlerweile das Lesen des Timestamps auf einem "Folder" nicht mehr = ergibt "Null". Da die Funktion aber immer nur am 01.01. ausgeführt wird ist es wohl bisher nie aufgefallen.
Die Änderung ist easy: anstelle getState muss einfach getObject benutzt werden
Neue Version liegt auf GitHub.@Boronsbruder
Das hängt mit https://github.com/SBorg2014/WLAN-Wetterstation/issues/74 zusammen. Fix gibt es aktuell noch keinen, da es sich um einen Designfehler (oder Denkfehler) meinerseits handelt. Am Monatsletzten wird im Grunde keine Auswertung mehr gefahren und Teile mit auf den 01. des Folgemonats gezogen. Da brauche ich Ruhe und Zeit dafür. Beides aktuell absolute Mangelware.@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Zwar drei Wochen her, deswegen zur üblichen Info "alle Jahre mal wieder": ich schreibe nichts in die InfluxDB
Der "Null"-Fehler ist nur ein Schönheitsfehler, außer man hat gerade mit der Statistik angefangen. Im 1. Jahr der Statistik wird diese einmalig resettet, da kein kpl. Jahr vorliegt, dies also auch keine Jahresstatistik ist.
Mit einer Änderung am JS/JSC funktioniert mittlerweile das Lesen des Timestamps auf einem "Folder" nicht mehr = ergibt "Null". Da die Funktion aber immer nur am 01.01. ausgeführt wird ist es wohl bisher nie aufgefallen.
Die Änderung ist easy: anstelle getState muss einfach getObject benutzt werden
Neue Version liegt auf GitHub.@Boronsbruder
Das hängt mit https://github.com/SBorg2014/WLAN-Wetterstation/issues/74 zusammen. Fix gibt es aktuell noch keinen, da es sich um einen Designfehler (oder Denkfehler) meinerseits handelt. Am Monatsletzten wird im Grunde keine Auswertung mehr gefahren und Teile mit auf den 01. des Folgemonats gezogen. Da brauche ich Ruhe und Zeit dafür. Beides aktuell absolute Mangelware.Leider habe ich immer noch den (Null) Fehler.
Habe es geändert auf die Version 2.06.
Ich habe dann die Liter händisch auf 0 zurückgestellt. Aber es kommt jeden Tag der Null Fehler.
Warum, weshalb keine Ahnung.
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Zwar drei Wochen her, deswegen zur üblichen Info "alle Jahre mal wieder": ich schreibe nichts in die InfluxDB
Der "Null"-Fehler ist nur ein Schönheitsfehler, außer man hat gerade mit der Statistik angefangen. Im 1. Jahr der Statistik wird diese einmalig resettet, da kein kpl. Jahr vorliegt, dies also auch keine Jahresstatistik ist.
Mit einer Änderung am JS/JSC funktioniert mittlerweile das Lesen des Timestamps auf einem "Folder" nicht mehr = ergibt "Null". Da die Funktion aber immer nur am 01.01. ausgeführt wird ist es wohl bisher nie aufgefallen.
Die Änderung ist easy: anstelle getState muss einfach getObject benutzt werden
Neue Version liegt auf GitHub.@Boronsbruder
Das hängt mit https://github.com/SBorg2014/WLAN-Wetterstation/issues/74 zusammen. Fix gibt es aktuell noch keinen, da es sich um einen Designfehler (oder Denkfehler) meinerseits handelt. Am Monatsletzten wird im Grunde keine Auswertung mehr gefahren und Teile mit auf den 01. des Folgemonats gezogen. Da brauche ich Ruhe und Zeit dafür. Beides aktuell absolute Mangelware.Leider habe ich immer noch den (Null) Fehler.
Habe es geändert auf die Version 2.06.
Ich habe dann die Liter händisch auf 0 zurückgestellt. Aber es kommt jeden Tag der Null Fehler.
Warum, weshalb keine Ahnung.
@babl
Deswegen mag [IRONIE /Aus] ich JavaScript auch so, gerade wegen der oft "aussagekräftigen" Fehler. Es gibt auch noch einen Fehler (was genau habe ich mir noch nicht angeschaut, hängt aber sicherlich wieder an einem JS-Update und funktioniert nun nicht mehr) in der "Auto-Delete Data" Routine.
Falls du (und Andere immer noch) den "NULL" Fehler haben, checkt mal ob ihr bei0_userdata.0.Statistik.Wetter.Control.AutoDelete_Data(oder wo ihr die Statistik liegen habt) einen kürzeren Zeitpunkt in Monaten als Daten habt. Hä...???Ein Bild und 1.000 Worte oder so...:
Eigentlich sollte nach der gewählten Anzahl der Monate alte Datensätze aus "Data" gelöscht werden. In der Routine ist ebenfalls ein "NULL"-Fehler. Mit erhöhen des Wertes wird die Routine nur aktuell nicht ausgeführt und der Fehler tritt nicht mehr auf. Da dies nur ein Datenpunkt pro Monat ist in meinen Augen verschmerzbar. Notfalls den Datenpunkt mit 2 Klicks selbst löschen (oder wenn unerwünscht das ganze Jahr).
-
@babl
Deswegen mag [IRONIE /Aus] ich JavaScript auch so, gerade wegen der oft "aussagekräftigen" Fehler. Es gibt auch noch einen Fehler (was genau habe ich mir noch nicht angeschaut, hängt aber sicherlich wieder an einem JS-Update und funktioniert nun nicht mehr) in der "Auto-Delete Data" Routine.
Falls du (und Andere immer noch) den "NULL" Fehler haben, checkt mal ob ihr bei0_userdata.0.Statistik.Wetter.Control.AutoDelete_Data(oder wo ihr die Statistik liegen habt) einen kürzeren Zeitpunkt in Monaten als Daten habt. Hä...???Ein Bild und 1.000 Worte oder so...:
Eigentlich sollte nach der gewählten Anzahl der Monate alte Datensätze aus "Data" gelöscht werden. In der Routine ist ebenfalls ein "NULL"-Fehler. Mit erhöhen des Wertes wird die Routine nur aktuell nicht ausgeführt und der Fehler tritt nicht mehr auf. Da dies nur ein Datenpunkt pro Monat ist in meinen Augen verschmerzbar. Notfalls den Datenpunkt mit 2 Klicks selbst löschen (oder wenn unerwünscht das ganze Jahr).
-
@sborg bei mir schaut das so aus.
Jahr 2023 ab August, Jahr 2024 vollständig und der Wert bei mir ist 0
siehe Bild
@babl
Q&D: stell es mal auf bspw. 96. Das wären dann 8 Jahre bis er anfängt zu löschen (bzw. "löschen will", die Funktion funktioniert aktuell nicht...). Dann sollte zumindest der "NULL"-Fehler aus dem Log verschwinden.
...und ich habe Zeit den Fehler zu fixen
-
@babl
Q&D: stell es mal auf bspw. 96. Das wären dann 8 Jahre bis er anfängt zu löschen (bzw. "löschen will", die Funktion funktioniert aktuell nicht...). Dann sollte zumindest der "NULL"-Fehler aus dem Log verschwinden.
...und ich habe Zeit den Fehler zu fixen -
@babl
Q&D: stell es mal auf bspw. 96. Das wären dann 8 Jahre bis er anfängt zu löschen (bzw. "löschen will", die Funktion funktioniert aktuell nicht...). Dann sollte zumindest der "NULL"-Fehler aus dem Log verschwinden.
...und ich habe Zeit den Fehler zu fixen -
hätt ein paar Fragen zu den Werten.
0_userdata.0.Wetterstation.Regen_Event= der aktuelle Regen; kann der vom Script wieder auf 0 gesetzt werden, wenn Regen vorbei?0_userdata.0.Wetterstation.Regen_Jahrvs.0_userdata.0.Wetterstation.Regen_Jahr_kumuliert?
Kann da quasi zB0_userdata.0.Wetterstation.Regen_Jahrauch von Juni bis Juni sein? Also wann die Station das erste mal in Betrieb genommen wurde?
Und0_userdata.0.Wetterstation.Regen_Jahr_kumuliertist der errechnete durch dein Script von Jänner bis Dezember?0_userdata.0.Wetterstation.Regen_Monatist klar. Aber warum ist hier ein Unterschied von ca. 2 mm zu0_userdata.0.Wetterstation.Regen_Jahr_kumuliert?Danke
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
hätt ein paar Fragen zu den Werten.
0_userdata.0.Wetterstation.Regen_Event= der aktuelle Regen; kann der vom Script wieder auf 0 gesetzt werden, wenn Regen vorbei?0_userdata.0.Wetterstation.Regen_Jahrvs.0_userdata.0.Wetterstation.Regen_Jahr_kumuliert?
Kann da quasi zB0_userdata.0.Wetterstation.Regen_Jahrauch von Juni bis Juni sein? Also wann die Station das erste mal in Betrieb genommen wurde?
Und0_userdata.0.Wetterstation.Regen_Jahr_kumuliertist der errechnete durch dein Script von Jänner bis Dezember?0_userdata.0.Wetterstation.Regen_Monatist klar. Aber warum ist hier ein Unterschied von ca. 2 mm zu0_userdata.0.Wetterstation.Regen_Jahr_kumuliert?Danke
-
@negalein
Ich hoffe dein Regen_Jahr ist nicht nur von Jänner 2025
@massiveattack sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@negalein
Ich hoffe dein Regen_Jahr ist nicht nur von Jänner 2025nö, von 2025 müsste ........_kumuliert sein. Sonst hätt ich schon Kiemen.
-
seit dem update von simple api auf v3.0 schreibt das log viele info messages:
simple-api.0 2025-03-10 09:56:56.750 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:56:56.325 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:56:24.372 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:56:23.934 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Monat" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:56:23.889 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:55:52.974 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:55:52.541 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:55:20.192 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:55:19.762 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Jahr" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:55:19.713 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:54:48.999 info State value to set for "javascript.0.Wetterstation.Sonnenstrahlung" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:54:48.924 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:54:48.485 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:54:16.274 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:54:15.842 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:54:15.798 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Tag" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:53:45.328 info State value to set for "javascript.0.Wetterstation.Sonnenstrahlung" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:53:45.249 info State value to set for "javascript.0.Wetterstation.Wind_max" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:53:44.810 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Monat" has to be type "number" but received type "string" simple-api.0 2025-03-10 09:53:44.761 info State value to set for "javascript.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string"müsste hier etwas angepasst werden?
MQTT-Protokoll, die das GW2000 seit der Firmwareversion 3.1.9 kann?
Support us
101
Online32.4k
Users81.3k
Topics1.3m
Posts