TTS-/TTN-Daten an Kotori weiterleiten

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

2 Likes

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

Patches

Dokumentation

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. ↩︎

1 Like

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:

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

Ü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.

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


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

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

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

Hi Matthias,

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.

Ich habe den Webhook umgestellt und was soll ich sagen? Das funktioniert :slight_smile:
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.

2 Likes

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

Backlog

  • Diesen Handreichungsschnipsel ordentlich an passender Stelle dokumentieren. Merci!

@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.

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

1 Like

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

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

Also wohl doch erstmal nicht ;[.

Bist du das @Jan?

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.

1 Like

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

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 …

… 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?

Hallo zusammen,
jep, das bin ich, sorry! :smiley:

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

2 Likes

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

2 Likes

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

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. ↩︎

1 Like