[Linux Shell-Skript] WLAN-Wetterstation

[SBorg]

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

Also entweder alle DP mind. 1 Jahr loggen, oder auf Temperatur vor einem Jahr verzichten?

Das typische Ja und Nein.
Mindestens 1 Jahr loggen muss natürlich sein, sonst hat man keine Werte.
...und nochmal ja, es geht nur ein Bucket. Das würde dann mit der Statistik zusammen ein Heilloses Durcheinander geben und kaum einer blickt da noch durch. Aber verzichten muss man auch nicht unbedingt darauf, man muss nur das/die Bucket/s entsprechend konfigurieren.
Aber man kann ja aggregieren, Daten "umshiften" etc. Da muss jeder seine Vorlieben (oder was er/sie/diverse genau möchte) im Grunde selbst umsetzen.
Ich werde mir bei Gelegenheit ein Flussdiagramm erstellen, da ich gewisse Präferenzen habe und sonst nicht mehr durchblicke...
Ich hätte bei der Temperatur bspw. gerne vor einem Jahr und vor x Jahren (4 Jahre sammele ich schon). Allerdings ist die Datenflut da reiner Irrsinn. Nur Temperatur: ~ 3k Messwerte pro Tag / ~1.1Mio pro Jahr
...und ich muss/will nicht wissen wie viel Grad es am 24.03.2021 genau um 17:40 Uhr war. Also werde ich die Messwerte stundenweise zusammenfassen: 24 Stück x 365 Tage = 8760 Datensätze pro Jahr

Also wird voraussichtlich alles in einem Bucket laden und Nachts wird das Bucket dann gecleaned, Werte in ein anderes Bucket geshifted ...

[Nashra]

Ich frage jetzt einfach mal, warum ist es nicht möglich die Aufbewahrungsdauer
in jedem Datenpunkt individuell einzustellen so wie es beim history-Adaper
auch möglich ist. Ok, die Frage gehört eigentlich in den entsprechenden Thread,
aber dann gäbe es das Problem nicht das man alle DP über ein Jahr loggen
muß für die Statistik und gewisse Datenpunkte könnten von dieser langen
Aufbewahrungszeit ausgenommen werden.

Werde auch mal im influx-Adapter Thread anfragen ob dies nicht möglich ist.

[Nashra]

@Negalein , danke für die Bewertung aber es ist so wie @SBorg schon geschrieben hat.
Für verschiedene Aufbewahrungszeiten muß jeweils ein eigenes Bucket angelegt
werden und somit jedes mal eine neue Influxdb-Instanz
Kannst du alles hier nachlesen was ich auch gemacht habe.
Im Klartext heißt das, wenn ich vier verschiedene Aufbewahrungszeiten haben möchte
muß ich vier Buckets anlegen und vier Instanzen.
Ist das so richtig @SBorg ?

[SBorg]

Also....

Die Retention lässt sich nur pro Bucket festlegen. Deswegen gab es das Skript auch so lange nur für Influx V1.x, da ich dies als Hauptmanko ansah.
Man kann aber trotzdem "tricksen". Dazu muss man "Tasks" in Influx nutzen. So kann man in einem Bucket mit einer Retention von "never" trotzdem eine Retention für Datenreihen mit bspw. 30 Tagen erreichen.

Ich werde wahrscheinlich (s.o. Stichwort Flussdiagramm) nur mit zwei Buckets arbeiten.
Eine einzige Influx-Instanz loggt alles in das "Hauptbucket" (=Homeautomation); Retention wahrscheinlich 30 Tage (da ich kaum etwas über einen längeren Zeitraum brauche).
Da mich aber der Gaspreisverlauf der letzten Jahre und der Verbrauch übers Jahr dessen interessiert, hätte ich jetzt ein Problem. Deswegen werden diese beiden Werte nun per Task in ein anderes Bucket ("Langzeitwerte") "umgeshifted".
Diese Bucket ist für den ioB nicht über eine Instanz sichtbar, ich kann aber per JS, Blockly, NodeRED oder Grafana darauf zugreifen.

landet dann im "Langzeit-Bucket":

