TTS-/TTN-Daten an Kotori weiterleiten

Entwicklung / Development Daten / Data
, ,
72

Auf keinen Fall alles in die DB blasen. Nach der Extraktion relevanter Teile den Rest bitte verwerfen.

1 Like
73

Du wirst den Patch selber anschauen und ggf. Einfluß nehmen können ;].

1 Like
74

Ich beschäftige mich erst seit kurzem mit TTN und dem Datentransfer zu Hiveeyes. Das sind meine ersten Versuche, da bin ich natürlich sehr froh das die ersten Daten in Grafana ankommen.

Ansonsten bin ich hier aber nicht fixiert und wenn es eine flexiblere Lösung gibt, mit der ich am Ende auch noch zusätzliche nützliche Informationen wie die Signalstärke darstellen könnte, wäre das natürlich von Vorteil und ich würde das selbstverständlich auch nutzen.

2 Likes
75

data.update(message["uplink_message"]["decoded_payload"])

Hier wird der Datenteil aus dem vollen Payload entnommen. Die Filterung im Webhook ist doch dann gar nicht nötig. Der Metateil würde erhalten bleiben können für weitere Extraktionen. Sprich, auch die tenant_id.

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