Hallo ,
auch wenn der Thread schon eine Weile nicht mehr weitergeführt wurde, habe ich Interesse daran, ob es möglich ist mittels Webhook den empfangenen Payload vonTTN V3 zu Hiveeyes zu transferieren.
Mein Test-Aufbau sendet Daten per LoRa und dank der Infos in diesem Thread habe ich es auch geschafft das Daten bei Hiveeys ankommen - aber leider fehlt mir noch der Finale Kniff bzw die richtige Konfiguration.
Dein Anwendungsfall sieht machbar aus, vielen Dank.
URL Addressierung: Für die Datenakquise per HTTP brauchst Du - wie bei MQTT auch - noch eine vierte Komponente in der Adressierung – z.B. hiveeyes/testdrive/ulmi/device-42 – und die Endpunkt URL sollte mit /data enden, wie bei [1] beschrieben. Sonst kommt ein solcher Fehler wie Du ihn beschreibst. Vielleicht klappt es mit dieser URL schon besser:
Payload Format: Ich sehe, dass man in der TTN Web Konsole den kompletten Payload des per JSON mitgeteilten Telemetriedatensatzes schick filtern kann, z.B. per up.uplink_message.decoded_payload[2]. Nun wird es jedoch noch nicht klappen, wenn dort noch eine so verschachtelte JSON Struktur rauskommt, wie im Beispiel zu sehen.
Bietet TTN hier vielleicht noch die Möglichkeit, diese noch weiter auszupacken, um ausschließlich die Werte zu übermitteln?
{"temperature_1": 53.3, "voltage_4": 3.3}
Falls nicht, reiche ich gerne einen kleinen Patch dazu ein, der Kotori diese Dekodierungsvariante beibringt. Dann sollte eigentlich alles reibungslos klappen. [3]
Bisher haben wir hier im Thread ja hauptsächlich danach geschaut, wie wir Kotori beibringen können, den kompletten Payload zu verdauen, um mehrere Teilnehmer einer TTN Application darüber routen zu können. Dein “Einzelteilnehmer-Szenario” ist daher eine nette Alternative – bedankt! ↩︎
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!
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.
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
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.
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?
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:
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.
Wobei, der Uplink-Message Pfad (ganz unten) kann auch weggelassen werden, denn die 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!
@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 device dev1 of application app1 will be posted at https://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.
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?
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.
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.
Gedanken
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. ↩︎
