TTS-/TTN-Daten an Kotori weiterleiten

Andreas · December 3, 2019, 10:24pm

Von @clemens grade bei Beelogger geteilt, finde ich die Integration mit TTN bei beelogger - LORA - Arduino Datenlogger mit Stockwaage für Imker auch hier erwähnenswert. Im Gegensatz zum plattformartigen Betrieb mehrerer Teilnehmer über die gleiche TTN-Application ist dies ist das Szenario, wenn jeder Teilnehmer einen eigenen TTN-Account hat. Das sollten wir bei der Ausreifung unserer entsprechenden Dekoder ebenfalls berücksichtigen.

Andreas · December 8, 2019, 5:43pm

Slightly OT, but if anyone ever wondered how the Javascript-based payload decoder implemented within TTN and accessible from the TTN console actually works, there are these two valuable resources about it.

Also interesting in this regard is:

Decrypting messages for dummies - The Things Network
GitHub - thesolarnomad/lora-serialization: LoraWAN serialization/deserialization library for The Things Network

poesel · July 5, 2020, 7:53am

Wie ist denn jetzt der Stand? Ich habe im code einige Funktionen gefunden, aber anscheinend gibt es nur wenig Doku dazu.

Konkrete Frage: kann ich mit Terkin Daten an Kotori per LPP schicken?
Wenn ja, wie? Wenn nein, warum nicht ?

Hintergrund ist das T-CALL System, das per 2G Daten schicken soll. Da wäre LPP schon ein gutes Mittel.

clemens · July 5, 2020, 4:57pm

Ich denke für 2G lohnt LPP nicht, du hast ja noch so viel Kommunikations-Overhead, da ist es dann egal, ob die Daten selbst nochmal geschrumpft sind weil das für die Gesamtmenge vielleicht 100 % vs. 95 % mit geschrupften Daten ausmacht.

LPP funktioniert in Terkin, @Thias und ich senden da schon muter Daten drüber. Das ist aber momentan eng an TTN gekoppelt, s.

github.com

hiveeyes/terkin-datalogger/blob/0.10.0/src/settings.example.py#L270-L281


# CayenneLPP over LoRaWAN/TTN
{
    # Enable/disable this telemetry target.
    'enabled': False,

    'endpoint': 'lora://',
    'format': 'lpp-hiveeyes',
    'settings': {
        'size': 12,
        'datarate': 0,
    },
},

Bei TTN encodet dann auch der TTN-Server die payload und schickt sie weiter, Daten in raw LPP encodet kann der Kotori afaik momentan nicht annehmen.

Was man hier also tun müsste

LPP vom Senden an TTN entkoppeln
bei Kotori eine Möglichkeit schaffen, LPP encodete Daten zu decoden und weiterzuverarbeiten.

Ja, wäre nice to have, für 2G alleine wäre mir das nicht wert. Vielleicht ist aber auch nicht so viel Arbeit wie es sich (für mich) anhört und @Andreas war evtl. auch schon mal am encoder dran. Teile existieren da auch (allerdings in JavaScrip), siehe Datenweiterleitung via TTN / LoRa zu Hiveeyes, BOB und BEEP einrichten

der code fürs "Custom Payload Format” in TTN https://raw.githubusercontent.com/hiveeyes/terkin-datalogger/master/client/TTN/decoder.js
und der Putsreq-Code: https://raw.githubusercontent.com/hiveeyes/terkin-datalogger/master/client/TTN/putsreq.hiveeyes.js

poesel · July 5, 2020, 5:30pm

Spannend wird das dann, wenn mehr als ein Datensatz pro connect übertragen wird. Dann wird sich das schnell lohnen. Stände dann ja auch für alle anderen Übertragungswege mit begrenzter Bandbreite zur Verfügung.

Andreas · March 2, 2021, 11:51am

Hi @Thias,

