Das wäre im Kontext der TTN-WAN Adressierung nicht soo schlimm, dann würden die Daten solcher Geräte halt standardmäßig auf einen Kanal konvergiert, der in unserem Fall mit Deinem Beispiel hiveeyes/default/eui/70b3d57ed005dac6 lauten würde.
Für das generische Verfahren müsste die Basisregel also eigentlich sein, dass Geräte-IDs opaque behandelt werden müssen. Die device Variable, z.B. aus /d/{device}/data.json, darf also niemals zerlegt werden.
Wir müssen also doch an irgendeiner Stelle vorsehen, elegant zwischen beiden Verfahren unterscheiden zu können – einmal mit, und einmal ohne TTN-WAN-spezifische Topic-Umsetzung.
Beide Varianten unterscheiden sich in der Handhabung des -. Die erste interessiert er nicht, die zweite versucht, sinnvoll damit umzugehen, indem sie die Adressierungsfragmente entsprechend auf die Kanaltopologie umzulegen versucht, wie es normalerweise ein MQTT Topic oder HTTP Pfad tut, der die Fragmente per / trennt.
P.S.: Das Feature ist noch nicht released, und braucht noch Dokumentation. ↩︎
Nur eine kleine usability-Bemerkung zu d vs. dt im Pfad, für Leute, die das nur sporadisch nutzen fällt der Unterschied in der URL vermutlich hat nicht auf. Ggf. ist das ja auch der Plan, fürs debuggen könnte etwas offensichtlicheres, z.B. dt vs. gd oder gleich dashed vs. generic hilfreich sein.
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.
Variante 1 bliebe gleich. Variante 2 würde nochmal einen Tick generischer angelegt – nämlich als “by-channel Adressierung”. Wie genau eine Kanaladresse dekodiert wird (hier: “dashed-topology”), kann dann die jeweilige Implementierung/Konfiguration flexibel festlegen. Schön!
Zusätzlich zu den langen Varianten wären auch noch Abkürzungen /d vs. /c denkbar, die sich zumindest besser unterscheiden lassen als /d vs. /dt. Auch schön!
Beide Labels haben auch noch die gleiche Wortlänge von sechs Buchstaben, daher stehen die Komponenten in der Doku fluchtend-symmetrisch nebenuntereinander, wie im Beispiel oben zu sehen. Exzellent.
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.
Ahja. Folgende Beispiele sind besser, weil sie zeigen, dass Felder/Variablen auch in den Host-Teil des base-url Konfigurationsattributs eingebaut werden können.
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.
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?
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.
@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.
