Temperatursummen in der Imkerei

Datenanalyse / Data analysis
1

temperatur und brut
synchronisation von blütenpflanzen und bienen über tagestemperaturmaxima

beim bienensymposium in weimar hat bernhard heuvel interessantes über die zusammenhänge von temperatursummen (temperatur tagesmaxima) und volksentwicklung beschrieben, er spricht und zeigt einem valides modell zur prognose der volksentwicklung (in der tendenz) um imkerliche eingriffe planbar zu machen.

ich versuche mal sein handout leicht gekürzt zusammenzufassen:

  1. stichworte: chronobiologie, externe zeigeber (licht und temperatur), entrainment
  2. temperatursummen werden in der landwirtschaft verwendet (grünlandtemperatur) daher wohl auch seine inspiration.
  3. für bienen gibt es natch dr. josef bretschko und prof. bergmann&sohn eine abhängigkeit der eiablage von der tagestemperaturmaxima. (bretschko - der magazinimker sowie bergmann - moderne betriebsweise im magazinbetrieb…)
  4. zitat:“ohen einschränkung kann festgestellt werden, dass unter der vorraussetzung eines ausreichenden futtervorrates und einer ausreichenden pollenversorgung die tagesmaximaltemperatur während der monate februar bis mai der dominierende reiz für die ausdehnung des brutnestes ist”
  5. formel eiablagequote; y=22,8295 * x^1,4254
  6. übertrag in die tabellenkalkulation.
  7. zeitversetzte effekte und populationsnachbildung
  8. mortalitätsrate adulter bienen: faktor 0,975 (entlehnt aus der populationsbiologie)
  9. schwarmstimmung entsteht laut empirischer beobachtung, wenn das verhältnis von brut zu bienen sich 120% nähert
  10. imkerliche tätigkeiten lasen sich mit hilfe der tabellenkalkulation (oder prognose in grafana?) genauer planen
  11. verwebdbar für honigraumgabe, zeitpunkt schwarmkontrolle, erntezeitpunkt, schröpfen, varroabehandlung und mehr. (besonders in kombination mit den phänologischen daten)
  12. begleitende lektüre: das grundgesetz der brut- und volksentwicklung der bienen von ferdinand gerstung, 1890.

er hat damit eine ziemlich eindrucksvolle excel tabelle gebaut die anschaulich die zusammenhänge gezeigt hat, start war eine geschätzte bienenpopulation beim auswintern.

1 Like
2

Habe den Bretschko vor 20 Jahren mal gelesen, war mir damals zu kompliziert und für die praktische Imkerei mit der Populationsschätzung zu aufwändig. Glaube, ich habe ihn damals auch nicht zu Ende gelesen.

Was ist hier y, was x?

Mortalitätsrate sind sterbend Bienen pro Tag / Monat? D.h. es sterben 0,975 % der Gesamtpopulation täglich?

Und schwärmen würden sie, wenn auf 100 Brutzellen 120 Adulte kommen?

3

y ist wohl die anzahl der täglich gelegten eier in abhängigkeit von x dem tagestemperaturmaximum

0,975 ist die tägliche mortabilitätsrate adulter bienen ohne spritzschäden und wespenmassaker.

hab es so erstanden das es einen brutüberhang gibt also das verhältnis brut zu adulten bienen 120% beträgt – das volk ist kurz vorm explodieren ;)

4

Dazu läßt sich dann doch Einiges finden, denn Bernhard Heuvel hat es veröffentlicht.

Die Betriebsweise (bei ihm Warré) dürfte nur wenig Einfluß auf die Anwendbarkeit des Modells haben, sofern die starke Außentemperatur-Kopplung durch offenen Gitterboden wie bei anderen Magazin-Systemen gegeben ist. Bretschkos Erkenntnisse allerdings sind mit Carnica entstanden; daß diese Erkenntnisse wahrscheinlich übertragbar sind auf andere Rassen in unseren Breiten, dazu finden sich jedenfalls Hinweise bei Ruttner 1976, erwähnt in: Imdorf, Ruoff, Fluri: Volksentwicklung der Honigbiene:

Interessanterweise zeigten nicht die Völker gleicher Abstammung, sondern die Völker am gleichen Standort ein ähnliches Brutverhalten […]. Dies beweist, dass die Umwelteinflüsse stärker wirken als die Einflüsse der erblichen Veranlagungen.

