Elecrow ESP32 Basic LoRaWAN-Gateway und The Things Network: Firmware und Konfiguration

LoRa, was ist das?

Nein, LoRa ist nicht der Name meines Papageis, der aufdringlich nach einem Keks verlangt, sondern LoRa steht für Long Range. Das ist ein spezielles Funk-Übertragungsverfahren, dass auf Störunanfälligkeit, und niedrigen Stromverbrauch getrimmt wurde. Dazu nutzt es eine Chirp-Spread-Spectrum-Modulationstechnik der Semtech Corporation. Das breite Spektrum und die Wellenform bietet eine geringe Störanfälligkeit und damit eine große Reichweite.

LoRa ist also gut für: Es bietet aber keine hohe Übertragungsraten. Da es auf den freien Frequenzen 433MHz (z. B. Schweiz), 868 MHz (Europa) und 915 MHz (USA) funkt, auf denen eh schon viel los ist, dürfen auch nur kurz andauernde Bursts - und damit kleine Datenpakete - gesendet werden. Sonst würde die Frequenz für andere Anwendungen unbrauchbar.

Und was ist LoRaWAN?

LoRa ist aber auch genau dafür gedacht: kurze Datenpakete von Sensoren zu einem Gateway zu senden, welches diese dann ins Internet weiterleitet. Diese Anwendung nennt man dann LoRaWAN. Es gibt auch noch andere Anwendungen und Protokolle für LoRa (wie Meshtastic), aber heute geht es um LoRaWAN.

Ein Endgerät (oder End Device) schickt sein Paket, zum Beispiel die Temperatur und die Luftfeuchtigkeit in einem Gewächshaus immer zu einem Gateway, zum Beispiel ein kleiner Server auf einem landwirtschaftlichen Betrieb. LoRa kann bei freier Sichtlinie Kilometer überbrücken. Und braucht eben nicht viel Energie, so das es auch möglich ist, die Endgeräte mit Akkus zu betreiben.

Das LoRaWAN-Gate nimmt die Datenpakete von den Endgeräten entgegen und schickt sie weiter ins Internet. Wir benutzen hier The Things Network. Dort kann man sich die Messages der Endgeräte nach Anwendung bündeln und sich anzeigen lassen. Oder man leitet sie weiter zu einem eigenen Webserver.

An diesen Webserver könnte man dann wieder Steuerungselektronik anschließen, um zum Beispiel mehr Wasser zuzuführen, wenn es im Gewächshaus zu trocken geworden ist.

Wie ich auf LoRaWAN gestoßen bin

Es ist schon ein paar Jahre her, da bin ich auf den TTGO T3 LoRaWAN OLED ESP32 gestoßen. Auf dem war eine Software namens PAXCNT (PaxCounter) vorinstalliert, die die nähere Umgebung nach Bluetooth-Geräten absucht und dann daraus errechnet, wieviele Personen sich wohl im näheren Umkreis befinden. Vielleicht ganz praktisch, um den Run in den Kantine abzuwarten und zu sehen, wann ein Konzert oder Fußballspiel vorüber ist.

Ich fand das Thema auf jeden Fall spannend. Allerdings hatte ich ein Problem: Ein LoRaWAN-Endgerät braucht auch immer ein LoRaWAN-Gateway zum Kommunizieren. Da gab es sogar eines bei mir in der Gegend. Trotzdem musste ich immer ins Auto steigen und in die Nähe des LoRaWAN-Gateways fahren, um meinen PaxCounter zu testen. Was dann doch sehr nervig war. Und LoRaWAN-Gateways kostete damals eine Stange Geld, weil sie auf vielen LoRa-Kanälen parallel lauschen "müssen". Also wurde ich nie so richtig warm, meine eigene LoRaWAN-Applikation zu designen und zu programmieren.

