Datenweiterleitung via TTN / LoRa zu Hiveeyes, BOB und BEEP einrichten

Entwicklung / Development Funkinfrastruktur / Wireless infrastructure
, ,
1

Einleitung

Das Ganze geht momentan nur mit der Hiveeyes Terkin Datalogger-Software in Verbindung mit der CayenneLPP Encodierung der Daten. Der Datenfluss ist dann dieser

NODE -> TTN -> PUTSREQ Endpoint -> HIVEEYES/BOB/BEEP

Die Konfiguration des Terkin-Datenlogger wird unter Konfiguration des Terkin-Datenloggers für LoRaWAN/TTN beschrieben.

Putsreq

Dieser Service dient dazu, das Datenpaket von TTN so umzuschreiben, dass es von den Datenaquise-Services (DAQ) korrekt angenommen und verarbeitet werden kann. Es bestehen auch bereits Putsreq Endpoints, die von allen Teilnehmern verwendet werden können. Die URLs sind bei @Thias oder @clemens zu erfragen.

Für ein eigenes Bucket wird bei https://putsreq.com oder einer selbst gehosteten Instanz eine

Eingehende Payloads von TTN können hier nach Einrichtung der Telemetrieeinheit und der TTN-App in dem Abschnitt POST betrachtet und später, bei erfolgreicher Annahme der Daten vom DAQ-Service, dessen Bestätigung im Response Abschnitt angesehen werden.

TTN (Console)

In der TTN Console eine Application einrichten. Nun der Application ein Device zugeordnen.

Wichtig! Die zu vergebende TTN dev_id muss dem Namensschema unter [1] entsprechen! Als Vorlage bitte hiveeyes-USER-LOCATION-NAMEOFHIVE verwenden, dann alle großgeschriebenen Platzhalter mit den eigenen (dann alles klein geschrieben) ersetzen, keine weiteren Bindestriche verwenden!

Payload Formats

In der Application “Payload Formats” aufrufen

  • in der ersten drop-down “Custom” auswählen
  • darunter auf “decoder” clicken und den Code von GIT /client/TTN/decoder.js 1:1 einfügen und abspeichern.

2020-06-12 20_31_17-The Things Network Console - SeaMonkey
2020-06-12 20_31_17-The Things Network Console - SeaMonkey1048×645 112 KB

Integrations

Ebenfalls in der Application “Integrations” aufrufen und mit

  • einem Click auf “add integration” eine neue hinzufügen, dann
  • “HTTP Integration” auswählen und dort
    – Process ID: hiveeyes-putsreq
    – URL: die Putsreq-Adresse (ohne /inspect) für die Datenweiterleitung zu Hiveeyes.org eintragen
    – Method: POST
    – speichern

2020-06-12 20_26_23-The Things Network Console - SeaMonkey
2020-06-12 20_26_23-The Things Network Console - SeaMonkey892×595 56.9 KB

ggf. eine weitere HTTP Integration anlegen für BOB (Bee Observer) oder BEEP

  1. LoRaWAN/TTN Setup — Terkin Datalogger 0.10.0 documentation ↩︎

2 Likes
7

A post was merged into an existing topic: Selbst-gehostetes PutsReq unter “putsreq.hiveeyes.org”

8

Die neue Version von decoder.js findet man jetzt unter terkin-datalogger/client/TTN/decoder_v3.js at main · hiveeyes/terkin-datalogger · GitHub könnten für TTS-/TTN-Daten an Kotori weiterleiten - #41 by Stefan ggf. relevant sein könnte.

9

Hi Clemens,

Vielen Dank. Der spielt schon eine Rolle, aber er sitzt schon drei Schritte vorher in der Pipeline, wo er erstmal die Binärdaten vom Gerät dekodiert und für eine etwaige Serialisierung ins JSON Format bereitstellt, wie z.B. ttn-uplink-example.json.

Appliance -> LoRaWAN -> TTN gateway
  -> Device "uplink" message -> TTN Network/Application Servers
  -> TTN JavaScript decoder -> TTN outbound Webhook
  -> HTTP/JSON -> Kotori (swarm.hiveeyes.org)

Was Kotori jetzt mit https://github.com/daq-tools/kotori/pull/81 macht, ist, zunehmend die Funktionalität des PutsReq Umsetzers putsreq.hiveeyes.ttn_v3.js zu integrieren, den wir auf Empfängerseite bisher immer noch brauchen.

Ein paar Details fehlen noch.

Viele Grüße,
Andreas.

1 Like
10

Mit den letzten Entwicklungen bei TTS-/TTN-Daten an Kotori weiterleiten - #77 by Thias ff. können wir die PutsReq Instanz vielleicht bald abschalten.

Das darf natürlich nicht so sang- und klanglos über die Bühne gehen, finde ich, weil es konzeptionell ja gar nicht so verkehrt ist. Grundsätzlich ist es natürlich für uns und andere viel praktischer, wenn ein “first citizen” TTN Umsetzer in Kotori selbst untergebracht wird. Andererseits ist das Konzept rund um “kleine Code Schnipsel bemühen, um gezielte Probleme zu lösen, ggf. auch per JavaScript, weil man es eh gerade in der Hand hat, z.B. für den CayenneLPP Dekoder [1], oder anderswie auf der TTN Konsole” ja nicht dumm. Nur, dass PutsReq so viele Ressourcen verbraucht, war im wesentlichen das große Problem.

Langer Rede kurzer Sinn, ich versuchte ja schon lange, diese JavaScript Schnipsel irgendwie anders hosten zu können, und aus dieser Idee ist nun der Beitrag bei [udf] Unlock JavaScript for user-defined functions by amotl · Pull Request #667 · mqtt-tools/mqttwarn · GitHub entstanden. :boom:

