TTS-/TTN-Daten an Kotori weiterleiten

Entwicklung / Development Daten / Data
, ,
76

Nötig ist er keinesfalls. Aber ich finde es gut, auch diesen Anwendungsfall abzudecken, der ja potentiell extra als Einstellung im TTN vorgesehen wurde, um datensparsam Daten nach außen rausgeben zu können, was für manche Anwendungsfälle bestimmt sehr relevant ist.

77

@Andreas, schau mal bitte auf den PR. Die volle Testumgebung kann ich aus Zeitgründen nicht aufsetzen. Getestet habe ich nur in der Python Konsole :no_mouth:

2 Likes
78

Exzellent. Ich hatte so gehofft, dass Du vielleicht einen Patch schicken würdest. Bedankt! Ich werde später noch ein paar Softwaretests hinzufügen.

1 Like
79

Ist integriert und wurde gerade ad hoc aufgespielt. Vielen Dank!

1 Like
80

Der Dekoder hat jetzt auch eine kleine Routine, um ihn ad hoc benutzen zu können, die in dieser Situation helfen kann.

81

Durch Datenübertragung per MQTT kommt nicht an - #9 by mois inspiriert bin ich gerade kurz bei Setup (LoRA) — MultiGeiger V1.17.0-dev documentation gelandet, wo ich aufgeschnappt habe, dass dort ein X-SID HTTP Header benutzt wird, um die Sensor ID zu übertragen.

Das fand ich reizvoll, hat aber doch den gleichen Nachteil, dass, wenn das auf “Application”-Ebene konfiguriert wird, jede Application nur ein einziges Gerät versorgen kann?

82

Was aber wäre, wenn wir einem solchen HTTP Header Feld die {/devID} zuweisen könnten? Das klänge doch schick?

83

Alle Geräte in einer Application verwenden den/die gleichen Webhook/s. Ich bekomme dann immer noch nicht die variable Location (Teil der devID) ins Topic. Egal ob über Header, Payload oder URL.

Was ich auch noch probiert habe, ist, device-spezifische manuelle Attribute zu verwenden. Auf die habe ich aber im Webhook leider keinen Zugriff

84

Ohne Weiteres geht es vermutlich nicht. Aber Kotori kann ja den HTTP Header entsprechend auswerten.

85

Die Device ID oder andere per-device Attribute bekomme ich nicht in den Header.

1 Like
86

Ok. Schade. Dann muss es wohl bei dem Plan bleiben, sie aus dem Payload zu holen. Danke!

87

Hätte da auch noch was, und zwar Daten eines PAX-Counters. Wenn ichs richtig verstanden habe sollte das ggf. schon ohne magic (automatische device / TTN-application-Referenzierung) wie bei Stefan funktionieren, muss ich mal testen, hier der data-Teil der payload:

  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ApplicationUp",
    "end_device_ids": {
      "device_id": "eui-70b3d57ed005dac6",
      "application_ids": {
        "application_id": "test-lopy4-paxcounter"
      },
      "dev_eui": "70B3D57ED005DAC6",
      "join_eui": "1561897126894563",
      "dev_addr": "260B3993"
    },
    "correlation_ids": [
      "as:up:01H169DDCAXDJ6VKV0CTKAEQYR",
      "gs:conn:01H160YDQRFQ6Z3DV6K4TMRCMA",
      "gs:up:host:01H160YDQYEA797TNT10R7N3D1",
      "gs:uplink:01H169DD5SY9VG9C30JSGREQ47",
      "ns:uplink:01H169DD5T7MSVAE6AY1SVVCXY",
      "rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01H169DD5S2EDF2V5XQR0EP6CK",
      "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01H169DDCAF7MQX062AXHN1W9J"
    ],
    "received_at": "2023-05-24T07:08:45.322360810Z",
    "uplink_message": {
      "session_key_id": "AYhMafaKiTqKIkKM6GTZ5w==",
      "f_port": 1,
      "f_cnt": 52,
      "frm_payload": "AQABAA==",
      "decoded_payload": {
        "ble": 1,
        "bytes": [
          1,
          0,
          1,
          0
        ],
        "pax": 2,
        "port": 1,
        "wifi": 1
      },
      "rx_metadata": [
        {
          "gateway_ids": {
            "gateway_id": "ttig-cgruber",
            "eui": "58A0CBFFFE800CFA"
          },
          "time": "2023-05-24T07:08:45.038361072Z",
          "timestamp": 287963436,
          "rssi": -74,
          "channel_rssi": -74,
          "snr": 8,
          "location": {
            "latitude": 52.52666243033787,
            "longitude": 13.697235367913564,
            "altitude": 64,
            "source": "SOURCE_REGISTRY"
          },
          "uplink_token": "ChoKGAoMdHRpZy1jZ3J1YmVyEghYoMv//oAM+hCs8qeJARoLCP3vtqMGEP6w9zUg4KfV37CCAg==",
          "received_at": "2023-05-24T07:08:45.075968299Z"
        }
      ],
      "settings": {
        "data_rate": {
          "lora": {
            "bandwidth": 125000,
            "spreading_factor": 7,
            "coding_rate": "4/5"
          }
        },
        "frequency": "867500000",
        "timestamp": 287963436,
        "time": "2023-05-24T07:08:45.038361072Z"
      },
      "received_at": "2023-05-24T07:08:45.114172984Z",
      "consumed_airtime": "0.051456s",
      "version_ids": {
        "brand_id": "opensource",
        "model_id": "esp32-paxcounter",
        "hardware_version": "_unknown_hw_version_",
        "firmware_version": "3.0.0",
        "band_id": "EU_863_870"
      },
      "network_ids": {
        "net_id": "000013",
        "tenant_id": "ttn",
        "cluster_id": "eu1",
        "cluster_address": "eu1.cloud.thethings.network"
      }
    }
  },
