Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

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

[wendy2702]

Guten Abend zusammen,

Ich habe noch eine der ersten Versionen des Scripts laufen da es mir die Daten liefert die mir wichtig sind.

Jetzt ist mir vor einigen Tagen aufgefallen das bei einigen Objekten die „0“ vor dem Komma fehlt:

In der App und auf den Webseiten der angebundenen Wetterdienste wird mir die „0“ angezeigt und ich meine mir einzubilden das es bei mir auch mal der Fall war.

Jemand eine Idee wie ich die „0“ wieder ins Objekt und damit auch in meine VIS Anzeige bekomme?

[SBorg]

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

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?

Nicht ganz ein Scherz, aber ich meinte eigentlich keine "unerlaubten" Sonderzeichen im Passwort nutzen.
Hilfe immer gerne, allerdings musst du Shell-Skript können und die API-Beschreibung darf ich nicht weitergeben. Man sieht zwar später etwas davon im Quelltext, größtenteils ist das dann aber ein Zahlenwirrwarr und viele nicht benutzte Parameter sind überhaupt nicht identifizierbar.

[SBorg]

@wendy2702
Das war mal gar nicht schlecht (keine Ironie).
Ist mir gar nicht aufgefallen, kam wohl mit irgendeinem Firmwareupdate. Die Station/Gateway sendet tatsächlich keine führende Null mehr bei den Werten (ich verarbeite den Wert 1:1).
Und genau das ist auch das String/Number Problem. So wird ein Zahlenwert von ".123" von der Simple-API als String identifiziert, "0.123" aber korrekt als Zahl. Deswegen konnte ich bis dato auch so kein System erkennen warum es mal funktioniert und mal nicht.
Muss ich eine Korrektur einführen die die fehlende Null wieder ergänzt. Dann hast du wieder deine Null und das String/Number - Problem sollte auch gelöst sein.

[Rene55]

@SBorg Schade - Shell-Script ist gar nicht. Bei Awekas sind übliche Sonderzeichen ja zulässig. Aber mach dir deswegen hier keinen Stress, es funktioniert ja wieder.

[mef70]

Hi,
ich habe eine Bresser 7-1 WLAN ClearView Station
In der WSLink App habe ich unter Andere Wetter Server den Eintrag gemacht der auf meinen raspi zeigt

Wenn ich die wetterstation im debug Modus starte werden auch nach kurzer Zeit Daten geschickt, aber das Skript wirft einen Kommunikationsfehler. Die Stations ID stimmt mit der WS_ID in der wetterstation.conf überein.
grafik.png

Was mach ich falsch? Danke für euren Input.

[SBorg]

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

Was mach ich falsch? Danke für euren Input.

"Leider" nix. Aber ev. gibt es noch eine Möglichkeit. Die von dir eingestellte Datenübertragung "Wunderground API" ist verschlüsselt (sieht man bei Data von Wetterstation. Da steht normalerweise ein Klartext.)
Kannst du noch ein anderes, wenn ja welche, auswählen?

[mef70]

Ich habe das "Wunderground API" und "WSLink API" zur Auswahl:

[SBorg]

Ich glaube zwar nicht so richtig daran, aber du kannst mal auf WSLink API umstellen. Wahrscheinlich kommt aber der selbe "Müll" (ist halt verschlüsselt) beim Datenstring heraus.

[mef70]

Du hast leier recht. Dann bleibt nur die Option mit pi-hole, oder?

[wendy2702]

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

@wendy2702
Das war mal gar nicht schlecht (keine Ironie).
Ist mir gar nicht aufgefallen, kam wohl mit irgendeinem Firmwareupdate. Die Station/Gateway sendet tatsächlich keine führende Null mehr bei den Werten (ich verarbeite den Wert 1:1).
Und genau das ist auch das String/Number Problem. So wird ein Zahlenwert von ".123" von der Simple-API als String identifiziert, "0.123" aber korrekt als Zahl. Deswegen konnte ich bis dato auch so kein System erkennen warum es mal funktioniert und mal nicht.
Muss ich eine Korrektur einführen die die fehlende Null wieder ergänzt. Dann hast du wieder deine Null und das String/Number - Problem sollte auch gelöst sein.

Hallo und Frohe Weihnachten,

hast du das mittlerweile schon korrigiert und ich habe nur das Update verschlafen?

Danke und Gruß

[SBorg]

@mef70
Nein, leider nicht. Die DNS-Umleitung leitet nur den Datenverkehr von Adresse X nach Adresse Y um. Die Kommunikation (=Daten) bleibt weiterhin verschlüsselt.

Wie wichtig sind dir denn die Daten?
Ich kenne deinen "Wettermast" nicht, aber die funken idR. alle auf 868Mhz ihre Rohmessdaten. Dann könnte ein zusätzliches Gateway funktionieren. Kostenpunkt ~60,- € (bei Bresser bin ich aber sehr vorsichtig mit solch Aussagen, denn die arbeiten sehr oft proprietär).
Man kann die Messdaten auch mittels eines ESPs und passendem Board direkt vom Mast abgreifen. Kostenpunkt ~10,- €. Hier kannst du aber dann nicht mehr mit dem Skript arbeiten (außer man ändert den Sketch vom ESP, dass er dann einen "Normstring" im Ecowitt-Format an eine IP+Port sendet) und musst mit einem Blockly, NodeRED-Flow, what else arbeiten.

[SBorg]

@wendy2702
Danke und ebenso (dem Rest der Mitleser natürlich genauso).
Leider nicht verschlafen, die liebe Zeit fehlt aktuell an allen Ecken und Enden.

Wenn ich was ändere landet das immer hier im Thread, auf GitHub sowieso (inkl. der Versionierung).

Ich weiß selbst wie das ist wenn man wartet, und ich bin auch nicht glücklich mit der aktuellen Situation, aber ich habe dermaßen "Land unter", dass ich hierzu (und auch anderem) einfach zeitlich nicht komme. Es ist wie es ist, durch jammern wird es auch nicht besser. Projekt deswegen einstellen ist jedenfalls aktuell keine Option, auch wenn ich mich zugegeben mit dem Gedanken bereits beschäftigt hatte.

[wendy2702]

Hi,

Mach dir keinen Stress wegen mir. Ich bin aktuell eher selten hier aktiv und wollte nur sichergehen das ich nichts verschlafen habe.

[Boronsbruder]

@SBorg
Wenn man dich unterstützen kann, würde ich gerne meine Kenntnisse (sofern sie ausreichen) zur Verfügung stellen.

[SBorg]

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

@SBorg
Wenn man dich unterstützen kann, würde ich gerne meine Kenntnisse (sofern sie ausreichen) zur Verfügung stellen.

Immer gerne, aber zu spät😜

Ich hatte mir schon einiges überlegt und in den letzten drei Stunden mal wieder unzählige Wege gefunden wie es nicht funktioniert. Problem war, dass auch bei negativen Werten von -0.99 bis -0.01 die führende Null fehlt. Das war dann schwieriger als gedacht. Umso erschreckender wie simpel im Nachhinein die Lösung erscheint...

Wer mal vorab testen will (nur direkt unter Linux, bitte nicht mit Windows und bspw. WinSCP bearbeiten!):

in der wetterstation.sub den Block (im Original Zeilen #364-366)

convertFtoC() {
   MESSWERTE[$1]=$(echo "scale=2;(${MESSWERTE[$1]}-32)*5/9" | bc -l)
}

einfach durch

convertFtoC() {
        local MESSWERT=$(awk "BEGIN {print (${MESSWERTE[$1]} - 32) * 5 / 9}")
        MESSWERTE[$1]=$(awk "BEGIN {print sprintf(\"%.2f\", $MESSWERT)}")
}

ersetzen. Das fügt dann bei der Aussentemperatur und bei allen Messwerten die in Fahrenheit vorliegen ggf. die "0" wieder vorne an: -0.34°C oder 0.78°C
Service restarten nicht vergessen: sudo systemctl restart wetterstation

An der

State value to set for "0_userdata.0.Wetterstation.Aussentemperatur" has to be type "number" but received type "string"

Problematik ändert es leider wiedererwartend nichts. Bei mir aktuell 2.78°C und er meckert...