====== LoRaWAN mit TTN v3 - Quick Start ====== Diese Informationsseite soll dir einen schnellen Einstieg in das Themengebiet LoRaWAN geben. Es kann jedoch nicht deine eigene, ausführliche Recherche ersetzen sondern stattet dich lediglich mit den notwendigsten Grundlagen aus, damit du dich zurechtfindest. Eine weitaus ausführlichere Zusammenfassung findest du unter: [[https://lora-developers.semtech.com/documentation/tech-papers-and-guides/lorawan-class-a-devices/]] ===== The Things Network ===== [[https://www.thethingsnetwork.org|The Thinks Network]] (aktuell Version 3, auch The Things Stack TTS) ist ein globales LoRaWAN-IoT-Netzwerk, das in der Community-Version frei genutzt werden kann und über zahlreiche freiwillige Gateway-Betreiber seine weltumspannende Reichweite erlangt. Das fiktive Unternehmen LIFtOff GmbH betreibt selbst ein solches Gateway. Eine Landkarte mit derzeit aktiven Gateways findet man [[https://www.thethingsnetwork.org/map|hier]]. ===== Kommunikation im TTN – ein Überblick ===== Am Beispiel eines Temperatursensors wird hier der Kommunikationsverlauf Schritt für Schritt nachvollzogen. {{ ::ttnv3.png?nolink | Typische LoRaWAN-Netzwerk-Implementierung }} Bild: Typische LoRaWAN-Netzwerk-Implementierung - Der Temperatursensor (Endgerät) verschickt in regelmäßigen Zeitabständen ein LoRa-Paket, in dem die Messwerte enthalten sind. - Befindet sich der Sensor in Reichweite eines Gateways, dann empfängt dieses das LoRa-Paket. Es überträgt die Daten weiter an den LoRaWAN-Netzwerkserver. Dabei ist es egal, wer das Gateway betreibt, solange es mit dem TTN verbunden ist. - Vom Netzwerkserver wird das Paket an den Applikationsserver weitergeleitet. Dort kann es anhand des beiliegenden Schlüsselmaterials einer bestimmten Applikation zugeordnet werden. - Die Applikation auf dem Applikationsserver verarbeitet die eingegangenen Daten und stellt sie auf verschiedene Arten berreit. - Unter anderm publiziert die Applikation die eingegangenen Daten auf dem MQTT-Broker des TTN. - Dein eigener MQTT-Client auf deinem Node-RED-Server kann das zugehörige Topic abonnieren und erhält dadurch umgehend die eigegangenen Daten. Der ebenfalls abgebildete Join Server spielt eine Rolle bei der Anmeldung von Endgeräten am Netzwerk. ===== Anmeldung von Endgeräten am Netzwerk ===== Endgeräte können auf zwei verschiedene Arten am Netzwerk angemeldet werden. Die einfachere aber auch weniger flexible und weniger sichere Variante ist **Activation by Personalization (ABP)**. Dabei werden auf dem Endgerät und im Netzwerk feste Schlüssel eingetragen (AppSKey, NwkSKey). Diese bleiben über die gesamte Lebensdauer des Gerätes gleich. Die bevorzugte Methode ist **Over-the-Air Activation (OTAA)**. Dabei meldet sich ein Endgerät zuerst beim Join Server. Verläuft die Authentifizierung erfolgreich, können die Sitzungschlüssel (AppSKey, NwkSKey) ausgetauscht und regelmäßig erneuert werden. ===== Schlüssel und Identifier ===== Die wichtigsten Schlüssel und IDs im Umgang mit LoRaWAN-Endgeräten finden Sie hier tabellarisch zusammengefasst. ^ Abkürzung ^ Benennung ^ Erläuterung ^ | AppKey | Application Key | symmetrischer Schlüssel zur Identifikation und Authentifizierung eines Endgerätes; Von ihm werden die Sitzungsschlüssel abgeleitet. | | AppSKey | Application Session Key | symmetrischer Sitzungsschlüssel für die Kommunikation zwischen Endgerät und Applikation | | NwkSKey | Network Session Key | symmetrischer Sitzungsschlüssel für die Kommunikation zwischen Endgerät und Netzwerk | | JoinEUI | auch AppEUI | eindeutige Identifikation des Applikationsservers als Ziel für die Nachrichten des Endgerätes (ggf. zusammen mit der DevEUI); wird auch AppEUI genannt | | DevEUI | | eindeutiger 8-Byte-Identifier zur Identifikation des Endgerätes | | DevAddr | Device Address | nicht eindeutige 4-Byte-Adresse | ===== Die MQTT-Schnittstelle des TTN v3 ===== Wie oben bereits geschildert, stellt eine TTN-Applikation die eingehenden Daten ihrer Endgeräte unter anderem über MQTT bereit. Die Adresse des **Servers** lautet ''eu1.cloud.thethings.network'' und zu **Port** ''8883'' kann eine TLS-verschlüsselte Verbindung aufgebaut werden. Der **Benutzername** setzt sich aus dem Applikationsnamen und der Erweiterung @ttn zusammen. In unserem Fall also beispielsweise: ''liftoff-beispiel@ttn'' Als **Kennwort** wird ein extra erzeugter **API-Key** verwendet. Mit ihm können in der TTN-Konsole bestimmte Berechtigungen verbunden werden, z. B. Uplink Messages zu lesen (vom Endgerät zur Applikation) und Downlink Messages zu publizieren (von der Applikation zum Endgerät). ==== Topics ==== Wie du bereits weißt, sind die Informationen bei MQTT nach Topics gegliedert. Im TTN ist eine feste Struktur vorgegeben. Der erste Teil der Topics, die ein bestimmtes Endgerät betreffen, folgt diesem Schema: ''v3/@ttn/devices//'' {{ ::ttnv3_mqtt-beispiel.png?nolink|}} Dahinter ist dann mit weiteren Verzweigungen die eigentliche Kommunikation nachvollziehbar. Das Topic up enthält die vom Endgerät gesendeten Daten, das Topic down enthält die Topics sent und qeued mit gesendeten und zu sendenden Downlink-Nachrichten und außerdem die Topics push und replace um Downlink-Nachrichten in die Warteschlange einzureihen oder die Schlange damit zu ersetzen. Das Topic für die Uplink-Nachrichten mit den gemessenen Temperaturwerten für den Sensor aus dem Beispiel rechts könnte so lauten: ''v3/liftoff-beispiel@ttn/devices/temp-innen/up'' Der Payload für eine Downlink-Nachricht könnte folgendermaßen aussehen: { "downlinks": [ { "f_port": 1, "confirmed": false, "frm_payload": "MjoxMzoyNSBQTQ==" } ] } Ein besonders hilfreiches Werkzeug ist hier der [[https://mqtt-explorer.com|MQTT-Explorer]]. ===== Downlink-Nachrichten im LoRaWAN ===== Damit der Energieverbrauch bei LoRa-Geräten gering gehalten werden kann, verbringen Sie grundsätzlich den Großteil ihrer Zeit im Schlafzustand. In diesem Zustand sind sie auch nicht in der Lage Downlink-Nachrichten zu empfangen. Dies trifft vor allem auf Klasse-A-Geräte zu. Klasse-B-Geräte bieten zusätzlich regelmäßige Zeitfenster an um Nachrichten zu empfangen und Klasse-C-Geräte sind ständig auf Empfang und daher meist nicht batteriebetrieben. ==== Downlink-Nachrichten bei Klasse-A-Geräten ==== Klasse-A-Geräte können nur Nachrichten empfangen, nachdem sie selbst eine Uplink-Nachricht versendet haben. Deshalb werden Downlink-Nachrichten auch in eine Warteschlange eingereiht. Eine bestimmte Zeit nach dem Ende der Uplink-Nachricht wartet ein Klasse-A-Gerät bis zu zwei mal auf eingehende DownlinkNachrichten. ---- {{ ::ttn_no_rx.png?nolink |Empfangszeitfenster Rx1 und Rx2 wenn keine Downlink-Nachrichten eingehen }} Bild: Empfangszeitfenster Rx1 und Rx2 wenn keine Downlink-Nachrichten eingehen ---- {{ ::ttn_rx1.png?nolink |Empfangszeitfenster Rx1, wenn im ersten Zeitfenster eine Downlink-Nachricht eingeht }} Bild: Empfangszeitfenster Rx1, wenn im ersten Zeitfenster eine Downlink-Nachricht eingeht ---- {{ ::ttn_rx2.png?nolink |Empfangszeitfenster Rx1 und Rx2 wenn im zweiten Zeitfenster eine Downlink-Nachricht eingeht}} Bild: Empfangszeitfenster Rx1 und Rx2 wenn im zweiten Zeitfenster eine Downlink-Nachricht eingeht ---- Ein Gerät sendet erst dann wieder Uplink-Nachrichten, wenn * es im Zeitfenster Rx1 eine Downlink-Nachricht erhalten hat oder * die Übertragung im Zeitfenster Rx2 vollständig ist oder * Rx2 verstrichen ist.