Irgendwann kann dann Maarten Westenberg aka Things4u, wohl mehr als Proof-of-Concept, auf die Idee, ein günstiges LoRaWAN-Gateway mit nur einem Kanal mit einem günstigen Endgeräte-Transceiver-Chip zu basteln.

Das Projekt war ein Erfolg und hat gut funktioniert und andere haben es adaptiert, so auch Elecrow, die daraus ihr Basic LoRaWAN-Gateway mit einem ESP32 gezaubert haben.

Damit rückte ein eigenes Gateway mit Kosten von nur rund 25 Euro in finanzielle Reichweite.

Das Basic LoRaWAN Gateway Module von Elecrow

Das Elecrow LoRaWAN Gateway Module bietet kurz umrissen:
Preis derzeit (Aug. 2025): USD 27.50

Die Konfiguration des Gateways

Tja, die ist leider gar nicht so einfach und hält so einige Fallstricke bereit. Mich hat es viele Stunden Debugging und Herumprobieren gekostet, bis ich das Gateway endlich am Laufen hatte. Plug and Play ist also leider nicht.

Ich versuche, euch hier eine Anleitung zur Verfügung zu stellen, mit der es klappt. Ihr müsst euch einfach nur dran halten, dann wird das was und ihr müsst nicht fast dem Wahnsinn verfallen, so wie ich.

Hardware: Die richtige Antenne an die richtige Buchse


Die beiden mitgelieferten externen Antennen machen erst einmal einen guten Eindruck. Sie ähneln sich aber auch wie ein Ei dem anderen. Doch wenn man genau hinsieht, hat die eine einen Aufdruck, den man eigentlich nur erkennen kann, wenn das Licht schräg darauf fällt: TX868-JK-11.

Das ist die LoRa Antenne für 868 MHz. Und die gehört natürlich auf die LoRa-Buchse geschraubt. Logisch. Nicht verwechseln, sonst ist euer Empfang unterirdisch. By the way: Das Gerät bitte nie ohne Antennen benutzen. Das tut den Chips eventuell nicht gut, wenn sie die Sendeenergie nicht richtig abführen können.

Dann schaltet ihr das Gateway ein. Das macht dann einen WLAN Access Point unter der IP-Adresse 192.168.4.1 (wird angezeigt) auf. Dann wählt ihr, am besten auf eurem Smartphone, das Netzwerk ELECROW-GW1C aus. Daraufhin müsst ihr ein Passwort für die Verbindung eingeben (WPA2). Hier lauert auch schon der erste, böse Stolperstein.

Kein Anschluss unter der Nummer 12345678


Wenn ihr die Gateway-Firmware-Version habt, die das Bild rechts mit dem WLAN-Passwort 12345678 anzeigt, dann seid gewarnt: Ihr könnt hier ewig oft das richtige Passwort, nämlich 12345678 eingeben, ihr werdet trotzdem immer einen Authentifizierungsfehler bekommen.

Zumindest hatte ich das auf allen meinen Systemen, von altem Samsung Smartphone, über iPhone, über Xiaomi Android Smartphone, unter Windows, unter Linux, überall!

Das scheint irgendwie daran zu liegen, dass 12345678 wohl ein zu einfaches Passwort ist und von WPA2, oder weiß der Teufel was, generell nicht akzeptiert wird. Da muss man auch erst einmal drauf kommen.

Wir brauchen eine neue Firmware

Also müssen wir das Passwort ändern. Jetzt könnte man auf die Idee kommen, einfach das Passwort im Source-Code der Firmware zu ändern. Die kann man auf der GW1C-Produktseite unter Factory Program nebst der Libraries auch herunterladen. Bzw. über Github.

