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