TTS-/TTN-Daten an Kotori weiterleiten

Entwicklung / Development Daten / Data
, ,
108

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

109

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

image
image2048×2048 403 KB

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

110

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
111

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.

112

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
113

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!
114

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

115

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

1 Like
116

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

117

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 ;[.

118

Bist du das @Jan?

119

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
120

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

image
image1098×132 10.5 KB

121

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?

122

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
123

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

2 Likes
124

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
125

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
128

Ja genau.

Nein, es gilt nur fürs “direct channel addressing”, nicht fürs “direct device addressing”.

Die Doku sollte stimmen. Die SensorWAN Konvention beschreibt das SensorWAN payload format signalling nur abstrakt, ich sollte im Anhang bei addressing examples wohl noch etwas konkreter werden, und dann am besten auf die entsprechenden Implementierungsdetails von Kotori verweisen.

=> /data muss immer und in jedem Fall dran, daran hat sich nichts geändert.

Bei diesem Verfahren bestimmt die Device ID nur das letzte Fragment <name> in <realm>/<network>/<group>/<name>. Hier ist <realm> ohnehin vorgegeben, und <network> sowie <group> werden dann fix mit devices bzw. default belegt.

Bei dieser Adressierungsvariante wird also implizit ein voller Kanalpfad erzeugt [1], wie dieser:

hiveeyes/devices/default/123e4567-e89b-12d3-a456-426614174000

Der Code dazu ist jener:

Die volle Kanaladressierung ist die Basiskonvention von SensorWAN und die kanonische Referenzimplementierung des entsprechenden Verfahrens in Kotori, und damit weiterhin die bevorzugte Methode. Du brauchst also nichts zu ändern.

Wenn Du Dir jedoch im speziellen Fall von TTS/TTN entsprechende Komfortmerkmale bzgl. der Verwaltung Deiner Geräte, Dekoder und Applications in der TTN Konsole wünschst, um dort z.B. mehrere Geräte über die gleiche “Application” fahren zu können, wie @Thias, dann kannst Du natürlich wahlweise auch die neuen Verfahren verwenden.

  1. Dadurch besteht, im Gegensatz zum “direct-channel” Verfahren, hier keine Gefahr, auf fremde Kanalgruppen schreiben zu können. ↩︎

1 Like
129

Danke für die Erklärung, das war mir so nicht bewußt, ich bin irgendwie davon ausgegangen, dass /device/ dann die volle Kanaladressierung wie hier beschrieben macht

und man dafür dann eben auch <network> und <group> braucht. Gut, dann haben wir drei mögliche Adressierungsarten.