TTS-/TTN-Daten an Kotori weiterleiten

Entwicklung / Development Daten / Data
, ,
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.

130

Wo ist das beschrieben, also was ist “hier”? Das wäre dann falsch in der Doku.

Ich kann mir gut vorstellen, dass dieses Feature Interpretationsspielraum bietet, wenn man sich für die Details interessiert, weil die Implementierungsdetails bisher noch nirgends dokumentiert wurden. Daher danke für die Gelegenheit Deiner Frage! :sunflower:

Aus Sicht der Benutzerinnen funktioniert es “einfach so” – zumindest die Datenannahme. [1]

  1. Um den HTTP Datenexport mit diesen neuen Adressierungsvarianten habe ich mich bisher noch gar nicht gekümmert. ↩︎

131

Passt alles, cognitive missmatch bei mir! :-) Bin davon ausgegangen, dass die /device/-Adressierung identisch mit der Referenzimplementierung ist.

1 Like
132

Ahja verstehe. Nein, eben genau nicht. Es soll das kanonische Verfahren werden, um Geräte nach ID zu identifizieren, wenn man sicherstellen kann, dass die Identifizierer eineindeutig sind, und man sich keinerlei Gedanken um Kanalgruppen machen will.

Dieses Verfahren wird die Basic application - Kotori DAQ Konfigurationsvariante und die entsprechenden Adressdekodierungsroutinen kotori/kotori/daq/strategy/lan.py at 0.27.0 · daq-tools/kotori · GitHub überflüssig machen.

135

Erledigt. Vielen Dank für die lange Begleitung dieses Features.

root@pulp:/srv/www/organizations/hiveeyes/putsreq.hiveeyes.org# docker compose stop
[+] Stopping 3/3
 ✔ Container putsreqhiveeyesorg_app_1    Stopped                                                                                                          11.8s
 ✔ Container putsreqhiveeyesorg_redis_1  Stopped                                                                                                           2.3s
 ✔ Container putsreqhiveeyesorg_db_1     Stopped

Sobald ein neues Release draußen ist, können wir dann endlich LABS - Store and visualize data using InfluxDB and Grafana - #17 by amotl - Application Development - The Things Network mit mehr Substanz versorgen.

… ist ja furchtbar, was dafür sonst so anzustellen ist, um die Daten passend zu routen. Die meisten Handreichungen scheinen sich um Node-RED zu drehen.

See also:

1 Like
136

Sie hat auch einen eindeutigen Vorteil gegenüber den spezielleren Varianten: Per Pfad-Adressierung lassen sich eine Reihe mehr erlaubter Zeichen verwenden als was per TTN Device ID erlaubt wäre – nämlich alles was per URL übertragbar ist, und was InfluxDB als Datenbank/Tabellenname akzeptiert.

1 Like