Was schneller weg kann/muss lässt sich dann auch mittels der Tasks droppen.

[da_Woody]

@sborg Imho ist influx 2 eine verschlimmbesserung.
Muss jeder für sich entscheiden.
Meine influx/grafana umbauen ist einfach irre.
Hab da keine Lust.

[SBorg]

@da_woody Lust hatte ich da auch nicht gerade darauf, aber was will man machen...
Andererseits war es auch gar nicht schlecht, da waren noch viele Dinge einfach aus anfänglicher Unwissenheit "nicht im Reinen".
Jetzt habe ich alles auf Variablen umgestellt. Ist zwar dann noch mehr Arbeit, dafür aber einmalig. Wenn sich jetzt was ändert brauche ich nur einmalig an einer Stelle den Wert ändern, schon gilt das für alle Grafana-Panels

...und ja, auch InfluxDB ist damit "komplizierter" geworden, zumindest auf den 1. Blick. Dafür ist es nun auch weitaus mächtiger.

[tritor]

[gelöst] - gefunden in der wetterstation.conf

Hab nun auch auf V3.0. updgedated.

Updater ausgeführt und im ioB auch das Script für die DPs Version 3.0 ausgeführt.

Script läuft, und die neuen DPs unter 0_userdata/wetterstation sind angelegt. Es kommen da aber keine Daten rein, alle Daten laufen weiterhin unter javascript/wetterstation

Ist das normal/so gewollt, oder wie stelle ich es um, daß die DPs unter userdata geschrieben werden?

[tritor]

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

Am einfachsten exportiert (egal ob aus Influx V1 oder V2) man sich die entsprechende(n) Datenreihe(n) zB. mittels "Killer-Befehl" aus der V1 :

echo '#datatype measurement,dateTime:RFC3339,boolean,string,double,double' > export.csv && influx -database [Datenbankname] -username [username] -password [passwort] -execute 'SELECT * FROM "javascript.0.Wetterstation.Aussentemperatur","javascript.0.Wetterstation.Regen_Tag","javascript.0.Wetterstation.Wind_max"' -format csv -precision='rfc3339' >> export.csv

Wie würde ein export/write aus einer V2 aussehen? Werde aus der InfluxDB2 Doku nicht schlau, wie selektiere ich die measurements korrekt?

[SBorg]

@tritor Am einfachsten selektierst du es im "Dataexplorer" wie bei einer Testabfrage für Grafana (Timerange anpassen nicht vergessen). Passt der Graph dann soweit mit den Daten einfach als "CSV" exportieren (es wird nur das exportiert was auch angezeigt wird).

Bei den "Sources" wählst du dann "Flux Annotated CSV" aus, dann im folgenden Fenster dein Bucket für den Import und die zuvor gespeicherte CSV aus:

[Chief42]

Erstmal Hallo in die Runde und im Voraus schonmal vielen Dank für die tolle Unterstützung hier! Ich beschäftige mich schon einige Wochen mit dem ioBroker und habe auch schon einiges hinbekommen aber mit dem Script für die Wetterstation komme ich nicht weiter.

Ich habe eine Bresser 7in1 Station die ich gerne mit dem Script nutzen möchte. Dazu habe ich auf meiner Firewall (Sophos UTM) einen statischen DNS Eintrag vorgenommen der die Adresse rtupdate.wunderground.com (und auch wunderground.com) auf den ioBroker weiterleitet. Laut Logfile der Firewall funktioniert das auch.

Das Script habe ich direkt auf dem ioBroker (Debian, Proxmox VM) installiert und das hat soweit auch ohne Fehler funktioniert. Wenn ich "./wetterstation.sh --debug" eingebe kommt ein Kommunikationsfehler zurück:

Müsste das grundsätzlich so funktionieren oder muss doch ein Pi-hole dazwischen geschaltet werden damit das funktioniert? Soweit ich das verstanden habe müsste der einfache DNS-Eintrag reichen.

Wenn ich einen tcpdump von der Firewall mache finde ich mit Wireshark zwar Pakete von der Wetterstation in Richtung ioBroker aber da stehen keine Wetterdaten drinnen. Wenn ich das richtig interpretiere werden keine HTTP-Daten übertragen/entgegengenommen.

