[Linux Shell-Skript] WLAN-Wetterstation

[Boronsbruder]

@sborg
Da er Skriptteil nur die passenden DP's befüllt, ist das, denke ich, unproblematisch.
Du mussst nur nicht mehr in deinem Skript die Vorjahresroutine jedesmal erweitern, weil er den JSON selbst durch geht.

Ich habe gestern vor dem Fixen festgestellt, dass bei mir noch eine der 1.1er Version des Statistik-Skripts lief...

Deswegen konnte ich aber einfach nachprüfen, wie das Skript auf einen zusätzlichen JSON-Eintrag reagiert:

• In den JSON von 02.2022 "Wuestentage":-1 eingefügt
• Resultat: der Datenpunkt Vorjahres_Monat.Wuestentage wurde ordnungsgemäß mit -1 befüllt:
  

Also kannst du noch VIIIIEEEEEL in deinen JSON reinpacken, wenn der passende DP angelegt ist, wird er brav befüllt.

Wenn ich rausfinde, wie ich nen Patch anlege, dann werde ich das machen Aber wahrscheinlich erst am Wochenende

Zum Thema InfluxV2 schließe ich mich Rene55 an:
Wenn ich die Daten irgendwie rüberbekomme...

Öftermal was Neues

[tritor]

@sborg

Ich bin seit geraumer Zeit auf influxDB2 und logge halt jeden einzelnen für mich wichtigen DP.
Wenn das Script das dann kann, wäre natürlich besser. Also meine Stimme für V3.x mit InfluxDB2 hast du.

[amiethaner]

@SBorg Mit der von dir gewohnten guten Doku sollte V2 schon gehen denk ich.

Aber ne andere Frage noch. Seit ich mit allem wieder aktuell bin, bekomm ich bei den Regenmengen immer Werte bis 3 oder gar 4 stellen hinterm Komma. So genau will ich des ja garned. Wie bekomm ich denn da wieder ne Rundung rein?

[SBorg]

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

Wenn ich rausfinde, wie ich nen Patch anlege, dann werde ich das machen

Danke, brauchst du nicht mehr --> ist jetzt in der V1.3.2 drin

[SBorg]

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

Aber ne andere Frage noch. Seit ich mit allem wieder aktuell bin, bekomm ich bei den Regenmengen immer Werte bis 3 oder gar 4 stellen hinterm Komma. So genau will ich des ja garned. Wie bekomm ich denn da wieder ne Rundung rein?

Das ist eigentlich schon seit Anfang an auf 3 Nachkommastellen "gerundet". Gerundet deswegen, weil die Umrechnung von Inch der Station auf "mm" eben krumme Werte ergibt. Schneidet man da aber zu viel ab, stimmt mit fortschreitendem Jahr die "kumulierte Regenmenge" nicht mehr, da sich die fehlenden Nachkommastellen dann zu einer sichtbaren Differenz aufsummieren.
Aber wo stört es denn (nicht ironisch gefragt)? In der VIS kannst du die Stellen begrenzen (+ er rundet dann auch automatisch), in Grafana ebenfalls und bei ECharts & Co geht es IMO ebenfalls.

[SBorg]

@Rene55

zB.: eine Zeile, Breakets [] weglassen
influx -database [name] -username [nutzername] -password [geheim] -execute 'SELECT * FROM "javascript.0.Wetterstation.Aussentemperatur"' -format csv > Aussentemperatur.csv

[Rene55]

@sborg Danke für die Hilfestellung. Daran arbeite ich (in verschiedenen Abwandlungen) schon den halben Vormittag. Ich bekomme immer den gleichen Fehler :error parsing query: found influx, expected SELECT, DELETE, SHOW, CREATE, DROP, EXPLAIN, GRANT, REVOKE, ALTER, SET, KILL at line 1, char 1.
Aber vielleicht gehe ich auch falsch vor. Meine InfluxDB läuft in einem Container. Via Portainer komme ich auf die bash. Hier kann ich mich anmelden und mir am Bildschirm die Inhalte der einzelnen Tabellen anschauen. Weiter komm ich nicht.

[SBorg]

Es braucht keiner Panik schieben das er abgehängt wird oder etwas nicht funktioniert.

Der Master-Plan sieht eine V3.0.0 vor, die keine neuen Funktionen hat sondern lediglich InfluxDB V2 supported. Da aktuell auch nix auf meiner Agenda steht wird es auch noch eine gewisse Zeit dauern bis zu einer weiteren Version.

Die Migration von Influx V1 --> V2 ist nicht soo schwer (schaut mal bei YT nach EddyD Smarthome; er hat dazu ein gutes Tut gemacht).
Lasst euch vor allen Dingen Zeit und überstürzt nichts. Der Aufbau der V2 will wohl überlegt sein (Stichwort buckets + retention policy).

Bei mir läuft aktuell beides parallel:

Ob ich ohne Influx-Adapter in die DB schreibe weiß ich noch nicht. Einteils weiß ich nicht ob ich mir das antun will, andern teils ist es so aber einfach nicht richtig:

Gerade wo man schon im Vorfeld schön mittels der Tags filtern kann...

---

Ich habe jetzt mal auf meine Synology ausgelagert, die hat eh nichts zu tun:

Dabei werde ich nicht portieren, sondern nur das maßgebliche exportieren und in verschiedene Buckets importieren. Da hat sich in den letzten Jahren einfach zu viel "Müll" angesammelt.

[SBorg]

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

expected SELECT,...

Sieht mir so aus als hättest du nur "" benutzt? Da haben wir nämlich schon den "Mist", dass Punkte im Measurement eigentlich nicht erlaubt sind: Adaptername.Instanz.bla.blupp.hastenichgesehen
Deswegen das Konstrukt mittels Ticks und Anführungszeichen 'SELECT * FROM "javascript.0.Wetterstation.Aussentemperatur"'

