Ick hab nix gemacht … zum Userinterface: Erst nen einfaches “Enter” in dem Flux-Query führt diesen Query auch neu aus. Rechts erscheinen dann die resultierenden Tabellen. (ne neue Zeile legt mensch mit shift+enter an.)
1 Like
Danke! Hatte gestern die query geändert und mich gewundert, dass sich nix tut auch nachdem man den edit-Modus verlassen hat. So ist das also!
noch ne kurze Anmerkung: die Gewichtsdifferenzen scheinen mir noch nicht voll belastbar, bzw scheint es mind. nen leichten Unterschied im windowing o.ä. zw. flux query (graphen oben) und influx-query in den diskreten panels zu geben, den wa noch erstudieren müssen. gebe denn hier bescheid, wenn ich was hab.
1 Like
Hatten wir da nicht auch unterschiedliche Implementierungen? z.B. habe ich das verwendet:
SELECT derivative(last("Gewicht"), 1d) FROM "default_2_sensors" WHERE $timeFilter GROUP BY time(1d) fill(null)
1 Like
Hi @clemens,
Meinst Du, wir könnten die BeeKloppten danach fragen bzw. sie dafür begeistern, die Positionen ihrer Stöcke wahlweise ±2.4 km oder ±20 km verunschärft mit in die Datenbank zu tun, damit wir hier auf die aktuelle Technik noch eine Schippe drauflegen könnten?
Mit “echten” Daten macht das Ganze halt einfach mehr Spaß.
Merci,
Andreas.
3 Likes
Ja, das wirkte irgendwie vonner Mathe her bislang noch recht buggy, sowohl im influxdb- wie im flux-query. ich hab jetzt beide mal auf Flux gemacht und folgende Magien gefunden, die denn machen, dass da jetz auch besser hinzuhauen scheint. (aka: Bitte nochmal nachrechnen … [edit: “Stichzeit” für den Tageswechsel scheint mir 01:00:00 in der default=browsertime=MEZ-Ansicht zu sein.])
Neu im Query ist unit: 1d im derivate() sowie der shift(shift: -1d):
from(bucket: "$beekeeper")
|> range($range)
|> filter(fn: (r) =>
r._field == "Gewicht"
)
|> derivative(unit: 1d)
|> aggregateWindow(every: 1d, fn: mean)
|> shift(shift: -1d)
|> map(fn: (r) => ({
_time: r._time,
_value: r._value * 1000.0,
_field: "tägliche Differenz"
})
[edit: ps.: Die Einzelangaben der Gewichtsdifferenzen in dem “Mini-Dashboard” sind noch nicht angepasst und bislang auch noch ausstehender Gegenstand “feiner Query-Schmiedereien”. Da kommt auch noch nen Update, ich geb bescheid. Dauert aber nochn bisschen; das Boom-Table-Plugin scheint nen bisschen allergisch auf ne Flux/InfluxDB-Querylanguage-Vermischung zu reagieren.]
1 Like
Ich konnts nicht lassen. Ging doch mit Flux & InfluxDB im selben Boom-Table-Panel. Allerdings ist der Wert von “letzte 24h” jetzt starr auf “ab jetzt”. Da müsste mensch vmtl. den Grafana-Leuten nen Ticket für weitere “start/stop current time-selection”-Variablen und passende Fütterungsmöglichkeit gen range(start/stop: xy) aufmachen bzw schauen obs das schon hat, damit des mit Flux funktioniert.
Ich probier grad auch häufiger die Versionierungs-Kommentare von Grafana (in den Dasboard-Einstellungen unter Versionen) zu nutzen, diese Changes in der Gewichtsberechnung sind dort mit “[critical]” versehen.
1 Like
Das ist in der Tat so, da in der BeeKloppten-Nomenklatur alles auf deutsch ist. Aber Du scheinst ja im Statista-Dashboard Dir schon einiges wiederzurechtmappen zu können. Yay :)
Aber es würde IMHO schon mal zu diskutieren gelten ob wir in solchen “nicht, dass das noch nen Standard wird”-Situation die Nomenklatur doch lieber auf englisch abhandeln sollten.
Ick hab mir aber die BeeKloppten ja auch selber ausgesucht und des eben weil da ja soviele kohärent gepflegte Datenreihen verschiedener Nasen rumfliegen.
2 Likes
Na wer von denen hat denn alles nen Useraccount in diesem Forum und will in diesem Thread noch unbedingt gementioned werden, auf dass die denn mal ne Mail bekommen, die sie hierher lotst? Die haben doch sicher noch nicht alle den Honig gerochen …
Ich glaube tatsächlich, die wenigsten sind hier. Vielleicht wäre das mindestens ein Anlass für eine Einladung. @Clemens?
1 Like
Ja, sollten wir so machen!
Teilweise wenig technik-affin, was unsere Sachen hier angeht, wollen nur eine Waage, die funktioniert und die würden wir hier überfordern oder sie würden sich denken, was solll der Schlll hier?!?? Daher eher nicht einladen!
Gut, dann pauschal “Brandenburg” annehmen als nächstgelegene Wetterstation?
Na können wir nicht @clemens als “Sprachrohr” zu den Beekloppten nutzen und Dich bitten denen einfach mal ne kleine Mail mit den zwei Punkten zu schicken?
a) da gibts jetzt so ne neue Ansicht, wollt Ihr mal ausprobieren?
b) isses für dich ok deinen Stock mit ner Geokoordinate wgn DWD zu versehen? wann ja, bitte schick die Koordinate und sind 2.4km Verungenauung ok?
Den Rest übernimmt dann Cobra 11.
1 Like
Missing blue sky! Noch ein kleiner bug-report zu den Wolkendaten: Mir ist gestern aufgefallen, dass in Zeiten ohne jedes Wölkchen in der Wolken-Grafix nix angezeigt wird, so bald eine Wolke im Zeitraum da ist passt das wieder.
Z.B.: Grafana zeigt noch Wolkendaten an: Etwas am Anfang des ausgewählten Zeitraums und etwas mehr am Ende:
Zoome ich nun in den wolkenlosen Zeitraum hinein Grafana erscheint kein blauer Himmel mehr, sondern es werden beim Wolken-Panel keine Werte mehr angezeigt, eigentlich sollte aber eine wolkenlose blaue Fläche erscheinen.
don’t blame @wtf, Du hast einen Zeitraum aus Mitte April bis MItte Juni 2018 angegeben. Da haben wir nicht unbedingt Wolkendaten. Rechts siehst Du ein Stück, das möglicherweise aus MOSMIX mitreingerendert wird.
gerade nachgeschaut: da gibts keine Wolkendaten: https://weather.hiveeyes.org/grafana/d/shzA3o6kz/stationsansicht-cdc?orgId=1&from=1523826700796&to=1529097100797 (default: Tegel)
Hört sich jetzt kryptisch an, aber: wetta hat für die Bewölkungsmetriken und v.a. im Hinblick auf deren Darstellung einige Ausnahmen gemacht, die auch die CDC- und MOSMIX-Datenbanknutzung in diesem speziellen Fall der Wolken betreffen. Das alles und warum das nicht immer gut klappt, soll besser er Dir erklären.
Daß man beim Reinzoomen dann nichts mehr sieht, hängt leider mit dem discreet-plugin zusammen, das zeigt halt leider nur was an, wenn was da ist. ;) Wenn von z.B. vier Wolkenhöhen nur drei da sind im angezeigten Zeitraum, dann werden auch nur drei Bänder gezeigt, bei 0 Werten leider auch nichtmal der canvas dahinter… file a ticket, contributions welcome! ;)
Wenn diese DWD-Wolkendaten tatsächlich fehlen, kann man die nachträglich importieren, das muß aber auch wetterfrosch machen.
3 Likes
Wenn tatsächlich Daten fehlen wäre die Anzeige ok, wenn nur nichts angezeigt wird weil 0 als missing interpretiert wurde, passt was bei der Darstellung nicht. aber das kann ich von hier aus nicht nachvollziehen.
Danke, vollkommen richtig ditte allet!
Allerdings könnte man durchaus auch die Erwartung haben, dass das trotzdem funktioniert: Der value “null” wird nämlich gemapped auf “0” (oder irgendwas anderes) und auch dann nicht gerendet.
Wir könnten das ja als Nachfrage zum erwarteten Verhalten als Issue ins passende GitWeb posten?
1 Like
Das Verhalten ist: Ein einzelner Query kann mehrere Reihen/Tabellen als Ergebnis haben, für jede wird ein Balken gemalt. (Für jeweilige Zeiträume gibts halt unterschiedlich viele Reihen.) Aber “es” weiss nicht wieviele Reihen es als Ergebnis erwartet.
Vmtl. bringt mit dem Hintergrund auch nen Issue dort nicht viel: Ich seh spontan keinen passenden Knopp/Hook/Parameter für “erwartete Anzahl Wertereihen”. Hmmmmmmm…
ps.: Soweit hab ich das erstmal nur für “null”-Werte studiert. Wenn dit natürlich auch bei ner “echten 0” auch der Fall ist → geht garnicht! Ich schau mir das bei nä. Gelegenheit diesbzgl. auch nochmal an.
3 Likes
Allgemein sollten wir auf jeden Fall missings von echten “0” unterscheiden, sonst hat man mitten im Gewitter strahlend blauen Himmel, nur weil der Sensor keinen Wert, also Missings liefert. Doof ist natürlich, falls der Sensor nur Werte liefert, wenn irgendwas ungleich 0 da ist und man keinen richtigen Wert für “keine Woken” hat, dazu kenne ich aber die Daten zu wenig, um da was sagen zu können.
1 Like
das hab ich bei Statista jetzt auch so eingebaut, v.a. das dev(1d) macht komische Faktoren (_value: r._value * 1000.0 oder noch größer) überflüssig, damit hauen dann auch die Einheiten in der y2-Achse wieder hin.
derivative(unit: 1d, nonNegative: false)
3 Likes