NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
@viper4iob Ich habe bis dato noch nichts nachteiliges bemerkt. Auch das "umshiften" von größeren Datenmengen innerhalb Influx klappt schnell. Größere Anfragen per Influx-Adapter habe ich allerdings keine, denn ev. hängt es hier auch am Adapter.
Per JS, Grafana etc. ist alles subjektiv gleich schnell, zumindest nicht spürbar schneller/langsamer.
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@viper4iob Ich habe bis dato noch nichts nachteiliges bemerkt. Auch das "umshiften" von größeren Datenmengen innerhalb Influx klappt schnell. Größere Anfragen per Influx-Adapter habe ich allerdings keine, denn ev. hängt es hier auch am Adapter.
Per JS, Grafana etc. ist alles subjektiv gleich schnell, zumindest nicht spürbar schneller/langsamer.
Ok, danke für die Info.
Werde es als nächstes mit dem neuem Grafana Dashboard von dir testen (danke schon mal im Voraus dafür).
Dann werde ich sehen, ob es generell an der InfluxDB liegt oder nur am Influx Adapter vom iobroker. -
@SBorg
Erst einmal wieder ein großes Dankeschön fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme, auch die Abfrage der Werte per Influx läuftDann generell:
Ich habe jetzt nochmal ein paar Tests zur Performance der InfluxDB V2 durchgeführt.- Auf der Influx DB Web UI habe ich im Data Explorer mal 60 Measurements markiert, die letzten 30 Tage abgefragt und das Ergebnis als Simple Table angezeigt. Der Query hat 0,1 Sekunden gedauert
- Ich habe das neue Grafana Dashboard importiert, das hat etwas gedauert, weil erstens die Änderung der Variablen bei mir nichts bewirkt hat (habs dann vorm Import in der json angepasst) und dann standen bei vielen Queries noch nicht die Variablen drin, was dann mit einem Suchen/Ersetzen in der json Datei erledigt wurde :wink: . Auf jeden Fall läd das neue Dashboard, das die Daten über die neue Data Source per Flux Sprache und Token abfragt, auch sehr schnell.
Es sieht also tatsächlich so aus, dass nur der Influx Adapter im iobroker beim Auslesen größerer Datenmengen zumindest bei mir Probleme macht.
Falls jemand mal Lust hat, bitte folgendes Script im iobroker anlegen, ggf. Influx Instanz / Bucket Namen anpassen und ausführen:sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h)', function (result) { if (result.error) { console.error(result.error); } else { // show result //console.log('Rows: ' + JSON.stringify(result)); console.log('fertig'); } });Das Skript fragt einfach mal die Werte aller Measurements der letzten 24 Stunden ab.
Danach mal ins iobroker Protokoll gehen und checken wie viel Zeit zwischen dem Skriptstart und der "fertig" Meldung vergangen ist. Bei mir hat das ca. 35 Sekunden gedauert :expressionless:
Natürlich ist es schwierig das zu vergleichen, weil das sehr davon abhängt wie viele Measurements man hat und wie viele Werte darin gespeichert sind. Ich habe aktuell um die 150 Measurements in der DB.
Eine Tendenz sollte aber trotzdem sichtbar sein und es würde mich interessieren, ob nur ich ein Problem damit habe oder ob das generell am Adapter liegt.
Danke schon mal im Voraus.Mir ist das Ganze auch nur aufgefallen, weil ich auch den ECharts Adapter zum Anzeigen von Graphen nutze und der zieht die Daten eben aus der Historie über den Influx Adapter des iobrokers.
Das Laden der Graphen dauert im V2 Modus des Influx Adapters nun deutlich länger als im V1 Modus (Ich kann noch den V1 Modus nutzen, weil ich die User aus v1 mit migriert habe, die dann weiterhin per Basic Auth und InfluxQL abfragen können). Ich habe mehrmals zwischen beiden Modi gewechselt und es ist reproduzierbar. -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Du kannst es da erst auswählen wenn du influx-1w auch wirklich als Datenquelle hinzugefügt hast
Ok, also hier zusätzlich eine Datenquelle (ident mit InfluxDB 2), und diese dann nur für
influx-1wverwenden.
Und hier bei
Default Bucketdanninflux-1weintragen.
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und hier bei Default Bucket dann influx-1w eintragen.
Jepp, das ist dann die Zuweisung "nimm für die Datenquelle dieses Bucket"
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@SBorg
Erst einmal wieder ein großes Dankeschön fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme, auch die Abfrage der Werte per Influx läuftDann generell:
Ich habe jetzt nochmal ein paar Tests zur Performance der InfluxDB V2 durchgeführt.- Auf der Influx DB Web UI habe ich im Data Explorer mal 60 Measurements markiert, die letzten 30 Tage abgefragt und das Ergebnis als Simple Table angezeigt. Der Query hat 0,1 Sekunden gedauert
- Ich habe das neue Grafana Dashboard importiert, das hat etwas gedauert, weil erstens die Änderung der Variablen bei mir nichts bewirkt hat (habs dann vorm Import in der json angepasst) und dann standen bei vielen Queries noch nicht die Variablen drin, was dann mit einem Suchen/Ersetzen in der json Datei erledigt wurde :wink: . Auf jeden Fall läd das neue Dashboard, das die Daten über die neue Data Source per Flux Sprache und Token abfragt, auch sehr schnell.
Es sieht also tatsächlich so aus, dass nur der Influx Adapter im iobroker beim Auslesen größerer Datenmengen zumindest bei mir Probleme macht.
Falls jemand mal Lust hat, bitte folgendes Script im iobroker anlegen, ggf. Influx Instanz / Bucket Namen anpassen und ausführen:sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h)', function (result) { if (result.error) { console.error(result.error); } else { // show result //console.log('Rows: ' + JSON.stringify(result)); console.log('fertig'); } });Das Skript fragt einfach mal die Werte aller Measurements der letzten 24 Stunden ab.
Danach mal ins iobroker Protokoll gehen und checken wie viel Zeit zwischen dem Skriptstart und der "fertig" Meldung vergangen ist. Bei mir hat das ca. 35 Sekunden gedauert :expressionless:
Natürlich ist es schwierig das zu vergleichen, weil das sehr davon abhängt wie viele Measurements man hat und wie viele Werte darin gespeichert sind. Ich habe aktuell um die 150 Measurements in der DB.
Eine Tendenz sollte aber trotzdem sichtbar sein und es würde mich interessieren, ob nur ich ein Problem damit habe oder ob das generell am Adapter liegt.
Danke schon mal im Voraus.Mir ist das Ganze auch nur aufgefallen, weil ich auch den ECharts Adapter zum Anzeigen von Graphen nutze und der zieht die Daten eben aus der Historie über den Influx Adapter des iobrokers.
Das Laden der Graphen dauert im V2 Modus des Influx Adapters nun deutlich länger als im V1 Modus (Ich kann noch den V1 Modus nutzen, weil ich die User aus v1 mit migriert habe, die dann weiterhin per Basic Auth und InfluxQL abfragen können). Ich habe mehrmals zwischen beiden Modi gewechselt und es ist reproduzierbar.@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme
So gut das ich eben einen Fix veröffentlicht habe :blush:
Neue Version des JavaScriptes Wetterstation-Statistik auf GitHub V2.0.2
- ~Bugfix fehlender Vorjahresmonat (Fix Issue #58)
Wie immer zu finden im GitHub
-
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme
So gut das ich eben einen Fix veröffentlicht habe :blush:
Neue Version des JavaScriptes Wetterstation-Statistik auf GitHub V2.0.2
- ~Bugfix fehlender Vorjahresmonat (Fix Issue #58)
Wie immer zu finden im GitHub
@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:
@viper4iob sagte in [Linux Shell-Skript] WLAN-Wetterstation:
fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme
So gut das ich eben einen Fix veröffentlicht habe :blush:
Neue Version des JavaScriptes Wetterstation-Statistik auf GitHub V2.0.2
- ~Bugfix fehlender Vorjahresmonat (Fix Issue #58)
Wie immer zu finden im GitHub
Auch hier danke, kann ich aktuell nur nicht nutzen, weil mein Influx Adapter auf V1 läuft, bis ich mir was wegen dem Performance-Problem vom Influx Adapter im V2 Modus überlegt habe (z.B. meine ECharts mit Grafana nachbauen und irgendwie in jarvis einbinden). Ich muss aktuell also erst mal noch das alte Wetterstatistik Skript verwenden :wink:
-
@SBorg
Erst einmal wieder ein großes Dankeschön fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme, auch die Abfrage der Werte per Influx läuftDann generell:
Ich habe jetzt nochmal ein paar Tests zur Performance der InfluxDB V2 durchgeführt.- Auf der Influx DB Web UI habe ich im Data Explorer mal 60 Measurements markiert, die letzten 30 Tage abgefragt und das Ergebnis als Simple Table angezeigt. Der Query hat 0,1 Sekunden gedauert
- Ich habe das neue Grafana Dashboard importiert, das hat etwas gedauert, weil erstens die Änderung der Variablen bei mir nichts bewirkt hat (habs dann vorm Import in der json angepasst) und dann standen bei vielen Queries noch nicht die Variablen drin, was dann mit einem Suchen/Ersetzen in der json Datei erledigt wurde :wink: . Auf jeden Fall läd das neue Dashboard, das die Daten über die neue Data Source per Flux Sprache und Token abfragt, auch sehr schnell.
Es sieht also tatsächlich so aus, dass nur der Influx Adapter im iobroker beim Auslesen größerer Datenmengen zumindest bei mir Probleme macht.
Falls jemand mal Lust hat, bitte folgendes Script im iobroker anlegen, ggf. Influx Instanz / Bucket Namen anpassen und ausführen:sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h)', function (result) { if (result.error) { console.error(result.error); } else { // show result //console.log('Rows: ' + JSON.stringify(result)); console.log('fertig'); } });Das Skript fragt einfach mal die Werte aller Measurements der letzten 24 Stunden ab.
Danach mal ins iobroker Protokoll gehen und checken wie viel Zeit zwischen dem Skriptstart und der "fertig" Meldung vergangen ist. Bei mir hat das ca. 35 Sekunden gedauert :expressionless:
Natürlich ist es schwierig das zu vergleichen, weil das sehr davon abhängt wie viele Measurements man hat und wie viele Werte darin gespeichert sind. Ich habe aktuell um die 150 Measurements in der DB.
Eine Tendenz sollte aber trotzdem sichtbar sein und es würde mich interessieren, ob nur ich ein Problem damit habe oder ob das generell am Adapter liegt.
Danke schon mal im Voraus.Mir ist das Ganze auch nur aufgefallen, weil ich auch den ECharts Adapter zum Anzeigen von Graphen nutze und der zieht die Daten eben aus der Historie über den Influx Adapter des iobrokers.
Das Laden der Graphen dauert im V2 Modus des Influx Adapters nun deutlich länger als im V1 Modus (Ich kann noch den V1 Modus nutzen, weil ich die User aus v1 mit migriert habe, die dann weiterhin per Basic Auth und InfluxQL abfragen können). Ich habe mehrmals zwischen beiden Modi gewechselt und es ist reproduzierbar.@viper4iob
Kann Deine Erfahrung mit V2 nur bestätigen - eCharts wird zur lahmen, unbrauchbaren Krücke.....
Ob es jetzt am Influx, eCharts oder dem Influx-Adapter liegt kann ich nicht sagen.Konkret: hab Influx auf einem extra Container laufen, bei einer eCharts Abfrage von 4 Messreihen der letzten 24h geht die CPU-Last vom Influx auf 150%, wenn man Glück hat erscheint mal eine Messreihe.... Wenn man dann noch Auto-Update eingeschaltet hat, ist's vorbei mit der Analyse von Charts.....
Die Anzahl der measuremenst dürfte ja keinen Einfluss haben. Mit V1 geht's qasi auch 'in Echtzeit'.
-
Hallo
Das Skript läuft auf einem Rasberry 4.
Bis Vorgestern lief alles wunderbar, dann habe ich probiert ein update zu machen.
Jetzt kommen keine Daten mehr rein../wetterstation.sh --debug
passierte folgendes:
DATA von Wetterstation: Debug VAR: Installationsverzeichnis: /home/pi/wetterstation IPP: 192.168.10.13:8087 WS_PORT: 1080 WS_POLL: 30 PRE_DP: 0_userdata.0.Wetterstation WEB: HTTP WS_PROT: Wunderground Zusatzsensoren: DP10/35/40/50/60/70/100/200/250/300: 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 WH31: 0 || WS90: 0 Script-Version: V2.21.0 Config-Version: V2.21.0 Sub-Version: V2.21.0 Kommunikationsfehler! Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein? pi@raspberrypi:~/wetterstation $Also habe ich alles deinstalliert und nochmal von vorn.
Bei der Anleitung ist mir aufgefallen das bei dem Befehl
chmod +x ws_updater
"Datei nicht gefunden kam. Ich habe dann ein .sh eingefügt und dann war die Meldung weg.
Ob das richtig war weiß ich nicht genau, aber für mich war es logisch.Die drei Dateien wurden dann automatisch in das Verzeichnis kopiert.
Installation ausgeführt.
Wetterstation.conf angepasst und per WinSCP rüberkopiert.Dann kam wieder die gleiche Fehlermeldung siehe oben.
Bei der Statusüberprüfung kommt das:
wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; vendor preset: enabl Active: active (running) since Fri 2023-03-03 12:10:51 CET; 16s ago Main PID: 10398 (wetterstation.s) Tasks: 3 (limit: 4915) CGroup: /system.slice/wetterstation.service |-10398 /bin/bash /home/pi/wetterstation/wetterstation.sh |-14592 /bin/bash /home/pi/wetterstation/wetterstation.sh `-14595 Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error ~ ~ ~ lines 1-20/20 (END)Kann mir jemand helfen oder habe ich irgendwas vergessen?
Gruß -
@viper4iob
@Latzi
Na dann
12:38:16.606 info javascript.0 (3146202) script.js.common.test_influx: Fertig! Rows: 137548 Dauer: 3061 ms -
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Und hier bei Default Bucket dann influx-1w eintragen.
Jepp, das ist dann die Zuweisung "nimm für die Datenquelle dieses Bucket"
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Jepp, das ist dann die Zuweisung "nimm für die Datenquelle dieses Bucket"
Servus
Hab jetzt eine 2. Datasource mit den temp. Buckets angelegt.
Standard
Temp
Beim Import des Dashboard beim Konfig Dialog hab ich dann die passenden DS ausgewählt.
Allerdings holt er sich keine Daten, da das Bucket nicht übernommen wird.
Query schaut zB so aus:
from(bucket: "TempData") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Wetterstation.Info.Wolkenbasis") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false) |> yield(name: "Wolkenbasis")
Ändere ich im Query das Bucket
TempDatainiobroker-1wwerden die Daten angezeigt.from(bucket: "iobroker-1w") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Wetterstation.Info.Wolkenbasis") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false) |> yield(name: "Wolkenbasis")
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
@SBorg
Erst einmal wieder ein großes Dankeschön fürs updaten des Wetterstations-Skripts, funktioniert soweit ohne Probleme, auch die Abfrage der Werte per Influx läuftDann generell:
Ich habe jetzt nochmal ein paar Tests zur Performance der InfluxDB V2 durchgeführt.- Auf der Influx DB Web UI habe ich im Data Explorer mal 60 Measurements markiert, die letzten 30 Tage abgefragt und das Ergebnis als Simple Table angezeigt. Der Query hat 0,1 Sekunden gedauert
- Ich habe das neue Grafana Dashboard importiert, das hat etwas gedauert, weil erstens die Änderung der Variablen bei mir nichts bewirkt hat (habs dann vorm Import in der json angepasst) und dann standen bei vielen Queries noch nicht die Variablen drin, was dann mit einem Suchen/Ersetzen in der json Datei erledigt wurde :wink: . Auf jeden Fall läd das neue Dashboard, das die Daten über die neue Data Source per Flux Sprache und Token abfragt, auch sehr schnell.
Es sieht also tatsächlich so aus, dass nur der Influx Adapter im iobroker beim Auslesen größerer Datenmengen zumindest bei mir Probleme macht.
Falls jemand mal Lust hat, bitte folgendes Script im iobroker anlegen, ggf. Influx Instanz / Bucket Namen anpassen und ausführen:sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h)', function (result) { if (result.error) { console.error(result.error); } else { // show result //console.log('Rows: ' + JSON.stringify(result)); console.log('fertig'); } });Das Skript fragt einfach mal die Werte aller Measurements der letzten 24 Stunden ab.
Danach mal ins iobroker Protokoll gehen und checken wie viel Zeit zwischen dem Skriptstart und der "fertig" Meldung vergangen ist. Bei mir hat das ca. 35 Sekunden gedauert :expressionless:
Natürlich ist es schwierig das zu vergleichen, weil das sehr davon abhängt wie viele Measurements man hat und wie viele Werte darin gespeichert sind. Ich habe aktuell um die 150 Measurements in der DB.
Eine Tendenz sollte aber trotzdem sichtbar sein und es würde mich interessieren, ob nur ich ein Problem damit habe oder ob das generell am Adapter liegt.
Danke schon mal im Voraus.Mir ist das Ganze auch nur aufgefallen, weil ich auch den ECharts Adapter zum Anzeigen von Graphen nutze und der zieht die Daten eben aus der Historie über den Influx Adapter des iobrokers.
Das Laden der Graphen dauert im V2 Modus des Influx Adapters nun deutlich länger als im V1 Modus (Ich kann noch den V1 Modus nutzen, weil ich die User aus v1 mit migriert habe, die dann weiterhin per Basic Auth und InfluxQL abfragen können). Ich habe mehrmals zwischen beiden Modi gewechselt und es ist reproduzierbar.javascript.0 2023-03-04 07:48:35.120 info script.js.common.1_1_Test: fertig javascript.0 2023-03-04 07:48:35.119 info script.js.common.1_1_Test: Rows: 2944 javascript.0 2023-03-04 07:48:34.990 info script.js.common.1_1_Test: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptionsAbfrage dazu war:
sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { // show result console.log('Rows: ' + JSON.stringify(result.result[0].length)); console.log('fertig'); } }); -
javascript.0 2023-03-04 07:48:35.120 info script.js.common.1_1_Test: fertig javascript.0 2023-03-04 07:48:35.119 info script.js.common.1_1_Test: Rows: 2944 javascript.0 2023-03-04 07:48:34.990 info script.js.common.1_1_Test: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptionsAbfrage dazu war:
sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { // show result console.log('Rows: ' + JSON.stringify(result.result[0].length)); console.log('fertig'); } }); -
@latzi
Interessant wäre auch die Startzeit des Skripts, dass man sieht wie lange es bis zum fertig dauerte ;)@boronsbruder
Zeit von Zeile 2 - Zeile 3 ;-)Edit: geht auch so:
let Startzeit = new Date(); sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { let Endezeit = new Date(); // show result console.log('Fertig! Rows: ' + JSON.stringify(result.result[0].length) +' Dauer: ' + (Endezeit.getTime()-Startzeit.getTime()) + ' ms'); } });Liefert dann:
10:16:04.177 info javascript.0 (2815519) script.js.common.1_1_Test: Fertig! Rows: 2924 Dauer: 149 ms -
@boronsbruder
Zeit von Zeile 2 - Zeile 3 ;-)Edit: geht auch so:
let Startzeit = new Date(); sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { let Endezeit = new Date(); // show result console.log('Fertig! Rows: ' + JSON.stringify(result.result[0].length) +' Dauer: ' + (Endezeit.getTime()-Startzeit.getTime()) + ' ms'); } });Liefert dann:
10:16:04.177 info javascript.0 (2815519) script.js.common.1_1_Test: Fertig! Rows: 2924 Dauer: 149 ms@viper4iob
@latzi
Na dann:
12:38:16.606 info javascript.0 (3146202) script.js.common.test_influx: Fertig! Rows: 137548 Dauer: 3061 ms -
@boronsbruder
Zeit von Zeile 2 - Zeile 3 ;-)Edit: geht auch so:
let Startzeit = new Date(); sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { let Endezeit = new Date(); // show result console.log('Fertig! Rows: ' + JSON.stringify(result.result[0].length) +' Dauer: ' + (Endezeit.getTime()-Startzeit.getTime()) + ' ms'); } });Liefert dann:
10:16:04.177 info javascript.0 (2815519) script.js.common.1_1_Test: Fertig! Rows: 2924 Dauer: 149 ms@latzi sagte in [Linux Shell-Skript] WLAN-Wetterstation:
let Startzeit = new Date(); sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { let Endezeit = new Date(); // show result console.log('Fertig! Rows: ' + JSON.stringify(result.result[0].length) +' Dauer: ' + (Endezeit.getTime()-Startzeit.getTime()) + ' ms'); } });Ich habe den Test nun auch gestartet. Influxdb läuft als Docker auf der Sinologie DS920+
2023-03-04 13:18:44.732 info Stop script script.js.TEST.Test_Performance_Influxdb javascript.0 2023-03-04 13:18:40.244 info script.js.TEST.Test_Performance_Influxdb: Fertig! Rows: 7228 Dauer: 200 ms javascript.0 2023-03-04 13:18:40.044 info script.js.TEST.Test_Performance_Influxdb: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions javascript.0 2023-03-04 13:18:40.035 info Start javascript script.js.TEST.Test_Performance_Influxdb -
@boronsbruder
Zeit von Zeile 2 - Zeile 3 ;-)Edit: geht auch so:
let Startzeit = new Date(); sendTo('influxdb.0', 'query', 'from(bucket: "iobroker") |> range(start: -24h) |> filter(fn: (r) => r._measurement == "0_userdata.0.Wetterstation.Aussentemperatur")', function (result) { if (result.error) { console.error(result.error); } else { let Endezeit = new Date(); // show result console.log('Fertig! Rows: ' + JSON.stringify(result.result[0].length) +' Dauer: ' + (Endezeit.getTime()-Startzeit.getTime()) + ' ms'); } });Liefert dann:
10:16:04.177 info javascript.0 (2815519) script.js.common.1_1_Test: Fertig! Rows: 2924 Dauer: 149 msHier sieht das so aus:
javascript.0 (3488667) script.js.common.Test.Influxtestv2: Fertig! Rows: 52 Dauer: 16 ms -
wo holst du dir die Daten von
0_userdata.0.VIS.Wetter.Regenvorschauher?
wie sehen bei dir die Alias aus (
truewird1,falsewird0), bzw. wie wandle ich mit einem Alias true in 0, usw.?
° Node.js: 20.17.0 NPM: 10.8.2
° Proxmox, Ubuntu 22.04.3 LTS
° Fixer ---> iob fix -
Hier sieht das so aus:
javascript.0 (3488667) script.js.common.Test.Influxtestv2: Fertig! Rows: 52 Dauer: 16 ms@ilovegym sagte in [Linux Shell-Skript] WLAN-Wetterstation:
javascript.0 (3488667) script.js.common.Test.Influxtestv2: Fertig! Rows: 52 Dauer: 16 ms
@viper4iob wie sieht´s bei dir mit dieser Abfrage aus?
-
Hallo
Das Skript läuft auf einem Rasberry 4.
Bis Vorgestern lief alles wunderbar, dann habe ich probiert ein update zu machen.
Jetzt kommen keine Daten mehr rein../wetterstation.sh --debug
passierte folgendes:
DATA von Wetterstation: Debug VAR: Installationsverzeichnis: /home/pi/wetterstation IPP: 192.168.10.13:8087 WS_PORT: 1080 WS_POLL: 30 PRE_DP: 0_userdata.0.Wetterstation WEB: HTTP WS_PROT: Wunderground Zusatzsensoren: DP10/35/40/50/60/70/100/200/250/300: 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 WH31: 0 || WS90: 0 Script-Version: V2.21.0 Config-Version: V2.21.0 Sub-Version: V2.21.0 Kommunikationsfehler! Kommunikationsfehler! Stimmt die WS_ID in der Konfiguration mit der der WS View-App überein? pi@raspberrypi:~/wetterstation $Also habe ich alles deinstalliert und nochmal von vorn.
Bei der Anleitung ist mir aufgefallen das bei dem Befehl
chmod +x ws_updater
"Datei nicht gefunden kam. Ich habe dann ein .sh eingefügt und dann war die Meldung weg.
Ob das richtig war weiß ich nicht genau, aber für mich war es logisch.Die drei Dateien wurden dann automatisch in das Verzeichnis kopiert.
Installation ausgeführt.
Wetterstation.conf angepasst und per WinSCP rüberkopiert.Dann kam wieder die gleiche Fehlermeldung siehe oben.
Bei der Statusüberprüfung kommt das:
wetterstation.service - Service für ioBroker Wetterstation Loaded: loaded (/etc/systemd/system/wetterstation.service; enabled; vendor preset: enabl Active: active (running) since Fri 2023-03-03 12:10:51 CET; 16s ago Main PID: 10398 (wetterstation.s) Tasks: 3 (limit: 4915) CGroup: /system.slice/wetterstation.service |-10398 /bin/bash /home/pi/wetterstation/wetterstation.sh |-14592 /bin/bash /home/pi/wetterstation/wetterstation.sh `-14595 Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error Mär 03 12:11:07 raspberrypi wetterstation.sh[10398]: (standard_in) 1: syntax error ~ ~ ~ lines 1-20/20 (END)Kann mir jemand helfen oder habe ich irgendwas vergessen?
Gruß@g-hawk Da funktioniert die Verbindung "Display/Gateway" zum "Rechner auf dem das Skript läuft" nicht korrekt.
Die IP in der WS-View[+]-App ist korrekt?
Du nutzt "Wunderground" als Format, da ist auch der Stationsname wichtig (APP wie auch in der *.conf. Müssen beide identisch sein [case sensitiv]): -
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Jepp, das ist dann die Zuweisung "nimm für die Datenquelle dieses Bucket"
Servus
Hab jetzt eine 2. Datasource mit den temp. Buckets angelegt.
Standard
Temp
Beim Import des Dashboard beim Konfig Dialog hab ich dann die passenden DS ausgewählt.
Allerdings holt er sich keine Daten, da das Bucket nicht übernommen wird.
Query schaut zB so aus:
from(bucket: "TempData") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Wetterstation.Info.Wolkenbasis") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false) |> yield(name: "Wolkenbasis")Ändere ich im Query das Bucket
TempDatainiobroker-1wwerden die Daten angezeigt.from(bucket: "iobroker-1w") |> range(start: v.timeRangeStart, stop: v.timeRangeStop) |> filter(fn: (r) => r["_measurement"] == "0_userdata.0.Wetterstation.Info.Wolkenbasis") |> filter(fn: (r) => r["_field"] == "value") |> aggregateWindow(every: v.windowPeriod, fn: last, createEmpty: false) |> yield(name: "Wolkenbasis")@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Beim Import des Dashboard beim Konfig Dialog hab ich dann die passenden DS ausgewählt.
Allerdings holt er sich keine Daten, da das Bucket nicht übernommen wird.Das war/ist auch soweit alles korrekt. Mit der ganz neuen Grafana-Version habe ich es noch nicht probiert (es kamen die Tage drei Updates), aber ich glaube da hat sich diesbzgl. ein Bug eingeschlichen. Als ich es exportiert habe ging es noch. Dann hatte ich plötzlich ein ähnliches Problem. Nach einer Änderung im Widget konnte ich partout keine Werte auswählen.
Erst nach einem Klick auf "Apply" und erneutem laden des Widget war dies möglich. -
wo holst du dir die Daten von
0_userdata.0.VIS.Wetter.Regenvorschauher?
wie sehen bei dir die Alias aus (
truewird1,falsewird0), bzw. wie wandle ich mit einem Alias true in 0, usw.?
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
wie sehen bei dir die Alias aus (true wird 1, false wird 0), bzw. wie wandle ich mit einem Alias true in 0, usw.?
Ganz, ganz schwerer Voodoo :joy:
val ? 1 : 0
wo holst du dir die Daten von 0_userdata.0.VIS.Wetter.Regenvorschauher?
Aus dem Weatherunderground-Adapter mittels Skript:
/* Wunderground Regen Abfrage des Weatherunderground Adapters im Bereich Vorhersage, wann der nächste Regen erwartet wird. Findet in den forecastHourly-Datenpunkt den ersten Regen-Eintrag Ausgabe in Text ("kein Regen", "X Stunden (X% [Wahrscheinlichkeit])") http://forum.iobroker.net/viewtopic.php?f=21&t=3447#p31858 01.08.2016 erstellt von Pix unter Nutzung des obigen Skriptes 28.06.2017 Korrekturen 12.07.2017 Fehler abfangen und Typ Variable auf String geändert 06.03.2019 Code optimiert berücksichtigt Niederschlag in der aktuellen Stunde (Stunde 0) 11.06.2019 auf neue Datenpunkte angepasst für weatherground-Adapter (getestet V3.0.11) 04.08.2019 geändert für Wunderground Adapter 3.1.1 08.03.2021 Codeoptimierungen @SBorg */ const vorstd = 36; // Vorschau in Stunden (Weatherunderground bietet neuerdings bis 36h Vorschau), kann hier auch kleiner sein const idRegen = "0_userdata.0.VIS.Wetter.Regenvorschau"; // Ziel-Datenpunkt const wunder_inst = "weatherunderground.0."; // Weatherground-Adapter Instanz const logging = false; createState(idRegen, "kein Regen", { name: "Regenvorschau", type: "string", role: "text" }); function berechneZeit() { if (logging) log("Berechne Dauer in Stunden bis zum nächsten Regen"); let data=0, pop=0; for (let i=0; i<vorstd; i++) { data = getState(wunder_inst + "forecastHourly." + i + "h.precipitation").val; if (data > 0) { pop = getState(wunder_inst + "forecastHourly." + i + "h.precipitationChance").val; if (logging) log("Regeneintrag gefunden bei " + i + "h " + data + "mm"); if (i == 0) { // wenn jetzt Regen if (logging) log("In dieser Stunde werden " + data + "mm Regen erwartet (Wahrscheinlichkeit " + pop + "%)"); setState(idRegen, "jetzt (" + pop + "%)", true); } else { if (logging) log("In " + i + " Stunden werden " + data + "mm Regen erwartet (Wahrscheinlichkeit " + pop + "%)"); if (i==1) { setState(idRegen, "1 Stunde (" + pop + "%)", true); } else { setState(idRegen, i + " Stunden (" + pop + "%)", true); } } i=vorstd-1; // beim ersten Auftreten der Regenwahrscheinlichkeit über 0 abbrechen } if ((i == vorstd-1) && (pop == 0)) { setState(idRegen, "Kein Regen erwartet (" + pop + "%)", true); if (logging) log("Kein Regen erwartet (" + pop + "%)"); } } } // bei jeglicher Aktualisierung von Weatherunderground Berechnung starten on({ id: /^weatherunderground\.[0-9]+\.forecast.*\.[0-9]+h\.precipitation$/, // forecastHourly, forecastDaily, forecast change: "any" }, berechneZeit); // bei Skriptstart berechneZeit();
Support us
811
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge