TTS-/TTN-Daten an Kotori weiterleiten

[Andreas]

@Andreas

Danke, Clemens. Ich könnte mir folgende Konvention vorstellen, die mit sprechenderen Namen arbeitet, und auf “device” vs. “channel” abzielt, um beide Verfahren zu unterscheiden.

Da diese Benennungskonvention hier auf Anklang stieß, ist sie jetzt Teil des offiziellen Verfahrens, siehe SensorWAN “direct” addressing. Vielen Dank!

[Andreas]

Halleluja. 3 1/2 years in the making. Vielen Dank für Eure Beiträge!

Patches

• [DA] Add per-device addressing (DA) to WAN topic/channel decoding strategy by amotl · Pull Request #136 · daq-tools/kotori · GitHub
• [TTN] Add documentation about multi-tenant data acquisition by amotl · Pull Request #141 · daq-tools/kotori · GitHub

Dokumentation

• MQTTKit application - Kotori documentation
• The Things Stack & Network (TTS, TTN) - Kotori documentation ^[1]

Beispiel

Datenübertragung

Mit Mandantenfähigkeit, wie lange ersehnt.

wget https://github.com/daq-tools/kotori/raw/main/test/test_tts_ttn_full.json
cat test_tts_ttn_full.json | \
  http POST https://swarm.hiveeyes.org/api/hiveeyes/channel/testdrive-area42-loranode/data

Grafana Dashboard

Beispiel: LoRaWAN multi-tenant first transmission, mit test_tts_ttn_full.json.

Backlog

• Bitte schickt mir ggf. Verbesserungsvorschläge zur Dokumentation und darüber hinaus, für optimale Benutzerfreundlichkeit. Merci!

---

1. Zur Aufhübschung hab ich mich hier Deines Dashboards bedient, @Thias. Sag bitte Bescheid, wenn Dir das nicht recht ist. ↩︎

[Andreas]

Unabhängig zu den gerade erschlossenen Neuerungen rund um die Datenfernmeldung per HTTP webhook gäbe es natürlich weiterhin die Möglichkeit der Datenfernmeldung per MQTT.

Ich glaube bisher wurde das immer noch per Mosquitto Bridge Konfiguration realisiert, vielleicht könnte man das aber zukünftig auch im Kotori machen.

Was ich interessant und schade finde, ist jenes, das ich gerade auf der entsprechenden Dokumentationsseite zur Integration über MQTT entdeckt habe:

Note on Using the Tenant ID

For all The Things Stack deployments except the Open Source, application IDs and other endpoints include the tenant ID. For the integration with The Things Stack MQTT Server on these deployments this means two things:

• The Username used for connecting will be of format {application id}@{tenant id} (see the section below)
• The MQTT topics will contain {application id}@{tenant id} (see MQTT Clients section)

– https://www.thethingsindustries.com/docs/integrations/mqtt/

Auf Deutsch: Es gibt tatsächlich eine “echte” Mandantenfähigkeit per “tenant ID”, diese wiederum steht aber in der Open Source Version nicht zur Verfügung!?

Ich denke es wird Zeit, dass wir mal ein paar mehr Seitenblicke wagen, mit einem dieser beiden guten Stücke, die mittlerweile garantiert auch schon aus der Mauser raus sind.

– OpenChirp: Open Source management framework for LoRaWAN networks
– ChirpStack: Open Source LoRaWAN network server stack

[Andreas]

Über Adding Webhook Templates | The Things Stack for LoRaWAN findet man schnell zum Repository GitHub - TheThingsNetwork/lorawan-webhook-templates, wo einige Vorlagen für die Fernmeldevariante über HTTP Webhooks gelistet sind.

Hier finden sich Beispiele von ein paar Kollegen.

• ttnmapper.yml
• thingspeak.yml
• dezem.yml

It looks like it would only be a small box of YAML.

– https://twitter.com/acloudguru/status/1344724013122260993

