[Linux Shell-Skript] WLAN-Wetterstation
-
@negalein Wie hieß das damals: Gotcha ?
Na egal, wieder einen "erwischt"...
In Grafana fragst du lt. obigem Flux das Bucket "iobroker-1w" ab, in der conf dann aber "iobroker"? Das geht natürlich auch, dann musst du aber auch in beide Buckets loggen. Oder dich halt für eines der beiden entscheiden
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
In Grafana fragst du lt. obigem Flux das Bucket "iobroker-1w" ab, in der conf dann aber "iobroker"? Das geht natürlich auch, dann musst du aber auch in beide Buckets loggen. Oder dich halt für eines der beiden entscheiden
Ok, wird in der .conf etwas für Langzeitzwecke benötigt?
Denke nicht. Oder doch?Dann werde ich es in iobroker-1w ändern.
und funktioniert
-
@negalein
und ich war letztens der "Portvergesser"
Schön das es jetzt auch bei dir klappt -
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ok, wird in der .conf etwas für Langzeitzwecke benötigt?
Denke nicht. Oder doch?Ein einziges: "Temperatur vor einem Jahr" braucht dazu ein Logging von wenigstens 365 Tagen
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ein einziges: "Temperatur vor einem Jahr" braucht dazu ein Logging von wenigstens 365 Tagen
Ok, in der .conf kann ich aber nicht beide verwenden?
Also entweder alle DP mind. 1 Jahr loggen, oder auf Temperatur vor einem Jahr verzichten?Oder wie ist das mit dem Statistik Script?
-
@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 JahrAlso wird voraussichtlich alles in einem Bucket laden und Nachts wird das Bucket dann gecleaned, Werte in ein anderes Bucket geshifted ...
-
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.
-
@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 ? -
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.
-
@sborg Imho ist influx 2 eine verschlimmbesserung.
Muss jeder für sich entscheiden.
Meine influx/grafana umbauen ist einfach irre.
Hab da keine Lust. -
@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.
-
[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?
-
@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.csvWie würde ein export/write aus einer V2 aussehen? Werde aus der InfluxDB2 Doku nicht schlau, wie selektiere ich die measurements korrekt?
-
@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:
-
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=ZuHauseIn 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?
-
@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. -
@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... -
@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.
-
@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=80Aber soweit bin ich ja noch nicht. Erstmal soll das Teil überhaupt mal Daten liefern .
-
@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.
