LoRaWAN-Kommunikation mit dem LR1262 Dev.-Board (RP2040) und einem Single-Channel Gateway

Heute komme ich endlich dazu eine LoRaWAN-Nachricht von meinem Elecrow LoRaWAN LR1262 Dev.-Board mit Raspi-Pico 2040 (siehe Vorstellungsartikel dazu hier) über mein Elecrow ESP32 Basic Single-Channel LoRaWAN-Gateway (siehe Vorstellungsartikel dazu hier) abzusetzen. Das soll die Nachricht dann über WLAN an das The Things Network weiterleiten, wo ein Webhook darauf wartet, die Nachricht an meinen Webserver weiterzuleiten, der daraus vorerst einmal eine e-mail macht, in der er die Daten an mich schickt.

So kann ich zum Beispiel die Telemetrie-Daten eines BMP280-Sensors (Temperatur und Luftdruck), einer BMP280 / AHT20-Kombination (zusätzlich Luftfeuchtigkeit), eines BME680-Sensors (zusätzlich Luftqualität / flüchtige organische Gase) oder eines anderen, beliebigen Sensors auslesen und in festen Intervallen, vielleicht alle halbe Stunde über das Gateway an meinen Webserver schicken. Dieser kann dann später eine einfache .csv-Datei mit Datum und Uhrzeit loggen, was man dann wieder zu einer schönen Verlaufsgrafik aufbereiten könnte.

Damit das Ganze auch klappt, müssen eine Menge Dinge zusammenpassen.

Die Crux mit einem Single-Channel-Gateway

Normalerweise sind LoRaWAN-Gateways nicht gerade günstig. Das liegt an dem leistungsfähigen LoRa-Chip, der auf mehreren Kanälen (meist 8) gleichzeitig in den Äther horcht, also parallel arbeitet.

Nun ist jemand auf die Idee gekommen, dass ein Gateway im Prinzip auch mit einem normalen LoRa für Endgeräte, die nur über einen Kanal arbeiten, funktionieren könnte. Das würde die Kosten für ein LoRaWAN-Gateway drastisch senken. So etwas nennt man dann ein Single-Channel-Gateway, weil es eben nur einen Kanal hat.

Okay, Single-Channel-Gateways sind günstig. Aber dass es nur einen Kanal gibt, hat einen entscheidenden Nachteil: das Single-Channel-Gateway kann nur eine Sache gleichzeitig machen. Und da man keine Nachricht verpassen will, konzentriert es sich aufs Horchen. Es lauscht also ständig auf seiner Frequenz nach LoRa-Bursts. Ein Umschalten von Empfangen zu Senden, zum Beispiel, um eine Empfangsbestätigung zu senden, findet bei einem Single-Channel-Gateway nicht statt.

Bei LoRaWAN gibt es zwei grundsätzliche Kommunikations-Modi. Zum einen OTAA (Over-The-Air Activation), den man sich als den "gesicherten Modus" vorstellen kann und zum anderen den ABP-Modus (Activation By Personalization), den ich auch den "Ad-Hoc"-Modus nennen will.

Die beiden Kommunikationsmodi von LoRaWAN

OTAA – Over-The-Air Activation ist die empfohlene und sicherere Methode. Der Ablauf sieht hier so aus:

Das Endgerät sendet eine Join Request an das Netzwerk.
Diese enthält:

DevEUI (Geräte-ID, weltweit eindeutig)
AppEUI (Anwendungs-ID)
AppKey (geheimer Schlüssel)

Der Network Server prüft die Anfrage.
Bei Erfolg sendet der Server eine Join Accept-Nachricht zurück.
Das Gerät erzeugt daraus zwei temporäre Schlüssel, die nur für eine Session gelten:

NwkSKey (Network Session Key)
AppSKey (Application Session Key)

Vorteil ist die bessere Sicherheit: es gibt dynamische Schlüssel und damit bei jedem Join neue Session Keys. Ein Abhören ist so unmöglich. Außerdem kann das Netzwerk Geräte verwalten, neu verbinden oder Roaming unterstützen.

Nachteil ist, dass der Join-Prozess Zeit und ein stabiles Funkfenster benötigt. Bei Geräten mit sehr seltenem Sendeintervall kann der erste Join fehlschlagen.

