NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
Installation des Plugins für Grafana: https://github.com/SBorg2014/WLAN-Wetterstation/tree/master/Grafana DashboardFlux:
from(bucket: "Bucketname") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Wind_max" or r._measurement == "0_userdata.0.Wetterstation.Windrichtung") |> filter(fn: (r) => r._field == "value") |> pivot(rowKey:["_time"], columnKey: ["_measurement"], valueColumn: "_value") |> filter(fn: (r) => exists r["0_userdata.0.Wetterstation.Windrichtung"] and exists r["0_userdata.0.Wetterstation.Wind_max"]) |> rename(columns: {"0_userdata.0.Wetterstation.Windrichtung": "directionRad", "0_userdata.0.Wetterstation.Wind_max": "speedMps"}) |> map(fn: (r) => ({ r with direction: r.directionRad / 3.14 * 180.0 })) |> map(fn: (r) => ({ r with speed: r.speedMps / 0.514 })) |> aggregateWindow(every: 2m0s, fn: first, column: "direction", createEmpty: false)@sborg
die line 9 und 10 mit den Divisionen sind doch Umrechnungen. Line 9 von rad auf Grad und der Divisor von 0.514 ist doch eine Umrechnung von m/s in Knoten.Benötigt man diese überhaupt, die Felder 0_userdata.0.Wetterstation.Windrichtung liefert doch schon km/h und
0_userdata.0.Wetterstation.Wind_max sollte doch auch schon Grad liefern.Liege ich hier mit meiner Annahme richtig?
Gernot
Host: i9 server Proxmox , Debian 12.0 for ioBroker
ioBroker: 7.7.19, Node.js: 22.21.1, NPM: 10.9.3, JS-controller: 7.0.7
Wetterstation: HP1000SEPro V1.9.0 Easeweather V1.7.0
Grafana 12.0.2 / InfluxDB 2.7.11 -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ist dein Grafana aktuell (9.3.6) ?
9.3.2
Aber ob es da wegen 0.0.4 so viele Unterschiede gibt?
Werde ein Update machen und testen.
mit 9.3.6 scheinen netzt zumindest einige
auf.Query ist jetzt zB
from(bucket: "${longtermBucket}") false false |> range(start: v.timeRangeStart, stop: v.timeRangeStop) false false |> filter(fn: (r) => r._measurement == "${Data_Prefix}.${Data_Instanz}.${Data_Ordnername}.Aussentemperatur" and r._field == "value") false false |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false) false false |> set(key: "_field", value: "Aussen") false false |> yield(name: "Aussen")Query-Inspektor zeigt weiterhin  @negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
mit 9.3.6 scheinen netzt zumindest einige
auf.https://forum.iobroker.net/topic/55627/test-adapter-energiefluss-v3-6-x-github-latest/2016
eventuell erklärung?gruß vom Woody
HAPPINESS is not a DESTINATION, it's a WAY of LIFE! -
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
mit 9.3.6 scheinen netzt zumindest einige
auf.https://forum.iobroker.net/topic/55627/test-adapter-energiefluss-v3-6-x-github-latest/2016
eventuell erklärung?@da_woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
eventuell erklärung?
nein, ist ein anderer.
Bei mir meckert er,Datasource ssI1YtJ4z was not found.
Wo er diessI1YtJ4zhernimmt ist mir ein Rätsel.
Btw., was ist die UID? Das Bucket? Die Organisation?
"datasource": { "type": "influxdb", "uid": "ssI1YtJ4z"° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@da_woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
eventuell erklärung?
nein, ist ein anderer.
Bei mir meckert er,Datasource ssI1YtJ4z was not found.
Wo er diessI1YtJ4zhernimmt ist mir ein Rätsel.
Btw., was ist die UID? Das Bucket? Die Organisation?
"datasource": { "type": "influxdb", "uid": "ssI1YtJ4z" -
@negalein die umstellung auf influx2 ist mir einfach noch zu undurchsichtig.
wenn ich da lese, mehrere buckets, (was ja eigentlich gut wäre wegen übersichtlichkeit) verbrauchen dann unmengen an speicherplatz...
ist aber wieder mal OT...@da_woody musst du nicht, ich hab auch nur ein bucket fuer den iobroker, andere Dinge haben ihr eigenes Bucket.. aber fuer verschiedene Buckets in iobroker braucht man auch mehrere Influx-Instanzen und das alles raus zu sortieren ist mir auch zu umstaendlich.
Ansonsten einfach den Link in influx von dem neuen Bucket auf ne Influxv1 Datenbank setzen und du kannst alle Grafana-Views nehmen, musst nur die Source in Grafana anpassen.
Bisher ohne Probleme, bis auf den 24h Temp Wert, der nicht geschrieben wird.. da gibts wohl noch keine Loesung..
-
@da_woody sagte in [Linux Shell-Skript] WLAN-Wetterstation:
eventuell erklärung?
nein, ist ein anderer.
Bei mir meckert er,Datasource ssI1YtJ4z was not found.
Wo er diessI1YtJ4zhernimmt ist mir ein Rätsel.
Btw., was ist die UID? Das Bucket? Die Organisation?
"datasource": { "type": "influxdb", "uid": "ssI1YtJ4z"UID steht hier für UniqueID der Datenquelle (siehe z.B. hier)
@da_Woody @ilovegym
es gäbe auch noch die Möglichkeit mit Tasks zu arbeiten und dort die Daten in andere Buckets umzusortieren oder z.B. "Herunterzubrechen" auf einen Durchschnitt (siehe Beispiel) und den zu speichern -
UID steht hier für UniqueID der Datenquelle (siehe z.B. hier)
@da_Woody @ilovegym
es gäbe auch noch die Möglichkeit mit Tasks zu arbeiten und dort die Daten in andere Buckets umzusortieren oder z.B. "Herunterzubrechen" auf einen Durchschnitt (siehe Beispiel) und den zu speichern@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
UID steht hier für UniqueID der Datenquelle (siehe z.B. hier)
Danke
Also muss ich die UID vom importierten Dashboard mit der UID von meinem Grafana ersetzen?
Wie bekomm ich die raus?
In Grafana hab ich 2 Datasources aktiv.- InfluxDB 1 (noch für alles andere)
- InfluxDB 2 mit Flux (für die Wetterseite)
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
UID steht hier für UniqueID der Datenquelle (siehe z.B. hier)
Danke
Also muss ich die UID vom importierten Dashboard mit der UID von meinem Grafana ersetzen?
Wie bekomm ich die raus?
In Grafana hab ich 2 Datasources aktiv.- InfluxDB 1 (noch für alles andere)
- InfluxDB 2 mit Flux (für die Wetterseite)
@negalein
bin mir nicht ganz sicher aber wenn du in grafana zu den datatsources gehst steht in der Browserzeile ein Kürzel am Ende
Evtl ist das die UID? -
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
UID steht hier für UniqueID der Datenquelle (siehe z.B. hier)
Danke
Also muss ich die UID vom importierten Dashboard mit der UID von meinem Grafana ersetzen?
Wie bekomm ich die raus?
In Grafana hab ich 2 Datasources aktiv.- InfluxDB 1 (noch für alles andere)
- InfluxDB 2 mit Flux (für die Wetterseite)
@negalein
die gleichen Fehlermeldungen waren bei mir auch
ich musste in jedem Widget die Source nochmal auswählen. Also bei mir (bereits ausgewählte) InfluxDB nochmal anklicken und auswählen. Dann war auch das Query zu sehen und die Werte wurden angezeigt. -
@negalein
die gleichen Fehlermeldungen waren bei mir auch
ich musste in jedem Widget die Source nochmal auswählen. Also bei mir (bereits ausgewählte) InfluxDB nochmal anklicken und auswählen. Dann war auch das Query zu sehen und die Werte wurden angezeigt.@quarkmax sagte in [Linux Shell-Skript] WLAN-Wetterstation:
ich musste in jedem Widget die Source nochmal auswählen. Also bei mir (bereits ausgewählte) InfluxDB nochmal anklicken und auswählen. Dann war auch das Query zu sehen und die Werte wurden angezeigt.
Danke, das wars!
-
@da_woody musst du nicht, ich hab auch nur ein bucket fuer den iobroker, andere Dinge haben ihr eigenes Bucket.. aber fuer verschiedene Buckets in iobroker braucht man auch mehrere Influx-Instanzen und das alles raus zu sortieren ist mir auch zu umstaendlich.
Ansonsten einfach den Link in influx von dem neuen Bucket auf ne Influxv1 Datenbank setzen und du kannst alle Grafana-Views nehmen, musst nur die Source in Grafana anpassen.
Bisher ohne Probleme, bis auf den 24h Temp Wert, der nicht geschrieben wird.. da gibts wohl noch keine Loesung..
@ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ansonsten einfach den Link in influx von dem neuen Bucket auf ne Influxv1 Datenbank setzen und du kannst alle Grafana-Views nehmen, musst nur die Source in Grafana anpassen.
jau, wieder mal eine geschichte durchs knie in die brust.
ich mach von mir aus ein Bucket, wie find ich das in grafana?
muss da noch weiterlesen um das zu verstehen... -
@sborg
die line 9 und 10 mit den Divisionen sind doch Umrechnungen. Line 9 von rad auf Grad und der Divisor von 0.514 ist doch eine Umrechnung von m/s in Knoten.Benötigt man diese überhaupt, die Felder 0_userdata.0.Wetterstation.Windrichtung liefert doch schon km/h und
0_userdata.0.Wetterstation.Wind_max sollte doch auch schon Grad liefern.Liege ich hier mit meiner Annahme richtig?
@tritor sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg
die line 9 und 10 mit den Divisionen sind doch Umrechnungen. Line 9 von rad auf Grad und der Divisor von 0.514 ist doch eine Umrechnung von m/s in Knoten.Benötigt man diese überhaupt, die Felder 0_userdata.0.Wetterstation.Windrichtung liefert doch schon km/h und
0_userdata.0.Wetterstation.Wind_max sollte doch auch schon Grad liefern.Liege ich hier mit meiner Annahme richtig?
Ich experimentiere aktuell selbst noch. Bei der Umrechnung von Rad in Grad hast du Recht, habe ich rausgeschmissen.
Bei der Geschwindigkeit bin ich noch unschlüssig. Steht mal beim Plugin überhaupt nix bei was es will/braucht.
Im Text steht aber "convert knots from m/s", könnte also bedeuten, dass er es in Knoten will? Ich habe jetzt mal versuchsweise durch 1.852 geteilt. Sieht mir nun schlüssig aus wenn ich es mit meinen Werten vergleiche. -
@ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Ansonsten einfach den Link in influx von dem neuen Bucket auf ne Influxv1 Datenbank setzen und du kannst alle Grafana-Views nehmen, musst nur die Source in Grafana anpassen.
jau, wieder mal eine geschichte durchs knie in die brust.
ich mach von mir aus ein Bucket, wie find ich das in grafana?
muss da noch weiterlesen um das zu verstehen...@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. -
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:
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@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.@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@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.Ich bin mir aktuell noch nicht sicher ob ich das überhaupt so lassen soll. Viele haben Probleme (oder wollen einfach nicht) mit mehreren Buckets zu arbeiten. Ev. wäre es besser mit einem "Wetter-Bucket" zu arbeiten und das per Influx-Tasks entsprechend zu befüllen. Das würde auch die Datenmenge stark reduzieren.
Wenn man alles nutzen will muss man aktuell auch alle Daten von zB. der Außentemperatur aufheben. Aber braucht irgendwer auch wirklich vom 22.04.2022 um 13:10 Uhr die Temperatur? Mir genügt eigentlich, um mal aktuell zu sein, die Min/Max/Avg-Temperatur vom 27.02.2022...
Das wären dann pro Jahr gerade mal 3 x 365 Datensätze (aktuell sind es pro Tag etwa ~3.000). Da könnte man auch über Jahre hinweg speichern (und bald Temperatur von vor 5 Jahren abfragen
)LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
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:
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Hat man nur eine für alles, bei beiden die selbe auswählen:
Danke
Also hier noch zusätzlich für
short......eine Datenquelle erstellen?
Ich hab jetzt in ioB influx.1 für
long(Bucket: iobroker) und fürshort(Bucket: iobroker-1w).Es reicht also nicht, 1 Datenquelle mit 2 Buckets?
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@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.Ich bin mir aktuell noch nicht sicher ob ich das überhaupt so lassen soll. Viele haben Probleme (oder wollen einfach nicht) mit mehreren Buckets zu arbeiten. Ev. wäre es besser mit einem "Wetter-Bucket" zu arbeiten und das per Influx-Tasks entsprechend zu befüllen. Das würde auch die Datenmenge stark reduzieren.
Wenn man alles nutzen will muss man aktuell auch alle Daten von zB. der Außentemperatur aufheben. Aber braucht irgendwer auch wirklich vom 22.04.2022 um 13:10 Uhr die Temperatur? Mir genügt eigentlich, um mal aktuell zu sein, die Min/Max/Avg-Temperatur vom 27.02.2022...
Das wären dann pro Jahr gerade mal 3 x 365 Datensätze (aktuell sind es pro Tag etwa ~3.000). Da könnte man auch über Jahre hinweg speichern (und bald Temperatur von vor 5 Jahren abfragen )@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
das per Influx-Tasks entsprechend zu befüllen
das klingt interessant.
Und wird auch sicher ein HowTo im Wiki geben? -
@tritor sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg
die line 9 und 10 mit den Divisionen sind doch Umrechnungen. Line 9 von rad auf Grad und der Divisor von 0.514 ist doch eine Umrechnung von m/s in Knoten.Benötigt man diese überhaupt, die Felder 0_userdata.0.Wetterstation.Windrichtung liefert doch schon km/h und
0_userdata.0.Wetterstation.Wind_max sollte doch auch schon Grad liefern.Liege ich hier mit meiner Annahme richtig?
Ich experimentiere aktuell selbst noch. Bei der Umrechnung von Rad in Grad hast du Recht, habe ich rausgeschmissen.
Bei der Geschwindigkeit bin ich noch unschlüssig. Steht mal beim Plugin überhaupt nix bei was es will/braucht.
Im Text steht aber "convert knots from m/s", könnte also bedeuten, dass er es in Knoten will? Ich habe jetzt mal versuchsweise durch 1.852 geteilt. Sieht mir nun schlüssig aus wenn ich es mit meinen Werten vergleiche. -
Ich habe da mal eine Frage zum Thema Performance der InfluxDB V2:
Ich habe auf Ubuntu 22.04 ein Direkt-Update von v1 auf v2 gemacht, was im Prinzip ohne Probleme funktioniert hat.
Da ich vorher eigene User für iobroker und Wetterstationsskript angelegt hatte, wurden diese mit migriert und als v1 User weiter geführt. Das hat den Vorteil, dass ich nun weiterhin die DB im v1 Modus abfragen kann.
Nun hatte ich im iobroker die InfluxDB Instanz auf V2 umgestellt und ich muss sagen, dass das Abfragen der Verlaufsdaten eines DP deutlich langsamer geworden sind.
Auch wenn ich irgendwelche ECharts abfrage, dauert das Laden dieser deutlich länger. Die CPU Last des influxdb Dienstes ist während der Abfrage auch extrem hoch.
Wenn ich dann einfach die iobroker Instanz wieder auf V1 umstelle und den migrierten V1 User dafür nutze, geht alles wieder gewohnt schnell, wie vorher.
Das Ganze läuft auf einer VM mit 4 Kernen je 3,3 GHz.
Die migrierten Daten von v1 auf v2 waren 320 MB, nur um mal die Größenordnung zu haben.
Ich würde also gerne mal wissen wie bei euch so die Performance der InfluxDB V2 in iobroker ist? -
Ich habe da mal eine Frage zum Thema Performance der InfluxDB V2:
Ich habe auf Ubuntu 22.04 ein Direkt-Update von v1 auf v2 gemacht, was im Prinzip ohne Probleme funktioniert hat.
Da ich vorher eigene User für iobroker und Wetterstationsskript angelegt hatte, wurden diese mit migriert und als v1 User weiter geführt. Das hat den Vorteil, dass ich nun weiterhin die DB im v1 Modus abfragen kann.
Nun hatte ich im iobroker die InfluxDB Instanz auf V2 umgestellt und ich muss sagen, dass das Abfragen der Verlaufsdaten eines DP deutlich langsamer geworden sind.
Auch wenn ich irgendwelche ECharts abfrage, dauert das Laden dieser deutlich länger. Die CPU Last des influxdb Dienstes ist während der Abfrage auch extrem hoch.
Wenn ich dann einfach die iobroker Instanz wieder auf V1 umstelle und den migrierten V1 User dafür nutze, geht alles wieder gewohnt schnell, wie vorher.
Das Ganze läuft auf einer VM mit 4 Kernen je 3,3 GHz.
Die migrierten Daten von v1 auf v2 waren 320 MB, nur um mal die Größenordnung zu haben.
Ich würde also gerne mal wissen wie bei euch so die Performance der InfluxDB V2 in iobroker ist?Bei mir im Docker deutlich schneller, und braucht weniger Ressourcen als v1
Support us
740
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge