LoRaWAN wird überwiegend für Sensoren eingesetzt, die in bestimmten Zeitintervallen oder zu bestimmten Anlässen Daten über Funk senden. Die Übertragungsrichtung vom Sensor über das LoRaWAN-Netzwerk bis hin zum Endpunkt wird als "Uplink" bezeichnet. Neben Uplinks gibt es auch die Möglichkeit, Daten vom Endpunkt über das LoRaWAN-Netzwerk zum Sensor zu senden. Dies wird als Downlink bezeichnet. Der LoRaWAN Downlink wird eher selten verwendet und derartige Beispielprojekte existieren nur wenige. In diesem Artikel geht es um den Bau von einem LoRaWAN Downlink Aktor. Der Aktor kann vier verschiedene Outputs von einem ESP32 LoRaWAN Board steuern und übermittelt als Uplink Payload den Status von den Outputs.

Was kann der Aktor?

Der Aktor besteht aus einem ESP LoRa 32 Board und kann mit dem Beispielcode vier digitale Ausgänge schalten. An den Ausgängen werden typischerweise Relaiskarten, MOSFETs, Optokoppler und andere Bauteile angeschlossen. Als Beispiel für dieses Projekt wird auf jeden Ausgang eine LED mit einer anderen Farbe angeschlossen. Wird nun ein LoRaWAN Downlink mit den Steuerbytes gesendet, so kann eine LED individuell geschaltet werden. Der Downlink besteht aus zwei Bytes, wovon das erste Byte den Ausgangspin definiert und das zweite Byte den Zustand (Ein oder Aus) definiert:

Vorbereitung der Software

Der Beispielcode arbeitet auf Basis der MCCI LMIC Library. Diese Bibliothek muss in der Arduino IDE installiert sein. Nach der Installation wechselt man in das Verzeichnis der Library und definiert in der Config-Datei (Ordner: Project Config, Datei: lmic_project_config.h) den Frequenzbereich. Sinnvoll kann auch die erweiterte Debug-Ausgabe sein, welche optional aktiviert werden kann.

Die Config-Datei sieht bei 868-MHz LoRaWAN wie folgt aus:

// project-specific definitions
#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP      /* for as923-JP; also define CFG_as923 */
//#define CFG_kr920 1
//#define CFG_in866 1
#define CFG_sx1276_radio 1
//#define LMIC_USE_INTERRUPTS
//Optional Debug Level
#define LMIC_DEBUG_LEVEL 2

Anschließend muss die Pin-Belegung (Pin-Mapping) vom LoRaWAN-Chip angegeben werden. Diese kann sich bei den Boards unterscheiden und muss deshalb immer mit dem Datenblatt des Herstellers überprüft werden. Folgender Beispielcode definiert die LoRaWAN-Hardware Pins (Beispiel: Heltec LoRa32 V2):

// Pin mapping
const lmic_pinmap lmic_pins = { // Pins on Heltec ESP32 LoRa Board
  .nss = 18,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 14,
  .dio = {26, 34, 35},
};

Neben dem Pin-Mapping werden für die serielle Kommunikation auch SPI-Pins benötigt. Diese sind ebenfalls mit dem Datenblatt zu überprüfen und im Code in der Sektion "void setup()" entsprechend anzupassen (Beispiel: Heltec LoRa32 V2):

SPI.begin(5, 19, 27, 18); // Pins on Heltec ESP32 LoRa Board

Zuletzt müssen noch die LoRaWAN-Schlüssel im Beispielcode eingegeben werden. "FILLMEIN" wird durch die vom LoRaWAN Netzwerk vorgegebenen Schlüssel getauscht:

Vorbereitung der Hardware

Grundsätzlich müssen für einen ersten Test keine Bauteile an den Ausgang angeschlossen werden. Der Serial Monitor zeigt an, wenn ein Ausgang geschaltet wird. Folgender Beispielschaltplan kann übernommen werden, um die Downlink-Steuerbefehle mit LEDs zu visualisieren:

Einen ersten Downlink senden

Nachdem der vollständige Beispielcode mit dem angepassten Pin-Mapping und den LoRaWAN-Keys auf das Board hochgeladen wurde, sollte ein JOIN in das LoRaWAN möglich sein. Nach einem erfolgreichen JOIN-Request sendet das Board alle 60 Sekunden ein Datenpaket als unconfirmed Uplink aus. Unmittelbar nach dieser Aussendung ist das Endgerät immer für ein kurzes Zeitfenster empfangsbereit, wo das LoRaWAN Netzwerk Daten an das Endgerät senden kann. In der TTN-Console kann nun ein Downlink angelegt werden. Um den Ausgang 1 Einzuschalten, werden nun zwei Bytes [01 01] im Feld "Message" eingeben und abgesendet:

Die Nachricht befindet sich nun in der Warteschleife und wird unmittelbar nachdem sich das Endgerät wieder beim LoRaWAN Netzwerkserver gemeldet hat, abgesendet. Erreicht das Downlink-Paket das Endgerät, so schaltet der Ausgang 1 ein. Folgende Byte-Befehle schalten weitere Ausgänge:

Rx-Bytes lesen mit der Library

Standardmäßig werden die empfangenen Bytes von einem Downlink-Paket nicht angezeigt. Der Beispielcode von diesem Projekt zeigt die empfangene hexadezimale Payload im Serial Monitor an. Folgender Code-Teil gibt die Payload aus und übergibt die zwei Bytes (Output, State):

Die verschiedenen LoRaWAN Klassen

Die LoRaWAN Klassen definieren, in welchen Zeitfenstern ein Endgerät vom LoRaWAN Netzwerk erreicht werden kann. Die Klasse hat unter anderem auch einen Einfluss auf den Energieverbrauch des Endgerätes. So kommt für einen autarken Sensor, der mit einer Batterie über mehrere Jahre laufen soll, nur die Klasse A in Frage. Jedes LoRaWAN-Endgerät muss zumindest die Klasse A unterstützen. Die LoRaWAN Klassen unterscheiden sich wie folgt:

Class A: Das Endgerät schaltet unmittelbar nach einer Aussendung kurzzeitig auf Empfang. In Summe gibt es zwei Zeitfenster, wo das LoRaWAN Netzwerk Daten an den Sensor senden kann. Nach Ablauf dieser Zeitfenster ist der Sensor nicht mehr Empfangsbereit und die nächste Möglichkeit, Daten an den Sensor zu senden, besteht erst, wenn dieser wieder ein Datenpaket zum LoRaWAN Netzwerk sendet.

Class B: Grundsätzlich funktioniert der Betrieb gleich wie bei Klasse A. Zusätzlich gibt es immer wieder kurze Zeitfenster, wo das Endgerät empfangsbereit ist, ohne das zuvor vom Endgerät ein Datenpaket an das LoRaWAN Netzwerk gesendet wurde.

Class C: Wird das Endgerät in Klasse C betrieben, ist es praktisch dauerhaft empfangsbereit. Dieser Modus ist grundsätzlich nur für Endgeräte vorgesehen, die dauerhaft mit Energie versorgt werden.

Die verwendete Library unterstützt die Klassen A und B. Ein Projekt für Klasse B ist geplant. Klasse C wird von der Library aktuell nicht bzw. nur eingeschränkt unterstützt.