TTS-/TTN-Daten an Kotori weiterleiten

Vorschlag zur Generalisierung

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.

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.


  1. 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. ↩︎