erstmal herzlichen Glückwunsch zu diesem Mega-Projekt. Ihr habt ja einiges auf die Beine gestellt. Respekt!
Ich hoffe, dass diese Frage hier im Forum ok ist.
Ich erstelle gerade ein System zur Temperatur-Überwachung mithilfe von LoraWAN Sensoren.
Diese senden u.a. Temperatur-Werte zum zentralen TTN (TheThingsNetwork) Server. Von dort werden diese mittels MQTT abgeholt und über Telegraf in eine InfluxDB geschrieben und mit Grafana visualisiert.
Für die Funkübertragung installieren wir TTN Gateways, die von jedermann genutzt werden können.
Dein Projekt klingt ja auch spannend … gibts da schon was zu sehen?
Für den DWD-Import zeichne bislang ich bzw. ein kleiner Berg Posix-Shell-Script-Zeilen verantwortlich, die sowas von unschön und unperformant sind, alsdass ich sie bislang nicht veröffentlichen wollte. (Auch Aspekte wie “dokumentierte Bedienbarkeit” oder “Feature-Vollständigkeit” sind sehr unterirdisch.)
Vom Prinzip her läufts alle Stunde per cronjob, holt sich alle aktuellen Stationsmeldungen und schreibt die letzten n Werte ein jeder Station in ein line-protocool-File, splittet dieses (InfluxDB mag pro post-request erstmal nur 20.000 Zeilen) und submitted dann die Chunks über die http-API von InfluxDB. (Falls zu einem Timestamp und einer Station bereits nen Wert vorlag wird dieser einfach überschrieben.)
Da das alles recht mit heißer Nadel gestrickt wurde finden sich auch hier schon Energien das in einer ordentlicheren Umgebung nachzubauen. Insbesondere gucke ich da zu @Andreas, der sich in letzer Zeit dazu dem Projekt “wetterdienst” angenommen hat.
Aber wenn Du magst, schicke ich Dir auch gern schonmal die Importscripte wie sie aktuell laufen.
gibt es denn zwischenzeitlich etwas neues von den Skripten für den Datenimport in InfluxDB?
Ich bin Landwirt und baue mir Hof-Dashboards, da wären diese Daten auch sehr praktisch.
Also bei meinen desolaten, innerlich-abgeschriebenem Shell-Script gibts nix neues (außer, dass es noch stabil weiterläuft) – haben wollte des der Uwe wohl doch nicht, Du? ;) … Aber wie angedeutet, bei dem Script wetterdienst von @Andreas und anderen hat sich wohl einiges getan, da gabs in der Zwischenzeit so einige Änderungen.
@Andreas, ich hab mich ja auch immernoch nicht rangetraut. In welchem Zustand sollt sich das Projekt denn gefühlt grad befinden? Zuletzt ging ich davon aus am Ende ein paar Werte in der Hand zu haben und denn selbst noch ne Matrize zum Befüttern einer InfluxDB hinten dran hängen zu müssen, aber da gabs ja auch schon Ambitionen, dass der wetterdienst selbst eine InfluxDB befüllen kann. blätter
Zumindest in der Dokumentation (wow, mein Script kennt sowas garnich), taucht schon was mit InfluxDB auf:
# Store readings to InfluxDB
fetch --target="influxdb://localhost/?database=dwd&table=weather"
Dit sollt einfach so funktionieren?! Wahnsinn :)
@Simon1 Für mich steht hier halt irgendwann noch die Großbaustelle an das wetterdienst-Pferd zu zäumen und damit mein altes Script abzulösen (und damit ungefähr alle Dashboards hier, die die Wetterdaten nutzen, zu verwirren).
Ach das klingt schön :) Da bin ich doch auch etwas neugierig, wie die so bei Dir aussehen, welche Parameter da für Dich relevant sind? (Wat bauste an, erziehste?)
(Wo ick mich grad ob dieser Pandemie da draußen geschäftlich etwas neu erfinden muss und auch etwas mehr Bezug zum Land gewonnen hab, find ich diesen Zweig auch beruflich grad recht interessant.)
wenn ich das richtig sehe sind über den Wetterdienst-Script bisher ja nur historische Daten verfügbar, oder?
Wie hast du das mit den Vorhersagen gemacht?
Naja, da gibt es sehr viele Daten die landwirtschaftlich interessant sind, das geht von Stromverbräuchen der einzelnen Geräte (Milchkühlung, Wasseraufbereitung für die Kühe etc.) über die Solarerzeugung (knapp 750kW Peak), Autarkiequote bis hin zu aktuellen GPS-Positionen und Zuständen von Traktoren.
Perspektivisch würde ich auch gerne die ganzen Silos (Mineralfutter, Kraftfutter etc) auf dem Hof auf Wiegefüße stellen, um auch den Füllstand bequem im Blick zu haben, Bestellungen sind bereit per App möglich, wäre interessant da vll auch eine Automatik zu integrieren.
Ansonsten gilt es viele Kennzahlen der Kuhherde im Blick zu behalten, da sind momentan noch verschiedene Programme/Apps zu öffnen, das wäre ebenfalls in einem gemeinsamen Dashboard gut aufgehoben.
Siehste in der Tat nicht ganz richtig: Zumindest laut README/Coverage kann wetterdienst auch die Vorhersagedaten des Modell-Output-Statistics-Mix (MOSMIX) des DWD importieren. Das sind auch dieselben, die das alte Script bislang hier zur Verfügung stellt (siehe bspw. das DWD CDC MOSMIX Meteogramm für eine Kombination aus historischen und künfigten Werten).
Wohlgemerkt: Es handelt sich hierbei um sog. “Punktvorhersagen”, die nur für bestimmte Orte (5.300 weltweit) erzeugt werden (meist wo sonst auch ne Wetterstation steht), im Unterschied zu “Flächenvorhersagen”, die in Rastergittern für zusammenhängende Fläche erzeugt werden. Letztere haben wir soweit nicht bearbeitet (beim DWD wäre es das ICON-Modell). Die Punktvorhersagen basieren auf dem Flächenmodell, werden aber um “statistische Eigenheiten” auf Basis historischer Werte “verfeinert”, was zu einer besseren Qualität für die jeweiligen Punkte führen soll.
(Schlimm beim DWD ist, dass es keine gemeinsame Stationsnummern- oder Namenslisten für die Messstationen und die Vorhersagepunkte gibt. Aber da für Deine Anwendung ja vmtl maximal nur ne Handvoll interessant sind, lassen die sich ja auch per Hand zuordnen.)
Beim Stichwort “Solar” muss ich grad noch an das Sun and Moon-plugin für Grafana denken. Mit dem könnte man noch den Sonnen(höchst)stand mit in eine bessere Erwartung für die Ertragsvorhersage erzeugen.
Also ein ganzer Zoo an Parametern, mit einer hohen Artenvielfalt! Wie schön :) Dit müssen ja janz schön ordentliche Wägezellen sein …
Und die kommen auch schon aus elektronischen Erfassungen, wo sich dann vmtl häufig so Fragen nach “wie krieg ich die Daten aus dieser und jenen mehr oder weniger proprietären Schnittstelle raus” anschließen?
Jo, ich bin zuallermeist selbstständiger Netzwerkadministrator mit nem – eigentlichen – Schwerpunkt auf Veranstaltungen, aber auch der Ausstattung bzw. dauerhaften Betreuung von Gewerbe-/Wohn- und eben Veranstaltungsstätten. Ob eines Faibles für Meteorologie und der Bekanntschaft zu einigen Akteuren hier hats mich denn hier weiter in den Bann gesogen. Wir beide können ja etwaiges Beschnuppern auch gern per Direktnachricht weiterführen.
kann es sein, dass ich als neues Forenmitglied noch keine Privatnachrichten schreiben kann? Ansonsten stell ich mich bloß zu blöd an und finden denn Button nicht
Hallo zusammen, ich möchte mich auch kurz zurückmelden. Ich bin beruflich zur Zeit stark eingespannt und dieses Projekt musste etwas zurückgestellt werden.
Aber ich bin damals weitergekommen - es ist zumindest nutzbar ;-)
Ich habe Wetterdienst Version 0.7.0 nach einigen Versuchen für meine Bedürfnisse ans Laufen bekommen (Trial&Error - die gefundene Doku hat mir persönlich nicht immer geholfen ;-) )
Mit Hilfe von wetterdienst werden per cron job regelmäßig die 1h und 10 Minuten Temperaturwerte (2m) von zwei Stationen eingelesen. Diese werden für InfluxDB angepasst und dann in die DB geschrieben. Weitere Skripte können genutzt werden um ganze Jahre (1h Werte) oder Monate (10Min Werte) aus der Vergangenheit in the DB zu schreiben.
Dies läuft seit einigen Wochen stabil.
Vielen Dank an die Entwickler von “wetterdienst” !
Gern geschehen! Den Dank reiche ich gerne weiter an @gutzbenj und bedanke mich gleichzeitig für Euer Interesse.
Wir haben die Dokumentation seit der Version 0.7.0 ordentlich überarbeitet und hoffen, dass die Situation mittlerweile besser geworden ist. Wir nehmen aber jederzeit gerne Verbesserungsvorschläge entgegen.
Ich würde sagen: Gut!
Exakt!
Das stimmt. Die MOSMIX-Vorhersagedaten können zwar bereits bezogen werden (siehe API » MOSMIX), allerdings steht noch keine entsprechende Funktionalität per wetterdienst-Skript zur Verfügung.
Auch wenn das Thema schon älter ist, passt es doch gut zu einer aktuellen Problematik. Ich baue gerade eine eigene kleine Wetterstation (Tinkerforge Bauteile) auf, die ihre Daten per MQTT direkt zur Verfügung stellen kann. Ich hab mir auch schonmal den Stack kotori, MQTT, influxDB, grafana aufgesetzt als Grundlage zur Aufzeichnung und Visualisierung. Ideal wäre es nun die Daten mit den DWD Daten anzureichern, also quasi genau so einen Datenimport zu machen wie ihr es macht und dort Vergleichs-Panels und Weiterführung per MOSMIX prediction zu machen.
Da ich eure Scripte nicht kenn, bin ich mir unsicher wie die Transformation der Daten vom DWD Source zu JSON in Influx passiert (oder nutzt ihr inzwischen das Python Tool zum Import?). Insofern wär es cool die Scripte mal zu sehen die die Daten vom DWD Server holen, transformieren und in Influx Persistieren (ich würde das wahrscheinlich mit ner kleinen Java App dann anders machen, aber mir kommts vor allem auf die Formate an), damit die tollen Dashboards die ihr habt dann automatisch auch auf meiner Influx DB funktionieren und ich die anpassen kann, bzw die Daten meiner Station dann gleich kompatibel mit einpflegen kann.
Wenn das alles intern bei mir gut läuft kann ich ja durchaus den MQTT feed auch in andere Datenbanken pushen wenn Interesse an den Wetterdaten von Berlin FHain besteht (Station steht auf dem Dach ca 23m Höhe).
vielen Dank für Deine Zuschrift und gutes Gelingen für das Wetterstationsprojekt.
Unser guter @wtf hat hierzu ein paar Zeilen Bash aneinandergereiht, was er auch oben im Beitrag beschreibt. Das funktioniert ganz gut und treibt deswegen auch produktiv die ganze Maschinerie an, wurde aber bisher nicht veröffentlicht.
Die aktuellen Dashboards würden mit Wetterdienst leider auch nicht 1:1 funktionieren, müssten also angepasst werden. Dann hätte man aber wirklich Datenschaufelei und Dashboards aufeinander abgestimmt und beides käme aus einem Guß daher. Das wäre durchaus ein schönes Ziel.
Wetterdienst ist an der Stelle schon wirklich ausgereift, auch, um Daten direkt in die InfluxDB schreiben zu können. Also wenn Dir ein klein wenig Python Code nichts ausmacht, dann knöpf Dir die Gerätschaft doch mal vor, @uwe hat es ebenso erfolgreich genutzt und @wtf mittlerweile ebenfalls [1].
Darüber hinaus könnten wir uns vielleicht wirklich mal gemeinschaftlich zusammentun – oder @wtf kann mal wieder zaubern? – die Dashboards auf Daten aus der Wetterdienst-Datenquelle umzustellen? Dazu müssten wir sie mal dauerhaft als cron job auf dem Server in Betrieb nehmen und dann könnte die Reise eigentlich schon starten.
Meldet Euch beide gerne, wenn Ihr denkt, da könnte ein Schuh draus werden.
Schön, das freut mich sehr [2]. Deine Wetterstation funkt ab Werk bereits MQTT, ja? Ich frage nur aus Neugierde, ob Du dabei WeeWX und Ingesting weather data from WeeWX using MQTT - Kotori DAQ benutzt hast, oder – falls ersteres zutrifft – gar nicht erst benötigt hast.
Hey, das ging ja fix mit der Antwort. Erstmal schonmal danke, war mir nicht sicher ob son alter Thread noch funktioniert.
Ich gehöre zu der Sorte Mensch der sich erstmal einen umfassenden Überblick über das verschafft was schon da ist und (weitgehend) funktioniert, da reinguckt wie es im Detail funktioniert, um rauszufinden was angepasst werden kann, was neu gemacht werden sollte und was wiederverwendet werden kann. Je mehr man weiss, desto weniger Arbeit hat man beim Neu-Erfinden des Rades.
Konzeptionell gibts ja viele verschiedene Ansätze wie man Wetterstationsdaten Visualisiert bekommt, am Ende stehen dann meisst InfluxDB und Grafana, aber der Weg dahin ist unterschiedlich, einige machen das mit OpenHAB (auch dafür gibts Tinkerforge Bindings), der Ansatz das per MQTT und Kotori zu machen fand ich aber gut, denn via MQTT broker kann man alle Daten die reinfliessen an beliebig viele Subscriber ausspielen, also auch an mehrere Influx-Instanzen oder eben auch an Ziele im Internet zum publishen.
Dabei bin ich dann auf hiveeyes gestossen und die dortigen Dashboards die die DWD Wetterdaten auch in Influx/Grafana reinstecken … warum das also nicht kombinieren und gleich die schönen Dashboards weiterverwenden, man muss das Rad ja nicht neu entwickeln wenn es schonmal jemand gemacht hat.
Idealerweise pusht nicht nur die eigene Wetterstation per MQTT ihre Messdaten in den Stack, sondern eben auch noch ein DWD Datenfetcher der einfach dieselbe Schnittstelle benutzt und seine Daten per MQTT published und darüber in die Influx/Grafana reinsteckt. Mit einer Kotori Anpassung kann man ja auch die Payloads noch passend machen wenn erforderlich.
Für mich wäre es wichtig zu wissen in welchem Format das nun bei euch bisher in der Influx landet (also welche DWD Daten/Felder genau wo in der Influx landen). Das kann ich mir vermutlich irgendwie auch aus den Panels und Infos aus anderen Threads erarbeiten, aber das ist dann viel Trial and Error, am besten wären die Shell-Scripte … ich arbeite schon seit 30+ Jahren mit Shell-Scripten aller Art, das sollte easy sein rauszufinden wie das zur Zeit gemacht wird und dann kann ich mir überlegen ob ich den Wetterdienst einfach an MQTT und Kotori so anflansche dass alles passend in der Influx landet, oder vielleicht doch was einfaches eigenes mache. Ich brauche ja auch nicht alle Wetterstationen sondern nur ein paar zum Vergleich mit den Daten der eigenen.
Ich komme eher aus der C/C++/C#/Java Welt und bin daher etwas ungelenk in Python, aber das ist ja auch kein Hexenwerk.
Ich muss @wtf mal anchatten ob er mir nicht mal die Scripte schicken kann … wär ne große Hilfe um das zu verstehen was da gemacht wird.
Die aktuellen Dashboards würden mit Wetterdienst leider auch nicht 1:1 funktionieren, müssten also angepasst werden. Dann hätte man aber wirklich Datenschaufelei und Dashboards aufeinander abgestimmt und beides käme aus einem Guß daher. Das wäre durchaus ein schönes Ziel.
Das käme halt drauf an … wenn man die mit Wetterdienst abgerufenen Daten so in den MQTT reinschaufelt dass es in Influx die gleichen Formate hat, kann man auch die Dashboards weiterverwenden. Sogar die eigene Wetterstation wäre dann einfach nur eine vergleichbar mit einer DWD station mit einer eigenen ID … ob das Sinn macht oder man doch die Datenstrukturen in der DB anpasst überlege ich mir wenn ich den Überblick habe … meisst ist es einfacher die Datenstrukturen zu transformieren, als die ganzen Consumer der Daten (also Grafana) anzupassen. Da die Ursprungsdaten (DWD) ja dieselben sind (egal ob per bash in Influx oder per Wetterdienst geholt), gibt es immer einen Weg die so zu transformieren, dass das Ergebnis in Influx dasselbe ist. Zumindest spricht erstmal nix dagegen.
Deine Wetterstation funkt ab Werk bereits MQTT, ja?
Ja genau … für alle Sensoren (ich glaub die haben mehrere duzend) und eben auch für die Wetter-Sensoren gibt es Bindings für fast jede Programmiersprache und eben auch ein MQTT Binding welches mit der passenden Konfiguration jeder Sensor seine Daten bei Anlieferung direkt in MQTT published.
WeeWX habe ich mir nicht weiter angeschaut. Ich weiss ja dass die Sensordaten in MQTT landen, und brauchte was, was das ganze dann in Influx persistiert und in Grafana anzeigt. Und da passt Kotori natürlich ideal, ich fange erstmal klein an mit der Minimalkonfiguration und den paar Daten und will aber perspektivisch einen Merge von DWD Stationen und meiner eigene eben vergleichbar mit eurem DWD Dashboard … dann kann man Messewerte nahe gelegener DWD Station vergleichen und per MOSMIX die aktuelle Messreihe fortschreiben …
Das alles wird ne Weile dauern da das ja eher nen Hobby nebenbei ist. Aber für die Bienen tun wir auch was auf unserer Dachterasse .-)
-Symbol auftauchen.