OTAA ist den "großen, echten" (und teuren) LoRaWAN-Gateways vorbehalten, denn es scheitert bei einem Single-Channel-Gateway schon daran, dass dieses nicht Join Accept-Nachricht zurücksenden kann.

Einem Single-Channel-Gateway bleibt also nur der Ad-Hoc-Mode, der ABP – Activation By Personalization Modus, was die statische, manuelle Methode ohne viel Drumherum ist. Entsprechend einfach ist der Ablauf:

Die Session Keys (DevAddr, NwkSKey, AppSKey) sind fest ins Gerät programmiert oder werden per Software auf eigene Werte gesetzt.
Ein Join ist nicht nötig, es kann sofort gesendet werden, nachdem dem Gerät der Modus mitgeteilt wurde.

Großer Vorteil des ABP-Modus ist dessen Einfachheit und dass er mit allen Gateways kompatibel ist, auch mit Single-Channel-Gateways. Der Nachteil ist eine geringere Sicherheit. Die Nachrichten könnten abgefangen werden und bei mehreren Sendungen hintereinander mit dem gleichen Schlüssel könnte man eventuell kryptoanalytisch auf den gleichbleibenden Schlüssel schließen. Um dem zu begegnen, könnte man zwar die Schlüssel durch die Software jedesmal neu konfigurieren. Das bedeutet aber wieder Mehraufwand und manche Schlüssel müssen fest sein, damit das TTN den LoRa-Client identifizieren und einer App zuordnen kann.

Da uns aber sowieso keine andere Wahl bleibt und sich außerdem niemand bei unwichtigen Daten wie Temperatur etc. die Mühe einer kryptoanalytischen Attacke machen wird - er kann auch einfach ein Thermometer bemühen - wählen wir für unsere Anwendung die Ad-Hoc-Methode.

LoRaWAN ist gerade in diesem Modus komplett zustandslos. Wir haben zu keiner Zeit die Garantie, dass unsere ausgesendeten Nachrichten auch ankommen. Wir blasen die Nachricht sozusagen einfach in den Äther und hoffen, das jemand zuhört. Wir bekommen als Endgerät nicht mit, ob unsere überhaupt von einem Gateway empfangen wurde, wir bekommen ja keine Rückmeldung. Auch das Gateway schickt die Nachricht per UPD weiter, was im Gegensatz zu TCP auch keine Rückmeldung gibt, ob das Datenpaket auch angekommen ist.

Es empfiehlt sich also, die Temperatur von unserer Sensor-Node öfters auszusenden. Denn wir müssen davon ausgehen, dass nicht jede Nachricht ankommt. Ein eigenes Gateway in der Nähe erhöht natürlich die Wahrscheinlichkeit enorm, dass die ausgesandte Nachricht auch gehört wurde. Ein LoRaWAN-Gateway schickt übrigens alle empfangenen Nachrichten weiter. Es weiß nicht, ob das Paket von uns oder einem Fremden ist. Es guckt sich die Pakete auch erst gar nicht an. Denn das ist dem Gateway egal, denn Prinzip ist: Jedes Gateway sendet alle empfangenen Datenpakete ungesehen weiter.

So kann es sein, dass unsere Nachricht von mehreren Gateways empfangen wurde, die sie alle zum TTN schicken. Das TTN erkennt das aber zuverlässig und fasst alles zu einer Nachricht zusammen (bzw. ignoriert alle außer einer). Das macht sie anhand des Framecounters ("FCnt" in der Live Data-Anzeige), den der LR1262-Chip nach jedem Senden erhöht:

05:53:08 Receive uplink message DevAddr 0504A03F FCnt 3 Data rate SF12BW125 SNR 12 RSSI -45
05:52:56 Receive uplink message DevAddr 0504A03F FCnt 1 Data rate SF12BW125 SNR 13 RSSI -45

Wir können also erst im TTN sehen, ob unsere LoRaWAN-Nachricht angekommen ist. Und auf dem Weg kann so einiges schief gehen und dann geht die Fehlersuche los. Da wir kein Feedback von den Instanzen vor TTN bekommen, kann das eine ganz schöne Raterei sein, was denn nicht stimmt.

Was alles stimmen muss für die Kommunikation

Ich habe hier einmal einen LoRa-Burst mit meiner SDR-Software aufgenommen, um zu zeigen, was technisch vor sich geht:

Oben die Wellenform zeigt einen Momentan-Zustand beim Senden eines Packets. Und unten, der bunte Block im Wasserfall-Diagramm zeigt einen vorherigen Burst.

Der für LoRa in Europa genutzte Frequenzbereich ist der um 868 MHz, was sich auch in der Grafik widerspiegelt. Unten kann man die Breite des Funksignals gut erkennen: es sollten 125 kHz sein.

Dieses breite Signal macht LoRa aus: so kommt es weit bzw. kann auch weit weg noch korrekt dekodiert werden. Auf der anderen Seite ist LoRa dafür langsam.

Man kann mit dem Spreading Factor (SF) genannten Wert, der auch Data Rate (DR) genannt wird, einen Kompromiss zwischen Reichweite und Geschwindigkeit wählen: In TTN / LoRaWAN werden Data Rates (DR0–DR5) definiert, die jeweils einen Spreading Factor (SF) und Bandwith (BW) haben:

DR (Data Rate)	SF (Spreading Factor)	Bandbreite	Bemerkung
DR0	SF12	125 kHz	niedrigste Datenrate, größte Reichweite
DR1	SF11	125 kHz
DR2	SF10	125 kHz
DR3	SF9	125 kHz
DR4	SF8	125 kHz
DR5	SF7	125 kHz	höchste Datenrate, geringste Reichweite

Standardmäßig ist im LR1262-LoRa-Chip DR0, also SF12 eingestellt. Zur Konfiguration der LR1262 werden AT-Kommandos (wie damals bei den Modems) benutzt. Komischerweise schlägt der AT-Befehl, um die Data Rate und damit auch den SF zu ändern, fehl. Es scheint nur DR=0 zu gehen, was heißt, dass wir auf SF12 festgenagelt zu sein scheinen.

Das ist aber nicht weiter schlimm, weil SF12, also höchste Reichweite eh meine Präferenz ist.

Allerdings scheint sich mit dem Spreading Factor auch die Modulation des Funksignals zu ändern. Mein Single-Channel-Gateway, was auf SF 7 eingestellt war, konnte die Signale auf SF12 nicht "hören" (sprich nicht dekodieren). Also musste ich mein Gateway noch einmal neu flashen und auf SF12 konfigurieren. Damit kommen die Datenpakete jetzt auch zum Gateway durch und dieses kann es zum TTN weiterleiten, wo ich dann erstmals erkennen kann, dass die Konfiguration passt.

Eine weitere Konfiguration des LR1262 betrifft den ChannelMode. Hier kann man zwischen Single Channel (0) und Multi Channel (1) wählen. Default ist 1, also Multi Channel. Darauf muss die Einstellung auch bleiben, sonst werden die Pakete nicht vom Gateway gehört.

Dann ist das Senden einer Nachricht von der LR1262-Node aus eigentlich ganz einfach - wenn man herausgefunden hat, welche Pins denn nun die richtigen sind, denn die sind leider in der Dokumentation auf der Herstellerseite widersprüchlich und fehlerhaft angegeben. Auch der Beispiel-Code funktioniert leider nicht.

Richtig ist - was ist durch stundenlanges Herumprobieren herausfinden musste:

#define PIN_LR1262_RX 1  // im Beispiel-Code FALSCH angegeben RX=5 TX=4
#define PIN_LR1262_TX 0
#define LR1262_BAUD 9600 // 115200 ist zu viel, 9600 geht, 38400 nicht, 19200 auch nicht
#define LR_Serial Serial1

Ist das richtig konfiguriert, kann man mit LR_Serial.println("AT..."); AT-Befehle an das LR1262-Modem schicken. Im Ad-Hoc-Modus ist das:

AT+JOIN=0
AT+SEND=1:0:48616C6C6F
AT+SAVE

Das ist auch schon alles. Leider sind auch die AT-Befehle auf der Herstellerseite nicht alle korrekt angegeben. Man sollte sich eher an das halten, was der "AT?"-Befehl ausgibt, der dummerweise nicht in der Liste auf der Herstellerseite vorkommt:

AT-Commands LR1262 (klicken, um diesen Abschnitt auf- und zuzuklappen)