[Andreas]

@Andreas

Hier finden sich Beispiele von ein paar Kollegen.

Ahja. Folgende Beispiele sind besser, weil sie zeigen, dass Felder/Variablen auch in den Host-Teil des base-url Konfigurationsattributs eingebaut werden können.

• cloudstudio.yml
• example.yml

fields:
  - id: server_instance
    name: Server instance
    description: Server instance hosting your IoT platform
    secret: false
    default-value: gear.cloud.studio
base-url: https://{server_instance}/Services/Interfaces/TTNInterfaceService.svc

[Andreas]

Hi Matthias,

@Thias

Für die Datencodierung vom Node zu TTN kann man entweder CayenneLPP nutzen oder eine individuelle Decoderfunktion hinterlegen, die dann zur Implementierung der Codierung auf dem Node passt und zB. ein JSON Paket zerlegt und auf den Variablenraum bei TTN packt. […] Meine klare Empfehlung ist, CayenneLPP zu nutzen, allerdings […]

Die Idee, CayenneLPP zu nutzen, ist keine schlechte – wir haben ja bei Integration des Cayenne Low Power Payload Protocol schließlich einiges dran geschafft und es lief im Großen und Ganzen recht gut, sofern ich mich richtig erinnere.

Beim Wälzen der Dokumentation von TTS/TTN bin ich jedoch gerade auf Device Repository | The Things Stack for LoRaWAN gestoßen, mit dem entsprechenden Repository bei GitHub - TheThingsNetwork/lorawan-devices: Device Repository for LoRaWAN devices.

Dort findet sich bei espeasy/packed-decode-uplink.js ein ansehnlicher Decoder von ESPEasy, der u.a. auch nativ die spezifischen Meßgrößen bzw. konkreten Gegebenheiten der BME-, BMP, INA219 - und auch HX711 Sensoren unterstützt.

Vielleicht ist das einen Blick wert, wenn es irgendeinen Mehrwert im Vergleich zum CayenneLPP Protokoll bietet?

Viele Grüße,
Andreas.

[Thias]

Ich habe den Webhook umgestellt und was soll ich sagen? Das funktioniert
Als URL habe ich eingestellt:
https://swarm.hiveeyes.org/api/hiveeyes/channel/{/devID}/data

Meine Device IDs sind noch 4 teilig und Bindestrich-separiert alla
hiveeyes-thias-freiland-hive2.
“hiveyes-” wird zuverlässig gefiltert und der Rest an den festen Realm angehängt. MQTT am Server gibt dann aus:
hiveeyes/channel/hiveeyes-thias-freiland-hive2/data.json {...} und die Daten landen in der gleichen Influx Series wie vorher.

Perfekto!

Werde beizeiten die Device IDs auf dreiteilig kürzen. Dazu muss ich allerdings auch einmal vor Ort sein, um die Einheit neu bei TTN joinen zu lassen.

[Andreas]

@Thias

Ich habe den Webhook umgestellt und was soll ich sagen? Das funktioniert. Perfekto!

Exzellent. So soll es sein, danke für die Rückmeldung. In Folge können wir den PutsReq Dienst jetzt also abschalten?

Backlog

@Thias

Als URL habe ich eingestellt: https://swarm.hiveeyes.org/api/hiveeyes/channel/{/devID}/data

Meine Device IDs sind noch 4 teilig und Bindestrich-separiert à la hiveeyes-thias-freiland-hive2.

• Diesen Handreichungsschnipsel ordentlich an passender Stelle dokumentieren. Merci!

[clemens]

@Andreas

In Folge können wir den PutsReq Dienst jetzt also abschalten?

@Thias und ich hatten auch eine PutsReq-Instanz eingerichtet, damit Leute mit BOB-Kit Daten parallel an die Uni Bremen und an hiveeyes schicken können. Ich habe aber keinen Überblick ob das (noch) genutzt wird.