1 Like
88

ja, tuts. Hier drüben getestet:

89

Vielen Dank. Ich habe Deinen Payload bei [1] eingepflegt. Wir müssen sehen, was Kotori/InfluxDB/Grafana aus der eingebetteten bytes Liste machen. Trial-and-error, würde ich vorschlagen.

  1. Add adapter for ingesting data from TTN · Issue #8 · daq-tools/kotori · GitHub ↩︎

90

bytes und port sind über die TTN “provision” reingekommen, brauchen wir aber nicht, siehe Wifi/BLE Paxcounter Project with ESP32 boards - #507 by Clemens_G - End Devices (Nodes) - The Things Network.

In TTN kann man den PAX-counter als “Gerät” auswählen, und dann ist schon ein payload decoder hinterlegt, der bytes und port ausgibt. Der offizielle decoder hat die gar nicht drinnen. Allerdings auch nicht das Feld “pax” was ja schon wichtig ist. :-) Das ist – laut in TTN für PAX hinterlegtem payload encoder – aber nur die Summe aus gezählten Wifi- und Bluetooth-Geräten, könnte man auch in Grafana realisieren:

        data.pax = 0;
        if ('wifi' in data) {
            data.pax += data.wifi;
        }
        if ('ble' in data) {
            data.pax += data.ble;
        }

Wird im (von TTN vorgehaltenen) decoder schon angeboten: :-)

    data.bytes = input.bytes; // comment out if you do not want to include the original payload
    data.port = input.fPort; // comment out if you do not want to inlude the port
1 Like
91

Das Uplink Format ist jetzt auch wunderbar dokumentiert bei [1] zu finden.

  1. Data Formats | The Things Stack for LoRaWAN ↩︎

1 Like
92

Drüben bei https://kotori.readthedocs.io/en/latest/handbook/decoders/tts-ttn.html ist die kanonische Anleitung zu finden, die zumindest für die Verdrahtung von Einzelgeräten gut funktionieren müsste.

Es wäre stark, wenn Du mir auf Deiner Reise a) Rückmeldung gibst, ob diese Doku korrekt ist, und b) noch ein paar Krumen fallen lässt, wie Paxcounter Geräte genau einzurichten sind [1], dann spendiere ich dafür einen separaten Abschnitt auf dieser Seite, der dies beschreibt.

Dazu würde sich dann natürlich auch gerne eine Beschreibung gesellen, wie sich die Daten optimal im Grafana darstellen lassen.

  1. Also Links zu guten Tutorials, oder vllt. sogar besser selbstgemachte Screenshots, die beleuchten, wie genau vorzugehen ist, z.B. auch den entsprechenden Binärdekoder zu aktivieren. Ich denke, das wars dann auch: Dekoder + Webhook, viel mehr ist nicht zu tun – oder? ↩︎

93

Hier die ausführliche Doku, die beschreibt, dass die dargestellten Variablen scheinbar nur in den Pfad interpolieren.

– https://www.thethingsindustries.com/docs/integrations/webhooks/path-variables/

1 Like
94

Mglw. leicht verwandt zu unserem Vorhaben – “Webhook templates” scheinen mir auch interessant.

– https://www.thethingsindustries.com/docs/integrations/webhooks/webhook-templates/
– Format | The Things Stack for LoRaWAN
– Instantiation | The Things Stack for LoRaWAN

95

Das hier liest sich doch ganz nett, finde ich.

https://stadtpuls.com/docs/ttn-sensor

1 Like