In der Firewall habe ich natürlich eine Freigabe für Port 80 von der Wetterstation in Richtung ioBroker eingerichtet.

Hier der Inhalt der wetterstation.conf:

### Settings V3.0.0 -----------------------------------------------------------
 #Debuging einschalten [true/false] / default: false / Ausgabe der Messwerte
  debug=false

 #Verhalten bei Kommunikationsfehler [true/false] / default: false / Soll der Datenpunkt automatisch resettet werden?
  RESET_KOMFEHLER=false

 #Logging einschalten [true/false] / default: false / schreibt die Datenstrings der Station in eine Datei
  logging=false

 #ioBroker-IP und Port der Simple-Restful-API [xxx.xxx.xxx.xxx:xxxxx]
  IPP=192.168.100.71:8087

 #Protokoll, ioBroker-IP und Port der Rest-API [http(s)://xxx.xxx.xxx.xxx:xxxxx] / leer lassen falls nicht benutzt
  RESTAPI_URL=
  RESTAPI_USER=
  RESTAPI_PW=

 #Protokoll der Wetterstation [1/2/9] / 1=Wunderground ; 2=Ecowitt ; 9=DNS / default: 2
  WS_PROTOKOLL=9

 #Anzahl der vorhandenen Zusatzsensoren Froggit, Ecowitt und Bresser / default: 0
  ANZAHL_WH31=0
  ANZAHL_WS90=0
  ANZAHL_DP10=0
  ANZAHL_DP35=0
  ANZAHL_DP40=0
  ANZAHL_DP50=0
  ANZAHL_DP60=0
  ANZAHL_DP70=0
  ANZAHL_DP100=0
  ANZAHL_DP200=0
  ANZAHL_DP250=0
  ANZAHL_DP300=0
  # jetzt kommt Bresser!
  ANZAHL_7009999=4

 #Protokoll (HTTP oder HTTPS) / default: HTTP
  WEB=HTTP

 #Ignoriere Zertifikatsfehler bei der Simple-Restful-API [true/false] / default: false / nötig bei eigenen Zertifikaten
  WEB_IGN_SSL_ERROR=false

 #User-Authentifizierung falls benutzt; sonst leer lassen
  AUTH_USER=
  AUTH_PASS=

 #Port der Wetterstation
  WS_PORT=80

 #Pollintervall der Wetterstation in Sekunden (minimal 16 Sekunden)
  WS_POLL=30

 #Name/ID der Wetterstation
  WS_ID=ZuHause

In der Wetterstation habe ich ebenfalls "ZuHause" bei der Station ID eingetragen.

Der Port der Simple-Restful-API stimmt auch.

Hat jemand einen Tipp für mich was ich noch überprüfen oder machen kann/muss?

[viper4iob]

@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.

[SBorg]

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

Müsste das grundsätzlich so funktionieren oder muss doch ein Pi-hole dazwischen geschaltet werden damit das funktioniert?

Ja und nein. Was man nimmt ist im Grunde egal (die Tage hatten wir es mittels eines Routers auf dem OpenWRT läuft realisiert).
Es muss nur die DNS-Anfrage der Station/des Gateways vom WWW auf eine heimische IP-Adresse umgeleitet werden, damit das Datenpaket "im Haus" bleibt.

Was ich so sehe/lese ist auch alles korrekt, aber eins bleibt zumindest noch offen. Ist der Port 80 (den kann man ja hier nicht ändern) auf dem Rechner auch wirklich frei?

sudo netstat -tulpen | grep :80
Da darf für Port 80 kein "Listen" oä. erscheinen:

...wie man sieht läuft dort bei mir der typische Apache-Webserver...

[SBorg]

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

Da muss wahrscheinlich auch ${DS_WETTERDATEN} oder ${DS_TEMPDATA} rein, damit er das beim Import korrekt ersetzt.

Danke, eben gefixt und hoch geladen. Scheint aber gar nicht in den beiden Panels von Bedeutung zu sein, nur trägt er halt anscheinend immer eine "Datasource" ein, ob benutzt oder nicht. Mein Testimport hat dann natürlich funktioniert, da ich die Source ja habe.

