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
Ohne Weiteres geht es vermutlich nicht. Aber Kotori kann ja den HTTP Header entsprechend auswerten.
Die Device ID oder andere per-device Attribute bekomme ich nicht in den Header.
Ok. Schade. Dann muss es wohl bei dem Plan bleiben, sie aus dem Payload zu holen. Danke!
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"
}
}
},
ja, tuts. Hier drüben getestet:
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.
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
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.
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? ↩︎
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/
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
Die Weiterleitung der PAX-Counter-Daten von TTN zu Hiveeyes / swarm hat super smooth und auf Anhieb (!) funktioniert. Sehr, sehr toll! Danke an @Andreas fürs möglich machen, an @Stefan fürs Anschubsen und @Thias für die konzeptionellen Überlegungen für später!
Was auch problemlos funktioniert ist, die device ID mit {/devID} als Variable im webhook path (vermutlich funktioniert es in der base URL auch) zu übergeben, was dann so was liefert:
hiveeyes/testdrive/test-pax/eui-70b3d57ed005dac6/data.json {"uplink_message": {"decoded_payload": {"ble": 1, "pax": 2, "wifi": 1}}}
Damit könnte man zumindest mit einer TTN application in unserem Adressierungsschema
imker – standort – bienenstock
bzw. user – site – node
den bienenstock / node dynamisch gestalten oder alternativ – bei nur einem Stock pro Standort – den Imker dynamisch aus der device ID (sic!) generieren, was z.B. für workshops o.ä. reichen würde.
Die gewünschte Doku kommt in eigenem Thread!
Exzellent, so soll es sein. Danke für die positive Rückmeldung.
Ja, damit geht eh schon einiges. Jetzt wünscht sich @Thias halt noch folgendes obendrauf, für maximale Flexibilität, durch die Einführung einer kleinen Konvention.
Just as a note: Wenn die “einfache” Adressierung oben parallel zum skizzierten “advanced”-Ansatz funktionieren soll, dürfen wir nicht blind nach Bindestrichen (“-”) in den devIDs das topic generieren, da von TTN autogenerierte devIDs wie z.b. eui-70b3d57ed005dac6 leider auch schon einen Bindestrich enthalten.
Habe gedanklich gerade nochmal ein klein wenig in die Tiefe gegraben, bevor ich den Spaten ansetze, und dabei folgendes entdeckt:
Das wäre im Kontext der TTN-WAN Adressierung nicht soo schlimm, dann würden die Daten solcher Geräte halt standardmäßig auf einen Kanal konvergiert, der in unserem Fall mit Deinem Beispiel hiveeyes/default/eui/70b3d57ed005dac6 lauten würde.
Blöder ist der Ansatz eines generischen per-Device Adressierungsverfahrens, wie bei [Proposal] Add a generic device-based addressing scheme for "WAN" networks · Issue #133 · daq-tools/kotori · GitHub beschrieben, und das geht dann in der Tat über Kreuz mit der anvisierten TTN-Umsetzungskonvention, wenn man mit Geräte-IDs daherkommt, die UUIDs sind, z.B. 123e4567-e89b-12d3-a456-426614174000, was ja nicht unwahrscheinlich ist. Diese würden falsch umgesetzt werden.
Für das generische Verfahren müsste die Basisregel also eigentlich sein, dass Geräte-IDs opaque behandelt werden müssen. Die device Variable, z.B. aus /d/{device}/data.json, darf also niemals zerlegt werden.
Wir müssen also doch an irgendeiner Stelle vorsehen, elegant zwischen beiden Verfahren unterscheiden zu können – einmal mit, und einmal ohne TTN-WAN-spezifische Topic-Umsetzung.
Der Patch [DA] Add per-device addressing (DA) to WAN topic/channel decoding strategy by amotl · Pull Request #136 · daq-tools/kotori · GitHub bringt diese Aspekte mit ein, und unterscheidet nun zwischen “generischer” Geräteadressierung, und einer sog. “dashed topology” Geräteadressierung, adressierbar per /d vs. /dt nach dem <realm>. Letztere Variante entspricht @Thias’ Wunschverfahren, davon wird die generische Variante jedoch nicht beeinträchtigt. [1]
Beide Varianten unterscheiden sich in der Handhabung des -. Die erste interessiert er nicht, die zweite versucht, sinnvoll damit umzugehen, indem sie die Adressierungsfragmente entsprechend auf die Kanaltopologie umzulegen versucht, wie es normalerweise ein MQTT Topic oder HTTP Pfad tut, der die Fragmente per / trennt.
P.S.: Das Feature ist noch nicht released, und braucht noch Dokumentation. ↩︎
Nur eine kleine usability-Bemerkung zu d vs. dt im Pfad, für Leute, die das nur sporadisch nutzen fällt der Unterschied in der URL vermutlich hat nicht auf. Ggf. ist das ja auch der Plan, fürs debuggen könnte etwas offensichtlicheres, z.B. dt vs. gd oder gleich dashed vs. generic hilfreich sein.
