[RFC] Grafana Datenquelle "BIENENJAHR"

Entwicklung / Development Daten / Data
1

Ihr Guten,

es soll hier um die einfache, schnelle aber vor allem wartungsarme Erschließung der Daten aus den Forschungsfeldern Phänologischer Kalender für Trachtpflanzen, DWD-Prognose Bienenflug oder Varroawetter im Grafana gehen, die schon lange auf der Wunschliste und seit ein paar Tagen in der konkreteren Planung ist.

Status quo

Wir hatten uns (mindestens in den bisherigen Diskussionen mit @einsiedlerkrebs, @clemens und @weef) im mentalen Modell zurechtgelegt, die Einbindung dieser Informationen über ein Grafana Plugin zur Verfügung zu stellen, das ähnlich wie das Sun and Moon datasource plugin gestaltet ist.

Ein Schritt zurück…

Vielleicht haben wir dabei aber viel zu kompliziert gedacht, vor allem vor dem Hintergrund, dass diese Variante bisher gar keine “pro Dashboard”-Individualisierung auf den Standort zulässt:

Hier müsste also ggf. noch mehr Zeit investiert werden, um sich in die interne Datenhaltung innerhalb von Grafana einzuarbeiten und dann müssen die Daten auch noch irgendwie zum Plugin hinfließen, natürlich abhängig von der Imker-individuellen Standorteinstellung, etc. pepe - alles nicht so trivial, um das möglichst generisch und wartungsfrei hinzukriegen.

… und vielleicht zwei nach Vorne

Nun hatte ich gerade den Gedanken, ob man diese Daten nicht kurzerhand in eine ganz normale InfluxDB Tabelle abspeichert - genau wie bei den Annotationen im Grafana über die HTTP/MQTT API - und damit über die Grafana Bordmittel alle Möglichkeiten zur Verfügung hat, sich diese Daten individuell und flexibel über entsprechend gestaltete Abfragen im Dashboard zu erschließen.

Toll wäre, wenn man diese Tabelle sowohl als Datenquelle für Annotationen im Graphen verwenden könnte, die Daten aber beispielsweise auch per “Table Panel” tabellarisch darstellen könnte. Vielleicht finden sich noch weitere Varianten. Der Standort sollte unter der Haube per Query Parameter bestimmt und im Grafana über eine entsprechend belegte Variable herausgeführt werden, die die Imkerin dann im Dashboard einstellen kann à la Wetterstationsauswahl bei Standard Dashboard für imkerliche Daten / Default dashboard for beekeepers. Easy!

Vielleicht hatte bisher nur ich diesen Denkfehler und Ihr wartet alle schon längst darauf, dass es diese Datenquelle bald geben wird ;]. Seis drum: Jetzt bin ich auf Kurs und wir können hier über den Aufbau der Tabelle diskutieren, damit sie uns komfortabel als Grafana Datenquelle all das liefert, was wir uns wünschen.

Gerade weil es in diesem Jahr in greifbarer Nähe scheint, diese Informationen noch zu Beginn der Saison endlich erschlossen zu haben, freuen wir uns wie immer über alle weiteren Anregungen zu diesem Thema.

Viele Grüße,
Andreas.

1 Like
2

Zwischenbericht Phänologiedaten

Gegenüber der Idee von damals haben wir mittlerweile immerhin schon mal das Betriebssystem dafür fertig.

Hier drüben wird diskutiert, wie eine Einbindung der Daten, z.B. ins Grafana, optimal aussehen könnte.

Dort wiederum gibt es ein erstes Beispiel für eine von vielen möglichen Integrationsweisen zu sehen, basierend auf Annotations | Grafana documentation.

3

Unter https://swarm.hiveeyes.org/grafana/d/cx_KOvH7k/documenta-stockubersicht-and-bienenwetter haben wir die DWD-Wetterstation per drop-down realisiert. Das ist zwar nicht so schön weil ein normalerweise fixer Parameter da als Auswahlliste steht und ich weiß auch nicht, was das datenbanktechnisch nach sich zieht (ich hoffe z.B., dass die per drop-down ausgewählten Daten auch erst dann nachgeladen werden und nicht die aller Stationen bei Aufruf des Panels) aber man sieht so recht transparent woher die Daten kommen und könnte sie auch (von Hand) anpassen.

Wir hatten dort allerdings mit unterschiedlichen Datenquellen zu tun, ob man überhaupt dynamisch annotations von unterschiedlichen Quellen dynamisch per drop-down technisch einbinden kann weiß ich nicht.

Die Möglichkeit zu einer gegebenen PLZ die nächstgelegene Station automatisch zu bestimmen fehlt auch noch. Ist aber gerade alles OT zum eigentlichen topic.

1 Like
4

Details

Gar nicht so sehr. Das sind die ganzen Details um die es hier geht. Die Daten müssen hin und zurück. Hin muss eine Benutzerauswahl aus (Zeit, Raum, Domänenparameter…), die die Anfrage repräsentiert, und zurück muss ein tabellarisches Ergebnis.

we are looking into how to optimally bring phenology data into our Grafana instance

Also wie genau sollen welche Parameter der Benutzer:in als Eingabemöglichkeit zur Verfügung stehen, und welche nicht (UX), und wie können die entsprechenden Widgets mit Daten gefüttert werden (TECH), um das Thema sinnvoll zu realisieren.

Das sind meine aktuellen Gedanken zu diesem Thema (TECH). Wenn die Schnittstelle “einfach nur SQL” wäre, kriegt man über einen schmalen Kanal (SQL expression) die maximale Ausbeute an Flexibilität – und wir bräuchten keinerlei Spezialadapter im Grafana.

Technik

Einleitung

Man sieht bei phenodata » Synopsis, dass es – je nach gewünschtem Detailgrad vs. sinnvoller Vorbelegung – so um die fünf sechs sieben Parameter sind, die zwischen Benutzer:in und Maschine übermittelt werden müssten.

Das wird mit der SQL Schnittstelle deutlich einfacher, um die Parameter nicht individuell übermitteln zu müssen, dem Vorbild Plant phenological online database (PPODB) folgend.

State of the onion

Das ist der aktuelle Stand beim Versuch einer Kopplung zwischen den Domänen Grafana und Python, bezogen auf unseren Anwendungsfall “phenodata via Grafana ins Netz bringen”.

Der aktuelle “Bunch of Parameters” ist derzeit noch komplett fest kodiert. [1]

phenodata_mellifera(
  dataset="immediate",
  years=tuple([2019, 2020, 2021]),
  phases=tuple([5, 7]),
  options=tuple(query.items())
)

Wenigstens der Stationsname wurde schon als Variable rausgeführt und kann von Grafana zum Backend übermittelt werden – immerhin. ;]

  1. species-selection darf natürlich auch nicht fehlen, die hängt derzeit ein paar Zeilen tiefer bei demo.py#L64, per Speziesgruppe "mellifera-de-primary". ↩︎