In einem anderen thread und Forum zeigt Herr Heuvel die gute Anwendbarkeit des Prinzips der Temperatursummen z.B. für den Raps:

Es kommt weniger auf “warme” Tage an, sondern auf aufgelaufene Temperatursummen. Die sich aufaddierende Differenz der Tageshöchst- und Tagesniedrigtemperatur seit Jahresanfang ergibt eine Temperatursumme. Wobei Raps bei 753 beginnt zu blühen. Und bei 1116 aufhört zu blühen.
[…]
Damit konnte ich in den vergangenen Jahren fast tagesgenau den Blütenbeginn von Pflaume, Kirsche und Raps prognostizieren.

(aus: Raps 2017 - März - Imkerforum seit 1996)

Dort ist auch das erwähnte Rechenblatt “Raps-Blührechner” verlinkt (leider auf ggl docs; kann gerne jemand raw hier ablegen) https://docs.google.com/spreadsheets/d/1jFZXPEes0-OgFnRzRjfYP_Uy8FRrKkAuMvjak0Lyq9s/edit?usp=sharing#

Heuvel’s Blührechner für Raps, Kirsche und Pflaume (je drei Blätter):
Blütenrechner.ods (40.6 KB) , Blütenrechner.xlsx (156.9 KB)

Insgesamt denke ich, daß es für uns mit den inzwischen gegebenen Möglichkeiten in unserem Datenmischwerk sehr interessant wäre, Temperatursummen-Prinzipien sowohl

  • für die Entwicklung des Bien selbst,
  • aber auch für die Entwicklung der Vegetation

zu erschließen bzw. einzubinden. Schon die Grünlandtemperatursumme und auch ihre Vorhersage (mit und ohne MOSMIX-Hilfe) könnte in Grafana aus Bordmitteln erzeugt werden (ob nun mit Werten der nächsten DWD-Station oder selbst gemessen).

Wenngleich dies wichtig ist, sind natürlich die Zeitpunkte der Massentrachten noch wichtiger. Die Wachstumsgradtage mögen jeweils leicht errechnet sein, aber es fehlen uns einige Koeffizienten wie oben für den Raps, um dies in z.B. phenodata oder als Hilfsdatenquelle für Influx/Grafana anlegen zu können … Leider sind in den Tabellen Rekursionen vorhanden, die zu realisieren so in Influx/Grafana nicht einfach klappt, und für welche ich erstmal mit @andreas und @wtf in Klausur gehen muß… ;)

weil es sich gerade schön verlinkt: erwähnte historische Literatur zum Thema:
“Gerstung, Ferdinand : Das Grundgesetz der Brut- und Volksentwicklung des Biens” (1902)
http://digital.zbmed.de/download/pdf/2437832?name=Das%20Grundgesetz%20der%20Brut-%20und%20Volksentwicklung%20der%20Bienen

5

Nur zur Info, er hat aktuell nicht mehr Warre, sondern seit er das hauptberuflich macht Dadant.

6

Mal unabhängig davon wie gut das Modell unterbaut ist, wäre es doch interessant es zumindest in einem Template zur Verfügung zu stellen und damit einen breiteren Test zu ermöglichen. Leider komme ich mit meinen nicht vorhandenen Grafana Kenntnissen schnell an die Grenzen. Bisher habe ich in einem Graph umgesetzt

Maximaltemperatur des Vortrages:
SELECT max("Temperatur") FROM "balkon_stand_sensors" WHERE $timeFilter GROUP BY time(1d) fill(null)

daraus die Eiablage nach Formel oben:
SELECT 22.8295*pow(max("Temperatur"),1.4254) FROM "balkon_stand_sensors" WHERE $timeFilter GROUP BY time(1d) fill(0)

Damit sollte dann die Summe der Eiablage der letzten 20 Tage die Anzahl der Brutzellen sein. Aber wie bekomme ich die aufsummiert - kann da jemand helfen?

2 Likes
7

