TTS-/TTN-Daten an Kotori weiterleiten

clemens · February 10, 2019, 11:20am

Fürs Debuggen mag das interessant sein und um am Standort vielleicht die optimale Position einer Richtantenne zu finden - für die erste halbe Stunde. Wenn wir aber anschließend vielleicht Jahre lang den ganzen Schrott bei uns in die DB schreiben wird die zur Müllhalde. Bei beweglichen nodes ist das ggf. anders, wenn man über die Gateways an die lat / long der nodes kommt.

Andreas · February 10, 2019, 8:31pm

Korrekt, genau darum geht es in diesem Fall gemeinsam mit @tonke, da sind wir mobil unterwegs. Wir wollen - unabhängig von der Speicherung der Zeitseriendaten in einer InfluxDB Datenbank - alle TTN Datenpakete 1:1 in einer MongoDB Datenbank aufzeichnen. Da es (verschachtelte) JSON Dokumente sind, die da über die TTN Infrastruktur hinten rausfallen, eignet sich das hervorragend, um z.B. nach einer Meßfahrt die Möglichkeit zu haben, die Daten bei der Abfrage flexibel nach beliebigen Kriterien im JSON Dokument filtern zu können.

clemens · February 10, 2019, 8:51pm

Ich würde mir gut überlegen, was wir von den metadaten brauchen. Schau’ dir nur im Beispiel oben das Verhältnis von eigentlcher payload und metadaten an. Klar, was kostet die Welt, bzw. TB an Speicher, aber warum den ganzen Schrott speichern, wenn man es später nie wieder braucht.

weef · February 10, 2019, 9:18pm

was Generelles in diesem Zusammenhang (unabhängig von “welche meta-Daten oder Verkehrsdaten recorden wir”):

MongoDB ist bei Debian und bei RedHat aus den repos geflogen aufgrund ihrer server-side public license (SSPL) . Wenngleich die Intention hinter der Lizenz nachvollziehbar ist, hätten sie besser die GPLv3 nehmen sollen, anstatt an der AGPL herumzupopeln; man kann diskutieren, ob ein Linux mit MongoDB neu lizensiert werden müßte…

Wenn also MongoDB, dann einen der forks - oder gleich Postgres.

Andreas · February 10, 2019, 9:46pm

Für dieses spezielle Vorhaben, im mobilen Betrieb Meßfahrten und dergleichen durchzuführen, und für alle Menschen die Ähnliches vorhaben, wollen wir in der Tat den vollständigen Payload aufzeichnen.

Den Dekoder, der aus diesem kompletten Satz die für eine Zeitseriendatenerfassung sinnvollen Daten herausfiltert, haben wir bereits, siehe store(self, ttn_message) beim https://github.com/daq-tools/ttnlogger.

Es geht dabei also v.a. um eine noch fehlende zusätzliche Funktionalität.

Andreas · February 10, 2019, 10:01pm

ttnlogger → InfluxDB + MongoDB

Gern. Hab da grade nicht so geschaut, was sich da so herauskristallisiert, nehme aber gerne Tipps entgegen. “Lebt z.B. TokuMX noch und was haben die (Percona) aus der Relizensierung gemacht?” frage ich mich z.B. an dieser Stelle.

MongoDB durch PostgreSQL ersetzen?

Grundsätzlich schon auch gern. Allerdings: Wir haben neulich die ersten Schritte unternommen, uns dem JSON Datentyp [1] und entsprechenden Funktionen [2] von PostgreSQL zu widmen. Das ist zwar alles ziemlich mächtig und man kann als Datenbankadministrator auch dort Datenbankindizes auf verschachtelte Strukturen legen, die Abfragesyntax ist aber nichts für Anfänger im Alltagsgebrauch, dort hat MongoDB für mich noch die Nase etwas vorn.

ttnlogger → InfluxDB + PostgreSQL/JSON

Vielleicht - die MongoDB Implementierung ist schließlich noch nicht im Kasten - schwenken wir aber noch rechtzeitig um und erarbeiten uns bei der Gelegenheit ein entsprechendes Tutorial à la “Getting started with PostgreSQL/JSON”, dann wird da u.U. ein Schuh draus und die Codebase des "ttnlogger" kann als Testbed/Blaupause dafür herhalten, dass wir uns da endlich weiterentwickeln.

