[Linux Shell-Skript] WLAN-Wetterstation
-
@babl
vielen dank!
das bedeutet dann, das die Daten einen Zeitabstand von 15min haben?
im moment logge ich "wind" und "richtung" alle 16sek, danach gibt es dann nur alle 15min einen datenpunkt, verstehe ich das richtig? -
@bigmike71 jawohl, das mache ich für die langzeitspeicherung, natürlich geht dir dann eine Böe z.B. verloren, aber für die letzten 30 Tage kannst du ja das normale Fenster (16sec) nehmen und ab dann das für die 15 min. In Grafana kannst das ja über die Variablen (Buckets) angeben bei Langzeitauswertung.
-
@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Im Skript ist ein Hinweis.
In der Doku fehlt er, glaube ich noch ?Eigentlich auch im Datenpunkt direkt, zumindest wenn er vom Script angelegt wurde.
Aber der Hinweis in der WiKi fehlt(e) tatsächlich.1.2. AutoReset_Jahresstatistik - [Zahl: 0,1,2] was soll am 01.01. des Jahres mit den Statistikdaten passieren?
0 = Aus | die Daten werden einfach fortlaufend weitergeführt
1 = Ein | die Werte werden "genullt" und ggf. (zB. Höchst-/Tiefstwert) auf Extreme gesetzt, damit dann wieder korrekte Höchst-/Tiefstwerte oä. ermittelt werden können
2 = Ein+Backup | wie 1, nur werden zusätzlich Daten in einer Jahresstatistik gespeichertExtreme bedeutet dabei "nicht mögliche Werte" wie zB. bei den Temperaturen.
Hier wird der Tiefstwert auf 99°C und der Höchstwert auf -99°C gesetzt. Somit wird zum nächsten Durchlauf jede Temperatur den Tiefstwert unterschreiten, sowie jede Temperatur den Höchstwert überschreiten.Min-Temp am 01.01. -5°C
Max-Temp am 01.01. 2°CFür den Vergleich ist dann
-5 weniger als 99 = neuer Tiefstwert -5°C
2 mehr als -99 = neuer Höchstwert 2°CWürden die auch nur "genullt" und wir hätten zB. am 01.01. ein Min von 6°C und ein Max von 9°C (wie es bei mir tatsächlich war), würde zwar der Maxwert korrekt auf 9°C gesetzt werden, der Minwert verbliebe aber bei 0°C, da 6 größer als 0 ist
...und löschen und keinen Wert hineinschreiben wird dann mit einer Fehlermeldung vom Javaskript-Adapter belohnt.Nur weil ich schon gefragt wurde warum diese verqueren "99er"-Werte. Ab und an denkt sich der alte Mann sogar etwas bei dem was er tut, wenn auch nicht immer
-
Seit heute morgen kommen falsche Werte bei mir in iobroker an. Bis ca. 9 Uhr hat es funktioniert. Die Displays (WH3000SE) zeigen noch die korrekte Temperatur an. Nur in ioBroker landen falsche Werte. Auch in WU landen nur korrekte Daten. Da sendet der DP1500, welchen ich auch für iobroker nutze. Debug zeigt folgendes:
PASSKEY=xxxxxxxx&stationtype=GW1000A_V1.7.7&runtime=7311343&dateutc=2024-01-07+10:19:16&tempinf=43.34&humidityin=44&baromrelin=27.950&baromabsin=27.950&tempf=59.36&humidity=85&winddir=72&windspeedmph=0.00&windgustmph=1.12&maxdailygust=11.41&solarradiation=0.00&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=2.000&yearlyrainin=52.201&totalrainin=52.201&temp1f=60.98&humidity1=40&temp2f=73.04&soilmoisture1=21&soilad1=150&soilmoisture2=59&soilad2=290&soilmoisture3=60&soilad3=290&soilmoisture4=27&soilad4=171&soilmoisture5=47&soilad5=244&lightning_num=0&lightning=17&lightning_time=1703179736&leak_ch1=0&tf_ch1=71.06&wh65batt=0&batt1=0&batt2=0&soilbatt1=1.5&soilbatt2=1.5&soilbatt3=1.5&soilbatt4=1.5&soilbatt5=1.5&wh57batt=5&leakbatt1=4&tf_batt1=1.52&freq=868M&model=GW1000A_ProHat jemand ne Idee, woran das liegen kann? Aktuell sind es Minus 5,4 ° und in ioBroker 15,2°. Scriptversion habe ich V3.2.0.
ZusatzInfo:
Momentan geht es wieder aber ich verstehe nicht wieso die falschen Werte ankamen. Naja Hauptsache geht wieder. -
@schittl Bei mir ist sowas kürzlich passiert kurz bevor die Batterie vom Außensensor aufgegeben hat.
-
@rushmed Ok danke für die Info. Das kann durchaus sein. Sensor ist ja schon mehr als 3 Jahre aktiv. Ich werde es beobachten.
-
@sborg Ich brauche nochmals eure Hilfe: Ich hatte vor, meine Datenbanken etwas zu säubern. 'Jetzt' gibt es ja die longtermBuckets und die shorttermBuckets. Gibt es eine Übersicht, welche Datenpunkte ins long müssen und welche nicht? Dann noch die anschließende Frage: in der wetterstation.conf muss ich ja ein Bucket angeben, damit bestimmte Werte aus der Influx geholt werden können. Muss der Bezug dann hier auf shorttermBucket stehen?
-
@rene55
Prinzipiell kannst du das erst mal handeln wie du willst. Der Gedanke war dabei die Daten 1 Jahr vorzuhalten. Länger fragt das WLAN-Skript auch keine Daten ab ("Temperatur vor einem Jahr").
Alles was man darüber hinaus behalten wollte sollte dann ins Longterm.Das Konstrukt ist aber offen gestanden suboptimal (ich nutze es selbst nicht mehr). Hier sind die Influx-Tasks mit aggregieren deutlich besser. Ich weiß meine Zeiträume gerade nicht auswendig, aber bspw. eine "Windrichtung" braucht man kaum aufheben. Die wird aber im ~30 Sekundenraster (halt Sendeintervall der Station) geloggt und belegt nur Platz. Wer braucht denn aktuell die Windrichtung vom 29. November 2023 um 11:52:33 Uhr? Also schmeiße ich die per Task (glaube 7 Tage) kpl. aus der DB raus. Auch die Temperatur ist jetzt (mir) nicht sooo wichtig, als dass ich die Ewigkeiten bräuchte. Sie ändert sich ja auch nicht alle 30 Sekunden. Also aggregiere ich einen 15 Minutenmittelwert der Temperatur und schrinke die DB um das 30-fache oder von 30 Datensätzen auf einen. Da kann ich sie auch länger aufheben und dann zB. nach 365 Tagen auch sagen "aggregiere" jetzt auf eine Stunde. Dann habe ich nur noch 24 Datensätze pro Tag.
Der Bezug in der conf muss halt auf das Bucket verweisen welches zumindest für 365 Tage Daten vorhält. Ob die "roh" sind oder bereits aggregiert sind ist dabei unerheblich. Ich lese immer dynamisch so viele Datensätze ein wie vorhanden sind
-
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Also schmeiße ich die per Task (glaube 7 Tage) kpl. aus der DB raus
kannst du das genauer erklären?
Hab mir dazu schon öfter was im Netz gesucht. Aber so richtig schlau, wie wo was konfiguriert werden muss, hab ich nichts vernünftiges gefunden.
-
@sborg Danke für die schnellen Antworten. Ja sicher, ob der Wind vor nem Jahr aus Osten kam ist sicher nicht wichtig. Ich hatte mich anhand des Dashboards hier angenähert. Da sah ich eigentlich nur vier Datenpunkte, die im long waren (Aussentemperatur, Temperatur_außen_Max_24h, Temperatur_außen_Min_24h und Solarenergie_Vortag). Wobei die Werte möglicherweise ja auch ins short könnten - oder liege ich da falsch? Welchen Ansatz verfolgst du denn, um den überflüssigen Datensalat zu entsorgen?
-
@sborg Da ich gerade so schön tief im Dashboard stecke. Welcher Adapter liefert denn die Ozon-Werte?
-
-
@latzi Danke dafür! Jetzt habe ich auch Ozon-Werte. Hast du das Wetterstation-Dashboard_V3 am laufen? Ich hab da einige leere und blöd aussehende Felder drin.
-
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Wetterstation-Dashboard_V3
nein, verwende ich nicht!
-
@latzi ok, trotzdem Danke.
-
@rene55 sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@latzi Danke dafür! Jetzt habe ich auch Ozon-Werte. Hast du das Wetterstation-Dashboard_V3 am laufen? Ich hab da einige leere und blöd aussehende Felder drin.
Wenn du sie füllen willst dann sag doch mal welche fehlen. Das Dashboard hatte ich für mich erstellt, wurde dann aber gebeten es öffentlich zu stellen. Deswegen sind da auch Dinge drin wie bspw. "Ozon" was überhaupt nichts mit dem WLAN-Skript zu tun hat. Ein oder zwei Dinge basieren auch auf einem JS (glaube Temperatur in 3 Stunden).
Solange es im Thema "Wetter" bleibt habe ich hier auch keine Probleme mit Fragen über Grafana/Influx, nur keine allgemeine Fragen diesbzgl. wie zB. "wie komme ich denn in Influx an die Daten meines Smartmeters..."
-
@sborg Besten Dank. Auch dafür, dass du das .json veröffentlicht hast. Vorweg: das alte Dashboard mit Influx1 habe ich derzeit auch noch laufen. Aber ich möchte den alten Ballast mal abwerfen. Ja konkret Ozon bekomme ich jetzt wahrscheinlich hin. Stimmt auch "Temperatur in 3 Stunden" fehlt (oder würde mir fehlen). Dann habe ich genau unter UV Index ein Panel, in dem keine Abfrage drin ist. OK, könnte ich löschen. Der größte Missstand ist der, dass ich z.B beim Regen dieses sehe:
Ich denke, ich hab da auch noch ein grundlegendes Problem mit Mehrfachdaten.
-
@negalein sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@sborg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Also schmeiße ich die per Task (glaube 7 Tage) kpl. aus der DB raus
kannst du das genauer erklären?
Hab mir dazu schon öfter was im Netz gesucht. Aber so richtig schlau, wie wo was konfiguriert werden muss, hab ich nichts vernünftiges gefunden.
+ @Rene55
Da wirst du so auch nichts "gutes" finden, denn Flux beherrscht kein "drop" von Datenreihen. Mit einem einfachen Task ist da nichts zu machen. Meine Lösung war (ich nutze sie auch nicht mehr) weder richtig praktikabel, geschweige denn massentauglich. Das war auslagern der gewünschten Daten, kpl. Reihe droppen und die ausgelagerte wieder importieren.
Sehr, sehr System lastig und durch den Im- und Export gehen auch definitiv Daten verloren, da alles was in dem Zeitraum Export - droppen - Import in die InfluxDB an neuen Daten geschrieben wird geht unweigerlich den Weg ins Nirvana.Aus Zeitmangel speichere ich aktuell einfach alles. Mein NAS hat im Moment 20TB, da ist noch Platz (auch für zusätzliche HDDs).
Der Zukunftsplan sieht dann aggregieren vor wo es Sinn macht (Temperatur genügt IMO alle 15 Minuten ein Messwert) und leider per Bash-Skript und Cronjob dann droppen der nicht benötigten Daten per Influx-CLI. Eine andere praktikable Lösung sehe ich aktuell nicht. Das Hauptproblem dabei ist, man kann halt nicht das aktuelle Bucket bearbeiten. Man muss immer alles in ein anderes Bucket schreiben. Verweist man bei Grafana auf das "neue" Bucket fehlen aktuelle Daten (außer man lässt den Task alle x Minuten laufen), nimmt man das "aktuelle" Bucket muss man die Daten in diesem auch zumindest für 365 Tage vorhalten
-
@sborg Das hört sich für mich gerade so an, als ob das aufspalten in long/short eigentlich gar nichts bringt.
Ergo: speichern bis die Platte voll ist; ja oder bis kurz davor, damit man noch was retten kann. Oder einen Fummel schreiben, der aus dem Datenwust, irgendetwas komprimiertes macht. Noch keine Ahnung, was das sein könnte. -
@rene55
Jupp, da fehlt wohl bisserl was beim Regen. Irgendwie finde ich im neuen Grafana gerade nicht den JSON-Export für ein Panel...
Hier ist mal mein JSON, allerdings müsstest du da überall die"uid": "ssI1YtJ4z"durch die UID deiner InfluxDB vor dem Import ersetzen.
Temperatur in 3h geht über den Adapter "Das Wetter" und ein kleines JS:
const idTemp = '0_userdata.0.Data.Temperatur_in_3h'; if (!existsState(idTemp)) { createState(idTemp, 0, { name: "erwartete Aussentemperatur in 3 Stunden", type: "number", role: "state", unit: "°C" }); } schedule('2 * * * *', function () { let hours3 = new Date().getHours() + 3; let id = 'daswetter.0.NextHours.Location_1.Day_1.Hour_' + hours3 + '.temp_value'; if(hours3 > 24) { hours3 -= 24; id = 'daswetter.0.NextHours.Location_1.Day_2.Hour_' + hours3 + '.temp_value'; } setState(idTemp, getState(id).val, true); });Das leere Panel unter UV-Index existiert bei mir nicht mehr, aber das könnte das Panel für das "Boom-Theme" sein. Das ist eigentlich auf unsichtbar gestellt, darüber kann man aber das Hintergrundbild auswählen.
Mit dem long/short bin ich noch unschlüssig. Eine Idee wäre in ein "Tages-Bucket" zu schreiben. Hierauf würden dann aktuelle Werte von Grafana (short) verweisen. Per Tasks wird dann alles kopiert, aggregiert und ins long geshifftet. Hierauf verweist dann Grafana auf alles was eben nicht "heute" ist (zB. Temperaturgraf der letzten 365 Tage).
Die Retention für dieses "Tages-Bucket" könnte dann bspw. 5 Tage sein, sprich alles älter als 5 Tage wird automatisch aus diesem Bucket gelöscht. Deswegen ist die Idee mit mehreren Buckets nicht abwegig, da man pro Bucket die Retention wählen kann
