Workshop zu den Themen IoT, LoRaWAN und The Things Network

15./16. Juli 2024, Akademie in Dillingen

Hubert Högl, Technische Hochschule Augsburg (THA), Hubert.Hoegl@tha.de

URL: https://www.tha.de/~hhoegl/iot_workshop


Neuigkeiten

  • Zusätzliches Material zum Kurs an der ALP in Dillingen (15./16. Juli 2024). Wer Fehler findet, Fragen oder Verbesserungsvorschläge hat kann mir gerne eine Email schicken.

    https://tha.de/~hhoegl/iot_workshop/alp24

  • Ich überarbeite diesen Text gerade, da manche Teile noch nicht das neue Heltec V3 Board beschreiben. Das betrifft vor allem die Abschnitte "Heltec Board V3" und "TTN konfigurieren". Die Demo für das Heltec V3 Board gibt es erst seit 14. Juli, sie ist im git Repo unter ttn_workshop/heltec_v3/.


Das Kursmaterial für den LoRaWAN Versuch auf dem Heltec Board ist im Gitlab Repository https://gitlab.com/huberthoegl/ttn_workshop. Man holt es auf den eigenen Rechner mit

git clone https://gitlab.com/huberthoegl/ttn_workshop

Ich mache gelegentlich Änderungen bei diesem Repository, sollten Sie es schon geklont haben, dann gelegentlich git pull eingeben, damit Sie auf dem neuesten Stand sind.

Die im Text genannten Dateien und Ordner sind in diesem Repository.

Alle Beispiele werden unter Linux gezeigt.

Sollte es nachträglich Fragen zu dem Workshop geben dann schreibt mir gerne eine E-mail an Hubert.Hoegl@tha.de.

Kurzübersicht der Themen

  • Grobe Übersicht zu LoRa und LoRaWAN

  • Account auf https://www.thethingsnetwork.org besorgen.

  • Wo ist das nächste Gateway? Siehe Map.

  • Falls man kein Gateway in der Nähe hat: TheThingsNetwork Indoor Gateway (TTIG)

  • LoRaWAN Gerät entweder selber bauen oder fertig kaufen

  • Eine einfache Anwendung auf ein Heltec-Board bringen

  • Payload kodieren und dekodieren

  • Anwendung und Gerät in TTN Konsole konfigurieren

    Alternative: Command-Line Interface ttn-lw-cli

  • Gerät schickt Daten, die man in der TTN Konsole sieht (Uplink)

    Von der TTN Konsole Daten an das Gerät schicken (Downlink)

  • "Integration": Uplink und Downlink aus der Ferne am TTN Server steuern

    • Storage

    • Webhooks

    • MQTT

    • Node-Red Dashboard

    • TTN Mapper

TheThingsNetwork Übersicht

TTN Übersicht

Zum Vergrössern klicken

Gateways an der Hochschule

  • Gebäude E: Seit 2017 auf dem Dach des E-Technik Hochhauses (Imst Lite Gateway, hsa-lora-gateway)

  • Gebäude J: Seit April 2023, für Workshop aufgebaut (RAK7258, hsa-rak-gateway, Bild)

Gateways

Zum Vergrössern klicken

LoRa Endgeräte

"LoRa Knoten" bzw. "Endgeräte" sind meist kleine batteriebetriebene Geräte die Sensordaten in ein LoRaWAN Netzwerk schicken. Das TheThingsNetwork ist ein frei zugängliches LoRaWAN Netz. Die Software zum Betreiben eines LoRaWAN Netzwerks ist der "The Things Stack", es ist Open-Source Software mit der man auch ein eigenes Netz realisieren kann (https://github.com/TheThingsNetwork/lorawan-stack).

Es gibt einige Möglichkeiten, zu einem Endgerät für LoRaWAN zu gelangen:

Mikroprozessor plus Funkchip

uP plus Funkchip

Die LoRa Funkchips kommen von Semtech (https://www.semtech.com), z.B. SX127x (1. Generation) oder SX126x (2. Generation, stromsparender, mehr Leistung beim Senden). Die 1. Generation findet man noch immer fast überall, z.B. auf den RFM95/RFM96 Modulen von HOPERF (siehe Abbildung). Beim Kauf von LoRa Modulen sollte man darauf achten, dass sie für die in Europa standardisierten 868 MHZ ausgelegt sind.

RFM95

Die Pinbelegung stammt aus dem Manual von HOPERF, siehe https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf.

RFM95-Pins

Beispiele:

  • Arduino Uno mit AVR Mega328 und einem "Dragino" Board, das über SPI mit dem AVR verbunden ist. Auf der Unterseite des roten Dragino Boards ist ein RFM95 Modul aufgelötet. Das war der allererste LoRa Versuch an der Hochschule, ca. 2017.

    Dragino

  • ESP32 + SX1276 auf "Heltec Wifi LoRa 32" Board. Es gibt mittlerweile die Versionen V1, V2 und V3. Die Versionen unterscheiden sich teilweise in den Anschlüssen. Die Stromsparqualität des ESP32 ist jedoch nicht besonders gut. Man tut sich schwer wenn man Geräte bauen will, die jahrelang aus einer kleinen Zelle mit z.B. 1 Ah laufen sollen.

    Heltec Board

Vorteile

⊕ Die Programmierung erfolgt fast immer über das Arduino Framework. Ist also auch für Bastler geeignet.

⊕ Auf dem Mikrocontroller läuft fast immer die LoRa "LMIC" Bibliothek für Arduino (bzw. "MCCI LoRaWAN LMIC").

Nachteile

⊖ Man muss immer noch etwas C oder C++ können, damit man den Arduino Code versteht und ändern kann.

⊖ Manche häufig verwendeten Mikrocontroller wie der ESP32 sind nicht gut für Stromsparen ausgelegt.

⊖ LMIC Bibliothek kann z.B. nicht "Class C" Geräte.

In Micropython programmierbare LoRa-Board

LoPy Modul

Die Abbildung zeigt das "LoPy" Modul der Firma PyCom (https://pycom.io), die von Micropython-Erfinder Damien P. George gegründet wurde. Micropython an sich (https://www.micropython.org) ist freie Software. Das LoPy ist im wesentlichen auch nur ein ESP32 mit SX1276.

Vorteile

⊕ Sehr leichte Programmierung, es gibt nichts besseres für (Programmier)-Anfänger

⊕ Gute Dokumentation, z.B. https://pycom.github.io/pydocs/datasheets/development/lopy.html

Nachteile

⊖ Es gibt (noch) keine freie Alternative für diese Boards

⊖ Die Module gibt es nur bei PyCom und haben einen stolzen Preis

System-on-Chip aus Mikroprozessor und Funkchip

Dabei handelt es sich um Chips die bereits einen Mikrocontroller und einen Funkchip enthalten. Die folgende Abb. zeigt ein "STM32WL55-Nucleo" Board, der obere IC in dem quadratischen Rahmen ist der STM32WL55. Die quadratische Fläche wird üblicherweise von einem Blechgehäuse verdeckt.

STM32WL55-Nucleo

Den STM32WL gibt es auch in der Ausprägung STM32WLE55, er enthält nur einen Kern (Cortex M4), der WL55 hingegen hat zwei Kerne (Cortex M4 + M0).

Fertig verwendbare Module, die mit dem STM32WLE55 ausgestattet sind:

  • "dnt-TRX-ST1" Module von ELV, Link

  • "E5" Module von Seeed, Link

  • "Lora868" Module von Olimex, Link

Die folgende Abb. zeigt das "ELV-LW-Base", das mit "dnt-TRX-ST1" ausgestattet ist (https://de.elv.com/lorawan).

ELV-LW-Base Basisboard

Vorteile

⊕ Sehr gute Stromspareigenschaften

Nachteile

⊖ Schwierigere Programmierung (ST-Micro CubeWL Bibliothek, eher was für erfahrene C Programmierer)

Ein paar Messungen an dem ELV-LW-Base ("LoRIS") Basisboard von ELV mit dem dnt-TRX-ST1 Modul: https://hhoegl.informatik.hs-augsburg.de/hhwiki/LoRIS (XXX leider aktuell hinter VPN)

Es wird bereits an einer Micropython Portierung dafür gearbeitet. Es kann gut sein, dass man in einiger Zeit komplette LoRaWAN Knoten mit diesem Baustein in Python programmieren kann.

LoRaWAN Module mit AT-Befehlssatz

Manche LoRaWAN Module können über die serielle Schnittstelle mit einem "AT-Befehlssatz" angesteuert werden. Eines der Ersten war das RN2483 von Microchip (https://www.microchip.com/en-us/product/RN2483).

RN2483

Der Befehlssatz wird in diesem Dokument beschrieben: DS40001784G

Es gibt auch Firmwares für die oben genannten Module auf der Basis des STM32WL55, die AT Befehlssätze implementieren. Leider gibt es hier keine Standardisierung der Befehle. Hier ist z.B. die Beschreibung für die AT Kommandos bei der Firmware für STM32WL55: AN5481. Die gleiche Firmware funktioniert auch auf den ELV Modulen "dnt-TRX-ST1". Das "E5" Modul von Seeed hat bereits einen eingebauten AT Befehlssatz, allerdings ist der auch wieder nicht zu anderen kompatibel.

Das RN2483 Modul ist z.B. auf dem "The Things UNO" drauf, einem Arduino der LoRaWAN kann (siehe https://www.thethingsnetwork.org/marketplace/product/the-things-uno). Zum Einstieg kann ich TT-UNO sehr empfehlen, die Dokumentation ist gut für Anfänger geeignet (https://www.thethingsindustries.com/docs/devices/the-things-uno).

Vorteile

⊕ LoRaWAN Protokollsoftware bereits im Funkmodul enthalten

⊕ Beliebiger Mikrocontroller kann verwendet werden, z.B. einer auf dem Micropython läuft (Raspberry Pico, BBC Micro:Bit, STM32, ...).

⊕ Es gibt Software-Bibliotheken, die das Ansteuern der diversen AT Kommandos übernehmen.

⊕ Man kann mit dem Modul sofort interaktiv am PC arbeiten

Nachteile

⊖ Keine Standardisierung des AT Befehlssatzes

⊖ Keine absolute Kontrolle über die Stromsparfunktionen

LoRa Endgerät mit Heltec WiFi LoRa 32 V1

Die Board Version V1 habe ich beim Workshop 2023 auf dem Linux Infotag verwendet.

Von den im vorherigen Abschnitten genannten Möglichkeiten, einen LoRa Knoten zu realisieren, habe ich mich für die Heltec Variante entschieden, der Preis liegt in etwa zwischen 10 und 20 Euro pro Stück.

LoRa Gerät mit Heltec WiFi LoRa 32 V1

Pinout V1

Zum Vergrössern klicken

Hardware

Mein Prototyp der Schaltung ist auf eine Lochrasterplatine gelötet und mit Kupferlackdraht auf der Unterseite verdrahtet:

Heltec-Demo

  • Der schwarze Taster ist active low und mit GPI36 verbunden. Vom Taster geht ein 10 kOhm Pullup Widerstand nach VCC (3.3V).

  • Die Anode der rote LED ist über einen 390 Ohm Widerstand mit GPIO17 verbunden, ist also active high. Die Kathode ist natürlich mit Masse verbunden. Auf dem Bild ist das die LED über der schwarzen Taste, sie sieht leider gelb aus, ist aber tatsächlich rot.

  • Ein Trimmpoti ist mit ADC Eingang GPI37 verbunden (ADC1 Channel 1 mit 12-Bit Auflösung). Das Trimmpoti hat 50 kOhm, je 3k9 nach Masse und Plus, da der lineare Messbereich des ADC Eingangs nur im Bereich ca. 0.2V bis 3.1 Volt ist. Damit liegt der gemessene 12-Bit Wert auf Linksanschlag bei 160, auf Rechtsanschlag bei 3920.

Schaltplan der Erweiterungen

Im Workshop würde man die Schaltung auf ein Steckbrett stecken. Statt des Heltec Boards ist hier ein "TTGO LORA 868 MHz SX1276 ESP32" Board zu sehen. Es hat die gleichen Anschlüsse wie das Heltec Board:

Steckbrett

Platformio

https://platformio.org

Platformio ist ein in Python geschriebenes Framework das viele Mikrocontroller-Programmierumgebungen und Plattformen vereint. Wir verwenden Platformio zur Programmierung der Heltec-Demo. Die Plattform ist "ESP32", die Programmierumgebung ist "Arduino". Man kann alles von der Kommandozeile steuern, die Arduino IDE wird nicht benötigt. Allerdings braucht man einen Programmiereditor, mit dem man die Datei src/main.cpp Änderungen machen kann. Es eignen sich die üblichen kleinen Editoren wie pico, nano und micro. Wer Vi kennt, verwendet natürlich vim.

  • Platformio installieren mit

    python3 -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"
    

    Danach gibt es im Homeverzeichnis den Ordner ~/.platformio. Er ist ca. 40 MByte gross.

    Info: https://docs.platformio.org/en/latest/core/installation/methods/installer-script.html

  • Virtuelle Umgebung starten mit . ~/.platformio/penv/bin/activate

    Zum Deaktivieren einfach deactivate eingeben.

    Version abfragen:

    pio --version
    PlatformIO Core, version 6.1.6
    
  • Projekt initialisieren

    In ttn_workshop/heltec ausführen:

    pio project init --board heltec_wifi_lora_32
    

    In diesem Schritt wird auch bereits die MCCI LoRaWAN LMIC Bibliothek installiert.

  • Serielle Schnittstelle für gewöhnlichen User freigeben.

    Damit Platformio auf die serielle Schnittstelle kommt noch das Kommando

    sudo adduser $USER dialout
    

    oder

    sudo usermod -a -G dialout $USER
    

    eingeben. Dann ausloggen und wieder einloggen. Bei Mint-Linux musste ich neu booten, damit der adduser Wirkung zeigte.

  • Kompilieren des Codes mit pio run oder pio run -v.

    Achtung: Vorher muss der Code angepasst werden. Siehe unten.

  • Upload mit pio run -v -t upload.

    Das Heltec Board muss über ein USB Kabel an den PC angeschlossen sein. Das Device der seriellen Schnittstelle wird automatisch gesucht, kann aber schief gehen. Explizite Angabe des Ports mit z.B. --upload-port /dev/ttyUSB3.

  • Konsolenausgabe

    Nach dem Programmieren kann man einen Terminal-Emulator an der gleichen seriellen Schnittstelle anschliessen. Damit sieht man dann die Ausgaben, die mit Serial.println() in den Code gestreut sind.

    picocom -b 115200 /dev/ttyUSB0
    

    Man beendet picocom mit Strg-A-X.

    Picocom muss eventuell noch installiert werden:

    sudo apt install picocom
    

Der Code

  • Der Quelltext ist in einer einzigen Datei enthalten: heltec/src/main.cpp. Er stammt von einem Beispielprogramm, das in der LMIC Bibliothek enthalten ist, und das ich leicht modifiziert habe:

    https://github.com/mcci-catena/arduino-lmic/blob/master/examples/ttn-otaa/ttn-otaa.ino

    Die Anwendung auf dem Heltec LoRa Board ist ein sehr einfacher LoRaWAN Knoten. Es ist ein "Class A" LoRaWAN Knoten der jede Minute den Zustand eines Tasters und eines Drehpotis als Uplink sendet. Man kann über den Downlink die rote LED ein- oder ausschalten.

    WARNUNG: Das Senden jede Minute ist für ein LoRaWAN Gerät schon zu häufig. Im normalen Betrieb senden LoRaWAN Knoten alle 20 bis 30 Minuten, viele noch deutlich seltener. Bitte die "Fair Access Policy" anschauen. Die Minute habe ich nur zum schnelleren Test gewählt. Das gilt auch für den Downlink. Die Regel ist max. 10 Downlinks am Tag.

    Fair Use Policy

  • Muss bei eigenem Code angepasst werden (OTAA):

    • APPEUI (8 Byte, kann Null bleiben. Auch JoinEUI genannt.)
    • DEVEUI (8 Byte, wird in der TTN Konsole generiert)
    • APPKEY (16 Byte, wird in der TTN Konsole generiert)

    Wie man diese Werte bekommt, findet man im nächsten Abschnitt "TTN Konfigurieren".

    Wichtig: Die DEVEUI muss im Quelltext tatsächlich anders herum (little endian) eingegeben werden als in der TTN Konsole sichtbar.

    Diese Konfiguration betrifft die LMIC Bibliothek, deshalb kann man auch in dessen Doku schauen: https://github.com/mcci-catena/arduino-lmic#configuration

  • Uplink Payload

    Der Code definiert eine Payload mit 5 Byte in einem Array das mydata heisst:

    static uint8_t mydata[5] = { 0, 0, 0, 0, 0 };
    

    Von den 5 Byte Payload werden wir im Beispiel nur 2 Byte nutzen. Das erste Byte (Offset 0) kodiert das Betätigen des schwarzen Tasters (0 = Taste offen, 1 = Taste wurde gedrückt). Das zweite Byte kodiert mit 7 Bit die Position des blauen Drehwiderstandes. Oben wurde schon gesagt, dass der Poti-Wert mit 12 Bit gemessen wird. Um auf die 7 Bit zu kommen, muss der Wert um 5 Bit nach rechts geschoben werden. Das erledigt die Zeile

    mydata[1] = potValue >> 5;  // Convert ADC value to 7-Bit 
    

    So sieht die Payload dann aus:

    +----+----+----+----+----+
    | 0  | 1  | 2  | 3  | 4  |
    +----+----+----+----+----+
       |    |
       |  Poti
      Taste
    

    Die Werte für die Bytes an dritter, vierter und fünfter Stelle sind immer Null.

  • Downlink Payload

    Die Payload beim Downlink besteht nur aus einem Byte. Wenn das Byte den Wert 0 hat, wird die rote LED ausgeschaltet. Bei dem Wert 1 wird die rote LED eingeschaltet (genau genommen ist lediglich das niederwertigste Bit entscheidend!). Siehe den folgenden Quelltext:

    digitalWrite(LED_RED_PIN, LMIC.frame[LMIC.dataBeg] & 1);
    

Das ist erst mal die "rohe" Payload in Bytes. Später kann man noch Payload Formatierer einbauen, welche die Umwandlung in besser lesbare JSON Objekte vornehmen. Siehe den Abschnitt "Payload Formatierung".

LoRa Endgerät mit Heltec WiFi LoRa 32 V3

Beim IoT Workshop in Dillingen verwenden wir das Heltec Board in der Version V3.

LoRa Gerät mit Heltec WiFi LoRa 32 V3

Pinout V3

Zum Vergrössern klicken

Hardware

Aufbau V3

Die prinzipielle Schaltung ist identisch mit der Schaltung für Heltec V1. Nur die Belegung der Pins ist anders:

  • Der schwarze Taster ist active low und mit GPIO6 (J3, Pin 17) verbunden. Vom Taster geht ein 10 kOhm Pullup Widerstand nach VCC (3.3V).

  • Die Anode der roten LED ist über einen 390 Ohm Widerstand mit GPIO7 (J3, Pin 18) verbunden, ist also active high. Die Kathode ist mit Masse verbunden.

  • Ein blaue Potentiometer ist mit ADC Eingang ADC1_CH0 verbunden (J3, Pin 12, entspricht GPIO1). Der ADC hat eine 12-Bit Auflösung. Die beiden Enden des Poti liegen direkt an GND und 3.3 Volt. Bei der Schaltung mit Heltec V1 hatte ich Vorwiderstände verwendet, um mehr in den linearen Bereich zu kommen. Da müsste man nachsehen, wie sich das Heltec V3 beim ADC Eingang verhält.

Das Programm ist im Ordner heltec_v3.

TTN konfigurieren

Achtung: Dieser Abschnitt ist noch auf dem Stand des Heltec LoRa V1. Beim neuen Heltec V3 Board gibt es einige Unterschiede, auf die ich im Kurs eingehen werde.

Dieser Abschnitt beschreibt die Arbeiten in der TheThingsNetwork Console

https://eu1.cloud.thethings.network/console

Account besorgen

Gehe auf https://www.thethingsnetwork.org und wähle "Sign Up".

Dann sieht man die folgende Seite im Browser:

Join TTN

Den linken Eintrag wählen (Join The Things Network).

TTIG Gateway (optional)

Erst mal schauen wo das nächste Gateway ist: https://www.thethingsnetwork.org/map

Hier sind die Augsburger Gateways (April 2023):

Gateways in Augsburg

Falls man keines in der Nähe hat, empfehle ich das TTIG (TheThings Indoor Gateway)

https://www.thethingsindustries.com/docs/gateways/models/thethingsindoorgateway

Das TTIG unterstützt 8 Kanäle, LoRaWAN 1.0.3 und hat im Inneren die Bausteine SX1308 (Gateway) und einen ESP8266 für die WiFi-Anbindung. Das Gerät hat keine Netzwerkbuchse. Normalerweise steckt man es einfach in eine Steckdose. Es hat aber auch einen USB-C Anschluss zur Stromversorgung.

Hier ist die Prozedur für eine Neuinitialisierung des TTIG Gateways. Die angegebenen Daten (Wifi Pwd und Gateway-EUI) beziehen sich auf mein Gateway, diese Daten sollten bei Euch anders sein.

  1. 5 Sek Reset druecken (LED blinkt rot und gruen)

  2. 10 Sek Setup druecken (LED blinkt dann schnell rot)

    Nun ist das TTIG neu initialisiert. Über einen integrierten AP bietet es das Netz mit der SSID MiniHub-80453A an.

  3. Rechner mit WiFi Netz MiniHub-80453A verbinden

    • Firefox verwenden!
    • http://192.168.4.1
    • Wifi Pwd: oJurJyfz

    Die Website des Accesspoints zeigt auch alle wichtigen Daten des TTIG an, siehe TTIG-Daten.

  4. Konfigurieren, so dass TTIG beim nächsten Starten als WiFi Client im Heimnetz ist.

  5. Reboot (gruen sollte irgendwann dauerhaft leuchten, dann ist alles richtig verbunden). An der Fritzbox sieht man dann den Netzteilnehmer MiniHub-80453A.

  6. Gateway in der TTN Konsole eintragen:

    Gateway-EUI 58 A0 CB FF FE 80 45 3A

Der Claim Authentication Code ist das Wifi Pwd.

Register Gateway

Wichtig: Bei mir war die im Bild gezeigte Gateway-ID schon vergeben, deswegen wurde eine Fehlermeldung ausgegeben und ich konnte das Gateway erst mal nicht anmelden. Man darf hier einen beliebigen Namen vergeben, ich habe dann huberts-ttig-gateway genommen, damit hat es dann gleich funktioniert.

Siehe auch den Ordner ttig.

Applikation einrichten

Eine neue Applikation einzurichten geht sehr einfach. Man wählt lediglich + Create application aus und vergibt eine neue Application ID, das ist ein Bezeichner für die Applikation. Ausserdem kann man einen Namen vergeben, den habe ich auf "Heltec Demo App for TTN Workshop" gesetzt (besser wäre aber ein kürzerer Name gewesen).

Sollte man die Applikation irgendwann wieder löschen, dann wird man bemerken, dass man die gleiche ID nicht mehr vergeben kann. Anfangs habe ich für den Workshop die ID heltec-demo vergeben, nachdem ich die Applikation zum Test gelöscht und neu angelegt hatte, musste ich auf einen anderen Namen umsteigen, z.B. heltec-demo-1.

So sieht der Fehler aus, wenn es den Namen früher schon gegeben hat:

Applikation Fehler

End Device einrichten

Das Anlegen eines Endgerätes (End Device) ist etwas umfangreicher. Man muss die folgenden Punkte beachten:

  • Daten manuell eingeben (da Selbstbaugerät)
  • Frequency Plan
  • LoRaWAN Spec 1.0.3
  • JoinEUI auf 00 00 ... setzen (war früher AppEUI)
  • DevEUI generieren
  • AppKey generieren
  • Abschliessend die End Device ID auf einen lesbaren Namen setzen, z.B. heltec-demo-dev1

Die DevEUI muss in der Reihenfolge "Little-Endian" übertragen werden, d.h. die in der TTN Konsole gezeigte Reihenfolge der Bytes muss umgedreht werden!

Diese Folge von Bildschirmkopien zeigt das Anlegen eines Endgerätes. In Bild 10 sieht man die umgedrehte Reihenfolge der DevEUI, so muss es in den Quelltext eingegeben werden:

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

API Keys

Wenn man aus einem Shell Skript, einem Python Programm oder einem Programm wie z.B. curl auf die Daten des TTN Servers zugreifen will, dann braucht man immer einen API Key. Den Key muss man in der TTN Konsole erzeugen (+ Add API Key). Er erhält einen Namen und einen Wert. Der Name ist in meinem Beispiel "heltec-demo-api-key", der Wert ist nur direkt bei der Erzeugung sichtbar und muss gesichert werden. Nach Abschluss ist der Wert nicht mehr zugänglich.

Der Key könnte in etwa so aussehen, muss aber natürlich an den eigenen Key angepasst werden:

NNSXS.ABS3TTW5OBMNZRBIW5ZMQDEC74N63JXYPAWAHVQ.GXO3XHNDPBYM2NW5I5ZYAMX6WNF3KRTX2FUW2YTFVXJXPVYFAGUQ

Die Demo-Programm für den Workshop lesen diesen API Key aus einer Umgebungsvariable WORKSHOP_API_KEY ein. Diese muss deshalb erst mal gesetzt werden. Das macht man mit dem folgenden Kommando in der Shell:

export WORKSHOP_API_KEY=NNSXS.ABS3TTW5OBMNZRBIW5ZMQDEC74N63JXYPAWAHVQ.GXO3XHNDPBYM2NW5I5ZYAMX6WNF3KRTX2FUW2YTFVXJXPVYFAGUQ

Dadurch bleiben die Skripte (1) unabhängig vom Schlüssel und können (2) auf öffentlichen Git Servern aufbewahrt werden, ohne dass Geheimnisse weitergegeben werden.

Die Key ID ist lediglich ein eindeutiger Bezeichner für den Schlüssel. Auf den Wert des Schlüssels kann nicht mehr zugegriffen werden. Sollte der Wert verloren gehen, muss man einen neuen Schlüssel erzeugen.

Hier sind eine Reihe von Bildschirmkopien die zeigen wie der API Key erzeugt wurde:

1 | 2 | 3 | 4 | 5

Es läuft

Es läuft zum ersten Mal. Wir sehen dass das Gerät aktiv ist ("Last activity XXX seconds ago"). Die Uplink Daten kommen im Reiter "Live data" in der Konsole an. Man sieht die Payload in Form der einzelnen Byte 00 30 00 00 00 Wenn man auf die Zeile mit den Daten klickt, dann öffnet sich ein Fenster mit einem "riesigen" JSON Objekt, es enthält u.a. frm_payload": "ADAAAAA=", das ist die Payload im Base64 Format.

Mit dem schon erwähnten Programm kann man diese Kodierung in Bytes umwandeln und erhält wie zu erwarten:

python base64tool.py -b ADAAAAA=
0x00  0x30  0x00  0x00  0x00

Über den Reiter "Messaging" kann man die Downlink-Daten in eine Queue einreihen. Ohne Payload Formatierer muss man zunächst direkt den Byte-Wert eingeben (00 = LED aus, 01 = LED ein).

Altenativ kann man hier auch das CLI Programm ttn-lw-cli verwenden (siehe Abschnitt "TTN CLI":

Rote LED an

ttn-lw-cli end-devices downlink push heltec-demo-1 heltec-demo-dev1 --frm-payload 01 --priority NORMAL --f-port 1

Rote LED aus

ttn-lw-cli end-devices downlink push heltec-demo-1 heltec-demo-dev1 --frm-payload 00 --priority NORMAL --f-port 1

Wenn später die Payload Formatierung in die TTN Konsole eingebaut ist, kann man den Uplink auch im dekodierten Format betrachten z.B. { adc: 1536, button: 0 }. Auch den Downlink kann man dann über ein dekodiertes JSON Objekt steuern, z.B. { "led": "on" }.

In Abschnitt 8 "Integration" sehen wir wie man mit anderen Mitteln Uplinks abgreifen bzw. Downlinks verschicken kann.

  • MQTT Client abonniert Uplink (subscribe)

  • Uplink wird per Webhook nach Ziel-URL übertragen

  • Downlink wird per Webhook an TTN Server gesendet

Payload Formatierung

Die Payload Formatierer erlauben es, statt auf der Ebene von einzelnen Bytes Daten zu veschicken, mit strukturierten Daten im JSON Format zu arbeiten. Das funktioniert sowohl für den Uplink als auch für den Downlink. Die Formatierer werden in die TTN Konsole eingeben, es handelt sich um JavaScript Code.

      unstrukturiert (Bytes)              strukturiert (JSON)
      ------------------------------------------------------------
      00 3f                   -->         { adc: 1536, button: 0 }
      01                      -->         { "led": "on" }

Nachdem die Formatierer angelegt wurden (siehe unten) sieht man den Uplink sofort neben den Bytes auch in strukturierter Form. Auch kann man nun beim Downlink auswählen ob man Bytes oder JSON Objekte übertragen möchte.

Payload Formatter

Siehe Verzeichnis payload. Darin sind die Quelltextdateien der Formatter.

Man kann die Formatter entweder an die Anwendung koppeln (sie gelten dann für alle Geräte dieser Anwendung) oder individuell an jedes Gerät. In diesem Beispiel ist er an der Anwendung festgemacht. Der Quelltext ist in JavaScript geschrieben (es gibt auch noch andere Formate).

Der Formatierer schreibt die ersten beiden Bytes der Payload in die Variablen button und adc. Diese werden dann in ein JSON Objekt { adc: ..., button: ... } gefüllt. Der ADC Wert wird wieder um 5 Bit nach links geschoben, so dass der ursprüngliche Wertebereich wieder hergestellt wurde (natürlich fehlen nun 5 Bit Genauigkeit, aber darum geht es hier nicht).

// Uplink formatter (decoder.js)

function decodeUplink(input) {
  var adc = 0;
  var button = 0;
  button = input.bytes[0];
  adc = input.bytes[1];
  return {
    data: {
      adc: adc << 5,
      button: button
      // bytes: input.bytes,
    }
    // warnings: [],
    // errors: []
  };
}

In der Konsole kann man beim Downlink entweder direkt die Bytes angeben (z.B. 01 (zwei Hex-Ziffern) um die LED einzuschalten), oder man kann ein JSON Objekt definieren. Für den gleichen Zweck könnte man z.B. { "led": "on" } nehmen. Die Aufgabe des Downlink Formatieres encodeDownlink() ist es, das JSON Objekt in die Bytes zu verwandeln.

Der Downlink Formatierer muss auch immer eine Umkehrungsfunktion decodeDownlink() haben, die von Bytes in das JSON Objekt umwandelt.

// Downlink formatter (encoder.js)

// Called when a downlink with decoded payload is scheduled to be sent to
// device. The result is an encoded array of bytes.
// input is either { "led": "on" } or { "led": "off" }

var led_state = ["off", "on"];

function encodeDownlink(input) {
    var b = 0;
    if (input.data.led == "on") {
        b = 1
    }
    return {
        bytes: [b],
        fPort: 1,
        warnings: [],
        errors: []
    };
}

// Decodes the binary payload back to decoded payload.
function decodeDownlink(input) {
    return {
        data: {
            // bytes: input.bytes
            led: led_state[input.bytes[0]]
        },
        warnings: [],
        errors: []
    }
}

Test der Formatierer

Die Endgeräte haben in der Konsole einen Reiter Payload formatters. Dort kann man den Uplink- und Downlink-Formatter mit Testdaten füttern und sieht dann ob er richtig funktioniert.

Test der Formatierer

Test der Formatierer

Übertragen der Formatierer mit ttn-lw-cli

Üblicherweise überträgt man die Formatierer per Copy/Paste in die entsprechenden Eingabefelder der TTN Konsole. Eleganter, da automatisierbar, ist die Übertragung per ttn-lw-cli Werkzeug. Die Formatter liegen dabei als JavaScript Dateien encoder.js und decoder.js auf der Platte.

Das Shell Skript ist in formatter/payload-formatter.sh zu finden, das ist der Inhalt:

# Muss vielleicht angepasst werden
appid=heltec-demo-1

ttn-lw-cli applications link set ${appid} \
--api-key $WORKSHOP_API_KEY \
--default-formatters.down-formatter FORMATTER_JAVASCRIPT \
--default-formatters.down-formatter-parameter-local-file "encoder.js" \
--default-formatters.up-formatter FORMATTER_JAVASCRIPT \
--default-formatters.up-formatter-parameter-local-file "decoder.js"

Payload im Base64 Format

Intern werden die Daten immer im Base64 Format übermittelt, sowohl beim Uplink als auch beim Downlink. Man sieht das auch, wenn man die Payload im JSON Format in der TTN Konsole genauer untersucht. Zum Beispiel wäre die Folge der zwei Bytes 01 3A im Base64 Format ATo=.

Das kann man mit dem Programm base64/base64tool.py zum Konvertieren von Base64 in Bytes und umgekehrt nachvollziehen. Ein paar Beispiele:

python base64tool.py -B 01 3A
ATo=

python base64tool.py -b ATo=
0x01  0x3a

python base64tool.py -B 00
AA==

Die Folge der Hex-Bytes hinter der -B Option kann beliebig lang sein.

Integration

MQTT
Webhooks
Storage
Node-RED
Mapper

Bisher haben wir nur interaktiv über die TTN Konsole Daten aus Upstream-Richtung betrachtet und in Downstream-Richtung eingegeben. Nun ist es das Ziel, dass man mit Programmen die auf dem eigenen Rechner laufen auf den TheThings Netzwerkserver zugreift, so dass man die TTN Konsole eigentlich nicht mehr braucht. Der Netzwerkserver bietet dafür die "Integrations". Die zwei wichtigsten grundlegenden Integrationen sind MQTT und Webhooks. Über diese Standards kann man Uplink und Downlink vom eigenen Rechner aus erreichen.

Die Uplink-Daten gehen nach dem Empfang im Netzwerkserver verloren, man sieht sie vielleicht noch in der Konsole, kann aber nicht mehr darauf zugreifen. Die Integration "Storage" speichert die empfangenen Daten eine Weile (24 Stunden) und man kann sie über einen HTTP Endpunkt lesen.

Als nächstes stelle ich kurz Node-RED vor, keine richtige Integration, sondern ein Werkzeug für grafische Programmierung. Es kann mit dem TTN Server über MQTT und Webhooks interagieren.

Zum Schluss zeige ich den TTN Mapper. Das ist eine vorgefertigte Webhook-Integration, mit der man die ungefähre LoRa-Abdeckung in einem Gebiet ermitteln kann.

MQTT

https://www.thethingsindustries.com/docs/integrations/mqtt

User: heltec-demo-1@ttn

Topic: v3/<user>/devices/<device-id>/up

Server: eu1.cloud.thethings.network, Port 1883 (unsafe), 8883 (safe)

Drei Demo-Clients:

  • Python: mqtt/client.py

    Paho-MQTT muss evtl noch installiert werden mit pip install paho-mqtt.

  • Mosquitto commandline client: mqtt/mosquitto.sh. Aufrufen mit bash mosquitto.sh.

    Installation:

    sudo apt install mosquitto
    sudo apt install mosquitto-clients
    
  • Node-Red (siehe Abschnitt ganz unten)

MQTTK: Simples Tool in Python mit Tkinter GUI

MQTTK

Die Installationsanweisungen auf meinem Linux Mint waren:

sudo apt install python3-tk
pip install mqttk

Webhooks

Auf "Webhooks" basieren jede Menge Dienste, die meist von externen kommerziellen Dienstleistern stammen. Wenn man bei der Webhook Integration auf + Add webhook klickt, dann sieht man sofort eine Menge Dienste, hier sind Bildschirmkopien: Webhooks1 | Webhooks2. Fast alle sind externen Dienstleister die meist einen kostenlosen Einstiegstarif anbieten, oft ist dieser aber in irgend einer Form beschränkt.

Der Dienst ganz links oben auf Webhooks1 ist der "Custom Webhook" den man für eigene Zwecke konfigurieren kann.

Die Anwendung heltec-demo hat eine solche Custom Webhook Integration bekommen.

webhook

Nun klickt man auf die Zeile heltec-demo-wh, danach sieht man die Einstellungen die man bei diesem Webhook vornehmen kann:

Webhook Konfiguration

Die Webhook-ID ist heltec-demo-wh. Als einzig wichtigen Parameter muss man die Base URL angeben, diesen habe ich auf https://webhook.site gesetzt. Das ist ein praktischer Dienst, mit dem man untersuchen kann, welche Daten ein Webhook tatsächlich abliefert. Siehe webhooks/README.md.

Im produktiven Einsatz würde man jedoch einen eigenen Webhook Server betreiben, der vom TTN Server die HTTP Webhook-Aufrufe erhält und der die im JSON Format übermittelten Daten abspeichert, auswertet, etc. Eine gut funktionierende Software für diesen Zweck ist der webhookd, siehe https://github.com/ncarlier/webhookd.

Die typischen Anwendungsfälle sind:

  • Uplink-Daten vom TTN Server auf einen anderen Rechner übertragen

  • Downlink-Daten von einem anderen Rechner auf den TTN Server übertragen

Den eingerichteten Webhook kann man editieren ("Edit webhook"). Bei "Enabled event types" klickt man auf "Uplink message" und gibt den Pfad an, der von webhook.site vorgegeben wurde (z.B. /a9242d1b-ebfb-42b4-b0ec-cd4f650437af) Daraufhin sieht man den Uplink in webhook.site:

https://webhook.site

zum Vergrössern klicken

Siehe im Verzeichnis webhooks die bash Skripte led-on.sh und led-off.sh. Sie übertragen mit dem curl Tool die Downlink-Daten zum TTN Server über HTTP POST Requests.

Storage

https://www.thethingsindustries.com/docs/integrations/storage

Kann man die Storage Integration für die Applikation oder individuell für ein Gerät in der Applikation ein- oder ausschalten. Für heltec-demo ist sie aktuell aktiviert.

Nicht zu viel erwarten, die Daten kommen nicht in Echtzeit an und werden auch nur eine bestimmte Zeit (24 Stunden) aufgehoben.

Die Daten bekommt man von den Endpunkten:

GET https://eu1.cloud.thethings.network/api/v3/as/applications/heltec-demo/packages/storage/{type}
GET https://eu1.cloud.thethings.network/api/v3/as/applications/heltec-demo/devices/{device_id}/packages/storage/{type}

Siehe das Verzeichnis storage im Git Repository. Abrufen der gespeicherten Einträge z.B. mit curl, siehe bash get-storage.sh, oder besser formatiert mit bash get-storage.sh | jq . | less.

Node-Red

https://www.thethingsindustries.com/docs/integrations/node-red

Node-RED (https://nodered.org) ist eine "low code" Programmierumgebung, in der man einfache Datenverarbeitungsabläufe grafisch im Web-Browser zeichnen kann. Man setzt Knoten (Nodes) in ein Zeichenfeld und verbindet die Knoten mit geschwungenen Linien. Für die Anbindung an den TheThings Network Server gibt es z.B. einen MQTT Knoten, den man mit den Verbindungsdaten konfigurieren kann.

Installation mit npm Paketmanager von Node.JS:

sudo npm install -g --unsafe-perm node-red

In Node-Red installieren (Menue -> Palette verwalten -> Installation).

  • node-red-dashboard
  • node-red-contrib-moment

Node-RED Server starten mit node-red. Man bedient Node-RED über den Web Browser mit folgendem Link:

http://127.0.0.1:1880

Das Dashboard hat einen eigenen Link:

http://127.0.0.1:1880/ui

Mit der Dashboard-Erweiterung bekommt man neue Knoten in der Kategorie "Dashboard", z.B. Text, Gauge und Chart.

Bildschirmkopie: Dashboard mit Poti

Der dazugehörige Node-RED "Flow" ist im Verzeichnis node-red in der Datei heltec-flow.json enthalten.

Mapper

Der TTN Mapper ist eine Web Anwendung unter https://ttnmapper.org. Man benötigt ein LoRa Endgerät, das über ein GPS Modul verfügt. Die Endgerätesoftware übermittelt periodisch die aktuellen GPS Koordinaten an den TTN Server. Die Applikation (oder das Endgerät) auf dem Server muss mit der vorgefertigten Webhook-Integration "TTN Mapper" verknüpft werden. Dadurch werden die empfangenen Daten inklusive des GPS Standortes auf ttnmapper.org per HTTP Push weitergereicht.

Bildschirmkopien:

  • Webhook Konfiguration

  • Auf ttnmapper.org:

    • Menüpunkt Advanced Maps Die gezeigte Device ID eui-70b3d57ed004c4a0 gehört meinem Mapper Endgerät.

    • Radfahrt am 22.4. Von zu Hause zur Hochschule und wieder zurück.

    • Radfahrt/Spaziergang am 23.4. Von zu Hause, Pfersee, Bahnhof, Innenstadt (Annastrasse), Rathaus, Maxstrasse, Wintergasse, Predigerberg, Bäckergasse, Puppenkiste, Hochschule und zurück. In einem Grossteil der Innenstadt gab es leider keine LoRa Verbindung zu einem Gateway. Erst ab der Gegend der Bäckergasse hat man wieder Empfang durch die Hochschul-Gateways und das "Maiskolben"-Gateway.

Der URL beim TTN Mapper kodiert die Device-ID, Start- und Enddatum.

https://ttnmapper.org/devices/?device=eui-70b3d57ed004c4a0&startdate=2023-04-23&enddate=2023-04-23&gateways=on&lines=on&points=on

Kommandoreferenz

Platformio
ttn-lw-cli
baes64tool.py
MQTT
Webhooks
Node-RED

Platformio

  • Installieren mit

    python3 -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"
    

    Es gibt danach den Ordner .platformio im Homeverzeichnis.

  • Virtuelle Umgebung aktivieren

    . ~/.platformio/penv/bin/activate
    

    Nun sollte das Kommando pio gefunden werden, am besten mal which pio eingeben und danach pio --version:

    which pio
    /home/hhoegl/.platformio/penv/bin/pio
    
    pio --version
    PlatformIO Core, version 6.1.6
    
  • Nun in das heltec Verzeichnis mit dem Beispielprogramm gehen. Dann aufrufen:

    project init --board heltec_wifi_lora_32
    

    Danach gibt es im heltec Verzeichnis einen versteckten Ordner .pio. In diesem befindet sich z.B. die benötigte LoRa Bibliothek. Ausserdem wurde der Ordner .platformio im Homeverzeichnis viel grösser (1,6G), da nun der Compiler und das Arduino-Framework für das Heltec Board (ESP32) darin installiert wurden.

  • Code kompilieren mit

    pio run 
    
  • Code auf das Heltec Board übertragen mit

    pio run -t upload
    

    Das angesteckte Heltec Board ist über ein USB Kabel mit dem PC verbunden. Das USB Kabel dient der Stromversorgung und zur Übertragung der seriellen Schnittstelle. Oft kommt man nur als Administrator (root) auf diese Schnittstelle. Deswegen erst noch dem gewöhnlichen Anwender ($USER) den Zugriff erlauben mit

    sudo usermod -a -G dialout $USER
    

    Danach ausloggen/einloggen oder komplett das Linux neu starten. Das Kommando pio run -t upload sollte automatisch das richtige serielle Gerät finden.

  • Wenn man pio nicht mehr braucht deaktiviert man die virtuelle Umgebung mit

    deactivate
    

ttn-lw-cli

Es gibt das Kommandozeilenprogramm ttn-lw-cli, das alle Funkionen der TTN Konsole auch über die Kommandozeile erledigen kann. Es ist Teil des The Things Stack und somit auch Open-Source Software.

https://www.thethingsindustries.com/docs/the-things-stack/interact/cli

Reference: https://www.thethingsindustries.com/docs/reference/cli

Download: https://github.com/TheThingsNetwork/lorawan-stack/releases

Anmelden

Version abfragen

ttn-lw-cli version

The Things Network Command-line Interface: ttn-lw-cli
Version:             3.25.1
Build date:          2023-04-18T08:13:17Z
Git commit:          bcfbbc610
Go version:          go1.20.3
OS/Arch:             linux/amd64
ttn-lw-cli use eu1.cloud.thethings.network

Lokal wird eine Datei .ttn-lw-cli.yml angelegt.

ttn-lw-cli login

Nun öffnet sich der Browser und zeigt den Auth-Code an. Diesen Code mit Copy/Paste in das Kommandozeilenfenster übertragen.

Danach sollte jedes Kommando funktionieren, z.B.:

ttn-lw-cli applications list
ttn-lw-cli end-devices list heltec-demo
ttn-lw-cli gateways list

Zum Schluss

ttn-lw-cli logout

Downlink

https://www.thethingsindustries.com/docs/devices/downlink-queue-ops

Downlink an Heltec Board schicken (1 Byte Nutzdaten)

Rote LED an

ttn-lw-cli end-devices downlink push heltec-demo eui-70b3d57ed005c674 --frm-payload 01 --priority NORMAL --f-port 1

Rote LED aus

ttn-lw-cli end-devices downlink push heltec-demo eui-70b3d57ed005c674 --frm-payload 00 --priority NORMAL --f-port 1

DevNonce zurücksetzen

Kann manchmal bei OTAA Geräten ganz praktisch sein ...

ttn-lw-cli end-devices reset heltec-demo eui-70b3d57ed005c674  --resets-join-nonces

base64tool.py

Siehe Ordner base64.

python base64tool.py -B 01 3A
ATo=

python base64tool.py -b ATo=
0x01  0x3a

python base64tool.py -B 00
AA==

MQTT

sudo apt install mosquitto
sudo apt install mosquitto-clients
pip install paho-mqtt

MQTTK

sudo apt install python3-tk
pip install mqttk

Webhooks

# led-on.sh
curl --location \
     --header 'Authorization: Bearer '$WORKSHOP_API_KEY \
     --header 'Content-Type: application/json' \
     --header 'User-Agent: my-integration/my-integration-version' \
     --request POST \
     --data '{"downlinks":[{ "frm_payload": "AQ==", "f_port": 10, "priority":"NORMAL" }] }' \
     https://eu1.cloud.thethings.network/api/v3/as/applications/${appid}/webhooks/${webhookid}/devices/${devid}/down/replace
# led-off.sh
curl --location \
     --header 'Authorization: Bearer '$WORKSHOP_API_KEY \
     --header 'Content-Type: application/json' \
     --header 'User-Agent: my-integration/my-integration-version' \
     --request POST \
     --data '{"downlinks":[{ "frm_payload": "AA==", "f_port": 10, "priority":"NORMAL" }] }' \
     https://eu1.cloud.thethings.network/api/v3/as/applications/${appid}/webhooks/${webhookid}/devices/${devid}/down/replace

Node-RED

  • Man sollte zunächst Node.JS installieren

    sudo apt install nodejs
    

    Deshalb erst mal testen ob man node schon hat:

    node
    Welcome to Node.js v12.22.9.
    Type ".help" for more information.
    > 
    

    Beenden mit Strg-D.

    Auch mal npm eingeben, der sollte mit Node.JS installiert worden sein.

  • Nun mit npm das Node-RED Programm installieren

    sudo npm install -g --unsafe-perm node-red
    
  • Node-RED starten mit

    node-red
    

    Das Kommando startet einen Server, der Webseiten ausliefert. Im Web-Browser unter http://127.0.0.1:1880 findet man die Benutzerschnittstelle.

  • In der Benutzerschnittstelle (Web-Browser) von Node-Red installieren (Menue -> Palette verwalten -> Installation).

    • node-red-dashboard
    • node-red-contrib-moment

    Das Dashboard hat einen eigenen Zugangs-Link unter http://127.0.0.1:1880/ui

Unter https://nodered.org/docs/getting-started/local findet man auch noch andere Installationsmethoden.

Aus der Bastelkiste

Auf dem Brett sieht man ein LoPy Board Version 1.0r (Link). Es ist aufgesteckt auf ein "Expansion Board" von Pycom. Damit man für Anwendungen eine kleine Benutzerschnittstelle machen kann, sind zusätzlich ein DOG-Display (2x16 Zeichen) und vier Tasten angeschlossen. Die Stromversorgung erfolgt über eine 10 Ah USB Powerbank.

Das LoPy programmiert man komplett in der Interpretersprache Micropython. Neben Versuchen mit Class-A Geräten habe ich auch Class-C darauf getestet.

LoPy-Brett


In dem kleinen Installationsgehäuse ist ein "STM32WL55-Nucleo" Board (Link), das ich mit der AT-Kommando Firmware geflasht habe. Damit kann ich alle LoRaWAN Anweisungen als lesbare Kommandos über die serielle Schnittstelle schicken. Das schwarze USB Kabel "enthält" auch die serielle Schnittstelle. Die Box teste ich aktuell an einem Raspberry Pi 3, auf dem die Beregnungssteuerung der Plätze eines Tennisvereins läuft. Da die Steuerung keine Verbindung zum Internet hat, möchte ich über LoRaWAN Class-C die wesentlichen Funktionen steuern und den Status abfragen.

STM32WL55-Box


In dem Installationsgehäuse (8 x 8 x 3 cm) befindet sich ein ELV-LW-Base Modul (Link), auf das ein ELV-AM-TH1 Applikationsmodul zum Messen von Temperatur und Luftfeuchtigkeit gesteckt ist (Link). Die Stromversorgung erfolgt aus einer Li-Ion 18650 Zelle über einen kleinen Schaltwandler von Pololu. Falls eine Zelle die Mindestspannung unterschreitet muss ich sie ausbauen und in ein Ladegerät stecken. Bisher laufen die Boxen aber seit 8 Monaten mit der ersten Ladung. Optional kann man auch einen externen Temperatursensor anschliessen (wird mitgeliefert, siehe schwarzes Kabel).

Mittlerweile habe ich vier dieser Boxen zu Hause in Betrieb um an verschiedenen Stellen in einem alten Haus aus den 50er Jahren die Feuchtigkeit und Temperatur im Auge zu behalten. Wenn man auch die Aussentemperatur und Feuchtigkeit einbezieht, kann man z.B. automatisiert über LoRa eine taupunktabhängige Lüftung des Kellers realisieren.

ELV-Loris-TH-Box


Auf dem LilyGo T-Beam ist ein GPS Empfänger, so dass man schnell ein LoRaWAN Gerät für den "TTN Mapper (https://ttnmapper.org) damit realisieren kann. Die Software findet man fertig im Netz und muss nur konfiguriert werden.

LilyGo T-Beam