Korrekt, das haut schonmal hin. Aber Du hast recht: die auflaufende Brut (also der Wert “Eiablage 20 Tage zuvor” läßt sich nicht einfach per query-Ausdruck ab dem 21. Tag abziehen.

Ein ähnliches Problem habe ich auch gerade bei der Erstellung der Grünlandtemperatursumme (da werden z.B. bei vielen Versionen die Werte monatsabhängig verschieden gewichtet, Startdatum und ggf. -offset der Funktion müßten einstellbar sein usw.), und das geht leider z.Z. doch nicht mit Bordmitteln. Grafana erlaubt gegenwärtig zusammen mit der aktuellen Version von InfluxDB keine queries, die auf mehr als den jeweils gewählten Zeitraum arbeiten, ein dafür nötiges time shift im query kann InfluxDB, aus Grafana heraus bedient, noch nicht (nur im view innerhalb Grafana).

Das zu lösen, ist nicht trivial, aber möglich. Ich bereite da gerade etwas vor für die Diskussion in der hiveeyes-Kerntruppe, aber als Vorgriff darauf:

  • InfluxDB 2.0 ist wenige tage vor dem alpha-release (master branch wird auf 2.0 umgeschaltet) , da sollten dann alle Probleme gelöst sein!™ ;)
    Natürlich noch nicht gleich, denn die alpha muß erst etwas reifen, bevor sie produktiv verwendet werden kann. Aber dort ist in der query language offenbar der timeshift als Bestandteil eines queries möglich, so wie in Graphite oder Prometheus. - Die Grafana-Leute haben wegen Quantensprung auf InfluxDB 2.0 angekündigt, daß diese umgehend in Grafana unterstützt werden wird.

  • es gibt MetaQuery, eine synthetische Datenquelle für u.a. diese timeshift-Funktion sowie für Arithmetic . Das Teil ist auch auf swarm.hiveeyes.org installiert und als data source auswählbar (auch mit Mixed) .
    Leider verzweifeln @wtf und ich regelmäßig an diesem Ding; die Beispiele sind ‘nur’ für ein ElasticSearch backend, den Syntax bei arithmetic für InfluxDB bekommen wir nicht in funktionierend hin; das, was klappt, ist nur trivial und nicht reproduzierbar 8( …

    Bestimmte Arten von nesting sind damit nicht möglich:

    Known Issues

    Moving average of moving average is not supported
    Moving average of time shift is not supported
    Time shift of Moving average is not supported
    Time shift of Time Shift is not supported

    … aber ob die begehrten arithmetics auch geschachtelt werden können, haben wir noch nicht erkunden können. Auch bereits eine funktionierende timeshift-Möglichkeit mithilfe dieses plugins, welche man sich im Anschluß im eigenen query zunutze macht, wäre schön!
    Also: wer sich schaffen möchte, darf gern die MetaQuery ausprobieren, da ist Forschungsbedarf.

    Metaquery als generell begehrenswerte Funktionalität ist auch ohne diesen Kontext des plugins auf der Agenda der Grafana-Entwickler; das interessiert auch jene, die andere Datenbanken als InfluxDB nutzen - und uns, die wir damit die in diesem thread angesprochenen Funktionen erledigen könnten. Ob und wie weit das ab 2.0 vielleicht schon integriert sein wird, kann ich noch nicht abschätzen. Daß die das bislang noch nicht gebaut haben, sondern nur dieses ‘Fremd’-plugin existiert, hat den Grund, daß es sehr viel Gehirnschmalz braucht: da der Rechenaufwand einer solchen Funktionalität schnell exponentiell steigen kann, muß die Last gut zwischen back end und front end verteilt werden, gewiß nicht trivial… ;)

Die anderen Möglichkeiten (influxdb-timeshift-proxy; kotori um weitere vendor specific -Dinge erweitern; continuous queries; Kapacitor verwenden für z.B. sowas ; …) wäre immer höherer Aufwand bis ungewünscht, oder nur ein Teillösung, oder nur ein Hack, oder es bräuchte jeweils immer ein (anderes) user interface… also erstmal verschoben.

Aber die MetaQuery -“Datenquelle” darf gern verwendet werden, das Ding könnte die schnellste Lösung für das Problem darstellen.

Die Grünlandtemperatursumme kann ggf. auch durch phenodata extrahiert werden, exquisiter wäre natürlich der Errechnung aufgrund der eigenen gemessenen Werte (auch Zuhilfenahme der nächsten DWD-Station), damit wir letztlich soetwas hier als automatische synthetische Datenquelle für einen Standort selbst erstellen könnten (dashboard von @clemens; über die annotations hovern):

1 Like
8