[Chief42]

@sborg Der Port ist (noch) frei.

Ich bin nicht rief drin in dem Script und habe es mir auch noch nicht so genau angeschaut aber müsste von der Logik her nicht der ioBroker/das Script auf Port 80 lauschen, die Anfrage annehmen und an Port 8087 weiterleiten?

Wenn ich den Port 80 von der Wetterstation in der Firewall per DNAT-Regel ändere müsste das aber auch mit einem anderen Port funktionieren. Dieser geänderte Port würde dann hier eingetragen werden, oder?

#Port der Wetterstation
  WS_PORT=80

Aber soweit bin ich ja noch nicht. Erstmal soll das Teil überhaupt mal Daten liefern .

[SBorg]

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

ioBroker/das Script auf Port 80 lauschen, die Anfrage annehmen und an Port 8087 weiterleiten?

Jein. Eine "echte" Weiterleitung ist das nicht. Er nimmt Daten an Port 80 entgegen, bereitet diese auf und schickt dann ein Datenpaket an den ioB-Adapter der auf Port xxxx läuft.

Wenn ich den Port 80 von der Wetterstation in der Firewall per DNAT-Regel ändere müsste das aber auch mit einem anderen Port funktionieren. Dieser geänderte Port würde dann hier eingetragen werden, oder?

Letzteres ja, ersteres hatte irgendwie nicht funktioniert. Selbst ausprobieren konnte ich es nicht, erinnere mich aber auch nicht mehr so Recht dran. Funktioniert hatte es aber nicht (wobei es allerdings sollte).

Ich vermute du hast ein "root"-Problem. Du bist zwar vorbildlich als "User" unterwegs, dass könnte dir hier aber zum Verhängnis werden. Die meisten Distris wollen bei Ports <1024 root-Rechte.

Versuch mal ein  nc -nlvw 1 -p 80 (das macht auch das Skript)... permission denied ?
Dann sollte es mittels "sudo" davor funktionieren. Man kann die Ports auch nach "unten" setzen, dann funktioniert es auch. Allerdings erlaubt dies auch jedem User des Systems dann alle Ports zu nutzen. Da wäre, wenn es funktioniert, ein DNAT von 80 --> bspw. 1080 die saubere Version:

(auf 80 läuft bei mir bereits der Apache), sollte dann aber bspw. ein Datenpaket der Station empfangen.

[Chief42]

@sborg You made my day!

Deine Vermutung war absolut richtig!

Ich habe dann in der Firewall ein wenig gespielt und konnte das Script schnell zum Laufen bringen. Folgendes habe ich eingerichtet:

Firewallregel (die Wetterstation bekommt über Port 9080 Zugang zum ioBroker):

DNAT-Regel (HTTP Port 80 von der Wetterstation wird auf Port 9080 umgebogen):

Im Firewall-Logfile sieht das schonmal gut aus (sah vorher, als es nicht ging, allerdings auch gut aus):

In der "wetterstation.conf" wurde der neue Port eingetragen:

#Port der Wetterstation
  WS_PORT=9080

Das Scipt konnte dann erfolgreich mit "./wetterstation.sh --debug" gestartet werden:

Im ioBroker erscheinen die Werte auch:

Hier fehlen allerdings die vier Zusatzsensoren. Ist hier das Protokoll evtl. doch auf einen Sensor beschränkt? Eigentlich bräuchte ich sogar noch ein paar Sensoren mehr als die vier evtl. möglichen ;-).

Meine Linux-Kenntnisse sind (bisher) nur sehr rudimentär aber das mit den Ports <1024 hatte ich irgendwo auch schonmal gelesen aber hätte das nie in Verbindung mit dem Problem gebracht. Vermutlich gibt es irgendwo ein Logfile in dem das sogar steht. Egal, jetzt läuft das Script (auch automatisch im Hintergrund).

Kannst Du bitte noch kurz etwas zu den Zusatzsensoren sagen?

In der Konfiguration habe ich die maximalen 4 Sensoren angegeben:

#Protokoll der Wetterstation [1/2/9] / 1=Wunderground ; 2=Ecowitt ; 9=DNS / default: 2
  WS_PROTOKOLL=9

 #Anzahl der vorhandenen Zusatzsensoren Froggit, Ecowitt und Bresser / default: 0
  ANZAHL_WH31=0
  ANZAHL_WS90=0
  ANZAHL_DP10=0
  ANZAHL_DP35=0
  ANZAHL_DP40=0
  ANZAHL_DP50=0
  ANZAHL_DP60=0
  ANZAHL_DP70=0
  ANZAHL_DP100=0
  ANZAHL_DP200=0
  ANZAHL_DP250=0
  ANZAHL_DP300=0
  ANZAHL_7009999=4

Wenn, wie in der Anleitung beschrieben ist, das Wunderground-Protokoll 4 Sensoren unterstützt scheint es bei der DNS-Variante nicht zu funktionieren. Bei Wunderground bin ich nicht angemeldet aber Weathercloud unterstützt auch nur einen Sensor.

[mctom]

Hallo zusammen,

vielleicht hat jemand hier einen Tipp für mich.
Ich habe in der Config jetzt dies Daten meiner InfluxDB eingetragen.
Im Vorfeld habe ich ein eigenes Bucket angelegt und dies auch in der Config eingetragen.
Leider tauchen keine Daten in der Datenbank auf.
Gibt es einen Tipp was ich prüfen kann, damit ich den Fehler ein wenig eingrenzen kann ?

Vielen Dank für die Hilfe.

Gruß

Michael

[SBorg]

@chief42
Ich habe es leider vergessen im Eingangspost zu ergänzen welcher User es mit der Bresser-Station war. Anhand seines Datenstrings habe ich dann die Zusatzsensoren eingebunden. Er hat(te) mehr als vier, im WU-Protokoll tauchen aber nur die ersten vier auf und was nicht vom Display kommt, kann ich auch nicht auswerten
...und die Bresser gehen alle nur per DNS, daran liegt es also nicht.

Stoppe mal den Service sudo systemctl stop wetterstation und führe dann im Installationsverzeichnis ./wetterstation.sh --data aus. Das liefert dann deinen/den Rohdatenstring. ID/Password kannst du auch kpl. raus löschen, brauche ich nicht und dann hier posten.
...und dann mittels sudo systemctl start wetterstation den Start nicht vergessen ;)7

[SBorg]

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

Leider tauchen keine Daten in der Datenbank auf.
Gibt es einen Tipp was ich prüfen kann, damit ich den Fehler ein wenig eingrenzen kann ?

Heißt, du siehst mittels des Dataexplorers (ich gehe mal von InfluxDB v2.x aus) keine Messwerte? Das hat dann so erst mal nichts mit dem Skript zu tun, denn ich schreibe selbst nichts in die InfluxDB, ich lese nur.
Hast du denn für den Bucket dann auch das Logging im Influx-Adapter für zumindest Aussentemperatur, Regen_Tag, Wind_max aktiviert?

[Chief42]

@sborg Hier das Ergebnis:

Listening on 0.0.0.0 9080
Connection received on 172.16.28.130 60566
GET /weatherstation/updateweatherstation.php?ID=ZuHause&PASSWORD=xxxxxxxxxx&action=updateraww&realtime=1&rtfreq=5&dateutc=now&baromin=29.48&tempf=50.0&dewptf=46.2&humidity=87&windspeedmph=1.5&windgustmph=1.5&winddir=228&rainin=0.0&dailyrainin=0.96&solarradiation=31.83&UV=0.0&indoortempf=63.6&indoorhumidity=57 HTTP/1.1

So wie es scheint liefert die Station nur die Werte von einem Innensensor. Komisch das es da scheinbar Unterschiede bei den Stationen gibt. Die Station selber zeigt die 5 Sensoren die ich habe (im Wechsel) an. Bis zu sechs Sensoren sind möglich.

Die Wetterstaion ist diese hier:
BRESSER-Profi-WLAN-Wetterstation-7in1-mit-Lichtintensitaet-und-UV-Messung