Nur wird euch das wenig nutzen, es sei denn ihr wollt in einen Kaninchenbau eintauchen, aus dem ihr vielleicht nicht mehr geistig gesund herauskommt. Ich habe jedenfalls versucht, die Firmware zu kompilieren, unter Android IDE 1.8.x, unter Android IDE 2.3.x und unter VS Code mit Platform IO. Obwohl die Libraries scheinbar mitgeliefert werden, gibt es da Ungereimtheiten bei den Abhängigkeiten. Mal ist byte gleich in mehreren Bibliotheken definiert. Hat man stattdessen uint8_t geschrieben und diesen Fehler korrigiert, taucht der nächste auf und dann wieder einer, und noch einer und noch einer. Und irgendwann habe ich aufgegeben.


Vergesst also diesen Weg. Es gibt einen einfacheren. Holt euch das V2-Firmware-Binary. Das ist nämlich schon mit einem neuen Passwort (aaaabbbb) kompiliert. Danke an den Elecrow-Support an dieser Stelle. Es ist zu finden unter https://github.com/Elecrow-RD/LoRaWAN-Gateway-Module-Based-on-ESP32-with-1.8-LCD/tree/master/factory_firmware/Lora_Gateway_release_bin_v2.0.

Das ist nämlich schon ein komplett fertige kompiliertes Firmware-Update mit dem neuen Passwort. Da ihr nichts kompilieren müsst, gibt es auch keine zig Compiler-Fehlermeldungen, die wir mühsam umschiffen müssten. Dass so etwas sehr langwierig und mühsam sein kann, habe ich bei meinem CYD-Projekt mit der TFT_eSPI-Library schmerzlich lernen müssen. Ich nenne das die "Library-Versions-Hölle". Das ist für Mikrocontroller das, was unter Windows als "DLL-Hölle" bekannt ist, nur noch ein bisschen schlimmer.

Stellt sich nun die Frage, wie man ein Firmware-Binary auf seinen ESP32 im Gateway bekommt. Das habt ihr persönlich vielleicht noch nicht gemacht, aber bei den Herstellern wird natürlich nicht jedes einzelne Gerät per Arduino IDE bestückt, sondern es gibt dafür extra ein Tool, um eine fertige Firmware auf einen ESP32 zu schieben.

Firmware mit Espressif ESP32 Flash Download Tool flashen

Das Tool habe ich schon einmal ausführlich vorgestellt in meinem Artikel Odroid Go (ESP32 Gameboy Clone): alternative Über-Firmware installieren. Auch der Odroid Go hat einen ESP32 on Board. Es ist also im Grunde dasselbe. Wie es genau vom Prinzip her geht, könnt ihr also im Odroid-Artikel nachlesen, für den Unterschied zum Gateway soll uns hier ein Screenshot reichen:



Wichtig: Wenn ihr das Gateway dann einmal konfiguriert habt (kommt gleich) und da was falsch gemacht habt und wollt die gespeicherten Konfigurationsdaten wieder loswerden, klickt vor den Start einmal Erase an. Sonst bleiben die Daten erhalten und ihr müsst noch einmal flashen.

Grundsätzlich muss das Gateway natürlich im Flash-Modus sein. Dazu Boot drücken und halten, kurz Reset drücken, dabei weiterhin Boot halten und zum Schluss auch Boot loslassen. Das müsst ihr ggf. vor jeder Aktion machen, also vor jedem neuen Flash oder Erase.

Einen Schritt weiter, aber noch lange nicht am Ziel

Jetzt endlich können wir uns mit der neuen Firmware über den GW1C-WLAN-Access Point und dem Passwort konnektieren Endlich wird das Passwort aaaabbbb akzeptiert, wohl, weil es nicht mehr nur aus Ziffern besteht.

Als nächstes müssen wir sehr sofgfältig sein und aufpassen, dass wir auch das richtige eingeben. Denn sonst müssen wird die Config zurücksetzen, was nur geht, indem wir das Flash Erasen und wieder neu flashen. Was mit der Zeit echt nervt.

Glaubt mir, ich habe viele Config-Kombinationen ausprobiert, bis ich eine hatte, die gepasst hat. Ich habe zweistellig neu geflasht. Das nervt irgendwann sehr. Und glaubt mir auch einfach, dass die Daten so sein müssen, wie nachfolgend beschrieben. Wenn ihr das nicht wollt: viel Spaß beim Probieren und flashen! Und vergesst nicht, das Alles muss später auch vom The Things Network akzeptiert werden. Wenn da irgendwas nicht passt, was hier angegeben werden muss: Willkommen zur nächsten Iteration!


Nachdem wir nochmal nachgezählt haben, dass die Gateway ID auch genau 16 Ziffern hat und wir die so gewählt haben, dass sie garantiert einmalig ist, können wir auf Submit klicken. Für die Einmaligkeit der Gateway ID ist vielleicht das ein Kochrezept: nehmt für die ersten acht Stellen das Datum im Format YYYYDDMM und danach noch weitere acht zufällige Ziffern, oder meinetwegen auch euer Geburtsdatum, wenn ihr es persönlich haben wollt. Hauptsache, jemand anderes auf der Welt hat nicht schon diese Gateway ID reserviert. Denn dann funktioniert nichts. Und ihr bekommt auch keine Fehlermeldung.


Nach dem Submit dauert es ein paar Sekunden, dann kommt ein WiFi Config und dann der Status Screen des Gateways - bei euch steht da natürlich eine andere Nummer hinter "ID:" und die Region auf "EU868". Aber der Rest ist gleich.

Dieser Status Screen sieht immer so aus. Egal, ob ihr euch mit der Config beim The Things Network (kurz TTN) als Gateway anmelden könnt oder nicht. Also egal, ob eure Config fehlerhaft oder fehlerfrei ist.

Mehr Infos gibt es nur, wenn ihr das Gateway an den PC anschließt und dort auf dem COM-Port mit einem Terminal-Programm lauscht. Wer nicht weiß, wie das geht, dem empfehle ich meinen Artikel Raspberry Pi Pico: Erste Schritte empfehlen, sucht darin nach "PuTTY".

Ihr merkt höchstens, dass euer Gateway funktioniert, wenn RX und TX auf dem Status Screen hochzählen, aber das wird nie der Fall sein, wenn ihr euer Gateway nicht auch bei The Things Network anmeldet.

Das Gateway bei TTN anmelden

Zu allererst braucht ihr einen Account bei TTN. Gebt https://console.cloud.thethings.network/ in eurem Browser an, dann werdet ihr schon nach einem Account gefragt, bevor ihr weiter machen könnt. Dann solltet ihr auf der Seite "Europe 1" als euren Heimat-Cluster auswählen.

Damit ist dann https://eu1.cloud.thethings.network/console eure neue TTN-Heimat und dessen Dreh- und Angelpunkt.

Oben rechts findet ihr in eurer TTN-Console dann den Button "Register gateway". Den müssen wird klicken. Denn ohne dass das TTN über unser Gateway Bescheid weiß, kann auch keine Verbindung und Kommunikation zwischen TTN und unserem Gateway zu Stande kommen.

Hier geben wir unsere Gateway ID aus der Gateway-Konfiguration ein, und zwar genauso, wie dort angegeben. Die Spaces werden automatisch eingefügt wegen der Lesbarkeit. Die können wir ignorieren:



Gleich mal als Warnung vorweg: Wenn ihr auf der TTN etwas falsch eingebt, dann könnt ihr das später nicht mehr ändern. Es gibt keine Edit-Funktion. Ihr könnt nur das Gateway löschen und nochmal neu eingeben. Was für ein Spaß, wenn man probieren muss/will!

Dann machen wir noch ein paar weitere Angaben:



Wichtig. Bei Gateway ID geben wir zuerst eui- ein und dann die Ziffern aus unser darüber liegenden Gateway EUI. Das muss genau gleich sein (ohne die Leerzeichen natürlich), sonst funktioniert das Gateway nicht. Bei Gateway name dürfen wir dann endlich ein wenig kreativ sein und uns einen Namen für unser Gateway ausdenken, an dem wir es gut wiederkennen. Falls wir irgendwann mal mehr als ein Gateway haben sollten, um sie auseinanderzuhalten.

Dann überprüfen wir nochmal alles, ob auch alles genau stimmt - letzte Gelegenheit Fehler zu korrigieren - und klicken dann auf Register gateway ganz unten.

Jetzt bleibt abzuwarten und zu hoffen, dass die Daten auf Gateway und TTN übereinstimmen und akzeptiert werden und das aus dem This gateway has not made any connection attempts yet. rechts irgendwann in Bälde ein "Gateway status mit Connection stats" wird, weil unser Gateway den Weg zum TTN gefunden hat. Und dafür müssen die Daten eben exakt überstimmen bzw. auf die geschilderte Weise ergänzt werden.

Bis es soweit ist, kann man die Geo-Koordinaten des Gateways unter Location eintragen. TTN erwartet die Koordinaten im "Dezimalgrad-Format". Mit dem Koordinaten-Umrechner auf GPS-Cache.de kann man aber fast jedes Format nach dahin umrechnen.

Sind schon Koordinaten hinterlegt, vielleicht in der Nähe von Shenzhen, China - da wo der Hersteller seinen Sitz hat - muss man erst Remove location data anklicken, bevor man die Koordinaten mit Set location manually manuell eingibt. Sonst werden die nicht überschrieben.

Und wenn das unser Gateway connected hat und online ist, kann man dann sein Gateway auf der Karte wiederfinden mit seiner Gateway-ID, etwa "eui-2025081512345678". Einen sprechenderen Namen kriegt man leider nicht hin mit diesem Gateway.

Da unser Gateway ja dann der öffentlichen LoRaWAN-Infrastruktur zur Verfügung steht, können auch andere ihre LoRaWAN-Messages über unser Gateway versenden. Und die wollen vielleicht sehen, wo sich das Gateway genau befindet, um evtl. etwas näher heranzufahren und einen besseren Empfang zu haben.

Und wenn viele mitmachen, gibt es vielleicht iregendwann ein flächendeckendes Netz von LoRaWAN-Gateways, so dass man überall seine LoRaWAN-Messages absetzen kann. Wie wäre es dann mit einen Endgerät mit GPS-Chip versteckt am Fahrrad? Um seine Radtouren aufzuzeichnen? Oder zu sehen, wo sein Fahrrad ist, wenn es mal gestohlen wurde? Da gibt es reichlich Anwendungsfälle. Allerdings muss sich ein LoRaWAN-Gateway in Empfangsreichweite befinden. Aber da LoRa ja eine hohe Reichweite hat, reicht alle paar Kilometer ein Gateway.

Ein Gateway muss was zu tun haben...


Okay, TTN sagt: unser Gateway ist online. Aber so richtig getestet haben wir es ja noch nicht. Für einen Test brauchen wir mindestens ein Endgerät, das eine Message absetzen will.

Also krame ich meinen TTGO T3 LoRaWAN OLED ESP32 heraus, auf dem noch PAXCNT (PaxCounter) installiert ist. Das zählt die Smartphones in der Nähe und schickt den PAX über ein LoRaWAN-Gateway an das TTN für die Weiterverarbeitung.

Im Source-Code im File loraconf.h finde ich die Konfiguration wieder, die ich noch für TTN brauchen werde:
static const u1_t DEVEUI[8] = { 0xC0, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }; static const u1_t APPEUI[8] = { 0x70, 0xB3, 0xD5, 0x7E, 0xD0, 0x01, 0xB9, 0x4E }; static const u1_t APPKEY[16] = { [16 Bytes] };

Eine Applikation auf TTN anlegen

Als Erstes brauchen wir für unsere Endgeräte eine Application. Die könnte z. B. in unserem Fall "Personenzählung" oder in einem anderen "Gewächshäuser" heißen. Die Application ist dazu da, mehrere Endgeräte logisch in einer Gruppe zusammenzufassen.

Wir klicken also in unserer TTN-Console auf Applications und dann oben rechts auf Add application und füllen dann die Felder aus:



Wählen wir die Application gleich aus. Links sehen wir ein Menü.

Ein End device auf TTN anlegen

Dort wählen wir End devices und klicken dann wieder rechts oben auf Register end device. Dann füllen wir zuerst den allgemeinen Kram aus:



Für die Provisioning information brauchen wir die Daten aus dem Source-Code: DEVEUI, APPEUI und APPKEY.

Wir können hier auch auf die Daten zugreifen, die unser Gateway empfangen hat. Denn bei der Anmeldung werden DEVEUI und APPEUI übertragen. Der APPKEY hingegen ist geheim und die Payload (die eigentlichen Nutzdaten) werden mit diesem verschlüsselt, damit nicht einfach jeder Gateway-Betreiber sehen kann, was da für Messages übertragen werden. Die Messages sind so verschlüsselt und bleiben geheim.

Um die Gateway-Daten einzusehen, gehen wir (am besten in einem zweiten Tab) auf Gateways, wählen unser Gateway aus und dann auf Live data. Dort sehen wir bei einer Anmeldung des PaxCounters unter den letzten Einträgen:



Dort können wir die Daten ins Clipboard kopieren und uns ein bisschen Tipparbeit sparen. Geben wir also die Daten ein. Bitte nicht vertippen, sonst funktioniert nichts und wir müssen wie bei TTN derzeit noch üblich löschen und neu anlegen.



Unser APPEUI aus dem Source-Code entspricht also der JoinEUI auf TTN und DEVEUI ist DevEUI. Der APPKEY und der AppKey müssen übereinstimmen. Entweder den APPKEY aus dem Source-Code bei TTN eintragen. Oder bei TTN einen neuen AppKey generieren und dann im Source-Code eintragen und dann neu kompilieren. Die DevEUI muss natürlich für jedes Endgerät anders sein. Da man dann sowieso pro Gerät neu kompilieren muss, kann man die anderen Werte auch ändern. Das wäre ein bisschen sicherer, aber bei so profanen Daten wie bei uns ist das eher egal.

Dann klicken wir auf Register end device und ab dem Zeitpunkt kennt das TTN unseren PaxCounter und kann ihn zuordnen. Wählen wir unseren ttgo-paxcnt-1 gleich mal aus, dann sehen wir gleich ein paar Daten:



Hier sehen wir, ob unser PaxCounter "durchgekommen" ist und ob er sich verbunden hat und wenn ja, mit welcher Empfangsstärke.



Hier sehen wir die letzten dekodierten Nutzdaten. Allerdings steht hier noch nur "{}" also nichts. Damit hier etwas steht und wir eine brauchbare Message haben, müssen wir noch ein wenig was tun. Da kommen wir gleich zu. Werfen wir zuerst einen Blick in See in live data Hier sollten wir folgende Zeilen finden:



Dies ist die Client-seitige Bestätigung vom PaxCounter des Joins ins TTN.



Und dies ist eine Message, also die Übertragung des Counters ansich. Die "01 00" sind die Nutzdaten. Diese zwei Bytes haben die Byte-Order Low/High und den Wert 1. Der PaxCounter stand also auf 1.

Damit wir diese 1 auch wirklich angezeigt bekommen und nicht nur ein "{}", müssen wir noch etwas tun.

Message Storage aktivieren

Das ist ein easy Schritt. Einfach den Message storage per Klick aktivieren und wir haben einen Platz, wo unsere Messages landen. Hier sehen wir dann alle Messages, die von unserem PaxCounter verschickt worden sind. Das geschieht immer, wenn sich der PaxCounter ändert. Bei mir steht schon etwas drin:



Die 1. Zeile ist das Resultat ohne Payload-Formatter. Die 2. Zeile das Resultat des Standard Payload-Formatters. Und die 3. Zeile ist das Resultat mit unserem eigenen, angepassten Payload-Formatter. Den legen wir jetzt an. Da wollen wir hin.

Einen Uplink payload formatter definieren

Klicken wir links im Menü (unter Applications) auf Payload formatters, und dann auf Uplink. Wir nehmen hier die Perspektive des Endgerätes ein. Uplink heißt also vom Endgerät zum TTN und Downlink ist die andere Richtung: vom TTN zum Endgerät.

Ändern wir dann den Default uplink payload formatter wie folgt:

function decodeUplink(input) { const bytes = input.bytes; return { data: { pax: bytes[1]*256 + bytes[0] // zwei Bytes: Low[0], High[1], "01 00" ist 1 und nicht 256. } }; }
Kurz zur Erklärung: Das Mini-Script holt sich die Eingabe in die Variable bytes. Dann bewertet es das erste Byte [0], das reinkommt mit der Wertigkeit 1 und das zweite Byte [1] mit der Wertigkeit 256, damit aus "01 00" "00*256 + 01" wird und die Zahl dann passt und 1 ist und nicht 256. Dieser Wert wird dann zusammen mit "pax" als Data definiert.

Und schon haben wir vernünftige Messages. Für jede haben wir ein Datum und eine genaue Uhrzeit. Und den PAX-Wert, so dass wir den Verlauf entsprechend sehen können. Naja, fast. Denn es werden nur die letzten 10 Werte angezeigt. Zum Testen reicht das.

Wenn wir die Werte aber weiterverarbeiten wollen, etwa um eine Verlaufskurve in Excel zu machen, dann brauchen wir natürlich alle Werte. Das geht mit Download. Für Excel und Datenbankimport empfehle ich CSV, wer in seinen Business-Programm lieber JSON benutzt: auch das geht. CSV ist aber kompakter.

Das TTN speichert Messages für 90 Tage, danach werden sie gelöscht und sind verloren. Man muss also regelmäßig seine Messages herunterladen und sich merken, wann man das das Letzte mal gemacht hat. Das geht ja gut nach dem Zeitstempel. Man muss nur dran denken, nicht dass man dann manche Daten zweifach in der Datenbank hat, weil sich der Inhalt des Downloads überschneidet.

Endlich fertig!

Für normale Anwendungen reicht das TTN-Message-System schon aus. Wer allerdings sofort auf Ereignisse seiner LoRaWAN-Engeräte reagieren will, der muss noch einen Schritt weiter gehen und Webhooks definieren. Damit kann man sich dann zum Beispiel den PaxCounter live auf seinem Always On Display anzeigen lassen. Oder einen Alexa Skill programmieren. Dann kann man seinen Echo Dot fragen, wieviele Leute gerade in der Kantine Schlange stehen.

Aber das ist ein weiteres Thema, dass ihr in meinem Artikel The Things Network Konfiguration: Mit Webhooks Messages an den eigenen Webserver weiterleiten nachlesen könnt.

Youtube-Video

Über die ganze Konfigurations-Orgie gibt es auch ein Video von mir, wo ich noch einmal einen Großteil der Einstellungen hier demonstriere:


Weiterlesen...

Im Artikel LoRaWAN-Kommunikation mit dem LR1262 Dev.-Board (RP2040) und einem Single-Channel Gateway erkläre ich, wie ich mit eigenem Entwicklungs-Board und eigenem Gateway LoRaWAN-Nachrichten über das The Things Networks an meinen Webserver verschicke.



Quellen, Literaturverweise und weiterführende Links

  1. Wikipedia: LoRa / LoRaWAN
  2. The Things Network
  3. GitHub-Seite von Things4U
  4. GitHub-Projekt ESP-1ch-Gateway von Things4U
  5. Produktseite Elecrow LoRaWAN Gateway Module
  6. GW1C-Firmware Binary V2