UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[ETGermany]

@mugel80 Wie hast du das denn hinbekommen? Habe mir die WH6000Ppro hier gekauft.

Im Setup kann ich weder Port noch Protokoll oder Pfad einstellen:

Sollt zumindest mal wissen, welch Port ich benötige, oder kannst du mir die wetterstation.conf schicken?

Vielleicht ist das ja auch ein ganz anderes Modell unter gleichem Namen. Sieht deine Station denn genau gleich aus?

Danke Eckhard

[ETGermany]

@etgermany Via rtl_433 am ioBroker hat sich die Station als Bresser 7-in-1 angemeldet, somit ist sicher, dass es keine WH600PRO wie früher ist. Ist eben alles aus China von einem Hersteller, egal welchen Namen das Zeug trägt. Angeblich wird ja alles vom OEB Fine Offset Electronics hergestellt.
Habe mir jetzt ein Ecowitt WS2910, lt. Handbuch sollte die Einbindung möglich sein.

[ETGermany]

@sborg Inzwischen habe ich eine ECOWITT, prinzipiell scheint es zu funktioniert, doch der Datentyp scheint nach einem Restart des Services zu wechseln.

Zuerst diese Fehler im Log:

simple-api.0
2025-10-16 11:01:30.680	info	State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Jahr" has to be type "number" but received type "string"

simple-api.0
2025-10-16 11:01:30.680	info	State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Monat" has to be type "number" but received type "string"

simple-api.0
2025-10-16 11:01:30.680	info	State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Woche" has to be type "number" but received type "string"

dann habe ich die Objekte angepasst, nach einem Service Neustart dann aber diese Fehler:

simple-api.0
2025-10-16 11:46:03.183	info	State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Jahr" has to be type "string" but received type "number"

simple-api.0
2025-10-16 11:46:03.182	info	State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Woche" has to be type "string" but received type "number"

simple-api.0
2025-10-16 11:46:03.182	info	State value to set for "0_userdata.0.Wetterstation.Info.Solarenergie_Tag" has to be type "number" but received type "string"

simple-api.0
2025-10-16 11:46:03.052	info	State value to set for "0_userdata.0.Wetterstation.Info.Sonnenschein_Monat" has to be type "number" but received type "string"

simple-api.0
2025-10-16 11:46:03.052	info	State value to set for "0_userdata.0.Wetterstation.Info.Sonnenschein_Tag" has to be type "number" but received type "string"

Weiterhin noch Fehler beim Start bzw. wenn man den Status abfragen tut:

iobroker@n51-ubuntu:~$ systemctl status wetterstation
● wetterstation.service - Service für ioBroker Wetterstation
     Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-10-16 11:29:41 CEST; 1min 59s ago
   Main PID: 1206786 (wetterstation.s)
      Tasks: 5 (limit: 9171)
     Memory: 2.8M (peak: 4.4M)
        CPU: 2.150s
     CGroup: /system.slice/wetterstation.service
             ├─1206786 /bin/bash /home/iobroker/bresser/wetterstation.sh
             ├─1207672 /bin/bash /home/iobroker/bresser/wetterstation.sh
             ├─1207673 timeout 66 nc -nlvw 1 -p 1080
             ├─1207674 tail -1
             └─1207675 nc -nlvw 1 -p 1080

Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207406]: /home/iobroker/bresser/wetterstation.sub: line 730: "0_userdata.0.Wetterstation.tempData.Sonnenschein" /86400: syntax error: operand expected (error token is ""0_userdata.0.Wetterstation.tempData.Sonnenschein" /86400")
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207407]: /home/iobroker/bresser/wetterstation.sub: line 731: "0_userdata.0.Wetterstation.tempData.Sonnenschein" /3600: syntax error: operand expected (error token is ""0_userdata.0.Wetterstation.tempData.Sonnenschein" /3600")
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207408]: /home/iobroker/bresser/wetterstation.sub: line 732: "0_userdata.0.Wetterstation.tempData.Sonnenschein" % 86400 /3600: syntax error: operand expected (error token is ""0_userdata.0.Wetterstation.tempData.Sonnenschein" % 86400 /3600")
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207409]: /home/iobroker/bresser/wetterstation.sub: line 733: "0_userdata.0.Wetterstation.tempData.Sonnenschein" % 3600 /60: syntax error: operand expected (error token is ""0_userdata.0.Wetterstation.tempData.Sonnenschein" % 3600 /60")
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207410]: /home/iobroker/bresser/wetterstation.sub: line 734: "0_userdata.0.Wetterstation.tempData.Sonnenschein" % 60: syntax error: operand expected (error token is ""0_userdata.0.Wetterstation.tempData.Sonnenschein" % 60")
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1206786]: /home/iobroker/bresser/wetterstation.sub: line 736: [: : integer expression expected
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1206786]: /home/iobroker/bresser/wetterstation.sub: line 742: [: : integer expression expected
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207429]: (standard_in) 1: syntax error
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207438]: (standard_in) 1: syntax error
Okt 16 11:30:47 n51-ubuntu wetterstation.sh[1207441]: (standard_in) 1: syntax error
iobroker@n51-ubuntu:~$

Aber wie gesagt, prinzipiell funktioniert es.

[icebear]

@etgermany said in [Linux Shell-Skript] WLAN-Wetterstation:

....doch der Datentyp scheint nach einem Restart des Services zu wechseln.

Dies ist ein bekanntes Problem, wenn dich das stört, stellt den DP Typ auf gemischt, dann kommt der Fehler nicht mehr.

[SBorg]

@etgermany
Zu String/Number siehe @icebear
Ich hatte noch eine Vermutung, dass der Simple-API ein Problem mit "Int" bzw. "Float" hat. So kann bspw. Temperatur=3 (also Integer) sein, oder halt zB. 3.1 (Float). Deswegen habe ich dann mal auf Temperatur=3.0 konvertiert (also eine Integer in Float). Ergebnis: keine Änderung. Keinerlei System wann er was als String/Number erkennt. Mal geht es, mal nicht. Das kam irgendwann mit einem Update des Simple-API oder JSC.
Mögliche Lösung wäre der Switch zur Rest-API. Allerdings ist dies nicht einfach ein umstellen des Aufrufes, sondern bedarf schon einer größeren Programmierarbeit.

Der letzte Fehler sollte sich dann auch erledigt haben. Das kann passieren wenn man gerade anfängt und die Aüßeren Umstände ungünstig waren. Sollte sich dann mit dem ausführen der ersten Mitternachtjobs erledigt haben. Dann liegen alle Werte vor (sollte dennoch auch beim 1. Start nicht auftreten).

[ManfredR]

Hallo,
habe kürzlich von Version 2.17 auf 3.60 aktualisiert. Mit 2.17 lief der Windy - Upload problemlos, mit der aktuellen Version bekomme ich in Windy keine Daten der Anlage angezeigt. Im Debug-Modus sieht das so aus:

Datenübertragung an windy.com:
{"update":{"update":{"stations":[],"observations":[{"si":0,"time":"2025-11-22T17:16:46.000Z","temp":-3.08,"wind":0,"wind_dir":271,"wind_gust":0,"rh":94,"dew_point":-6.44,"pressure":98611,"precip":0,"uv":0}]},"errors":{"observations":[],"stations":[]}},"result":{"0":{"stations":[],"observations":[{"success":true,"value":{"si":0,"time":"2025-11-22T17:16:46.000Z","temp":-3.08,"wind":0,"wind_dir":271,"wind_gust":0,"rh":94,"dew_point":-6.44,"pressure":98611,"precip":0,"uv":0}}]}}}

wenn ich das Script innerhalb von 5 Minuten nochmals laufen lasse, kommt folgende Meldung:
{"update":{"update":{"stations":[],"observations":[{"si":0,"time":"2025-11-22T17:25:46.000Z","temp":-2.94,"wind":0,"wind_dir":63,"wind_gust":0,"rh":95,"dew_point":-5.94,"pressure":98578,"precip":0,"uv":0}]},"errors":{"observations":[],"stations":[]}},"result":{"0":{"stations":[],"observations":[{"success":false,"value":{"si":0,"time":"2025-11-22T17:25:46.000Z","temp":-2.94,"wind":0,"wind_dir":63,"wind_gust":0,"rh":95,"dew_point":-5.94,"pressure":98578,"precip":0,"uv":0},"error":"Measurement sent too soon, update interval is 5 minutes"}]}}}

Wenn ich den API - Key verfälsche, dann kommt "invalid user", die Datenübertragung an sich scheint also zu funktionieren mit korrektem API-Schlüssel. Irgendwie erscheint mir der JSON String aber etwas sonderbar aufgebaut, konnte aber auf die Schnelle keine anderen Beispiele finden.
Habt Ihr eine Ahnung, woran das liegen könnte bzw. wie ich den Fehler finden kann?

Danke und Grüsse,
Manfred

[icebear]

Ich mach das mittlerweile mit meiner Ecowitt Weatherstation anders um den Daten zu Windy. zu schicken. Läuft bei mir seit Monaten problemlos.

Schau dir mal folgendes an Station Forwarder

[Boronsbruder]

edit: Falschaussage

[SBorg]

@ManfredR
Sieht alles soweit gut aus. Das JSON kommt direkt von windy, teilt aber "success: true" mit. Die Übermittlung der Daten ist also erfolgt und war valid.
Ev. aktualisiert sich die Seite im Browser einfach nicht? Hast du mal ein STRG+F5 (neu laden der Seite erzwingen ohne Daten aus dem Cache zu lesen) probiert?

Seit der Bereitstellung von Windy habe ich nichts mehr an diesem Bereich gemacht, 2.x.x und 3.6.0 sind also in dieser Hinsicht absolut identisch.

[Rene55]

Kann mir hier noch jemand auf die Sprünge helfen. Ich habe (leider) erst heute gesehen, dass ich keine Wetterdaten mehr an Awekas sende. Hatte bis August noch funktioniert. Gab es eine Änderung? Wie könnte ich prüfen, was falsch läuft.

[ManfredR]

@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:

@ManfredR
Sieht alles soweit gut aus. Das JSON kommt direkt von windy, teilt aber "success: true" mit. Die Übermittlung der Daten ist also erfolgt und war valid.
Ev. aktualisiert sich die Seite im Browser einfach nicht? Hast du mal ein STRG+F5 (neu laden der Seite erzwingen ohne Daten aus dem Cache zu lesen) probiert?

Seit der Bereitstellung von Windy habe ich nichts mehr an diesem Bereich gemacht, 2.x.x und 3.6.0 sind also in dieser Hinsicht absolut identisch.

Danke für die Rückmeldung. Habe grad nochmal geschaut, das sieht nun gut aus bei Windy. Komisch, hatte das bei mehreren Browsern getestet - keiner hatte zuvor was angezeigt.

[Boronsbruder]

@Rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Kann mir hier noch jemand auf die Sprünge helfen. Ich habe (leider) erst heute gesehen, dass ich keine Wetterdaten mehr an Awekas sende. Hatte bis August noch funktioniert. Gab es eine Änderung? Wie könnte ich prüfen, was falsch läuft.

Ich hab letztens eine Email bekommen von AWEKAS, die natürlich im Spam gelandet ist, daß meine Station ungewöhnliche Daten sendet.
Ursache war, dass ich den rel. Luftdruck nachjustiert hatte und dadurch kurzzeitige Schwankungen entstanden sind.
Danach musste ich meine Station wieder bei AWEKAS aktivieren.

Zeitlich befristete Deaktivierungen können Sie auch selber in Ihren AWEKAS Benutzereinstellungen ( https://www.awekas.at/de/benutzer.php ) reaktivieren

Prüfen sie bitte ihre Sensoren und die Übertragungstechnik. 
Sollten sie die Deaktivierung als ungerechtfertigt empfinden, setzen sie sich bitte mit uns in Verbindung. 

[Rene55]

Danke für die Antwort. Ich komme mit Awekas nicht klar. Da wo ich die Daten zu meinem Account habe, sehe ich unten in rot "Fehler vorhanden - bitte korrigieren Sie alle roten Felder". Nur sehe ich keine roten Felder. Ich schreib Awekas mal an.

[Rene55]

Die Antwort von Awekas lautet: "Ihr IO Broker sendet keine Daten an uns. Es kommt nichts an:
Bitte prüfen Sie die Einstellungen für die Daten Url und Benutzernamen". Daraufhin habe ich das Passwort mal geändert (diesmal ohne Sonderzeichen) - und schon ist Awekas wieder uptodate.
Gab oder gibt es die Restriktion auf 'einfache' Passworte?

[Thomas Braun]

@Rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Gab oder gibt es die Restriktion auf 'einfache' Passworte?

Kommt halt darauf an, wie Passworte geparst werden. Eigentlich sollte sowas abgefangen werden.
Aber manchmal werden Sonderzeichen wie % $ - interpretiert.

[Rene55]

Ja, stimmt. Da bin ich auch schon mal drüber gestolpert. Vllt. hat @SBorg da noch eine Idee.

[SBorg]

@Rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Vllt. hat @SBorg da noch eine Idee.

Nicht nutzen ;)
Aber Spaß beiseite. Da die Datenübertragung (auch das Passwort) per URL erfolgt, sind alle Zeichen die in einer URL vorkommen können kritisch, wie zB. /=?&:
Dafür kann man (ich) nun encoden: mache aus ":" ein %3A
Nur heißt das dann noch lange nicht, dass auch die Gegenseite es wieder korrekt decoded.
Ich habe dann bewusst darauf verzichtet, da hier das beste Passwort eh nichts nutzt, solange es im Klartext gesendet wird. Auch bietet die bash meines Wissens keine Möglichkeit direkt zu encoden. Dies geht allerdings mittels "jq", der sowieso schon installiert sein muss und für Operationen benutzt wird. Wäre also prinzipiell möglich, aber wegen des Klartext-Versandes eher kontraproduktiv (das super geheime schwierige Passwort für den PC pappt per PostIT am Monitor...).

Abhilfe würde nur die Nutzung der API von AWEKAS schaffen (die hat mir Otmar von AWEKAS schon zukommen lassen). Hier wird das Passwort als HASH verschlüsselt und ist so erstmal nicht mehr lesbar. Das ist aber nicht mal gerade so in 5 Minuten umgesetzt und mir fehlt dafür aktuell (und nicht absehbar) schlichtweg die Zeit.

[Rene55]

Danke für die Antwort. War die Antwort "nicht nutzen" nur ein Scherz oder gibt es dazu einen Grund - ausser dem offenen Password. Und: kann ich dir beim Implementieren der API etwas helfen?