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.
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.
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.
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
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.
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
}
}
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.
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
Ähnliches hatten wir bereits unter Imkerliche Metadaten angerissen.
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.
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.
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.
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.
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:
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.
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.
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
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
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.
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.
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. ↩︎
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.
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.
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.
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.
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.
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:
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.devID abgeleitet per replace(/-/g, '/') + "/data"devID=hiveeyes-thias-freiland-hive2 wird dann hiveeyes/thias/freiland/hive2/data
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
...
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 ↩︎
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?
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.
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?
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