[Linux Shell-Skript] WLAN-Wetterstation
-
Neue Beta-Version des Wetterstation WLAN-Skriptes auf GitHub V2.22.0
(Beta-Releases lassen sich nicht! über den ws_updater.sh installieren, nur die *.conf lässt sich mit dem ws_updater.beta ggf. patchen [s.u.])
- + Support für Bresser Thermo-Hygro-7Ch-Sensor #7009999 / Issue #53
Wie immer zu finden im GitHub
Update-Routine:
- wetterstation.sh, wetterstation.sub und ws_updater.beta (muss "ausführbar" sein
chmod +x ws_updater.beta) ersetzen bzw. kopieren - wetterstation.js muss ebenfalls im JavaScript-Adapter ersetzt und einmalig ausgeführt werden (nur nötig wenn man auch einen entsprechenden Sensor der Firma Bresser im Einsatz hat) (1)
./ws_updater.beta --patchim Installationsverzeichnis ausführen und ev. Hinweise beachten- nun mittels
[sudo] systemctl restart wetterstationden Service neu starten
(1) es empfiehlt sich danach den Simple-API-Adapter neu zu starten (entweder per WebIF oder einfach
iob restart simple-api.0)
Da es ein reines Funktions-Betarelease ist, ergibt der Einsatz dieser Version nur einen Vorteil wenn man auch Sensor/en der Firma Bresser nutzt. Trotzdem wäre ein Test nicht schlecht, da ich den Sensortyp nicht "einfach" hinzufügen konnte und weitere Änderungen vornehmen musste. Es könnte also durchaus sein, dass ich dabei eine andere Funktion oä. "gegrillt" habe (speziell Zusatz-Sensoren des Typs DP100)
-
Servus zusammen!
Bei mir läuft die Script Vers: 1.3.0
In den Objekten für Werte Vorjahres_Monat steht bei mir überall {"ack":true}
Aber erst seit heute. Die Januar Werte passten noch.
Wenn ich aber unter Data 02/2022 schau, steht da alles soweit gut drin:[{"Tiefstwert":-7.77,"Hoechstwert":15.77,"Temp_Durchschnitt":3.6,"Max_Windboe":47.96,"Max_Regenmenge":8.6,"Regenmenge_Monat":78.1,"warme_Tage":0,"Sommertage":0,"heisse_Tage":0,"Frost_Tage":44,"kalte_Tage":39,"Eistage":1,"sehr_kalte_Tage":0}]Läuft hier iwas falsch, oder werden de Werte erst heute Nacht richtig berechnet/übernommen?
-
@amiethaner sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Läuft hier iwas falsch, oder werden de Werte erst heute Nacht richtig berechnet/übernommen?
Ja und nein
Für die aktuellen Daten neues JS anlegen (Datenverzeichnis ggf. anpassen [Zeile #1]) und einmalig ausführen, dann sollten die Daten da sein:
const PRE_DP='0_userdata.0.Statistik.Wetter'; //Speicherort der Statistikdaten const monatsdatenpunkt='.Data.2022.02'; //.Data.Jahr.Monat let VorJahr = getState(PRE_DP+monatsdatenpunkt).val; VorJahr = JSON.parse(VorJahr.substring(1, VorJahr.length-1)); setState(PRE_DP+'.Vorjahres_Monat.Tiefstwert', VorJahr.Tiefstwert, true); setState(PRE_DP+'.Vorjahres_Monat.Hoechstwert', VorJahr.Hoechstwert, true); setState(PRE_DP+'.Vorjahres_Monat.Temperatur_Durchschnitt', VorJahr.Temp_Durchschnitt, true); setState(PRE_DP+'.Vorjahres_Monat.Max_Windboe', VorJahr.Max_Windboe, true); setState(PRE_DP+'.Vorjahres_Monat.Max_Regenmenge', VorJahr.Max_Regenmenge, true); setState(PRE_DP+'.Vorjahres_Monat.Regenmenge_Monat', VorJahr.Regenmenge_Monat, true); setState(PRE_DP+'.Vorjahres_Monat.warme_Tage', VorJahr.warme_Tage, true); setState(PRE_DP+'.Vorjahres_Monat.Sommertage', VorJahr.Sommertage, true); setState(PRE_DP+'.Vorjahres_Monat.heisse_Tage', VorJahr.heisse_Tage, true); setState(PRE_DP+'.Vorjahres_Monat.Frost_Tage', VorJahr.Frost_Tage, true); setState(PRE_DP+'.Vorjahres_Monat.kalte_Tage', VorJahr.kalte_Tage, true); setState(PRE_DP+'.Vorjahres_Monat.Eistage', VorJahr.Eistage, true); setState(PRE_DP+'.Vorjahres_Monat.sehr_kalte_Tage', VorJahr.sehr_kalte_Tage, true); setState(PRE_DP + '.Vorjahres_Monat.Wuestentage', VorJahr.Wuestentage, true); setState(PRE_DP + '.Vorjahres_Monat.Tropennaechte', VorJahr.Tropennaechte, true); setState(PRE_DP + '.Vorjahres_Monat.Regentage', VorJahr.Regentage, true);Wenn das funktioniert hat die V1.3.1 von GitHub laden und nutzen.
btw.: das müsste jeden betreffen, genereller Fehler
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Jop, ging, nur Regentage, Tropennächte und Wüstentage ned. Aber die wurden da bei mir noch ned aufgezeichnet. Hab die letzten Tage erst von ner alten Version geupdated
-
1.2.2023, 18:37:33.611 [info ]: javascript.0 (12957) Start javascript script.js.common.wetter.fix 1.2.2023, 18:37:33.628 [info ]: javascript.0 (12957) script.js.common.wetter.fix: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions 1.2.2023, 18:37:33.634 [error]: javascript.0 (12957) script.js.common.wetter.fix: TypeError: VorJahr.substring is not a function 1.2.2023, 18:37:33.634 [error]: javascript.0 (12957) at script.js.common.wetter.fix:11:38 1.2.2023, 18:37:33.635 [error]: javascript.0 (12957) at script.js.common.wetter.fix:47:3 1.2.2023, 18:39:44.297 [info ]: javascript.0 (12957) Stop script script.js.common.wetter.fixconst PRE_DP='0_userdata.0.Statistik.Wetter'; //Speicherort der Statistikdaten const monatsdatenpunkt='.Data.2022.02'; //.Data.Jahr.Monat let VorJahr = getState(PRE_DP+monatsdatenpunkt).val; console.log (VorJahr); // Daten vom Vorjahr durchiterieren und Datenpunkte befüllen VorJahr.forEach(obj => { Object.keys(obj).forEach(key => { // fix für Datenpunktname let setkey = key; if (key == 'Temp_Durchschnitt') setkey = "Temperatur_Durchschnitt"; setState(PRE_DP+'.Vorjahres_Monat.' +setkey, obj[key], true); }); });So übernimmt er alle im Vorjahr vorhandenen Daten (also keine Tropentage usw. wenn diese noch nicht gesetzt waren).
Falls dir das hilft, darfst du es gerne verwenden
Edit: Sorry, für die vielen Edits bin zu blöd für Copy und Paste
-
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Falls dir das hilft, darfst du es gerne verwenden
Edit: Sorry, für die vielen Edits bin zu blöd für Copy und PasteIm Grunde schon, aber mittlerweile bin ich der Meinung, dass es nicht die beste Idee ist/war mit unterschiedlichen JSONs "rumzuhampeln". Jetzt fällt es uns schon auf die Füße, beim nächsten mal wieder...
Wenn du kannst/magst, mach doch bitte einen Patch der über die "Data"-JSONs iteriert und ggf. die fehlenden GradTage dem JSON hinzufügt. Dann braucht es bei der nächsten Änderung auch keinen Patch mehr, bzw. wenn/falls ein neuer Wert hinzukommt kann man dann alle auf eine gleiche Syntax bringen. Ev. den Wert als User-Parameter, dann kann sich jeder das eintragen was er will, um zu sehen was keinen echten Wert darstellt. Oder wir nehmen pauschal einfach -1, denn bspw. -1 Wüstentage gibt es wohl nicht......und mir haut die Board-Software auch so gelegentlich Zeichen hin wo sie nicht sein sollten
-
Dann mal was an alle (oder den harten Kern
) :Seid ihr mit InfluxDB V1 "fest verheiratet"? Es gelingt mir nicht ohne größeres hängen und würgen alles auf V1 + V2 lauffähig zu bekommen. Irgendetwas geht immer nicht
...und offen gestanden habe ich so nun auch keinen Bock mehr dazu...
Die Konsequenz wäre eine neue V3.x des Skriptes, die nicht mehr mit Influx V1 kompatibel wäre (+ich für V2.x des Skriptes nichts mehr weiter entwickeln würde. Neuerungen gebe es dann nur noch in der 3er). Im Grunde müsste ich sogar direkt in die InfluxDB schreiben, da der Influx-Adapter es leider so macht, wie man es seitens Influx eigentlich nicht machen soll.
Der Datenpunkt heißt so wie der gesamte Pfad, also bspw. javascript.0.Wetterstation.Aussentemperatur
lt. Influx sollte er aber getagged sein, also zB. in der Art: "Temperatur Ort=Aussen (oder Wetterstation oä.) usw." Dann kann man relativ einfach alles per Tags zusammenfassen ("alle Gradtage vom März 2022" oder "alle Wüstentage seit 2019"). Das ist so aktuell nicht möglich da keine Tags verwendet werden und jeder GradTag eine eigene Messwertereihe ist. -
@sborg
Ich würde den Schritt begrüßen. Ich setze seit mehr als einem Jahr Influxdb V2 ein und muss beispielsweise die Statistik-Scripte umändern. -
@sborg
Ich würde ab Version 3.x nur noch influx v2 unterstützen, das ist die Zukunft und solange das script v2.x noch läuft ist ja für alle noch okay.Bin auch gerade dabei meine ganzen grafana views auf influx v2 ( Flux) umzustellen..
Hab sonst nur noch den unipoller der die v1 nutzt und dein Script..
-
@sborg Ich wäre auch für eine Version V3.x mit direktem Schreiben incl. Tagging. in die Influx 2.x. Ich müsste dann nur mal schauen, wie ich die alten Daten mit rüberbekäme. Hat dazu jemand einen Tip oder Vorgehensweise?
-
@sborg
lebe schon seit längerer Zeit mit influx V2 zusammen, nachdem ich mich von influx V1 getrennt habe -
@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 WochenendeZum Thema InfluxV2 schließe ich mich Rene55 an:
Wenn ich die Daten irgendwie rüberbekomme...Öftermal was Neues
-
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. -
@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?
-
@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
-
@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. -
zB.: eine Zeile, Breakets [] weglassen
influx -database [name] -username [nutzername] -password [geheim] -execute 'SELECT * FROM "javascript.0.Wetterstation.Aussentemperatur"' -format csv > Aussentemperatur.csv -
@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. -
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. -
@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"'
