Hallo @Andreas ,
ein ganz herzliche Dankeschön für Deine Blitzanalyse.
Punkt1 zur URL Adressierung habe ich sofort umgesetzt.
Für Punkt 2 werde ich mich auf die Suche begeben,
leider war diese anfangs noch nicht recht ergiebig was die Dokumentation zum Thema Filter Event Data angeht - aber ich bleibe dran!
Besten Dank!
Stefan
Ich arbeite jetzt an https://github.com/daq-tools/kotori/pull/81 weiter, damit ist die Lösung eigentlich gleich ums Eck. Du musst also nicht weiter schauen.
Hi @Thias,
ich habe jetzt mal jegliche bei TTS-/TTN-Daten an Kotori weiterleiten - #40 by Thias und vorher besprochenen Dinge rund um die Mehrfachteilnehmeroption weggelassen und nur die Einzelteilnehmervariante realisiert.
Sobald wir die live schalten, bleibt Dein funktionierender Datenkanal hiveeyes/thias/freiland/hive1 davon unberührt, aber Dein bisher nicht funktionierender hiveeyes/thias/freiland/hiveeyes-thias-freiland-hive1 sollte dann funktionieren. Da sie unterschiedliche Kanalnamen haben, kommen sie sie m.E.n. nicht in die Quere und laufen einfach parallel.
Wenn Du Dir wünschst, dass wir den neuen Kanal dann hernach in den alten konvergieren lassen wollen, können wir dann ja sehen, wie wir das realisieren.
Einverstanden?
Viele Grüße,
Andreas.
Hi Andreas,
Schön, dass hier wieder Schwung rein kommt!
Ich bin nach wie vor der Auffassung, den Datenkanal / das Topic aus der device_id des full Payloads abzuleiten. Das macht es erst möglich, mehrere Geräte unter einer TTN Application mit dem entsprechenden Webhook universal zu behandeln. Neben decoded_payload wünsche ich mir die Extraktion weiterer Felder aus dem Full Payload analog zu [1]. Erst dann werde ich auf putsreq verzichten können.
Eine Applikation per Device mit jeweils fixer URL im Webhook ist unschön im Aufbau
[1] terkin-datalogger/putsreq.hiveeyes.ttn_v3.js at main · hiveeyes/terkin-datalogger · GitHub
Hi Matthias,
Ja – danke Stefan! Und auch an Dich und diesen schon lange reifenden Patch denke ich immer wieder regelmäßig.
Ich bin ganz der gleichen Meinung, will nur den Schwung nutzen, das häppchenweise reinzubringen, daher habe ich einen Teil aus [1] nun nach [2] verschoben, da ich an dieser Stelle damals nicht mehr gut weiterkam, sofern ich mich richtig erinnere [3].
Verstanden. Hierzu hatte ich mir gemerkt, dass wir doch beim ttnlogger bzw. beim PutsReq Umsetzer putsreq.hiveeyes.ttn_v3.js schon alles dafür Relevante erarbeitet hatten – stimmts?
Das stimmt schon, aber für einfache ad-hoc Datenweiterleitungen auf Einzelgerätebasis ist es doch auch ganz wunderbar im Standalone Modus, finde ich. Und dazu kommt, dass diese Variante eben denkbar einfach zu realisieren/dokumentieren/erklären ist [3:1]. Die fortgeschrittene mandantenfähige Variante kommt dann hinterher, ein wenig Arbeit ist dafür noch notwendig, glaube ich.
Viele Grüße,
Andreas.
[WIP] [TTN] Add experimental TTS/TTN HTTP Webhook forwarder by amotl · Pull Request #132 · daq-tools/kotori · GitHub ↩︎
Technisch ist dafür halt im Kotori einfach nur ein “Dekoder” notwendig, der sehr einfach gestaltet werden kann. Leider gibt es bislang noch keinen Mechanismus, wo Dekoder Komponenten gezielt Einfluss auf die Adressierungsdaten nehmen können. Aber ich hoffe auch, dass das bald möglich sein wird ;]. ↩︎ ↩︎
Der Patch wurde auf swarm in Betrieb genommen. Bei TTS/TTN decoder — Kotori 0.27.0 documentation gibt es die Dokumentation dazu. Könnt Ihr die Dokumentation prüfen und mir berichten, ob es genau so klappt, wie dort beschrieben?
@Thias: Von Dir kommen Daten auf den besagten neuen Kanälen an. Von Dir, @Stefan, habe ich gerade keine gesehen.
Das hier scheinen die Panels der neuen Datenkanäle zu sein. Das klappt ja soweit ganz gut.
Die individuellen Dashboards dafür sind zwar nun auch da, aber dort passen höchstwahrscheinlich die Feldnamen nicht zusammen – wie auch ;].
Hi Andreas,
ja, da kommt was an. zB in meinem Dashboard für meinen Stand im freiLand:
Allerdings taucht da jetzt auch mein zweiter Standort auf. Aber gut, ich filtere die erstmal im Dashboard raus.
Ich denke, wir kommen langfristig nicht um einen dedizierten API Endpunkt für alles was von TTN kommt nicht herum.
Dieser löst dann die devID (mit -) auf in das Topic (mit /). Die devID wird dabei in der TTN Applikation von Anfang an angelegt mit hiveeyes-MANDANT-STANDORT-VOLKNAME, eine volle Beispiel-URL wäre also:
https://swarm.hiveeyes.org/apittn/hiveeyes-<imker>-<standort>-<volk>/data
bzw., technisch generischer betrachtet:
https://daq.example.org/apittn/<kollektiv>-<imker>-<standort>-<volk>/data
https://daq.example.org/apittn/<realm>-<user>-<location>-<node>/data
Neben dem decoded_payload werden noch die oben referenzierten Datenfelder zur Signalqualität etc gefiltert und der Rest verworfen. Den full Payload brauchen wir nicht in die Datewnbank zu kippen, denn der Großteil ist meta und für uns absolut irrelevant.
Der Webhook wäre dann generisch:
devID verbirgt sich auch im vollen Payload unter:{"end_device_ids": {"device_id": "hiveeyes-thias-freiland-hive1"}, ...}
Ich hatte das schon so vorgeschlagen, wollte es aber hier nur noch mal zusammengefasst hier niederschreiben. Ob das auch so realisierbar ist. hast du einst nicht kommentiert. Ich weiß auch nicht, ob der Zwischenschritt von dir nötig ist, oder ob der universelle one-fits-all Pfad am Ende sogar Entwicklungzeit spart.
Dürfte denn die devID eigentlich auch Forward-Slashes "/" enthalten, so dass an dieser Stelle u.U. gar kein Sonderweg notwendig wäre? 
Vermutlich wird das nicht möglich sein, sonst ergäben sich haufenweise lustige Probleme für unbedarfte Endnutzer.
Andersrum dürfen bei Kotori bisher Dashes "-" in der Addressierungskomponente enthalten sein, daher müssen wir das für die Kanaladressierung per URL vermutlich tatsächlich so machen wie vorgeschlagen, mit einem gesonderten Präfix wie "/apittn", der mir aber eigentlich nicht so gut gefällt. Vielleicht ließe es sich auch mit einem besonderen Suffix realisieren, aber dazu kann ich jetzt auf die Schnelle nichts sagen. Vermutlich hing ich bei GH-132 damals an diesem Thema fest und bin damit erstmal froh, dass GH-81 endlich im Kasten ist.
Ja, ich habe beide Varianten auf dem Schirm, auch diese für “Kanaladressierung via Payload”, und würde technisch tatsächlich auch gerne beide realisieren. Danke!
Da fügen wir doch jetzt erstmal die volle Dekodierungslogik hinzu, nicht? Also jene hier, meine ich:
Nope:
Na, das wäre was! 
@Andreas: Ein ganz großes Dankeschön für Deine Unterstützung - Heureka! es klappt, keine Fehlermeldung mehr auf https://swarm.hiveeyes.org/transmissions und die Daten kommen am Instant Dashboard an. Ich bin begeistert!
Das Du keine Daten gesehen hast ist nicht verwunderlich, da mein Testaufbau “airtime” gespart hat und stromlos war.
Sieht nach meiner Einschätzung gut aus und enthält alle notwendigen Informationen
@Thias Evtl. ist es gar nicht nötig eine eigene Applikation per Device anzulegen.
Laut Webhook Guides kann man die Device ID als Variable für den Pfad verwendet werden.
So könnte man mit einer Webhook, mehrere Devices bedienen und die Device ID im Pfad mit übermitteln.
Beispiel aus dem Webhook Guide:
For example, if the Base URL is
https://app.example.com/lorahooks{/appID}and the Path is/up{/devID}an uplink from the devicedev1of applicationapp1will be posted athttps://app.example.com/lorahooks/app1/up/dev1.
Und als ich den Link zum Webhook Guide eingefügt habe, hat mich die Forums-Software drauf hingewiesen, das @MKO hierzu bereits über die Möglichkeit geschrieben hat Variablen für den Pfad bei Webhooks zu verwenden.
Exzellent. Danke.
Ja, genau darum [1] geht es in unseren Diskussionen, die sich mittlerweile schon etwas in die Länge ziehen. Es muss nun endlich einmal Code folgen, der das optimal realisiert. Bei GH-132 geht die Reise weiter.
Wir peilen auch noch eine weitere Variante an: Mit dieser – “Kanaladressierung via Payload” genannt – wird vollständig darauf verzichtet, die Adressierungsinformationen über die URL zu übermitteln, sondern sie werden stattdessen aus dem Nachrichteninhalt geholt. Dafür darf dieser natürlich noch nicht an der Stelle so stark gefiltert werden, wie Du es derzeit tust [2], sondern muss am besten vollständig übermittelt werden. ↩︎
Daher finde ich auch Dein Beispiel so wunderbar, weil es zeigt, dass es für diese Fälle “mit starker Filterung” gut ist, die herkömmliche Adressierungsvariante zu benutzen, die Kotori schon generisch beherrscht, und nun per GH-81 um den TTN-Dekoder erweitert wurde. ↩︎
Bitte stelle sicher, dass Du für den Produktivbetrieb dann nicht mehr den testdrive Kanal benutzt, sondern Deinen eigenen. Du hast bereits einen Account, ja?
Wie bestellt… ;].
Restarting…
P.S.: Was bin ich froh, wenn wir den Eumel endlich weg haben!
Ja, das geht - auch im Upload Path. Hatte ich im meinem Beispiel oben schon genutzt.
Problem bleibt, dass es auf der gleichen Applikation keine Variabilität in allen Topic Leveln gibt. Ich benötige es zB um Standorte zu unterscheiden. Ebenso testdrive/hiveeyes gehört auf den ersten Topic Level. Und wie gesagt, ich möchte (ihr auch?) alles in einer Applikation.
Um weitere Verwirrung zu stiften, habe ich bei [Proposal] Add a generic device-based addressing scheme for "WAN" networks · Issue #133 · daq-tools/kotori · GitHub gerade einen Vorschlag eingereicht, der einige der hier vorgestellten Aspekte aufgreift, und versucht, sie in ein allgemeines neues Annahmeverfahren zu generalisieren, das nicht unbedingt TTN-spezifisch ist [1].
Auf unseren Anwendungsfall gemünzt, sähen entsprechende URLs damit beispielhaft folgendermaßen aus.
# Device ID kommt aus der URL.
https://swarm.hiveeyes.org/api/hiveeyes/d/testdrive-backyard-hive1/data
# Device ID kommt aus der Nachricht.
https://swarm.hiveeyes.org/api/hiveeyes/data
Das Schema ist nicht viel anders gegenüber den ursprünglichen Vorschlägen. Die Unterschiede sind:
a) Es gibt einen speziellen URL Infix "/d", der einer Device ID vorangeht.
b) Der Realm bleibt außerhalb der Device ID, "hiveeyes" ist also nicht enthalten.
Die hier vorgestellte Lösung ginge auf jeden Fall in diese wartungsarme Richtung, da beide Annahmevarianten parallel implementiert werden und damit von Haus aus zur Verfügung stehen, ohne dass vorab administrativ-operativ eingegriffen werden müsste.
Wenn alles gut geht, würden die TTN-spezifischen Dekodierungsaspekte weiterhin vom bereits etablierten passiven TTN Dekoder abgedeckt, der, wie andere Kotori Dekoder auch, weitgehend heuristisch arbeitet, und daher keine speziellere Konfiguration benötigt. ↩︎
hiveeyes wäre dann in beiden Fällen fixiert und nicht variabel für einem anderem Realm. Könnte also genauso in die Device ID gezogen und aus der URL entfernt werden.? Entsprechend:
# Device ID kommt aus der URL.
https://swarm.hiveeyes.org/api/d/hiveeyes-itest-foo-bar/data
# Device ID kommt aus der Nachricht.
https://swarm.hiveeyes.org/api/data
Ersteres geht voll in die Richtung meiner ursprünglichen Gedanken. Jedoch muss Kotori anschließend erkennen, welche Struktur es im vollen Payload erwartet und das dann entsprechend verarbeiten. Heute nutzen wir ungeschachtelte JSONs und jetzt zusätzlich die stark strukturierten von TTN v3. Was kommt morgen? Ein eigener Endpunkt für jeweilige Varianten und Konventionen will mir immer noch nicht aus der Birne.
Genau. Ja und nein. Der Realm ist fester Bestandteil der Basisadressierung und daher auch fest verdrahtet. Zwar flexibel, aber doch manifest in der Konfiguration pro “Kotori Anwendung”, die das komplette Kanalbündel verwaltet und betreibt. Hier ein Beispiel:
Erst hinter dem Realm geht es dann los, dass der Benutzer individuelle Dinge bestimmen kann, normalerweise startend mit einer Adresskomponente für die Benutzerkennung, bei uns “Imker ID”.
Der Hintergrund dafür, dass wir fest bekannte Präfixe und Suffixe so dringend brauchen – in diesem Fall der Realm, aber auch die bekannten “/data” oder “/event” Suffixe – ist, das wir beide als Ankerpunkte im Suchausdruck brauchen, damit das dazwischen befindliche {address:.*} so flexibel bleibt, verschiedene Strategien bei der Umsetzung der Topologie anwenden zu können.
Das ist jetzt zwar sehr technisch, aber so sieht derzeit die Konfiguration der Vermittlungsschicht von Kotori aus, und irgendwie müssen die neuen Anforderungen durch dieses Nadelöhr.
Langer Rede kurzer Sinn: Der Realm ist nach aktuellen Richtlinien fix in der URL. Ich hoffe das ist nicht allzu enttäuschend für Dich.