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

Hallo lieber @SBorg, ich hoffe dir gehts gut!
Seit gestern herrschen bei mir negative Außentemperaturen und seitdem kommt bei Wolkenbasis nurnoch 0.

Ich habe das gleiche Problem, genauer gesagt steht bei mir immer "null".
Ich habe mir das jetzt mal angeschaut, das Problem ist folgende Zeile der Funktion do_wolkenbasis() in der wetterstation.sub:
local WOLKENBASIS=$(echo "scale=2;(${MESSWERTE[1]}-${MESSWERTE[2]})*125"| bc -l)
MESSWERTE[1] ist die Außentemperatur
MESSWERTE[2] ist der Taupunkt
Das bc Kommando hat scheinbar ein Problem, wenn MESSWERTE[2] negativ ist. Das kommt dann mit dem Minus Minus nicht zurecht und schmeißt einen Syntax Error.
Wenn man um den MESSWERTE[2] nochmal Klammern setzt, geht es wieder, die Zeile sieht dann so aus:
local WOLKENBASIS=$(echo "scale=2;(${MESSWERTE[1]}-(${MESSWERTE[2]}))*125"| bc -l)
Danach das Wetterstationsskript oder falls eingerichtet den Dienst neu starten und dann sollte das wieder funktionieren.

Erst einmal ein generelles Danke für diese Tabelle, nutze sie jetzt seit kurzem.
Ein kleiner Punkt:
Ich habe gerade die Tabelle um neue Zeilen für die neuen Werte wie Wüstentage etc. erweitert.
Das war im Prinzip kein großes Problem, weil man einfach das varData Objekt am Anfang erweitert.
Allerdings muss man für die Jahreszahl auch den table rowspan erweitern.
Da hatte ich jetzt 2 Stellen im Skript gefunden.
Damit man das in Zukunft nicht manuell anpassen muss, folgende Idee:
Ich habe unter dem varData die Anzahl der dort enthaltenen Werte ermittellt, was dann ja der Anzahl der Zeilen entspricht und man muss dann noch 1 für die Überschriften dazuzählen:
const table_rowspan = Object.keys(varData).length + 1;

Und weiter unten habe ich dann an 2 Stellen die entsprechende Tabellendefinitionen angepasst (bei rowspan=):
tableContent+='<td class=\"myWetterStation\" width=\"25px\" style=\"color:'+monatFarbe+';font-size:26px; background-color:'+hintergrund+' ; vertical-align:middle; text-align:center \" rowspan='+table_rowspan+'\">'+test+'</td><td style=\"color:'+monatFarbe+'; background-color:'+hintergrund+'"\>Jahreswerte</td>'

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

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

Bzgl. der MySQL Anbindung, das wäre eine nice-to-have, weil ich es eh schon nutze, aber im Notfall muss ich eben noch eine InfluxDB aufsetzen, wäre jetzt auch nicht so dramatisch

Da würde ich aktuell vom Notfall ausgehen, denn eine Umsetzung sehe ich eher Mittel- denn Kurzfristig, da du auch aktuell der Einzige bist. Somit steht es auf der Prioliste nicht ganz oben

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

@viper4iob ich würde sagen, steig um auf influx. einfach, weils mit grafana einfacher ist und da auch mehr hilfe zu erwarten ist.

Das mit Grafana habe ich auch schon mitbekommen, das ist mit MySQL etwas umständlich.
Und ja, der generelle Support in Verbindung mit influx ist einfach besser.
Ach ja: die InfluxDB läuft seit gestern und ich lasse auch schon testweise ein paar Datenpunkte aus iobroker rein schreiben

Zum Thema Dateirechten und Besitzerschaft vom Skript:
Im Prinzip gebe ich @Martin-0 recht. Wenn man das Skript im Home vom iobroker betreibt, sollte es auch iobroker gehören.
Aus Sicherheitssicht spielt es aber keine große Rolle, denn sobald das Skript als systemd Service gestartet wird, läuft es unter root. Kann man beispielsweise mit ps -ef | grep wetterstation kontrollieren.
Und das Risiko ist denke ich deutlich höher, falls eben jemand das Github Repository manipuliert und man sich diese Änderungen dann installiert.