[Andreas]

@clemens

Ich habe keinen Überblick ob Leute mit dem BOB-Kit diese Schnittstelle noch nutzen.

Scheinbar nicht, es kommen keine Anfragen mehr an. Der PutsReq Dienst wird also abgeschaltet.

[Thias]

@Andreas

In Folge können wir den PutsReq Dienst jetzt also abschalten?

Absolut. Seit der Umstellung habe ich keine Probleme bemerkt. Und zur Not kann ich auch auf das Original putsreq.com zurückgreifen.

[Andreas]

@Andreas

Scheinbar nicht, es kommen keine Anfragen mehr an.

Da funkt doch noch etwas.

• device_id: hiveeyes-jankr-hhduv-datscha01
• decoded_payload: digital_out_0: 0, load_5: 60.022, voltage_0: 4.02

@Andreas

Der PutsReq Dienst wird also abgeschaltet.

Also wohl doch erstmal nicht ;[.

[Thias]

Bist du das @Jan?

[Andreas]

@Andreas

Da funkt doch noch etwas.

• device_id: hiveeyes-jankr-hhduv-datscha01

Die Anfragen kommen z.Zt. bei https://putsreq.hiveeyes.org/HVcfGHeC4jDM4SRQzFN7 an. Wir könnten Anfragen dorthin am Nginx per Lua identifizieren (nach device_id=hiveeyes-jankr-hhduv-datscha01) und entsprechend an die neue HTTP-basierte SensorWAN-by-channel Annahmeschnittstelle auf swarm.hiveeyes.org umleiten.

[Andreas]

@Andreas

device_id: hiveeyes-jankr-hhduv-datscha01

Ich hab auch mal einen Sensor geschaltet, damit wir mitbekommen, wenn etwas kaputtgeht.

[Andreas]

@Andreas

Wir könnten Anfragen umleiten…

@Thias

Bist du das @Jan?

Besser wäre aber natürlich, @Jan würde es in der TTN Konsole umstellen, entweder wie Du es bei TTS-/TTN-Daten an Kotori weiterleiten - #113 by Andreas gemacht hast …

@Thias

Als URL habe ich eingestellt: https://swarm.hiveeyes.org/api/hiveeyes/channel/{/devID}/data

… oder vermutlich “direkter”, ohne {/devID} Platzhalter, sondern ausformuliert:

https://swarm.hiveeyes.org/api/hiveeyes/channel/jankr-hhduv-datscha01/data

Könntest Du das tun, @Jan?

[Jan]

Hallo zusammen,
jep, das bin ich, sorry!

Ich habe den Webhook jetzt auch angepasst, und zwar auf https://swarm.hiveeyes.org/api/hiveeyes/channel/jankr-hhduv-datscha01/data

Ich beobachte das mal kurzfristig.
VG,
Jan

[Jan]

Ok, das scheint zu funktionieren. In Grafana ist der aktuelle Datenpunkt um 10:50 Uhr zu sehen.

[Andreas]

Exzellent, herzlichen Dank! Ich habe die Auditing Tabellen gelöscht und schaue dann mal, ob doch noch andere Anfragen reinkommen. Wenn nicht, schalte ich unsere PutsReq Instanz ab.

> db.requests.drop()
true
> db.responses.drop()
true

[Andreas]

Ich habe jetzt auch mal die bei MQTTKit application - Kotori documentation erklärte Einstellung direct_channel_allowed_networks aktiviert ^[1][2].

# Restrict SensorWAN direct addressing to specified networks/owners.
direct_channel_allowed_networks = jankr, testdrive, thias

---

1. Auf elbanco unter /etc/kotori/apps-enabled/hiveeyes.ini. ↩︎

2. Solange wir noch keine Authentifizierungsmöglichkeit implementiert haben, ist es ein wenig sicherer, auch wenn nicht unbedingt schädliches Verhalten zu befürchten ist. ↩︎