Danke für die tollen Vorschläge. Auch wenn wir alle schon sehnsüchtig auf InfluxDB 2.0 und Flux warten und es so bald wie möglich ausprobieren wollen, will ich hier auch noch auf den weiteren potentiellen Kandidaten TimescaleDB hinweisen, den wir ebenfalls ins Auge gefasst hatten, weil diese Datenbank u.U. ebenfalls einige Probleme lösen könnte, die wir derzeit so bei der Datenverwaltung haben.

Wenn der aufgemotzte PostgreSQL die von Euch gewünschten arithmetischen Dinge gut beherrscht, könnten wir so Meß- und Metadaten in der selben Datenbank verwalten - das hört sich erst einmal nicht unpraktisch an ;].

Gefällt mir, ich hoffe wir können das für die kommende Saison realisieren.

9

OK, dann warten wir mal was die neue Version so bringt. Wenn man über die letzten 20 Tage aufsummieren könnte hätte man schon einmal die aktuelle #brutzellen. Für die Anzahl Bienen müsste man im prinzip immer nur die Mortalität multiplizieren und die schon berechnete Legerate addieren (Bienen*0,975 + legerate(-20d)).

Auch wenn ich das noch nicht in Excel modelliert habe könnte ich mir vorstellen, daß das Modell intrinsisch robust ist und es keine Grenzbedingungen braucht. Im Winter wird die Legerate automatisch niedrig, es sollte sich also eine Population auf niedrigem Niveau einstellen (ich tippe mal, daß diese etwas unterschätzt, da die Mortalität für Winterbienen zu hoch angesetzt ist). Unter Null geht das ganze aber ja nie und auch die Legerate wird mit der Formel nie Null, wodurch immer Bienen vorhanden sind. Im Frühling müssten sich dann von alleine die gewünschten Werte einstellen, die auch realistischer sind. Dann wird das Verhältnis Bienen/Brut ggf. aussagekräftig. Natürlich sind hier keine Trachtlimitierungen, Milbenschäden, etc. drin. Aber im Grunde geht es ja auch nur darum, daß die Werte von April bis Juni einigermaßen realistisch sind, wenn Schwärme fallen könnten und da sollte immer Tracht vorhanden sein (außer man steht im Raps) und Milben sind hoffentlich noch nicht kritisch.

10

Die Temperatursummen-Theorie bedeutet am Ende ja, dass die Volksgröße, sagen wir mal zu Beginn der Schwarmsaison, nur von der Startgröße der Population im Januar, d.h. bei Brutbeginn nach der brutfreien Zeit und den Temperatursummen abhängt.

Bienen fangen nach der Winterphase, die normalerweise brutfrei ist, Ende Januar an zu brüten. Auch da wäre spannend, wie sie den Zeitpunkt bestimmen, Vermutlich merken sie, dass die Tage länger werden und nehmen dann – unabhängig von der Außentemperatur – das Brutgeschäft auf. Aber auch das ist nur ein Faktor, die absolute Außen-Temperatur spielt auch eine Rolle und kann zu einem früheren Beginn führen, Kollegen berichten z.B. schon jetzt zu Hl. Dreikönig von Brut in den Völkern! Mit dem milden Winter gibt es also auch frühere Startpunkte. Für die Bienen ist das natürlich eine Wette auf Leben und Tod, wenn es gut geht, d.h. das Futter reicht und sich auch kein Futterabriss einstellt – weil es doch mal noch kälter wird und die Bienen auf der Brut sitzen bleiben und sie wärmen und dann nicht zum “Treibstoff” nebenan kommen und so auf gut vollen Waben verhungern – haben sie einen Entwicklungsvorsprung von anderen Vökern, die erst später mit dem Brutgeschäfft anfangen. Wenn das Futter nicht reicht, weil sie gegen zu viel Kälte heizen müssen oder sie nicht ans Futter kommen kann es auch den Tod des Volks bedeuten.

Der Brutbeginn ist also ein wichtiger Faktor, damit hängt dann auch wieder die Varroavermehrung zusammen, der Futterverbrauch, die Futterversorgung von außen. D.h. für die erste Aufwärtsentwicklung können neben den Temperatursummen noch andere gravierende Faktoren dazukommen.

1 Like
11