Damit müssen wir die hier erarbeiteten Dinge vielleicht nicht komplett beerdigen, sondern sie können anderswo sinnvoll weiterleben.

  1. terkin-datalogger/decoder_v3.js at main · hiveeyes/terkin-datalogger · GitHub ↩︎

11

Hi @Thias,

Ist es eigentlich schon soweit? Aufgespielt hatten wir Deinen Patch ja bereits, aber danach wieder ein bisserl den Faden verloren.

Viele Grüße,
Andreas.

12

Ich denke, dies ist der Faden:

13

Ja achso, die Geschichte zur Generalisierung der WAN Adressierung ist klar, das meine ich nicht.

Ich meine nur, ob wir den PutsReq Dienst denn nicht schon abschalten können? Da kamen doch vor unserem kürzlichen Decoder Patch auf dem HTTP Kanal nicht erkannte TTN Payloads von Dir an, die jetzt ja scheinbar gut konvergieren, und keine Meldungen auf dem Fehlerkanal mehr verursachen.

Daher vermute ich, dass jetzt endlich mehr geht, wo es das vorher noch nicht tat, und die Daten des jeweiligen Kanals wunderbar in der Datenbank landen. Gleichzeitig vermute ich, dass wir den alten Umsetzer daher nicht mehr brauchen.

14

Hatte ich mal versucht, klappte aber nicht. Ich schaue heute Abend noch einmal. Die MQTT Subscription gab jedenfalls das komplette Payload aus. Im Moment nutze ich wieder putsreq.com, weil sehr stabil zuletzt

15

Du meinst, wenn man auf swarm.hiveeyes.org subscribed, siehst Du das komplette Payload von TTN, und dachtest, das wäre ein Indikator, dass der Dekoder nicht ordentlich arbeitet?

Ich glaube es ist andersrum: Der Dekoder ist nicht spezifisch für HTTP, sondern dekodiert erst nach der Annahme per MQTT. Der HTTP Kanal wiederum konvergiert ja die Nachrichten 1:1 nach MQTT, daher ist das beobachtete Verhalten “ganz normal”.

1 Like
16 
> use hiveeyes_thias
> select * from ttntest_hiveeyes_thias_freiland_hive1_sensors
name: ttntest_hiveeyes_thias_freiland_hive1_sensors
time                analog_in_1 analog_in_2 analog_in_3 bw  counter device_id                     freq  gtw_count gw_machbar-ffp_rssi gw_machbar-ffp_snr gw_ttig-pdm-thias_rssi gw_ttig-pdm-thias_snr sf
----                ----------- ----------- ----------- --  ------- ---------                     ----  --------- ------------------- ------------------ ---------------------- --------------------- --
1684781908418728000 65.23       64.96       4.09        125 970     hiveeyes-thias-freiland-hive1 868.5 2         -100                4.8                -102                   6.5                   7

Sieht sehr gut aus. Cool!

Auf Putsreq kann ich (noch) trotzdem nicht verzichten, weil ich zwei verschiedene Standorte im Level 3 vom Topic nutze bzw Kotori die Bindestriche in der DeviceID nicht in Slashes umsetzt so wie ich das in Putsreq gelöst hatte:

const URL = "https://swarm.hiveeyes.org/api/" + output.dev_id.replace(/-/g, '/') + "/data";

Daher kommen jetzt mit der DeviceID freiland-hive1 und der Webhook URL https://swarm.hiveeyes.org/api/hiveeyes/thias/freiland{/devID}/data die Daten in der DB freiland_freiland_hive1_sensors an. Würde aber gerne die bisherige DB weiterschreiben.

17

Wunderbar.

Ja, das wäre das WAN Adressierungsverfahren, wenn die Uplink → Downstream Kommunikation über die TTN Organisation / Application läuft, nicht? Aber Du kannst doch das HTTP Ziel auch pro Gerät konfigurieren, nicht?

18

Ich habe 3 Devices für zwei Standorte in einer TTN App und die nutzen Webhooks gemeinsam. Also nein, alle Devices haben die gleiche Base URL.

Und die Devices auf Apps per Standort verteilen? würde gehen, aber ist nicht wirklich schick ;-) und ich müsste an die Boards zum flashen :confused:

19

Ja klar, wir wollen noch besser werden. Aber es wäre immerhin jetzt schon verfügbar.

Oh, ach. Nein, das will ich natürlich nicht vorschlagen. Ich dachte einfach nur daran, direkt pro-Device in der TTN Konsole eine Webhook-URL anzugeben, auf das richtige Ziel, pro Kanal individuell eben – und fertig ist die Laube.

22

Da es nun (Sommer 2023) die Möglichkeit gibt, Daten via TTN webhook an hiveeyes zu schicken und der selbstgehostetet PutsReq-Dienst einiges an Arbeit und Speicher verlangte und noch dazu nicht so stabil wie gewünscht lief, wollen wir den PutsReq-Dienst komplett abschalten.

Die jetzt “neue” direkten Ankopplungsmöglichkeiten von TTN devices an Kotori / hiveeyes wird hier beschrieben: TTS-/TTN-Daten an Kotori weiterleiten - #107 by Andreas . Ein sehr viel knapperes und mehr hands-on-Beispiel für eine “wide channel”-Konfiguration gibt es unter Pax-Counter mit LoPy4 .

1 Like
23

image image

Hundertvierzig(!) Threads hatte das gesamte Gerät verschlungen. :person_facepalming:

1 Like