Wichtig wäre also meiner Meinung nach den Service unter einem anderen User als root ausführen zu lassen. Das Skript braucht soweit ich das aktuell feststellen konnte, für das normale Ausführen keine root-Rechte, es führt netcat aus und solange der Port über 1024 ist, braucht das keine root Rechte. Und dann kommuniziert es mit iobroker und die InfluxDB über deren Schnittstellen, was ebenfalls keine root Rechte benötigt.
Um den Service als anderer User zu starten muss man im Service File im Abschnitt [Service] die Argumente User und Group hinzufügen und da dann beispielsweise den iobroker angeben.
Ich hab es aktuell unter meinem eigenen User laufen.
Streng genommen sind beide User nicht optimal und man müsste einen komplett neuen User nur für das Skript anlegen, der sich auch nicht interaktiv anmelden kann und darüber dann den Dienst laufen lassen, aber das war mir dann auch zu viel des Guten.
Unter meinem User funktioniert es auf alle Fälle.
Über den iobroker User habe ich es noch nicht getestet. Der iobroker user wäre vielleicht aktuell sogar die bessere Wahl, weil der sich wahrscheinlich nicht interaktiv anmelden kann, also nur ein System User ist. Nur weiß man nie, ob sich da mit irgendeinem Update mal wieder was ändern könnte. Bis vor einiger Zeit lief der iobroker auch nicht unter eigenem User, das wurde dann irgendwann mal angepasst.

@SBorg
Das wäre evtl. nochmal ein Punkt, worüber man für den Install Guide und der Service File Definition nachdenken könnte. Vielleicht auch einfach nur als Hinweis und man kann dann selbst entscheiden.

@sborg

Ich wollte die OpenSenseMap Registrierung über das Skript durchführen: ./wetterstation.sh --osem_reg.
Nur leider bricht diese gleich mit folgendem Fehler ab:

So sieht die conf aus:

Die Zeile, die den Fehler erzeugt, ist diese:

Jetzt habe ich mich gefragt, wo dieser OSEM_USER her kommt, der hier geprüft wird, in der conf gibt es nur einen senseBox_USER, und die Abfrage am Terminal durch read kommt erst nach dieser Prüfung. Und ich konnte auch keine Stelle finden, an der der senseBox_USER aus der conf ausgelesen und in den OSEM_USER geschrieben wird.
Und selbst wenn im OSEM_USER an der Stelle den Inhalt aus senseBox_USER hätte, müsste dann das Prüfen auf den Leerstring vielleicht eher so aussehen if [ ! -z $OSEM_USER ];?
Nun weiß ich auch nicht, ob nur ich damit ein Problem habe, weil das ws_update Skript bei mir auch nicht richtig läuft, wo das patchen schief geht und ich immer noch nicht weiß warum.
Aber vielleicht ist es ja hier ein anderes Problem

@sborg
Hi,
ich habe mal auf die 2.17.0 beta aktualisiert und mal USE_AVG_WIND auf true gesetzt.
Kann es sein, dass für die Windgeschwindigkeit an wetter.com noch der Teiler durch 3,6 fehlt.
Da war ja damals das Problem, dass man nicht weiß, welchen Wert die dort erwarten und tendenziell war es eher m/s als km/h.

Auf dem Screenshot von wetter.com habe ich markiert, wann ich das Update durchgeführt habe.

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

@viper4iob
erstellst du bitte ein issue auf github damit @SBorg es im Auge behält (er war schon einige Zeit nicht mehr im Forum ). Für die Wolkenbasis hab ich´s schon gemacht.

Erledigt und @SBorg hat auch reagiert:
https://github.com/SBorg2014/WLAN-Wetterstation/issues/47

viper4gh created this issue in SBorg2014/WLAN-Wetterstation

closed Problem Wetterwarnungen #47

@SBorg
Könntest du vielleicht in der Grafana Readme noch die DPs benennen, die in den shorttermBucket und in den longtermBucket landen sollen?
Oder zumindest eins von beiden, dann weiß man, dass der Rest in dem anderen Bucket landen muss.
Danke.

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

Ich habe eine neue Version des Dashboard-Exports hochgeladen (bei wem es mittlerweile läuft braucht nichts zu tun ), welche das Import-Problem fixen sollte.
Problem ist/war, dass er die UID (anhand derer kann Grafana eindeutig alles identifizieren, selbst wenn man den Namen ändern sollte) auch mit den (meinen) Datenquellen verknüpft. Deswegen kann meine UID nur absolut zufällig mit der eurigen übereinstimmen. In der neuen Version wird man nun beim Import gefragt und muss die passenden Datenquellen auswählen.
Hat man nur eine für alles, bei beiden die selbe auswählen:

Da ist noch ein kleiner Fehler drin. Ich wollte das Dashboard gerade selbst "for external" exportieren und da hat mir Grafana einen Fehler geschmissen, dass er ${DS_HOMEAUTOMATION} nicht kennt.
Im Grafana V3 Template steht das an 2 Stellen:
https://github.com/SBorg2014/WLAN-Wetterstation/blob/master/Grafana Dashboard/Wetterstation-Dashboard_V3.json#L5550
https://github.com/SBorg2014/WLAN-Wetterstation/blob/master/Grafana Dashboard/Wetterstation-Dashboard_V3.json#L5679
Da muss wahrscheinlich auch ${DS_WETTERDATEN} oder ${DS_TEMPDATA} rein, damit er das beim Import korrekt ersetzt.

Ich würde auch helfen das Problem einzugrenzen, habe aber die Kinder zu Hause wegen Ferien und versuche nebenbei irgendwie noch zu Arbeiten.
Ich kann aber zumindest bestätigen, dass das Deaktivieren der metsommer Funktion in der Datei wetterstation.sh das Skript normal durchlaufen lässt.

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

Heute habe ich auch endlich den korrekten Export des Dashboardes hinbekommen. Importieren und 5 Variablen angeben, fertig und läuft. Kommt demnächst auf GitHub

Ah, super.
Kann es kaum erwarten
Danke schon mal im Voraus.

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

Hallo zusammen,
ich hätte da mal eine Frage. mein Vater hat mich mit dem ganzen Thema etwas angefixt. Er ist Amateurfunker und hat in seinem Hobbyraum eine ganze Station um Wetterbilder von Meteosat zu empfangen.
Aber zu meiner Frage, ich habe vor mir die Froggit HP1000SE PRO Display inkl. Innensensor + DP40 Aussen Temperatur/Luftfeuchte + DP80 Regensensor + DP300 Anemometer zu kaufen. Wie läuft das mit dem DP80 Regensensor? Der steht ja nicht in der Liste der Zusatzsensoren, wird der mit dem Display verbunden und dann so an ioBroker übermittelt oder wie kann ich mir das vorstellen?

Danke und liebe Grüße aus dem Westerwald
Michael

Hi,
ich habe von Froggit die HP1000SE PRO Single Sensor Edition und zusätzlich einen zweiten Außentemperatursensor und einen Blitzdetektor.
In der Single Sensor Edition ist auch der DP80 enthalten und das funktioniert ohne Probleme, er sendet also seine Werte als "regulärer Sensor" und muss nicht als zusätzlicher Sensor hinzugefügt werden.
In der config habe ich bei folgenden Sensoren eine 1 stehen:

ANZAHL_WH31=1	#Außen Thermo-Hygrometer
ANZAHL_DP40=1	#zusätzliches Außen Thermo-Hygrometer
ANZAHL_DP50=1	#Innen Thermo-Hygrometer
ANZAHL_DP60=1	#Blitzdetektor
ANZAHL_DP300=1	#Anemometer und Lichtsensor

@martybr
Aussentemperatur und Regen_Tag werden auch in die Influx DB aufgezeichnet, also über das Zahnrädchen in iobroker?
Eventuell auch nochmal die Influx Settings in der wetterstation.conf checken.

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

@SBorg
Ich habe das Update auf die 3.1.1 gemacht. Auch ich hatte die "kein Patch nötig" Meldungen. Das Programm ist aber heute Nacht durchgelaufen.
Aufgrund dieser Problematik habe ich mir die Datenpunkte

0_userdata.0.Wetterstation.Info.Regenmenge_Met_Sommer
0_userdata.0.Wetterstation.Info.Temp_Met_Sommer_avg

angeschaut. Beide Datenpunkte werden durch das Script nicht geändert und haben den Ursprungswert 999,9 l bzw. 99,9 °C.

Ich setze Influxdb Vor. 2 ein. Die Aktivierung für Inful habe ich manuell gemacht (Zahnrad):

Heißt das, du hast Influx Version 1.x ?
Wenn ja, dann kann es nicht funktionieren, weil das Skript seit Version 3.0.0 nur noch Influx DB V2.x unterstützt und dort eine komplett andere Abfrage Syntax für die Influx DB genutzt wird bzw. sich auch die Authentifizierung geändert hat (nicht mehr Benutzer/Passwort sondern mit Tokens):
https://github.com/SBorg2014/WLAN-Wetterstation/releases/tag/V3.0.0
Breaking Release / Support für (und nur noch!) InfluxDB V2.x

Die beiden oben genannten Werte müssen auch nicht in die Influx DB aufgezeichnet werden, sondern diese Werte werden durch das Skript befüllt und das Skript muss dafür die Werte für .Aussentemperatur und .Regen_Tag zwischen dem 01.06. und dem 31.08. direkt aus der Influx DB auslesen können.
Und das kann nicht funktionieren, sollte die Influx DB noch auf einer Version 1.x sein.