Daher danke vielmals für den Impuls! Ich könnte mir vorstellen, dass auch @tonke nicht abgeneigt sein wird, erst recht wenn ihm die Dinge wie wir sie bei GIS Funktionalitäten zur Abfrage der luftdaten.info Stationsliste eingerichtet haben genauso gefallen wie uns.

[1] PostgreSQL: Documentation: 10: 8.14. JSON Types
[2] PostgreSQL: Documentation: 10: 9.15. JSON Functions and Operators

Andreas · April 3, 2019, 11:53pm

Feldnamenkonvergenz bei Übertragung via TTN

Einleitung

Auch im Zuge der Arbeiten am GitHub - hiveeyes/terkin-datalogger: Datalogger for MicroPython and CPython. streben @einsiedlerkrebs, @tonke und ich Konvergenz zwischen klassischer MQTT/HTTP Datenübermittlung und dem Transport von Meßdaten über TTN an und haben nun für die erste Iteration ebenfalls CayenneLPP als Serialisierungsformat anvisiert. Im Zuge dessen wollen wir Kotori nun endlich die angepeilte TTN-Schnittstelle verpassen - auf Basis einer TTN-Application mit Standard CayenneLPP Decoder, genau wie von @Thias gewünscht.

Recap Kanaladressierung

Recap Serialisierungsformat und Feldnamenmapping

CayenneLPP sieht bereits bestimmte Sensor-/Meßwertfamilien vor, alle übrigen müssen wir über analog_X tunneln. Ein ingress-payload sieht also beispielsweise folgendermaßen aus:

{
  "payload_fields": {
    "temperature_2": -3.2,
    "temperature_1": -2.9,
    "analog_in_1": 35.99,
    "analog_in_3": 3.53,
    "relative_humidity_2": 57.5,
    "relative_humidity_1": 55.5
  }
}

Problemstellung

Wir wollen sprechende Feldnamen (vgl. “Feuchte außen”) im Grafana gewinnen, über den schmalen TTN Kanal mit CayenneLPP Serialisierung ist das jedoch nur begrenzt möglich.

Lösungsvorschlag

Wir wollen ein Feldnamenmapping einführen, mit dem man Feldnamen der Telemetriestrecke sprechenden Meßwertfeldnamen zuordnen kann. Dieses Mapping kann einmalig gesetzt werden und bedient sich intern dem bereits für die CSV Datenerfassung [1,2] etablierten Subsystem, ähnlich wie unter CSV data acquisition beschrieben.

# HTTP
cat mapping.json | http POST $HTTPURI/$CHANNEL/mapping.json

# MQTT
cat mapping.json | mosquitto_pub -h $BROKER -t $CHANNEL/mapping.json -l

[1] Daten per HTTP und PHP ans Backend auf swarm.hiveeyes.org übertragen
[2] Telemetriesubsystem für Arduino Firmwares generalisieren

Per-channel metadata store

Ähnliches hatten wir bereits unter Imkerliche Metadaten angerissen.

Automatic fieldname announcement

In der Luxusvariante teilt der Meßknoten sein konfiguriertes Mapping einmalig beim Startvorgang mit - sofern er über WiFi verbunden ist und damit über HTTP oder MQTT kommunizieren kann.

Ausblick

Wir erschließen damit nun den langersehnten Komfortmapper auf Infrastrukturseite, der in Folge alle möglichen schmalen Radiotransporte unterstützen kann - sowohl seitens des PHY (RFM69, RFM95… (LoRa), LoRaWAN, etc.), als auch seitens des jeweils verwendeten Serialisierungsformats (BERadio, CayenneLPP, custom-bytepacked, etc.). Natürlich kann er aber auch darüber hinaus ein Remapping der Feldnamen leisten.

Requests for comments

Falls Ihr einen besseren Vorschlag fürs “Naming Things” anstelle des Suffixes mapping.json habt: Her damit! (vielleicht einfach meta.json?) Weitere Vorschläge und Ideen zu diesem Thema sind natürlich ebenfalls immer willkommen.

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