Bleibt noch die Frage ob dank Klimawandel der Brutbeginn überhaupt noch so relevant ist - zumindest meine Bienen brüten bisher mehr oder minder durch. Es soll ja auch Imker geben die den Bienen “etwas gutes tun” und sie in Italien überwintern, was die Winterpause auch deutlich verkürzen düfte. In den Tropen gibt es eh keine wirkliche Brutpause. Brutbeginn erfordert typischerweise Pollen (so die klassische Denkweise) und den gibt es hier meist mit der Blüte der Salweide, deswegen ist es sicher auch spannend die Blühphasen in Dashboard zu haben.

Habe mal etwas mit dem Modell gespielt für zwei extreme (wobei dann doch wieder recht ähnliche Standorte) List auf Sylt und Oberstdorf (die nördlichste und südlichste DWD Station). Hier erst mal die Brutzellen und die Zahl der Bienen über die letzten beiden Jahre:

Entwicklung

Und dann das Verhältnis von Brut zu Bienen:

Verh%C3%A4ltnis

Hier sieht man, erst mal, daß das Modell natürlich im ersten Monat nicht brauchbar ist (Anfangswert für Bienen war 0). Es fällt auf, daß eigentlich nie Schwarmstimmung einsetzt (Sterblichkeit zu klein?) und im zweiten Jahr in Oberstdorf die Brut früher beginnt - da war es letztes Jahr offenbar Anfang März mal zwei Wochen kurz recht warm.

Eine Schwäche ist sicher auch, daß hier alle Bienen berücksichtigt werden. An anderer Stelle habe ich aber einmal gelesen, daß es vor allem die Ammenbienen sind und gerade bei einer Massentracht wird im Volk eben auch schnell einmal umgeschult, damit mehr zum sammeln raus können (siehe Seeley).

3 Likes
12

Nachtrag: Eigentlich müsste man mit den Daten die wir ohnehin schon haben auch die Sammelbienen abschätzen können

  • Gewichtsverlust am morgen / Gewicht einer Biene
  • Honigeintrag über den Tag / (Honigblase * Sammelflüge/Tag)

Falls jemand einen der Lichtchranken-Bienenzähler an seiner Beute hat könnte man das sogar einmal validieren - dann reicht es schon fast für ein halbes Paper.

13

Korrekt! Siehe auch die Beschreibung der shift() Funktion als Bestandteil der neuen Anfragesprache Flux.

Examples

Shift forward in time

from(bucket: "hotzenplotz")
	|> range(start: -5m)
	|> shift(shift: 12h)

Shift backward in time

from(bucket: "hotzenplotz")
	|> range(start: -5m)
	|> shift(shift: -12h)
1 Like
14

Wird leider nicht so einfach sein, da ja während die “Spätaufsteher” erst ausfliegen, die ersten frühen schon wieder reinkommen. Wir wissen nur, wann die Bienen anfangen auszufliegen, da gibt es eine Gewichtssenke in der Grafik. Dann kommen wieder Bienen mit Nektar rein, es fliegen aber auch wieder wlche aus. Wie viel eine Biene tatsächlich einträgt hängt auch von der Flugstrecke ab, wenn sie weit weg muss ist der Eintrag weniger, da sie auch Futter für den Flug braucht. Daher werden wir die Ausflüge / Sammlerinnen nicht alleine mit dem Honigblaseninhalt errechnen können. Auch beim Nektar gibt es Unterschiede in der Zusammensetzung, vielleicht bekommen auch die Sammlerinnen wenig und kehren mit halbvoller Honiglbase zurück. In der Zwischenzeit trocknen die Bienen auch wieder den Nektar, d.h. am Abend ist weniger da als absolut gesehen eingetragen wurde.

Habe ich, liegt als Prototyp schon Jahre im Schrank. ;-)s

15

Was davon hast Du im Schrank: den Zähler oder das paper?! ;p

16

Den bee counter! ;-) fürs Paper hab ich deswegen noch keine Daten.

17

Zusammenstellung einiger öffentlicher Quellen für offizielle fortlaufend aktualisierte Grünlandtemperatursummen für Deutschland

ISIP

Übersicht und Auswahl::

https://www.isip.de/coremedia/generator/isip/Kulturen/Gruenland/GruenlandTempSum/Land.html

direkt: Baden-Württemberg, Bayern, Brandenburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz und Saarland, Sachsen, Sachsen-Anhalt