herzlichen Dank für Deine neuesten Beiträge add payload decoder function for TTN Stack V3 · hiveeyes/terkin-datalogger@71699de · GitHub sowie add putsreq payload extractor for TTN V3 · hiveeyes/terkin-datalogger@1cc6df9 · GitHub.

Mit @einsiedlerkrebs denken wir gerade daran, die Dekodierung auch endlich Kotori selbst beizubringen, wie schon lange geplant ^[1].

TTN Stack V3 bietet an dieser Stelle scheinbar neue Möglichkeiten für den Datentransport. Ich habe selbst zwar noch keine Dokumentation gewälzt, aber eine Diskussion mit @einsiedlerkrebs hat ergeben, dass der neue PubSub V3 Mechanismus u.U. ermöglichen könnte, TTN Daten à la HTTP Webhook auch direkt auf einen fernen MQTT Broker (unseren) zu publizieren.

Viele Grüße,
Andreas.

Referenzen

Kotori selbst habe ich gerade auf der Werkbank, siehe Giving the backend software infrastructure some love. Vielleicht wird es ja nun etwas, die im GitHub - daq-tools/ttnlogger: Converge TTN messages into InfluxDB and display in Grafana vorbereitete Logik in einen passenden Kotori channel decoder zu transplantieren. Das Vorankommen ist noch etwas zäh, das neue Packaging nach der Umstellung auf Python 3 hält mich noch etwas auf. Aber im Laufe der nächsten Tage könnte das Gerät empfänglich für neue Features sein. ↩︎

Thias · March 2, 2021, 12:45pm

PUB/SUB ist es bestimmt wert, mal genauer anzusehen. Ich befürchte allerdings, dass device-spezifische Topics nicht möglich sind. Man kann in einer Application für das Topic einen Base Path und einen Sub Path je nach Message Type (Uplink, Downlink, Join, Service, …) angeben. Die Device ID ist dann erst im Payload enthalten.

Dann würde es doch auf Kotori hinauslaufen, dass mit dem Payload am http Endpunkt das Topic ableiten müsste (à la dev_id.replace(/-/g, '/')) und wir so erst Putsreq verabschieden können.

V2 wird für den öffentlichen Community-Teil von TTN noch dieses Jahr auslaufen. Uplinks werden jedoch schon von V2 nach V3 geroutet. Das neue Payload-Format unterscheidet sich zudem vom V2 TTN Backend. Weiß nicht, ob man da noch Arbeit in die Unterstützung von V2 stecken sollte. Ich werde jedenfalls mein Nodes alsbald auf V3 umrüsten.

Andreas · March 2, 2021, 1:47pm

Ja, das kann gut sein.

Genau, wir hatten ja unabhängig von etwaigen Transportmöglichkeiten (MQTT subscribe V2 vs. HTTP Webhook V2 vs. MQTT PubSub V3) bereits ins Auge gefasst, die Device-ID aus dem entsprechenden Payload-Feld abzuleiten, ich glaube es war die "dev_id". Mit @einsiedlerkrebs hatte ich das neulich auch bereits besprochen und ich werde zusehen, diese Möglichkeit innerhalb des Kotori-Decoder-Subsystems zu ermöglichen.

Letzteres war bisher die größte Krux. Und weil ich damit nicht vorankam, mussten wir die Workarounds über ttnlogger und PutsReq veranstalten, soweit ich mich erinnere. Ich finde es für diese Aspekte grundsätzlich völlig in Ordnung, Kotori diese Möglichkeit beizubringen, so wie wir es oben ab post #4 bereits skizziert haben – Stichwort “Kanaladresse” bzw. “Kanaladressierung”. Nur war und ist das Subsystem eben wahrscheinlich noch nicht soweit – damals gab es dieses “Decoder”-Subsystem noch überhaupt gar nicht. Hier sind wir mittlerweile schon etwas weiter, wenn auch noch nicht am Ziel.

wtf · March 2, 2021, 1:59pm

