Payload Decoder

#1

Moin,
ich merke in den Threads, dass ich keinen „copy 'n paste“ payload-Decoder für’s TTN finde. Da wird bestraft, wer einen wilden Mixx an Sensoren hat. Entweder fehlen mir in den Scripten Sensoren oder ich habe zuviele… Und es kommt wohl auf die Stringlänge an… die variiert dann … ohhh ich erahne es aber verstehe es nicht :slight_smile:

Ganz klar ist mir aber folgendes nicht:

Meine Sensebox:Home (Feinstaub, Schalldruck, Temp & Humidity) redet via LoraWan mit dem TTN.
Die Integration zu Opensensemap ist auch via TTN… zumindest war das mein Integrationsweg. Oder sprechen Opensensemap und SenseBox noch über einen anderen Weg miteinandern?
Wenn nicht … wieso kann Opensensemap dann die Daten decodieren?

Aber nun mal ein Vorschlag… wenn ich mir mit der Vorgabe der Sensoren das Binary für die MCU kompilieren lassen kann, kann ich dann nicht auch gleich in diesem Prozess einen Payload-Decoder bereitstellen. Sernsoren, IDs ist doch da alles bekannt.

Ahoi
Christoph

#2

Hallo @Christoph,

ich versuche mal einzelnd auf deine Punkte zu antworten.

Die openSenseMap und TTN reden über unsere TTN Integration per Webhooks. Das bedeutet, dass TTN leitet die empfangenen Informationen an unseren eigenen Endpunkt weiter. Beispiele für die Datenformate findest du hier.

Unsere TTN Integration kann anhand des eingestellten Decoding Profiles in den Geräteeinstellungen die weitergeschickte Nachricht dekodieren.

Wenn ich deinen Vorschlag korrekt verstehe, würde ich sagen, dass das schon der Fall ist. Zumindest wenn du eine senseBox:home V2 registrierst und das Decoding Profile auf senseBox:home stehen lässt. Der kompilierte Sketch schickt die Messwerte der angeschlossenen Sensoren immer in einem vordefinierten Format, welches auch die openSenseMap TTN Integration kennt.

Beste Grüße, Matthias

#3

Was ich mit meiner Idee meinte wäre, dass zur compilierten sketch.bin eine Textdatei mit dem Payload-Decoder für TTN bereitgestellt wird. Weil wenn man im Forum nachschaut, die Decodierung definitv ein Thema ist.

#4

Ich habe mir aber mal den Payload-Decoder Caspar Armster aus dem Forum über GitHub geholt und diesen dann „sehr stumpf“ um die überschüssigen Sensoren befreit.
Ich habe also alle Variablen, Funktionen und Aufrufe mit den überschüssigen Sensoren gelöscht. Es waren UV- und Licht-Sensoren dabei, die meine Box nicht hat. Das hat jetzt wunderbar geklappt, wobei die decodierte Payload nun immer SensorID:Sensorwert ausgibt. Damit kann ich aber super arbeiten. Nicht elegant … aber lüppt.

image
image1654×149 30.1 KB

#5

Ah okay. Also möchtest du schon gerne in TTN den dekodierten Payload sehen und nicht nur die Bytes?

Ich denke das können wir anbieten im TTN Bereich auf der openSenseMap.

Hier das Issue in der API dazu: https://github.com/sensebox/openSenseMap-API/issues/845

1 Like
#6

Das SensorID „Problem“ kann man recht einfach umgehen, indem man statt der IDs valide Namen vergibt, siehe unser abgewandelter Decoder: https://github.com/makerspace-partheland/senseBox-homeV2LoRa/blob/main/payloaddecoder.js

Die Werte/Namen/Bezeichnungen die man nutzen kann, damit die Daten auf opensensemap landen und man gleichzeitig die Werte schön lesbar via TTN im Log sieht oder MQTT abrufen kann, sind hier zu finden: https://github.com/sensebox/ttn-osem-integration/blob/main/lib/decoding/sensebox_home.js

#7

Alternativ kann man auch den CayenneLPP Payload nutzen, der sowohl in Blockly als auch in der Arduino IDE verfügbar ist. TTN kann den dann selbst dekodieren und verwendet einen standardisierten Decoder der von denen auch aktuell gehalten wird. Die OpenSenseMap liest in dem Fall einfach nur noch die dekodierten Daten mit und packt die in die Box rein. Siehe hier