TTS-/TTN-Daten an Kotori weiterleiten

Andreas · January 19, 2022, 12:54pm

Hi Matthias,

Vielen Dank für beides! Ergänzend hier auch noch die HTTP Präambel (Request und Header) zu dem von Dir genannten Payload ^[1]:

POST /api/hiveeyes/thias/freiland/hiveeyes-thias-freiland-hive2/data HTTP/1.0
Host: swarm.hiveeyes.org
X-Real-IP: 63.34.43.96
X-Forwarded-Proto: https
X-Forwarded-For: 63.34.43.96
Connection: close
Content-Length: 1734
User-Agent: TheThingsStack/3.17.0-SNAPSHOT-d76af1e33 (linux/amd64)
Content-Type: application/json
X-Tts-Domain: eu1.cloud.thethings.network
Accept-Encoding: gzip

{"end_device_ids": ...

Als Referenz hier auch noch die aktuelle Struktur des Payloads, wie er über PutsReq an hiveeyes/thias/freiland/hive2/data.json reinkommt:

{
  "analog_in_1": 59.04,
  "analog_in_2": 58.69,
  "analog_in_3": 3.49,
  "relative_humidity_2": 78.5,
  "temperature_2": 4.2,
  "temperature_3": 3.4,
  "sf": 7,
  "bw": 125,
  "freq": 868.5,
  "counter": 2289,
  "gtw_count": 2,
  "gw_breitestr-hh-ffp_rssi": -107,
  "gw_breitestr-hh-ffp_snr": -6.5,
  "gw_machbar-ffp_rssi": -90,
  "gw_machbar-ffp_snr": 7,
  "dev_id": "hiveeyes-thias-freiland-hive2",
  "recv_at": "2022-01-19T19:02:34.007345025Z"
}

Ich schaue mir das heute Abend mal an.

Viele Grüße,
Andreas.

root@elbanco:~# ngrep -Wbyline -d lo host localhost and port 24642 ↩︎

Andreas · January 19, 2022, 6:46pm

Kannst Du die letzte Komponente, hiveeyes-thias-freiland-hive2, denn dann bei Dir (im TTN oder am Gerät?) auf hive2 ändern, oder soll ich ein entsprechendes Aliasing kurzerhand in die Routine einbauen, damit die Daten hernach auf dem gleichen Kanal wie vorher in die Datenbank gelangen, falls möglich?

Andreas · January 19, 2022, 9:53pm

Hi Matthias,

ich habe hierzu noch eine Rückfrage.

Wie in dem Screenshot zu sehen, konfigurierst Du nun die “Base URL” auf https://swarm.hiveeyes.org/api/hiveeyes/thias/freiland. Ist diese denn “pro-Device” einstellbar oder doch weiterhin “pro-Application”? Das geht aus Deinem Beitrag nicht klar hervor, oder ich habe es überlesen.

Andernfalls müsste nämlich wohl doch hiveeyes-thias-freiland-hive2 aus der device_id herangezogen werden, um den kompletten Kanalnamen zu bestimmen. Die o.g. URL könnte ja nicht generisch “für alle Teilnehmer von TTN::Hiveeyes” verwendet werden, da sie thias/freiland/ bereits mit einschließt. Das würde bedeuten, dass die URL https://swarm.hiveeyes.org/api/data lauten müsste/könnte, wenn sie “pro-Application” gültig sein sollte.

Viele Grüße,
Andreas.

P.S.: Ich gehe hierbei davon aus, dass Du die komplette Application hiveeyes multimandantenfähig versorgen willst, ohne Konfigurationsaufwände pro-Device bewerkstelligen zu müssen, nicht? Das war doch immer irgendwie unser Meta-Ziel gewesen, wenn ich mich nicht täusche? Bitte hilf mir auf die Sprünge, wenn ich in meiner Argumentationslinie irgendwo falsch abgebogen bin bzw. Dich falsch verstanden habe.

P.P.S.: Sorry, dass ich die aktuelle Variante der TTNv3 Konsole und dessen Datenmodell noch nicht kenne. Sonst könnte ich mir wohl leichter selbst einen Überblick verschaffen, wie die Dinge zusammenhängen.

Andreas · January 19, 2022, 11:46pm

Im Zuge von https://github.com/daq-tools/kotori/pull/81 bin ich auf Creating Webhooks | The Things Stack for LoRaWAN gestoßen. Dort sieht es so aus, als wäre die Konfiguration eines Webhook “per-Application” gedacht?

Thias · January 20, 2022, 2:16pm

ich habe noch einen Prototypen, bei dem ich das am Wochenende evtl machen kann. Bei den Live-Nodes müsste ich die in der TTN-App mit neuer ID anlegen und neu Joinen lassen. Dann klappt aber erstmal die Putsreq-Variante nicht mehr. Wegen devID → Topic.

Pro App. Alles Nodes darin verwenden den gleichen Webhook.

ja, das wäre eine ungeschickte Einschränkung

Oder eine andere Einstiegs-URL, zB https://swarm.hiveeyes.org/apittn/devID/data, wo devID 4-komponentig bleibt.

ja, genau. TTN Applications mit Projektgranularität (privat, Workshops, Vereine) schwebt mir weiterhin vor

Stefan · May 7, 2023, 1:31pm

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.

Meldung auf Wtee

Konfiguration des Webhooks

Für einen Hinweis, ob und falls ja, wie es möglich ist die Daten von TTN zu Hiveeyes zu bringen wäre ich dankbar.

Stefan

Andreas · May 7, 2023, 1:49pm

Hi Stefan,

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:
```
https://swarm.hiveeyes.org/api/hiveeyes/testdrive/ulmi/device-42/data
```
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.
```
{"uplink_message": {"decoded_payload": {"temperature_1": 53.3, "voltage_4": 3.3}}}
```
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]

Viele Grüße,
Andreas.

HTTP — Kotori 0.27.0 documentation ↩︎
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! ↩︎
Ich finde diese Integrationsvariante minimal, aber flexibel und einfach durchzuführen und zu dokumentieren. Daher gefällt sie mir recht gut, und wird wahrscheinlich die “große Variante” überholen, an der wir bei Add TTS (The Things Stack) / TTN (The Things Network) decoder adapter by amotl · Pull Request #81 · daq-tools/kotori · GitHub arbeiten. ↩︎

Stefan · May 7, 2023, 6:29pm

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

Andreas · May 7, 2023, 8:40pm

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.

Andreas · May 7, 2023, 9:54pm

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.

Thias · May 7, 2023, 10:10pm

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

Andreas · May 7, 2023, 10:32pm

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.

https://github.com/daq-tools/kotori/pull/81 ↩︎
[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 ;]. ↩︎ ↩︎

Andreas · May 7, 2023, 11:30pm

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?

Andreas · May 8, 2023, 12:55am

@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 ;].

Thias · May 8, 2023, 8:05am

Hi Andreas,

ja, da kommt was an. zB in meinem Dashboard für meinen Stand im freiLand:
Bildschirmfoto vom 2023-05-08 09-17-39

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:

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.

Andreas · May 8, 2023, 1:11pm

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 · May 8, 2023, 1:24pm

Da fügen wir doch jetzt erstmal die volle Dekodierungslogik hinzu, nicht? Also jene hier, meine ich:

Thias · May 8, 2023, 1:48pm

Nope:
Bildschirmfoto vom 2023-05-08 15-46-50

Na, das wäre was!

Stefan · May 8, 2023, 2:31pm

@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

Stefan · May 8, 2023, 2:48pm

@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.