Ich dachte, testdrive wäre ein weiterer Realm und Realms damit auch variabel.
Aber ich kann hiveeyes auch aus der Device ID nehmen und pauschal als mein Realm annehmen.
Anyway, das Problem mit der Konvention vom Payloadformat bleibt
Wunderbar.
Ja. Ach. Da ist noch Platz in der Datei! ;]
Klappt bislang auf unserem Nachbarhost eltiempo hervorragend 
. Bis es umfällt, können wir ruhig so weitermachen ;]. Nen Geschwindigkeitswettbewerb lässt sich so vielleicht nicht gewinnen, aber in der Haltungs- und Harmonienote wirds ne 10 – im Wortsinn!
Ahja. Genau, nein. testdrive ist ein offener Kanal anstelle der geschützten Benutzerkanäle, und kommt topologisch hinter / untergeordnet zum Realm hiveeyes.
Ich finde das deckt sich doch dann konzeptionell hervorragend mit der Idee, dass es eine “echte” 1:1 Verbindung zwischen einer TTN Anwendung und einer Kotori Anwendung gibt? Im besten Falle heißen sie auch noch gleich. Gleichzeitig reduziert sich der Anteil an Informationen, der in der Device ID stecken muss.
Ich finde es heuristisch akzeptabel, und die Signatur ist bislang hinreichend einzigartig. Wenn es zu langsam wird, müssen wir sie halt in Rust neu schreiben. Wenn sie unzureichend ist, müssen wir sie halt verfeinern.
"uplink_message" in payload and "decoded_payload" in payload
1 Like
Check, habe mich geirrt. Go ahead
Das Payload lässt sich sicher auch über "tenant_id": "ttn" als von TTN stammend identifizieren.
1 Like
Das volle TTN Payload sicherlich, aber nicht mehr die gefilterte Variante, wie von @Stefan verwendet.
Vielleicht machen wir zwei verschiedene Signaturerkennungen, weil @Stefan’s Anwendungsfall ja bereits nun wunderbar durch die bereits bestehende Implementierung abgedeckt ist, per Einzelgeräteadressierung.
Man könnte sagen, wenn man die möchte, dann bitte so. Und gleichermaßen könnte man sagen, dass die neuen Varianten bitte gerne eine feinere Heuristik bevorzugen würden. Aber ob sich der Unterscheidungsaufwand lohnt?
Und falls hilfreich, so schaut der Header vom Webhook aus
{
"VERSION": "HTTP/1.1",
"CONNECTION": "close",
"ACCEPT-ENCODING": "gzip",
"X-TTS-DOMAIN": "eu1.cloud.thethings.network",
"CONTENT-TYPE": "application/json",
"USER-AGENT": "TheThingsStack/3.25.2-rc100-SNAPSHOT-55891a035 (linux/arm64)",
"CDN-LOOP": "cloudflare",
"CONTENT-LENGTH": "2096"
}
Der User Agent hat mit TheThingsStack/3* auch einen Fixpunkt und Stackversion für den Dekoder.
1 Like
Ja, das ist doch auch mal nett. So wird es das beste sein, das als Signatur heranzuziehen, danke! [1]
Hinweis: Ich habe noch keine Ahnung, ob die entsprechenden Stellen im Code einfachen Zugriff auf die HTTP Header bieten. Es wird sich zeigen. ↩︎
Die Filterung kommt für mich nicht in Frage, denn die spannenden Infos zur Signalqualität stecken nicht in der uplink_message. Worum geht es genau? Siehe die Panels in [1] ganz unten in der ausklappbaren Zeile.
[1] Grafana
Dass Du Dir das volle Payload nicht entgehen lassen willst, ist klar! Vielleicht ändert @Stefan seine Meinung ja noch, aber einstweilen finde ich es hervorragend, dass damit drei jeweils leicht verschiedenartige Anwendungsfälle hoffentlich endlich gut zusammenkommen werden.
1 Like
Auf keinen Fall alles in die DB blasen. Nach der Extraktion relevanter Teile den Rest bitte verwerfen.
1 Like
Du wirst den Patch selber anschauen und ggf. Einfluß nehmen können ;].
1 Like
Ich beschäftige mich erst seit kurzem mit TTN und dem Datentransfer zu Hiveeyes. Das sind meine ersten Versuche, da bin ich natürlich sehr froh das die ersten Daten in Grafana ankommen.
Ansonsten bin ich hier aber nicht fixiert und wenn es eine flexiblere Lösung gibt, mit der ich am Ende auch noch zusätzliche nützliche Informationen wie die Signalstärke darstellen könnte, wäre das natürlich von Vorteil und ich würde das selbstverständlich auch nutzen.
2 Likes
data.update(message["uplink_message"]["decoded_payload"])
Hier wird der Datenteil aus dem vollen Payload entnommen. Die Filterung im Webhook ist doch dann gar nicht nötig. Der Metateil würde erhalten bleiben können für weitere Extraktionen. Sprich, auch die tenant_id.
Nötig ist er keinesfalls. Aber ich finde es gut, auch diesen Anwendungsfall abzudecken, der ja potentiell extra als Einstellung im TTN vorgesehen wurde, um datensparsam Daten nach außen rausgeben zu können, was für manche Anwendungsfälle bestimmt sehr relevant ist.
@Andreas, schau mal bitte auf den PR. Die volle Testumgebung kann ich aus Zeitgründen nicht aufsetzen. Getestet habe ich nur in der Python Konsole 
2 Likes
Exzellent. Ich hatte so gehofft, dass Du vielleicht einen Patch schicken würdest. Bedankt! Ich werde später noch ein paar Softwaretests hinzufügen.
1 Like
Ist integriert und wurde gerade ad hoc aufgespielt. Vielen Dank!
1 Like
Der Dekoder hat jetzt auch eine kleine Routine, um ihn ad hoc benutzen zu können, die in dieser Situation helfen kann.
Durch Datenübertragung per MQTT kommt nicht an - #9 by mois inspiriert bin ich gerade kurz bei Setup (LoRA) — MultiGeiger V1.17.0-dev documentation gelandet, wo ich aufgeschnappt habe, dass dort ein X-SID HTTP Header benutzt wird, um die Sensor ID zu übertragen.
Das fand ich reizvoll, hat aber doch den gleichen Nachteil, dass, wenn das auf “Application”-Ebene konfiguriert wird, jede Application nur ein einziges Gerät versorgen kann?
Was aber wäre, wenn wir einem solchen HTTP Header Feld die {/devID} zuweisen könnten? Das klänge doch schick?