@sborg
Ich wollte nur nochmal bestätigen, dass die Release Version 3.1.1 aus github jetzt ohne Probleme funktioniert.
Ich habe allerdings die Dateien manuell ausgetauscht, weil der Patcher bei mir von Anfang an Probleme gemacht hat, ich nutze den also grundsätzlich nicht.
Deshalb kann ich nichts zu den Patcher Meldungen sagen.

@MassiveAttack
Das "local" vor IFS muss bleiben, das war genau der Fix, damit das Skript Nachts wieder durchläuft.

@SBorg
Kann ich ebenfalls bestätigen, Skript ist ohne Probleme durchgelaufen.
Der IFS war es dann.
Gute Arbeit
Das ist so ein blöder Fehler, den man manchmal tagelang sucht, also Respekt, dass du den so schnell finden konntest.

Ich habe die Änderung mit dem IFS auch mal vorgenommen und sicherheitshalber eine Service Restart für 0:10 Uhr per cronjob hinterlegt, weil ich sonst wieder eine böse Mail von AWEKAS bekomme
Ich checke dann morgen, ob es Fehlermeldungen gab und gebe Rückmeldung.
Bei mir sieht der Status nach dem jetzigen Restart so aus:

● wetterstation.service - Service für ioBroker Wetterstation
     Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2023-06-05 13:30:17 CEST; 36s ago
   Main PID: 16570 (wetterstation.s)
      Tasks: 5 (limit: 6982)
     Memory: 2.8M
        CPU: 1.730s
     CGroup: /system.slice/wetterstation.service
             ├─16570 /bin/bash /opt/wetterstation/wetterstation.sh
             ├─18387 /bin/bash /opt/wetterstation/wetterstation.sh
             ├─18388 timeout 46 nc -nlvw 1 -p 1080
             ├─18389 tail -1
             └─18390 nc -nlvw 1 -p 1080

Jun 05 13:30:17 kubix systemd[1]: Started Service für ioBroker Wetterstation.
Jun 05 13:30:17 kubix wetterstation.sh[16603]: Connection to 127.0.0.1 8087 port [tcp/*] succeeded!

Ich würde auch helfen das Problem einzugrenzen, habe aber die Kinder zu Hause wegen Ferien und versuche nebenbei irgendwie noch zu Arbeiten.
Ich kann aber zumindest bestätigen, dass das Deaktivieren der metsommer Funktion in der Datei wetterstation.sh das Skript normal durchlaufen lässt.

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

Ich habe eine neue Version des Dashboard-Exports hochgeladen (bei wem es mittlerweile läuft braucht nichts zu tun ), welche das Import-Problem fixen sollte.
Problem ist/war, dass er die UID (anhand derer kann Grafana eindeutig alles identifizieren, selbst wenn man den Namen ändern sollte) auch mit den (meinen) Datenquellen verknüpft. Deswegen kann meine UID nur absolut zufällig mit der eurigen übereinstimmen. In der neuen Version wird man nun beim Import gefragt und muss die passenden Datenquellen auswählen.
Hat man nur eine für alles, bei beiden die selbe auswählen:

Da ist noch ein kleiner Fehler drin. Ich wollte das Dashboard gerade selbst "for external" exportieren und da hat mir Grafana einen Fehler geschmissen, dass er ${DS_HOMEAUTOMATION} nicht kennt.
Im Grafana V3 Template steht das an 2 Stellen:
https://github.com/SBorg2014/WLAN-Wetterstation/blob/master/Grafana Dashboard/Wetterstation-Dashboard_V3.json#L5550
https://github.com/SBorg2014/WLAN-Wetterstation/blob/master/Grafana Dashboard/Wetterstation-Dashboard_V3.json#L5679
Da muss wahrscheinlich auch ${DS_WETTERDATEN} oder ${DS_TEMPDATA} rein, damit er das beim Import korrekt ersetzt.

@mango1402

Den Startzeitpunkt kann ich bestätigen, habe das im Log auch gerade nachvollzogen, macht irgendwie nicht so viel Sinn, erst mal alle Werte seit 2000 zu laden, erklärt aber zumindest, warum es mehrere Sekunden dauert.
Und jetzt kommts, im Influx Adpater V1 Modus macht er das nicht, habe ich gerade ausprobiert.
Wenn ich da den Verlauf von z.B. "Dieser Tag" anzeigen lasse:

2023-03-24 13:40:38.527  - debug: influxdb.0 (2583993) javascript.0.Wetterstation.Aussentemperatur16796616385270.6902108576272359 getHistory message: {"id":"javascript.0.Wetterstation.Aussentemperatur","options":{"instance":"influxdb.0","start":1679612400000,"end":1679661660000,"from":true,"ack":true,"q":true,"addID":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}}

Da steht als Start-Zeitpunkt 1679612400000 = Fri Mar 24 2023 00:00:00 GMT+0100