Für Schleswig-Holstein und Thüringen sowie die Stadtstaaten sind keine Messungen ausgewiesen, zumindest für die letzteren sind aber in deren Randregionen representative Stationen der angrenzenden Bundesländer zu finden.

DLR RLP

Über die Dienstleistungszentren Ländlicher Raum Rheinland-Pfalz (DLR RLP) lassen sich die GTS für die Stationen folgender Bundesländer finden:

Baden-Württemberg, Bayern, Rheinland-Pfalz und Thüringen

Die Werte der identischen Stationen zwischen ISIP und DLR RLP sind gleich (kaum verwunderlich), der Voraussagezeitraum ist aber bei letzteren vier Tage länger. Bei DLR RLP sind außerdem noch die historischen Werte ab 1994 an gleicher Stelle abrufbar.

1 Like
18

Beispiel für die Darstellung von Grünlandtemperatursummen (GTS) in Grafana

Abbildung für Januar: 0,5 * (positive Tagestemperatur-Mittelwerte)

Die beispielhafte Darstellung ist geringfügig zu optimistisch, da u.a. der Startwert nicht richtig in die Kalkulation genommen wird / werden kann in IFQL. Umsetzung auf FLUX ist noch in Arbeit.

image
image.png1000×500 41.6 KB

2 Likes
19

Eine erste Umsetzung in Flux ist für die DWD-Daten fertig: Ein Query, der aus drei einzelnen Queries für die jeweils anders gewichteten Zeiträume besteht, die resultierenden Tabellen mittels union() in einer zusammenfasst und diese dann als Tageswerte yield()et sowie ne akkumulierte Summe rauswirft:

jan = from(bucket: "dwd_cdc")
  |> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)
  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2" and
      r.produkt == "10_minutes"
     )
  |> aggregateWindow(every: 1d, fn: mean)
  |> keep(columns: ["_value", "_time"])
  |> filter(fn: (r) => r._value > 0)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 0.5
    }))
  
feb = from(bucket: "dwd_cdc")
  |> range(start:2019-02-01T00:00:00Z, stop: 2019-02-28T23:59:59Z)
  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2" and
      r.produkt == "10_minutes"
     )
  |> aggregateWindow(every: 1d, fn: mean)
  |> keep(columns: ["_value", "_time"])
  |> filter(fn: (r) => r._value > 0)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 0.75
    }))
  
rest = from(bucket: "dwd_cdc")
  |> range(start:2019-03-01T00:00:00Z, stop: 2019-12-31T23:59:59Z)
  |> filter(fn: (r) =>
      r._measurement == "dwd_cdc_temp_2m_c" and
      r._field == "value" and
      r.sta_name == "$COMMON_CDC_NAME" and
      r.quality_level == "2"  and
      r.produkt == "10_minutes"
     )
  |> aggregateWindow(every: 1d, fn: mean)
  |> keep(columns: ["_value", "_time"])
  |> filter(fn: (r) => r._value > 0)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value * 1.0
    }))
  
union(tables: [jan, feb, rest])
  |> sort(columns: ["_time"], desc: false)
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value,
    foo: "Tag"
    }))
  |> yield(name: "bars")
  |> cumulativeSum(columns: ["_value"])
  |> map(fn: (r) => ({
    _time: r._time,
    _value: r._value,
    foo: "Total"
    }))

Oder auch zum Angucken als dediziertes Dashboard im DWD-Folder: Wetter: DWD / Grünlandtemperatursumme (GTS) und Kältesumme

Wo sich des mit den separaten Zeiträumen und Schwellwerten nun so schön in Flux abbilden lässt: Wünscht sich jemand noch andere, Pflanzen/Bienen/Einhörner-spezifische, Temperatursummen? [Da gibts ja noch ganz andere Rechenwege für andere Pflanzen. Edit: Damn, sind ist immernoch keine Exponenten berechenbar in Flux. Auch selbst eine Exponentialfunktion zu implementeren scheint mir bislang nicht trivial.]

2 Likes
20

Flux Abfragemonster here…

jan = from(bucket: "dwd_cdc")
    |> range(start:2019-01-01T00:00:00Z, stop: 2019-01-31T23:59:59Z)

    [...]

Saustark! Sieht nach ordentlich bewältigter Flux Lernkurve aus.

P.S.: Bei Gelegenheit muss ich mir von Euch mal erklären lassen, was Ihr da tut.

1 Like