[Rene55]

@sborg Nee leider nicht. Ich hab mich ziemlich an das Beispiel gehalten. Ich hab auch ein Measurement ohne Punkte (Alias) - gleiches Ergebnis.
Dann habe ich nochmal select * from "0_userdata.0.Wetterstation.Aussentemperatur" versucht. Sobald ich aber die Bildschirmausgabe in eine Datei umleiten will, gibt es den Fehler "ERR: error parsing query: found >, expected ; at line 1, char 61".

[wendy2702]

Habe das Proxmox / Influx geschwätz mal abgetrennt und nach hier gepackt:

https://forum.iobroker.net/topic/62656/proxmox-influxdb-v1-zu-v2-wie

[Beowolf]

Ich muß mal einfach fragen. Gibt es "die" Wetterstation die empfehlenswert ist?

Grüße
Manfred

[amiethaner]

@sborg sorry, ich bin selber blöd. Klar ich kanns in der Vis ja kürzen wie ichs brauch

[SBorg]

@beowolf "die" ist schwierig, da jeder andere Erwartungen/Vorstellungen hat was er damit umsetzen möchte.

Ich bin kein Meteorologe, von daher kann ich mit Ungenauigkeiten der Heim-Stationen leben (sonst muss ich halt zB. Davis oä. nutzen). Die Toleranzen sind gering, aber halt vorhanden. Wenn meine Station 15°C (oder Windgeschwindigkeit, Regenmenge usw.) anzeigt kann ich damit leben, dass das in echt 14.5 - 15.5°C sein können. Das genügt trotzdem, um Informationen zum steuern vom SmartHome zu erlangen.

Deswegen den "Standard-Wettermast" (oder wenn es ohne bewegliche Teile sein soll den "Wittboy") und ein Display was einem optisch zusagt. Anstelle, oder zusätzlich, zum Display kann man auch ein Gateway nutzen. Das Gateway ist dann eh nötig wenn man Zusatzsensoren (siehe 1. Post was es da so alles gibt bzw. derzeit unterstützt wird) nutzen möchte.

Am flexibelsten ist man da eigentlich mit Froggit oder Ecowitt. Die können viele Protokolle und funktionieren ohne weitere Klimmzüge wie bspw. die von Bresser.

[SBorg]

@amiethaner Kein Problem, "Brett vorm Kopf" = mit der nackten Stirn dagegen hämmern

Kenne ich nur zu gut. Eine Lösung zu suchen für ein Problem was es gar nicht gibt. Hätte ja aber auch ein "echtes" Problemchen sein können. Also Lösung haben wir, suchen wir jetzt ein passendes Problem dazu...

Manchmal denkt man einfach zu kompliziert.

[SBorg]

@banza Kurze Nachfrage: ich sehe in meiner Übersicht ein Upvote, im Beitrag nun einen Downvote.

Soll heißen "für" oder "gegen" eine InfluxDB V2 - Unterstützung?

[Rushmed]

@sborg Hallo, keine Ahnung wo ich voten muss aber ich bin für eine V2 Unterstützung.

[da_Woody]

@beowolf nuja:
Bisher getestete Stationen:

BRESSER®
    WLAN Farb-Wetter Center mit 5-in-1 Profi-Sensor V (*)
    WLAN Comfort Wetterstation mit 7-in-1 Profi-Sensor (*)
ChiliTec Funk Wetterstation 12in1
DNT Weatherscreen PRO
ELV WS980WiFi
Eurochron EFWS 2900 (baugleich zu Sainlogic 10in1 Wifi, Ambient Weather WS-2902, Chilitec CTW-902 Wifi)
Froggit
    Gateway/USB-Dongle DP1500
    HP1000SE Pro
    WH3000 SE
    WH4000 SE
    WH6000 Pro
Renkforce WH2600
Sainlogic
    7in1 WiFi WS3500
    Profi Wlan Wetterstation FT0300 (*)
Ventus W830

[SBorg]

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

@sborg Hallo, keine Ahnung wo ich voten muss aber ich bin für eine V2 Unterstützung.

Ein echtes Voting gibt es nicht, da man es nur im 1. Post machen kann, nicht mitten im Thread. Aber die bisherigen Meinungen sind alle , bis auf den einen in einem der letzten Posts.

---

Die V3.x mit InfluxDB V2 - Support ist eigentlich schon beschlossene Sache. Da es eh ein Breaking-Release wird, zieht es per Default auch gleich von "javascript.x...." nach "0_userdata,x...." um. Hat so nur Auswirkungen auf Neuinstallationen. Allerdings kann es halt später vorkommen, dass zB. irgendeine neue Default-Einstellung dann "0_userdata.0.blabla" lautet und diejenigen die bei "javascript..." bleiben, es dann halt auf "javascript.0.blabla" ändern müssen (zB. bei den beiden JS wird es dann eben 0_userdata... lauten).

...und nochmals: wer kein InfluxDB in Verbindung mit dem Shell-Skript nutzt, für den ändert sich überhaupt nichts. Die Anderen haben die Wahl, aber in absehbarer Zeit weder Vorteile noch Nachteile (außer ev. die generelle Retention-Policy für den bucket bei InfluxDB 2.x).

*EDIT* Ach ja, + kleinere Änderungen, irgendwo steht immer noch "Windboe" (als Wert, nicht als Text) --> "Windboee" ("ö" ist da leider nicht erlaubt ).

[banza]

@sborg sorry dafür, bin für InfluxDB V2 - Unterstützung