LoRaWAN UDP Packet Forwarder 1
17.12.2024
Elektronik | Funk | Software
Der Technik-Blog
Damit Daten von einem Arduino, ESP32, TTGO etc. über ein LoRa Modul via LoRaWAN an TTN gesendet werden können, muss zuvor eine entsprechende Konfiguration bei TTN angelegt werden. Dieser Artikel bezieht sich auf die Einrichtung eines Gerätes oder Sensors bei TTN (The Things Network) im APB Mode. Da selbst gebaute Sensoren keine eigenen Schlüssel vorinstalliert haben, werden sämtliche notwendige Schlüssel von TTN bzw. vom Anwender generiert. Die in The Things Network eingerichteten Geräte sind anschließend mit allen aktiven Gateway, dass zu TTN kommuniziert, kompatibel.
APB bedeutet "Activation by Personalisation" auf Deutsch übersetzt "Persönliche Aktivierung". Dabei werden alle Sitzungsschlüssel und die Konfiguration statisch im Gerät gespeichert. Sowohl OTAA als auch ABP unterstützen bidirektionale Verbindungen. Es ist also möglich, dass über TTN Daten an das Endgerät in bestimmten Zeitfenstern gesendet werden können. Ein großer Vorteil von ABP ist die Kompatibilität zu jedem Gateway, vor allem speziell auch zu Single-Channel-Gateways. Außerdem reicht der Simplex-Betrieb aus, um Sensordaten an TTN zu senden. Bei OTAA gibt es einen "Join-Request", wo das Endgerät mit dem Gateway bzw. TTN bidirektional kommunizieren muss, damit die Sitzungsschlüssel ausgetauscht werden können. Auch der Frame Counter wird über diesen Join-Request immer zurückgesetzt. Das Gateway muss in diesem Fall das Endgerät erreichen können. Bei Single-Channel und Dual-Channel Gateways funktioniert dies nur, wenn dies vom Gateway unterstützt wird und vor allem nur, wenn die richtigen Frequenzen eingestellt sind. Daher wird die höchste Kompatibilität nur mit ABP erreicht. Nachteile gibt es im Gegensatz zu OTAA bei der Sicherheit, automatischer Frequenz und SF-Optimierung (ADR) sowie bei der Energieeffizienz
Damit ein Gerät mit TTN kommunizieren kann, wird ein entsprechender Account benötigt. Anschließend muss eine neue Applikation erstellt werden, wo die einzelnen Geräte registriert werden können. Ein eignes Gateway wird grundsätzlich nicht benötigt, da eine Kommunikation über alle aktiven Gateways möglich ist. Ein eigenes Gateway ist grundsätzlich sehr zu empfehlen, da man als Anfänger gerade dadurch auch sehr viele zusätzliche Informationen bekommt, die bei der Fehlersuche hilfreich sein können. Für ABP reicht auch ein günstiges Single-Channel oder Dual-Channel Gateway wie beispielsweise das Dragino LG-02 aus.
Im ersten Schritt muss bei TTN in der Console unter Applications eine neue Applikation erstellt werden. Die Applikation ist primär für die Datenaufbereitung und Datenweitergabe notwendig. In der jeweiligen Applikation befinden sich anschließend die einzelnen Geräte. Hinweis: Eine Applikation verfügt über mindestens ein Gerät! Es können aber auch mehrere Geräte einer Applikation zugeordnet werden. Es spielt weiters keine Rolle, ob die Geräte von einem oder von verschiedenen Herstellern sind und ob OTAA oder ABP bzw. ein Mix aus beiden Verfahren verwendet wird. Für die Registrierung einer neuen Applikation werden folgende Parameter benötigt:
Appliaction ID: Die Application-ID ist die eindeutige Identifikation der Anwendung. Sie ist frei wählbar und besteht aus höchstens 36 Zeichen sowie nur aus Kleinbuchstaben und Zahlen. Sonderzeichen sind nicht erlaubt!
Description: Hierbei handelt es sich um eine Beschreibung der Applikation. Diese Angabe ist optional.
Application EUI: Die Applikation EUI wird bei einer neuen Registrierung automatisch erstellt. Sie kann später durch eine andere App-EUI ersetzt werden. Außerdem können mehrere App-EUIs einer Applikation zugeordnet werden.
Handler registration: Der Handler kümmert sich um die Weitergabe von Daten. Sofern kein eigener Handler verwendet wird, wird in der Regel in Europa der Handler "ttn-handler-eu"ausgewählt.
Nachdem die Applikation erstellt wurde, können in dieser Applikation die einzelnen Geräte bzw. Sensoren registriert werden. Ein Klick auf "register device" öffnet eine neue Seite, wo folgende Parameter abgefragt werden:
Device ID: Die Device-ID ist die eindeutige Identifikation des Gerätes. Sie ist frei wählbar und besteht aus höchstens 36 Zeichen sowie nur aus Kleinbuchstaben und Zahlen. Sonderzeichen sind nicht erlaubt!
Device EUI: Die Device EUI ist eine eindeutige Kennung für das jeweilige Gerät im Netzwerk. Die Device-EUI besteht aus genau 8 Byte im hexadezimalen Format (0-16, A-F). Bei fertigen Sensoren ist diese Kennung meist schon vom Hersteller vergeben. Bei eigenen Boards wie dem Arduino, ESP32 etc. muss diese Kennung selbst erzeugt werden.
APP Key: Der APP-Key wird zur Verschlüsselung aller Daten verwendet. Je nach Hardware kann dieser auch bereits angegeben sein. Falls nicht oder für Development Boards, bleibt dieses Feld leer. Der Schlüssel wird automatisch von TTN generiert.
APP EUI: Die Application-EUI wurde bereits in Schritt 1 erstellt. Wenn es mehrere APP-EUIs gibt, können diese im Dropdown-Menü ausgewählt werden. Es wird empfohlen, die Standardvorgabe von TTN zu verwenden.
Standardmäßig stellt TTN das Gerät auf OTAA. Unter "Settings" des jeweiligen Gerätes wird die Activation Method von OTAA umgestellt auf ABP. Bleiben die beiden Felder "Network Session Key" und "App Session Key" leer, so erstellt TTN automatisch während dem Erstellen beide Keys. Zusätzlich kann auch gleich der "Frame Counter Check" deaktiviert werden. Mehr dazu bei Punkt 5.
Sobald der ABP-Mode aktiviert wurde, können alle notwendigen Schlüssel von TTN kopiert werden und in die jeweilige Library oder in den Source Code eingebunden werden. Folgende Schlüssel sind für die Verbindung zu TTN im ABP-Mode notwendig:
Network Session Key (NWKSKEY): Der Network Session Key wird für die Kommunikation zwischen Sensor und Netzwerk benötigt. Außerdem wird mit diesen Key die Nachricht auf Gültigkeit mittels MIC Check (Message Integrity Code Check) geprüft.
App Session Key (APPSKEY): Der App Session Key ist für die Ver- und Entschlüsselung der Payload zwischen Handler und Endgerät notwendig. Zusammen mit dem NWKSKEY wird die gesamte Verschlüsselung gebildet.
Device Address (DEVADDR): Die Device Address ist für die Adressierung notwendig und wird von TTN automatisch generiert. Es ist die einzige Adresse bei TTN, die nicht vom Anwender geändert bzw. erzeugt werden kann. Die Adresse kann weltweit mehrfach vergeben werden.
Der Frame Counter ist ein beidseitiger Zähler, der mit jeder Nachricht um den Wert Eins erhöht wird. Im Endgerät wird der Frame Counter vor dem Senden um Eins erhöht. TTN erwartet sich beim Empfangen, dass dieser Frame Counter um Eins höher ist als bei der letzten empfangenen Nachricht. Ist dies der Fall, wird die Nachricht akzeptiert, ansonsten abgelehnt. Umgekehrt, wenn TTN zum Endgerät sendet, passiert genau das gleiche im Gerät. Fällt im Endgerät jedoch die Batterie aus oder gibt es einen Reset, wird der Counter zurückgesetzt. Werden jetzt Nachrichten an TTN gesendet, werden diese abgelehnt. Um dies zu vermeiden, kann der Frame Counter dauerhaft deaktiviert oder einmalig zurückgesetzt werden. Die bessere Lösung wäre ein EEPROM oder Flash Speicher, der den aktuellen Frame Counter speichert und nach dem Start wieder der Software zur Verfügung stellt. Generell ist der Frame Counter ein Bestandteil vom Sicherheitskonzept, der beispielsweise verhindert, dass "mitgehörte" Datenpakete erneut abgesendet werden können.
Einstieg in das LoRaWAN (TTN) mit dem Heltec LoRa32 V3 und Einrichtung vom Board in der Arduino IDE
WeiterlesenStarthilfe LoRaWAN - Diese Seite richtet sich an alle Einsteiger, die mit LoRaWAN starten wollen und ihre Sensoren in das IoT-Netzwerkt TTN integrieren wollen
WeiterlesenAEQ-WEB © 2015-2024 All Right Reserved