Das ist leider nicht so, default ist keine annotation aktiviert:
Die dann tatsächlich einzurichten ist gar nicht so einfach, weil man erst mal rausfinden muss wie die Datenbank / “Tabelle” / Untergruppe genau benannt ist.
Weiter passen die Feldnamen nicht, im Demo-annotation dashboard gibt es drei Felder
während bei meiner neu erzeugten Datenbank nur zwei Felder erscheinen
Und die werden auch nicht korrekt zugeordnet
die Tags erscheinen da wo eigentlich der Titel hin soll …
Wenn es annotations gibt, die genau den gleichen timestamp haben
2018-03-29 Schlehe
2018-03-29 Rosskastanie
ich habe beide mit time=‘2018-03-29T00:00:00 CET’ eingetragen - erscheint immer nur die zuletzt eingetragene. :-(
Klar, alle, die automatisch ‘on-boarded’ haben (z.B. alle “hiveeyes open-hive-* automatic”) haben (mindestens) einen Kanal namens Events default_1. Beim manuellen Anlegen eines dashboards, so wie Du das jetzt bestimmt gemacht hast, passiert das nicht.
Ah, die automatic haben das. Gut, dann habe ich das “beim Anlegen des Dashboards” falsch verstanden. Und siehe, da brauche ich auch nicht die Annotation-DB auswählen und tags / title / text stimmen auch. Da habe ich mich unnötig gequält:
Hi Clemens,
schön, dass Du Dich für die Details der Implementierung bei den Annotationen interessierst.
Jep, habe ich auch so beobachtet.
Da bin ich mir auch noch nicht sicher, was zukünftig besser passt bzw. für die Benutzer komfortabler ist. Wir wollen ja - wie immer ;] - dass sich das System DWIM-konform verhält.
Nein, die Annotationen, die man derzeit über die Kotori API absetzen kann, landen in der InfluxDB, während die im Grafana selbst erzeugten Annotationen in der Grafana-internen Datenbank gespeichert werden.
Danke für den Link! Es wäre ja ggf. schön, wenn man über die Kotori API zukünftig beide Varianten ansteuern kann, nicht?
Toll, Du hast ja mittlerweile schon erste Erfolgserlebnisse erzielt, stimmts? Gratuliere!
Viele Grüße,
Andreas.
Exzellent!
Feine Idee! Das können wir gern bei Gelegenheit für "phenodata" nachreichen.
Sehr schön!
ja, bei der neuen Art der interactive annotations ist offenbar noch nicht alles so beisammen, wie es könnte. Merkwürdigerweise gilt title als deprecated, wie auch aus einem Bild oben von Dir zu sehen ist. Es sieht so aus, als wenn aus irgendeinem Grund title zugunsten in etwas der interactive annotations aufgegeben worden sei - immerhin scheint die HTTP annotations API title noch wie immer zu honorieren, und ein gültiger title wird offenbar noch richtig angezeigt.
Aber jedenfalls ist das noch nicht ganz fertig, z.B. bei der sunmoon datasource im Grafana werden die tags innerhalb dessen sun* events’ auto annotations verhackstückt, und der Mond bekommt keine tags mehr:
Wenn wir die phänologischen Daten irgendwann mit den Sensordaten in Zusammenhang bringen wollen (Blühbeginn Obst → Gewichtsanstieg Volk) wäre es vorteilhaft beides in der selben Datenbank zu haben, daher sollten wir uns für einen Speicherort entscheiden und für mein Verständnis wäre das die InfluxDB. Daher würde ich sagen, wenn der Kotori eines beherrscht braucht er nicht unbedingt das andere noch. - Ausser die Funktionalität ist unterscheidlich und wir wllen / brauchen das und können es nicht anders realisieren:
Ich denke da an die Anzeige in allen panels eines dashboards (über Kotori) vs. Anzeige nur in einem Panel (interaktive annotations). Z.B. Zarge aufgesetzt, daher +10 kg, das macht nur im Gewichts-Panel Sinn und verwirrt bie den Temperatur-Daten.
Wichtiger wäre mir aber, dass wir die imkerlichen Eingriffe auch von der Grafik aus “nachtragen” können und dass dann in der Beep-App landet, also der Eintrag entlang der Zeitachse, Daten dann aber in der Stockkarte.
Unter Annotationen im Grafana über die HTTP/MQTT API findest Du weitere Details dazu, daraus ist auch das Programm RPi-Beelogger/set-mqtt-annotation.py at master · beelogger/RPi-Beelogger · GitHub von @mhies entstanden.
Darüber hinaus wollen wir Dich noch auf Ereignisse interaktiv im Grafana annotieren hinweisen, hier wird die alternative Variante zum interaktiven Erstellen und Bearbeiten von Annotationen beschrieben.
Genau, das entspräche mit viel Phantasie der minimalen Variante einer Stockkarte. Wir wollen die Möglichkeiten zu reichhaltigeren Stockkarteneinträgen an dieser Stelle zukünftig noch ausbauen. Auch phänologische Informationen könnte man auf diese Weise einblenden, wie z.B. bei phenodata-berlin-dahlem schonmal geübt.
OK, das werde ich mir mal anschauen. Meine Frage war eher ob jemand dafür schon etwas fertiges hat, evtl. auch als App. Aber das kommt vielleicht irgendwann noch. Ich denke auch mal, daß dann nicht jeder alles öffentlich haben will (z.B. die Erträge).
Zu den Phenodaten könnte man ja überlegen die Datenbank zum Blühphasenmonitoring vom DLR ähnlich wie die DWD Wetterdaten anzubinden. Wobei da natürlich die Standorte nicht fest sind, man müsste also mit Radien oder Regionen arbeiten.
Ich hatte den code direkt aus dem Post (Daten per MQTT ans Backend auf swarm.hiveeyes.org übertragen) kopiert, nicht aus dem Beispiel hinter dem link…
Zu beachten ist aber, dass beide Arten von Annotationen in unterschiedliche Datenbanken abgespeichert werden. Erstere werden in der InfluxDB neben den Meßdaten abgelegt, zweitere werden standardmäßig nur in der Grafana-eigenen Datenbank gespeichert.
@einsiedlerkrebs und ich haben gerade herausgefunden, dass der Speicherort der interaktiven, per Grafana editierbaren Annotationen konfigurierbar ist und es damit vermutlich ebenfalls möglich ist, die Daten in der InfluxDB zu speichern.
Wir werden zusehen, dass wir das Subsystem in die entsprechende Richtung treiben, so dass sowohl die interaktiv als auch die per API erzeugbaren Annotationen im selben Speicherort landen.
und bei einem darstellungsproblem wäre ich auch noch für tipps dankbar. es ist ein bisschen wie das von clemens vor gut einem jahr: in dem einen dashboard siehts gut aus:
in dem anderen erscheint meine datenquelle statt dem titel:
hat’s mit dem anlegen des dashboards zu tun (hab ich manuell gemacht, indem ich json kopiert und gepastet und dabei den hash in der url verändert habe)?
lässt sich das im nachhinein noch fixen?
Hm.
Nur direkt in der Datenbank. Daher sind die interaktiven Ereignisse eigentlich auch komfortabler.
Erinnere mich bitte bei Gelegenheit nochmal, wenn es sehr stört. Tritt es bei vielen Annotationen bei Dir auf?
ja, wie auf den screenshots zu sehen: in dem alten dashboard kommen alle gut raus und bei dem neuen dashboard alle schlecht.
und: sehr stören tut es nicht. gibt sicher wichtigeres. und wenn es sich nebenher klärt, wenn ihr mal solche automatischen annotationen wie die mit dem mond rausputzt, dann reicht das allemal.
Ok, danke.
Das wird es leider nicht. Das ist die Baustelle einen Meter weiter. Wir können jetzt allerdings Grafana: Annotationen direkt in der Datenbank manipulieren, das geht in die Richtung dessen, was Du brauchst. Wenn Du uns die betreffende Dashboard-ID ansagst, dann schauen wir vielleicht bei Gelegenheit.
wenn ich das mit der ID richtig gecheckt habe, dann hat der dashboard, auf dem es stimmt, die 130 und der mit der verkorksten anzeige hat die 548.
Dort gibt es gerade nur einen einzigen Eintrag:
sqlite> select * from annotation where dashboard_id=548;
5211|2|0|4|548|34||||keene ahnung wat hier los war?!|||||1560184524419|0|["explained","downtime"]|1560297241399|1560297241399
Achso: Deine Ereignisdaten stehen - per Annotationen im Grafana über die HTTP/MQTT API kommend - ja direkt in der Zeitseriendatenbank und nicht in der Grafana-internen Datenbank, daher waren sowohl mein Hinweis auf Grafana: Annotationen direkt in der Datenbank manipulieren als auch meine Frage nach der Dashboard-ID nonsense. Tut mir leid.
Daten in der Zeitseriendatenbank zu manipulieren, ist unseren Erfahrungen nach aufwendiger.