AT?              : This text
AT+<CMD>?        : Help on <CMD>
AT+<CMD>         : Run <CMD>
AT+<CMD>=<value> : Set the value
AT+<CMD>=?       : Get the value
AT+ChannelMode=<Channel><CR>. Get or Set single channel or multi-channel=[0:off, 1:on]
AT+LowPower=<LowPower><CR>. Get or Set power=[0:off, 1:on]
AT+RESET Trig a MCU reset
AT+RFS: Restore EEPROM Factory Settings
AT+SAVE: Store current context to EEPROM
AT+VL=<Level><CR>. Set the Verbose Level=[0:Off .. 3:High]
AT+LTIME Get the local time in UTC format
AT+AppEui=<12><CR>. Get or Set the App Eui
AT+NwkKey=<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX><CR>: Get or Set the Network Key
AT+AppKey=<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX><CR>: Get or Set the Application Key
AT+NwkSKey=<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX><CR>: Get or Set the Network Session Key
AT+AppSKey=<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX><CR>: Get or Set the Application Session Key
AT+DevAddr=<XXXXXXXX><CR>. Get or Set the Device address
AT+DevEui=<XXXXXXXXXXXXXXXX><CR>. Get or Set the Device EUI
AT+NWKID=<NwkID><CR>. Get or Set the Network ID=[0..127]
AT+JOIN=<Mode><CR>. Join network with Mode=[0:ABP, 1:OTAA]
AT+LINKC. Piggyback a Link Check Request to the next uplink
AT+SEND=<Port>:<Ack>:<Payload><CR>. Send binary data with the application Port=[1..199] and Ack=[0:unconfirmed, 1:confirmed]
AT+VER=? Get the FW version
AT+ADR=<ADR><CR>. Get or Set the Adaptive Data Rate setting ADR=[0:off, 1:on]
AT+DR=<DataRate><CR>. Get or Set the Tx DataRate=[0..7]
AT+BAND=<BandID><CR>. Get or Set the Active Region BandID=[0:AS923, 1:AU915, 2:CN470, 3:CN779, 4:EU433, 5:EU868, 6:KR920, 7:IN865, 8:US915, 9:RU864]
AT+CLASS=<Class><CR>. Get or Set the Device Class=[A, B, C]
AT+DCS=<DutyCycle><CR>. Get or Set the ETSI DutyCycle=[0:disable, 1:enable] - Only for testing
AT+JN1DL=<Delay><CR>. Get or Set the Join Accept Delay between the end of the Tx and the Join Rx Window 1 in ms
AT+JN2DL=<Delay><CR>. Get or Set the Join Accept Delay between the end of the Tx and the Join Rx Window 2 in ms
AT+RX1DL=<Delay><CR>. Get or Set the delay between the end of the Tx and the Rx Window 1 in ms
AT+RX2DL=<Delay><CR>. Get or Set the delay between the end of the Tx and the Rx Window 2 in ms
AT+RX2DR=<DataRate><CR>. Get or Set the Rx2 window DataRate=[0..7]
AT+RX2FQ=<Freq><CR>. Get or Set the Rx2 window Freq in Hz
AT+TXP=<Power><CR>. Get or Set the Transmit Power=[0..15](valid range according to region)
AT+PGSLOT=<Period><CR>. Set or Get the unicast ping slot Period=[0:1s .. 7:128s](=2^Period)
AT+TTONE Starts RF Tone test
AT+TRSSI Starts RF RSSI tone test
AT+TCONF=<Freq in Hz>:<Power in dBm>:<Lora Bandwidth <0 to 6>, or Rx FSK Bandwidth in Hz>:<Lora SF or FSK datarate (bps)>:<CodingRate 4/5, 4/6, 4/7, 4/8>:
         <Lna>:<PA Boost>:<Modulation 0:FSK, 1:Lora, 2:BPSK, 3:MSK>:<PayloadLen in Bytes>:<FskDeviation in Hz>:<LowDrOpt 0:off, 1:on, 2:Auto>:
         <BTproduct: 0:no Gaussian Filter Applied, 1:BT=0,3, 2:BT=0,5, 3:BT=0,7, 4:BT=1><CR>. Configure RF test
AT+TCONF=868000000:14:50000:50000:4/5:0:0:0:16:25000:2:3 /*FSK*/
AT+TCONF=868000000:14:10000:10000:4/5:0:0:3:16:25000:2:3 /*MSK*/
AT+TCONF=868000000:14:4:12:4/5:0:0:1:16:25000:2:3 /*LORA*/
AT+TTX=<PacketNb><CR>. Starts RF Tx test: Nb of packets sent
AT+TRX=<PacketNb><CR>. Starts RF Rx test: Nb of packets expected
AT+CERTIF=<Mode><CR>. Set the module in LoraWan Certification with Join Mode=[0:ABP, 1:OTAA]
AT+TTH=<Fstart>,<Fstop>,<Fdelta>,<PacketNb><CR>. Starts RF Tx hopping test from Fstart to Fstop in Hz or MHz, Fdelta in Hz
AT+TOFF Stops on-going RF test
AT+BAT Get the battery Level in mV

AT+JOIN=. Join network with Mode=[0:ABP, 1:OTAA]
AT+SEND=::. Send binary data with the application Port=[1..199] and Ack=[0:unconfirmed, 1:confirmed]
AT+SAVE: Store current context to EEPROM

Mit AT+JOIN=0 wählen wir also ABP, den Ad-Hoc-Modus, passend zu unserem Single-Channel-Gateway. Mit AT+SEND=0:0:48616C6C6F senden wir auf Port 1 den Text "Hallo", zu Hex kodiertes ASCII "48616C6C6F". Die zweite 0 gibt an, dass wir keine Bestätigung vom Gateway wollen, die kann ein Single-Channel-Gateway eh nicht zurücksenden.

Und mit AT+SAVE wird laut Beschreibung der Kontext gespeichert. Ich gehe davon aus, dass damit die (mit weiteren AT-Befehlen) gesetzten Keys und IDs und der Framecounter abgespeichert werden. Aber nach einem AT+RESET sind alle Daten wieder im Ausgangszustand: alle IDs, alle Keys und auch der Framecounter beginnt wieder bei 1.

Probleme mit dem Framecounter

Wurde bereits eine Nachricht mit einem gewissen Framecounter empfangen, oder eine Nachricht mit einem geringeren Framecounter als dem nächsten, dann verwirft TTN diese Nachricht, weil es denkt, dass sie (ggf. auch verspätet) bereits weitergeleitet wurde.

Das kann aber auch bei einem Reset der LoRaWAN-Node zu einem Problem werden. Ist der Chip nicht so intelligent, sich seinen Framecounter stets zu merken (also z. B. im Flash zu speichern), dann vergisst er ihn bei einem Reset und fängt wieder bei 1 an. Das hat zur Folge, dass alle weiteren Nachrichten verworfen werden und nichts mehr ankommt. Das geht solange, bis der Framecounter den bisherigen bei TTN gespeicherten Höchstwert für den Framecounter überschreitet. Erst dann werden die Nachrichten weitergeleitet.

Leider gibt es keine Möglichkeit den Framecounter manuell durch einen AT-Befehl zu setzen. Dieser wird komplett durch den LoRa-Chip verwaltet. Man sollte darum eigentlich nach jedem Send den AT-Befehl "AT+SAVE" absetzen, damit der Framecounter über einen Reset oder eine Stromabschaltung hinaus erhalten bleibt.

"Eigentlich", weil zumindest bei meinem Exemplar das "AT+SAVE" wirkungslos bleibt. Das heißt, nach jedem Reset ist der Framecounter wieder auf 1 und es werden erst einmal alle Nachrichten vom TTN ignoriert - bis der Framecounter dann wieder auf der Gesamtanzahl der mit diesem Gerät gesendeten Nachrichten erreicht hat. Ein allererster Test möchte deswegen gut aussehen, aber in der Praxis ist das absolut inakzeptabel.

TTN konfigurieren

Der Rest ist, TTN richtig zu konfigurieren. Dies habe ich in meinem Artikel Elecrow ESP32 Basic LoRaWAN-Gateway und The Things Network: Firmware und Konfiguration beschrieben.

Bei der End Device-Konfiguration unter Applications in TTN lauert allerdings eine Stolperfalle, die gerne übersehen wird:

Man muss zuerst Show advanced activation, LoRaWAN class and cluster settings anklicken, damit weitere Optionen erscheinen. Hier muss unbedingt "Activation by personalization (ABP)" angeklickt werden, damit unsere ABP-Single-Channel-Gateway-Kommunikation funktioniert.