Bin jetzt nicht ganz im Klaren darüber ob TTN hier nun das gegenständliche LoRaWAN-Netzwerk darstellen soll, aber wenn ja – und so klingt es hier ja: Dort gibt es schon länger die Möglichkeit die per LPP übermittelten Daten “ausgepackt” per MQTT abzurufen. (Dieser Weg machts natürlich nicht einfacher nen eigenens LoRaWAN so zu betreiben.)

Ist der Unterschied jetzt, dass hier, im PubSub V3, die TTN-Server nen Client und nicht nen Server im MQTT-Kosmos darstellen? Wär natürlich schick, so push statt pull.

Hab das mit dem MQTT-Client-holt-bei-TTN-ab mal ausprobiert und auf eltiempo nen Telegraf damit beauftragt ein-zwei LPP-emittierende TTN-Nodes direkt in ne InfluxDB schreiben zu lassen. Tut seit ein paar Monaten, anstandslos.

Andreas · March 2, 2021, 2:04pm

Hi @wtf,

merci dass Du hier auch mittust.

Das stimmt.

Top!

Ja, das klappt generell gut. Entweder mit Telegraf oder mit Mosquitto-Bridge oder ttnlogger oder anderen Hilfsmitteln. Dafür muss aber Infrastruktur selbst konfiguriert und betrieben werden. @Thias macht das derzeit auch ähnlich:

Hier in der Diskussion geht es primär darum, einen Schritt weiterzugehen und die Kotori wash&go Philosophie auf ein Niveau zu bringen, so dass es für eine Reihe von Anwendungsszenarien innerhalb der vorhandenen TTN-Infrastruktur (“wem gehört die »Application«” vs. “kann ich mit meiner eigenen »Application« ebenfalls auf den Hiveeyes-Realm funken?”) möglich wird, Daten absolut wartungsfrei fließen zu lassen und dabei möglichst DWIM-like zu implementieren, damit dann auch diese Instant-Dashboards und andere Dinge wie stromlinienförmiger Datenexport über die HTTP-Schnittstelle gut gehen.

Exakt. Das war auch mein Gedanke, als ich von dieser Möglichkeit neulich erstmalig von @einsiedlerkrebs hörte.

“Push” war ja auch bisher schon via HTTP Webhook möglich, daher hatten wir das aus V2-Perspektive bereits anvisiert, aber bisher noch nicht einmal das implementiert, da Kotori leider bis dato jegliche Möglichkeiten fehlen, das Payload-Format ordentlich zu dekodieren. Jenes wäre für die Nutzer:innen mit minimalstem Konfigurationsaufwand seitens der TTN-Applikation verbunden, weil einfach nur nen HTTP-Endpunkt in der TTN Admin UI eingestellt werden müsste. Da kommen wir bei dieser Diskussion auch her:

Da nun aber mit TTN Stack V3 auch noch “MQTT Push” möglich scheint, wollten wir das in die neu aufgelegten Planungen auf jeden Fall mit einbeziehen.

Herzlichst,
Andreas.

MKO · October 24, 2021, 11:49pm

Hast du eine Quelle? Habe dazu leider nichts finden können.

PUB/SUB scheint es leider nicht mehr zu geben, oder heißt jetzt Webhooks.
Habe ein wenig gestöbert und experimentiert. Man kann Pfadvariablen benutzen.
https://www.thethingsindustries.com/docs/integrations/webhooks/path-variables/
Über die es ist also möglich die "dev_id" direkt im Path zu benutzen.
über den Header läst
Für swarm.hiveeyes müsste das ganze dann so aussehen.

über den HTTP-header lassen sich auch noch weitere Variablen mitschicken.
In meinem Test war das Auth=Testkey theoretisch wär sicherlich auch noch ein
TTNV3=True denkbar.
Theoretisch begrenzt sich der Aufwand dadurch auf das extrahieren der Payload.

Thias · January 19, 2022, 10:31am

Ich habe mich mal an den Webhooks bei TTN versucht.

Ein data Block vom TTN-Event sieht zB so aus:

  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "hiveeyes-thias-freiland-hive2",
      "application_ids": {
        "application_id": "hiveeyes"
      },
      "dev_eui": "00465D1CCFB4A17A",
      "join_eui": "70B3D57ED0007AA4",
      "dev_addr": "260B35C2"
    },
    "correlation_ids": [
      "as:up:01FSRWFW1R4AH0ZMZT2S0W79H9",
      "gs:conn:01FS1XREKAF1VGXD79TV7QXCZN",
      "gs:up:host:01FS1XREN37S08XY8TQABVMKV2",
      "gs:uplink:01FSRWFVTX04GS2NBSYTT1KTJZ",
      "ns:uplink:01FSRWFVV2FQCC9XXPXXZKKZHT",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FSRWFVV121HBKGFRNBHNEQXY",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FSRWFW1Q69FFWRVZ6JK5T7D2"
    ],
    "received_at": "2022-01-19T10:00:35.642012331Z",
    "uplink_message": {
      "session_key_id": "AX5KoGq/st4z2NPfzyALvg==",
      "f_port": 1,
      "f_cnt": 2181,
      "frm_payload": "AQIXBgICFuQCZwAqAmi3A2cAIgMCAV0=",
      "decoded_payload": {
        "analog_in_1": 58.94,
        "analog_in_2": 58.6,
        "analog_in_3": 3.49,
        "relative_humidity_2": 91.5,
        "temperature_2": 4.2,
        "temperature_3": 3.4
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "machbar-ffp",
            "eui": "B827EBFFFE9EE1AB"
          },
          "time": "2022-01-19T10:00:35.392669Z",
          "timestamp": 1867852644,
          "rssi": -100,
          "channel_rssi": -100,
          "snr": 2.5,
          "location": {
            "latitude": 52.38947922585195,
            "longitude": 13.078503949318263,
            "altitude": 35,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChkKFwoLbWFjaGJhci1mZnASCLgn6//+nuGrEOTW1PoGGgwIw8KfjwYQsefnyAEgoP3Fpa6drwEqDAjDwp+PBhDIzp67AQ==",
          "channel_index": 6
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7
          }
        },
        "coding_rate": "4/5",
        "frequency": "867700000",
        "timestamp": 1867852644,
        "time": "2022-01-19T10:00:35.392669Z"
      },
      "received_at": "2022-01-19T10:00:35.426356023Z",
      "consumed_airtime": "0.077056s",
      "locations": {
        "user": {
          "latitude": 52.389433391870924,
          "longitude": 13.078771058635807,
          "altitude": 35,
          "source": "SOURCE_REGISTRY"
        }
      },
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "ttn-eu1"
      }
    }
  },

Recap von gegenwärtiger Lösung mit Putsreq:

TTN-Webhook direkt an Putsreq
Putsreq extahiert das decoded_payload aus dem Uplink JSON, welches im Block uplink_message.decoded_payload residiert. Zusätzlich entnimmt das Skript einige Parameter über die Empfangseigenschaften des Pakets aus uplink_message.rx_metadata und uplink_message.settings. zB RSSI, SNR, SF und BW.
Das Topic wird aus der TTN devID abgeleitet per replace(/-/g, '/') + "/data"
Bedeutet also, dass die devID 4 Komponenten haben muss, die den MQTT Topiclevels entsprechen. Hat den Vorteil, dass man all seine Devices in die gleiche TTN App legen kann und trotzdem Kontrolle auf das gesamte Topic hat. Bei der direkten Variante unten geht das nicht.
Aus devID=hiveeyes-thias-freiland-hive2 wird dann hiveeyes/thias/freiland/hive2/data
Das alles wird in ein eindimensionales JSON verpackt und dann an die swarm API gesendet.

Vision: Kotori vesteht das Webhook Payload direkt:

Mit dem gegenwärtigen Fähigkeiten von Kotori ist die Annahme von device-spezifisches Topics insofern möglich, als dass man die ersten drei Levels vom Topics (/+/+/+/) schon im Basepath fixieren und dem Device einen kurzen Namen für das letzte Level vergeben müsste. Sehr ähnlich dem Vorschlag von @MKO oben. Der Webhook wird dann so konfiguriert:

Das Problem ist jetzt wohl das große und verschachtelte JSON, welches von TTN ankommt. zB:
(hier noch mit meiner langen Device ID)

hiveeyes/thias/freiland/hiveeyes-thias-freiland-hive2/data.json {"end_device_ids": {"device_id": "hiveeyes-thias-freiland-hive2", "application_ids": {"application_id": "hiveeyes"}, "dev_eui": "00465D1CCFB4A17A", "join_eui": "70B3D57ED0007AA4", "dev_addr": "260B35C2"}, "correlation_ids": ["as:up:01FSRWFW1R4AH0ZMZT2S0W79H9", "gs:conn:01FS1XREKAF1VGXD79TV7QXCZN", "gs:up:host:01FS1XREN37S08XY8TQABVMKV2", "gs:uplink:01FSRWFVTX04GS2NBSYTT1KTJZ", "ns:uplink:01FSRWFVV2FQCC9XXPXXZKKZHT", "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01FSRWFVV121HBKGFRNBHNEQXY", "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01FSRWFW1Q69FFWRVZ6JK5T7D2"], "received_at": "2022-01-19T10:00:35.642012331Z", "uplink_message": {"session_key_id": "AX5KoGq/st4z2NPfzyALvg==", "f_port": 1, "f_cnt": 2181, "frm_payload": "AQIXBgICFuQCZwAqAmi3A2cAIgMCAV0=", "decoded_payload": {"analog_in_1": 58.94, "analog_in_2": 58.6, "analog_in_3": 3.49, "relative_humidity_2": 91.5, "temperature_2": 4.2, "temperature_3": 3.4}, "rx_metadata": [{"gateway_ids": {"gateway_id": "machbar-ffp", "eui": "B827EBFFFE9EE1AB"}, "time": "2022-01-19T10:00:35.392669Z", "timestamp": 1867852644, "rssi": -100, "channel_rssi": -100, "snr": 2.5, "location": {"latitude": 52.38947922585195, "longitude": 13.078503949318263, "altitude": 35, "source": "SOURCE_REGISTRY"}, "uplink_token": "ChkKFwoLbWFjaGJhci1mZnASCLgn6//+nuGrEOTW1PoGGgwIw8KfjwYQsefnyAEgoP3Fpa6drwEqDAjDwp+PBhDIzp67AQ==", "channel_index": 6}], "settings": {"data_rate": {"lora": {"bandwidth": 125000, "spreading_factor": 7}}, "coding_rate": "4/5", "frequency": "867700000", "timestamp": 1867852644, "time": "2022-01-19T10:00:35.392669Z"}, "received_at": "2022-01-19T10:00:35.426356023Z", "consumed_airtime": "0.077056s", "locations": {"user": {"latitude": 52.389433391870924, "longitude": 13.078771058635807, "altitude": 35, "source": "SOURCE_REGISTRY"}}, "network_ids": {"net_id": "000013", "tenant_id": "ttn", "cluster_id": "ttn-eu1"}}}

Die Möglichkeit nur bestimmte Blöcke in den Webhook zu leiten, ist nicht vorgesehen bei TTN. Kotori quittiert das jedenfalls mit:

hiveeyes/thias/freiland/hiveeyes-thias-freiland-hive2/error.json {
    "type": "<class 'influxdb.exceptions.InfluxDBClientError'>",
    "message": "400: {\"error\":\"unable to parse 'freiland_hiveeyes_thias_freiland_hive2_sensors
    ...

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