Wenn das Endgerät angelegt ist, müssen wir noch einmal in die Einstellungen. Die Einstellung, damit TTN mit einem (nach einem Reset des Endgerätes) zurückgesetzten Framecounter zusammenarbeitet, ist sehr versteckt: ttn-app-device-framecounter-reset.png anklicken. End devices anklicken. Das entsprechende Endgerät auswählen. Dort ganz oben rechts auf Settings klicken. Auf Expand hinter Network layer klicken und den Abschnitt aufklappen. Auf Custom MAC settings klicken und den Abschnitt damit aufklappen. Dann "Resets frame counters" anklicken und dann Save changes am Seitenende:

Nur dann akzeptiert TTN es, dass das Endgerät nach einem Reset wieder mit Null anfängt. Da das "AT+SAVE" nicht auf dem LR1262 funktioniert, ist dies die einzige Möglichkeit unser LR1262 Dev.-Board zusammen mit einem Single Channel Getway im ABP Modus zu benutzen.

Wer Webhooks bei TTN anlegen will, damit seine LoRaWAN-Nachrichten an den eigenen Webserver weitergeleitet werden, dem sei auch noch The Things Network Konfiguration: Mit Webhooks Messages an den eigenen Webserver weiterleiten zur Lektüre empfohlen.

Dann erhält man eine solch formatierte e-mail (xxx = anonymisiert, fett = wichtiger Teil, Erklärung nach dem Code):

SGFsbG8= ist Base64 kodiert für "Hallo".

Hallo als Text wurde durch folgenden Upload-Payload-Formatter (Custom Javascript) in TTN erzeugt:

function decodeUplink(input) {
  const bytes = input.bytes;
  const text = String.fromCharCode.apply(null, bytes);

  return {
    data: {
      text: text
    },
    warnings: [],
    errors: []
  };
}

C0016A7E00000001 ist die EUID für mein Gateway, sozusagen Hex-Leet-Speak für "COOLGATE-1"

[spreading_factor] => 12 und [frequency] => 868100000 stimmen.

[received_at] => 2025-10-24T08:05:33.333082864Z ist UTC oder Zulu-Time, auch Greenwich Mean Time (GMT) genannt. Deutschland ist UTC+01 im Winter und UTC+02 im Sommer.

[consumed_airtime] => 1.318912s: Die Übermittlung hat 1.3 Sekunden gedauert.

Fazit

Das Development Board und das Basic (Single-Channel) Gateway von Elecrow sind günstig. Leider ist die Dokumentation nicht gut. So einige Dinge sind dort falsch wiedergegeben und muss lange probieren, bis man die richtigen Pins, AT-Befehle und Konfigurationseinstellungen hat. Mit einer guten Dokumentation könnte das alles viel einfacher sein und schneller gehen. Was dann allerdings immer noch bleibt, ist das scheinbar funktionslose "AT+SAVE" und das Problem mit dem Framecounter.

Kurz gesagt: Es gibt einen Weg, das Duo mit TTN zum Laufen zu bringen, aber es ist extrem nervig. Die fehlerhafte Dokumente und nicht funktionierender Beispiel-Code im Elecrow Github lässt fast vermuten, dass der Hersteller selbst nicht wirklich weiß, wie sein Gerät zu programmieren ist.

Mit dieser Anleitung funktioniert es dennoch, dass das Duo funktioniert - eigentlich wäre das die Aufgabe des Herstellers gewesen. So kann man eine kostengünstige LoRaWAN-Verbindung aufbauen. Allerdings ist diese dann nicht mehr so sicher wie eine "richtige" OTAA-Verbindung mit Join. Die festen Schlüssel und der fehlende inkrementelle Framecounter nagen ein bisschen an der Sicherheit.

Aber wahrscheinlich ist das von TTN anvisierte Sicherheitslevel eh ein wenig Overkill für die meisten Anwendungen. Meist werden doch nur profane Sensordaten wie Temperatur, Luftdruck oder Luftfeuchtigkeit übertragen. Eigentlich nichts Geheimes, bei es schlimm wäre, wenn jemand mitliest.

Mit einem sehr viel teureren Multi-Channel-Gateway ist dann auch OTAA möglich. Dann wird es zwar noch ein wenig komplizierter, aber auch sicherer. Für professionelle Anwendungen sollte man dann vielleicht doch tiefer in die Tasche greifen.

Video

Im nachfolgenden Video demonstrieren ich die Zusammenarbeit von LoRaWAN-Node, Gateway und The Things Network: