The Things Network LoRaWAN für Maker und Entwickler

The Things Network (TTN) ist ein globales, offenes, freies und dezentrales Internet der Dinge (IoT). Ziel dieses Beitrags ist es, die Grundlagen zu LoRaWAN zu vermitteln und die durch das TTN gegebenen Möglichkeiten aufzuzeigen und zu nutzen.

Das Internet wurde von Menschen entwickelt, die ihre Netzwerke verbunden haben, um den Datenaustausch zwischen ihren Servern zu ermöglichen. Wie die rasante Entwicklung des Internets verlief, gibt der Wikipedia-Beitrag »Geschichte des Internets« sehr eindrücklich wieder [1]. 

Das Resultat war die enorme Zunahme der Datenkommunikation und exponentielle Innovation, die vollkommen neue Anwendungen hervorgebracht hat. Bild 1 verdeutlicht an Hand der Zahl der installierten Internet Hosts diese Entwicklung sehr deutlich.

Beim Internet der Dinge kommt es nun darauf an, die Datenkommunikation auch zwischen batteriebetriebenen Netzwerkknoten (Nodes) über größere Entfernungen zu ermöglichen. Der Umfang der zu übertragenden Mitteilungen ist dabei eher überschaubar.

The Things Network (TTN) ist ein globales, durch eine Community finanziertes, offenes, freies und dezentrales Internet der Dinge (IoT). Eine globale Community aus rund 13.409 Mitgliedern und über 83 Ländern bildet dieses globale IoT-Netzwerk (Stand: 30.03.2017). Indem das TTN eine Infrastruktur für das IoT bereitstellt, soll der Prozess der Innovationsförderung rund um das IoT unterstützt werden.

Begonnen hat TTN als Experiment in Amsterdam und bekam weltweiten Zuspruch. Über eine Kickstarter-Kampagne wurde die Entwicklung eines TTN-Gateways finanziert, welches kostengünstig und einfach anwendbar das Rollout des TTN beschleunigen soll.

Das TTN ist ein Low Power Wide Area Network (LPWAN) auf der Basis von LoRaWAN und Bluetooth LE. Diese Technologien erlauben es, ohne 3G/4G oder WiFi mit dem Internet zu kommunizieren, und bedeuten keine WiFi-Codes und keine kostenpflichtigen mobilen Abonnements.

Ziel dieses Beitrags ist es, Grundlagen zu LoRaWAN zu vermitteln und die durch das TTN gegebenen Möglichkeiten aufzuzeigen und zu nutzen. Der Datenfluss von einem LoRaWAN-Sensor-Node über ein LoRaWAN-Gateway bis hin zum LoRaWAN-Server und die weiterführende Verwendung der übermittelten Daten werden gezeigt.

Die Entwicklung bei den LoRa-Komponenten ist stark im Fluss. Wer die diesjährige »embedded world« in Nürnberg besucht hat, konnte sich von den zahlreichen Angeboten auf diesem Gebiet überzeugen.

Eine Übersicht zur LoRa-Hardware bietet »The Things Network« [2]. Prinzipiell trifft das aber auf den gesamten LoRa-Markt zu, weshalb hier eine jeweils aktuelle Recherche sehr empfehlenswert ist. Auch das TTN selbst ist einer ständigen Weiterentwicklung unterworfen. 

LoRa vs. LoRaWAN 

Beschäftigt man sich mit LPWAN-Technologien, dann kann es bei den Begriffen LoRa und LoRaWAN sehr leicht zu Unklarheiten kommen. In dem Beitrag »A Primer for LoRa/LoRaWAN« [3] werden die Zusammenhänge in ausführlicher Weise erläutert. Ich versuche es hier mit einer knappen Darstellung.

Die physikalische Schicht (PHY) auf Hard-ware-Ebene eines Kommunikationssystems, definiert die elektrischen Spezifikationen für die Datenübertragung. LoRa bezeichnet streng genommen das Modulationsformat Chirp Spread Spectrum (CSS) von Semtech. Die LoRa-Chips SX1272 und SX1276 verwenden diese Modulationstechnik, um die physikalische Schicht (PHY) des Technologie-Stacks zu bilden. 

Die Datenverbindungsschicht ist verantwortlich für das Erfassen von Änderungen in der PHY-Schicht und das Festlegen eines Protokolls zum Senden von Daten.

LoRaWAN ist ein offener Standard, der das Kommunikationsprotokoll für die LPWAN-Technologie auf Basis eines LoRa-Chips definiert. LoRaWAN definiert die Media Access Control (MAC) in der Datenverbindungsschicht und wird von der LoRa Alliance gepflegt.

Diese Unterscheidung zwischen LoRa und LoRaWAN ist wichtig, weil Unternehmen wie Link Labs eine proprietäre MAC-Schicht (genannt Symphony Link) auf einem LoRa-Chip verwenden, um ein besseres, hybrides Design zu schaffen. Zusammengefasst heißt das: 

LoRa = PHY Layer,

LoRaWAN (oder Symphony Link) = MAC Layer und

LoRa + LoRaWAN = LPWAN Technology Stack. 

Bild 2 zeigt eine schematische Darstellung des LoRa/LoRaWAN-Stacks mit zwei wichtigen Markierungen. 

LoRaWAN hat verschiedene Klassen von End-Devices, die sich bezüglich der Kommunikation vom Server zum End-Device unterscheiden. Für Details muss ich an dieser Stelle auf die Literatur [4] verweisen.

Class A Devices, die wegen ihrer geringen Leistungsaufnahme für batteriebetriebene Knoten am besten geeignet sind, sind nach dem Versenden ihrer Daten nur eine kurze Zeit für Mitteilungen vom Server erreichbar. Ein solches Class A Device werde ich im Anwendungsbeispiel auch verwenden.

Des Weiteren müssen die länderspezifischen ISM-Bänder beachtet werden. ISM-Bänder (ISM steht für Industrial, Scientific und Medical) sind lizenzfreie Frequenzbänder für industrielle, wissenschaftliche und medizinische Anwendungen. Bei diesen Frequenzbändern, die weltweit etwas differieren, ist lediglich die Sendeleistung und die Störung für benachbarte Frequenzbereiche geregelt. In Europa verwenden wir das Band EU 868 (MHz). 

The Things Network 

The Things Network (TTN) steht für zwei Bereiche. Es sind die TTN-Communities und die TTN-Infrastruktur, die Interessenten eine Technologie-Evaluation und die Umsetzung eigener Projekte ermöglichen. 

Lokale Communities übernehmen den Aufbau des Netzwerks in einem genau definierten Bereich (Stadt, Kommune etc.). Verschiedene Akteure sorgen für die erforderlichen Res-sourcen zum Ausbau des betreffenden Netzwerks und setzen unter anderem die folgenden Aufgaben um: 

Realisierung eines Budgets für den Kauf der LoRaWAN-Gateways,

Sicherstellung des Know-hows zur Kon-figuration der Gateways und Anschlussgeräte,

Auswahl der geeigneten Standorte für die Einrichtung der LoRaWAN-Gate-ways sowie

Organisation des Aufbaus eines innovativen Netzwerks von Menschen. 

Communities sind das zentrale Moment bei der Vermittlung des erforderlichen technischen Know-hows, der Entwicklung von Kreativität und der Entdeckung neuer Geschäftsmöglichkeiten.

Im Sinne der Maker-Initiative ist man sich bei TTN bewusst, dass durch die Zusammenführung von Menschen mit unterschiedlichen Fähigkeiten, Fachwissen und Lebenserfahrungen, großartige Innovationen vor einem technisch komplexen Hintergrund möglich sind. Die Kernprinzipien der TTN-Community sind: 

Anerkennung der im TTN-Manifest erwähnten Prinzipien [5] und

Offenheit für jedermann.

Die Menschen sind die Grundlage der Gemeinschaft, nicht die Gateways.

Der regelmäßige soziale Kontakt ist die treibende Kraft der Entwicklung der Community.

Vielfalt ist entscheidend. 

TTN kann mittlerweile weltweit auf ein engmaschiges Netz von Communities verweisen [6]. Um den Status einer offiziellen Community zu erreichen, sind gewisse Mindestanforderungen zu erfüllen, wie mindestens 8 Mitglieder, 2 Gateways, Posts im Forum und Kommunikation über Slack. 

Für diejenigen, die sich für die Geschichte hinter der Zürcher TTN-Community interessieren, sei hier auf einen Beitrag in der NZZ verwiesen [7].

Deutlich mit der Anzahl von Communities einher geht die Anzahl der installierten LoRaWAN-Gateways, die die Brücke zum TTN-Server bilden. Die Verteilung der TTN-Gateways (in Betrieb – blau, geplant – grün, inaktiv – rot) ist unter [8] ersichtlich.

Die Niederlande als Initiator von TTN zeigen eine sehr gute Abdeckung mit TTN-Gateways. Belgien und die Schweiz folgen mit recht guten Werten, während in Deutschland eine hinreichende Abdeckung allenfalls in den Ballungszentren gegeben ist. Wenn dieser Beitrag als Aufruf zum Schließen dieser Lücken verstanden würde, wäre das sicher im Sinne der Initiative insgesamt. 

TTN-Hardware 

Zum Aufbau der kompletten TTN-Infrastruktur bedarf es verschiedener Komponenten. Bild 3 zeigt die Architektur des TTN im Blockdiagramm. 

Für die LoRaWAN-Nodes und die LoRaWAN-Gateways gibt es Hardware von TTN, die über den TTN-Shop (https://shop.thethingsnetwork.com/) bezogen werden kann. Der Einsatz von Hardware von Drittanbietern ist ebenso möglich.

Als wichtiger Baustein des LoRaWAN ist das TTN-Gateway klein, einfach zu installieren und dient als Router zwischen den LoRaWAN-Nodes und dem Internet.

Ein TTN-Gateway ist durch die folgenden Eigenschaften gekennzeichnet: 

Es bietet bis zu 10 km Radius der Netz-abdeckung ,

einfacher Anschluss an WiFi oder an Ethernet,

Bluetooth-4.2-Modem für Verbindungen kurzer Reichweite,

Sicherheit durch die https-Verbindung und eingebettet in das LoRaWAN-Protokoll,

XBEE-Steckplatz für zukünftige Erweiterbarkeit,

die Hard- und Software sind Open Source und

es kann bis zu 10.000 Knoten bedienen. 

The Things Uno und The Things Node 

Von TTN selbst wird mit »The Things Uno« ein Arduino Uno mit LoRaWAN zur Verfügung gestellt. Diese Arduino-Variante beinhaltet ein LoRaWAN-Modul von Microchip. Verschiedene in einem wasserdichten Gehäuse (IP 54) untergebrachte Sensoren, wie Bewegungs-, Licht- und Temperatursensor, eine RGB-LED und eine Taste bilden »The Things Node«. 

Nach Herstellerangaben sollen 3 AAA-Batterien den Strom für über ein Jahr der Nutzung liefern. »The Things Node« ist ein vielseitiges Gerät zum Testen oder Erstellen von IoT-Nodes. Ein intuitives Web-Interface unterstützt die einfache Einrichtung als IFTTT-Knoten. 

The Things Network Server 

Der TTN-Server übernimmt die von regis-trierten LoRaWAN-Gateways übermittelten Mitteilungen und speichert diese temporär, damit ein Anwendungsprogramm diese Daten weiter verarbeiten kann. 

Um im TTN aktiv werden zu können, bedarf es eines Accounts mit den üblichen Angaben. Nach dem Einrichten des Accounts hat man über die Console Zugriff auf den TTN-Server (https://console.thethingsnetwork.org) und kann Gateways registrieren und Applikationen einrichten.

Ein wichtiger Indikator für die ordnungsgemäße Funktion eines Gateways ist der Eintrag Last Seen im Gateway Overview (Bild 4). Dieser Wert sollte ständig aktualisiert werden und so eine bestehende Verbindung zum TTN-Server signalisieren. Bild 5 zeigt einige eingerichtete Anwendungen, wobei ich hier nur auf den TMP36 LoRaWAN-Node eingehen werde.Aus Gründen des erforderlichen Umfangs muss ich die Erläuterungen hier knapp halten. Bei Fragen bietet aber die Dokumentation unter https://www.thethingsnetwork.org/docs/ eine sehr gute Hilfestellung.

Im Bild 6 ist dargestellt, wie der An-wendung tmp36-node-20170216-ck ein Device zugeordnet wird. Das ist ein LoRaWAN-Node.

Ich verwende hier Activation by Personlization (ABP), da das als TTN-Gateway eingesetzte Single- Channel-LoRa-Gateway (auf Basis eine Raspberry Pi 3 mit Dragino Lora/GPS HAT und der Single-Package-Forwarder-Software) keinen Downlink zur Verfügung stellt.

Beim späteren Einsatz des noch erwarteten TTN-Gateways kann dann auf Over-the-Air-Activation (OTAA) umgestellt und die Device-Daten müssen im betreffenden Arduino-Programm des LoRaWAN-Node verankert werden.

Ist der LoRaWAN-Node nun mit der LoRaWAN-Anwendung verknüpft, so werden im Fenster Application-Data die empfangenen Messages zu sehen sein. Neben der codierten Ausgabe ist auch die decodierte Message im JSON-Format ausgewiesen. Im hier gezeigten Implementierungsbeispiel wird nur etwa alle 10 Minuten eine Mitteilung empfangen (Bild 7). 

Eingesetzte Hardware 

Da die TTN-Hardware zwar zur Auslieferung angekündigt, aber zum Zeitpunkt der Erstellung dieses Beitrags noch nicht verfügbar war, habe ich mit alternativen Komponenten gearbeitet. 

An Stelle des TTN-Gateways habe ich hier einen Raspberry Pi 3 mit einem Lo-Ra/GPS-HAT von Dragino eingesetzt. Installation und Inbetriebnahme sind detailliert in [9] beschrieben. Softwareseitig wird die Single-Package-Forwarder- Soft-ware [10] eingesetzt.

Vom Autor der Software wird explizit darauf hingewiesen, dass es sich um eine »proof-of-concept implementation of a single channel LoRaWAN gateway« handelt.

Getestet wurde die Software auf einem Raspberry Pi mit einem Semtech SX1272 Transceiver (HopeRF RFM92W) sowie auch mit einem SX1276 (HopeRF RFM95W). Dieses Gateway ist TTN-kompatibel, aber nicht konform mit LoRaWAN. 

LoRaWAN-Node 

Das Dragino-Lora-Shield für Arduino ist eine ausgezeichnete Basis für erste Experimente mit einem LoRa-Knoten. Das in Bild 8 gezeigte LoRa-Shield bildet eine Brücke zwischen dem RFM95W-Modul und dem Arduino. 

Neben der Hardware steht außerdem noch LoRaWAN-C-Bibliothek (LMiC), eine portable Implementierung der LoRa-MAC-Spezifikation in C von IBM zur Verfügung. Die LMiC-Library unterstützt sowohl die EU-868- als auch die US-915-Variante der Spezifikation sowie Class A und B End-Devices [11].

Diese Bibliothek benötigt die Arduino-IDE-Version 1.6.6 oder höher, da der C99-Modus standardmäßig aktiviert sein muss. Die LMiC-Library kann von Github installiert werden (https://github.com/matthijskooijman/arduino-lmic).

Als Grundlage für meine Experimente habe ich ebenfalls von Github das Programmbeispiel »lora_shield_ttn.ino« von Dragino verwendet und mit einer Sensor-erweiterung versehen (https://github.com/dragino/Lora/tree/master/Lora%20Shield/Examples/lora_shield_ttn).

Zur Messung der Temperatur habe ich einen Temperatursensor TMP36 mit dem Eingang A0 sowie VCC und GND verbunden und einige Codezeilen dem Quelltext des ursprünglichen Programms hinzugefügt.

Auf die Angabe des kompletten Listings des Programms »lora_shield_ttn_tempC.ino« möchte ich an dieser Stelle aus Platzgründen verzichten. Alle in diesem Beitrag erwähnten Programmbeispiele sind unter »https://github.com/ckuehnel/LoRa« abgelegt und stehen zum Download zur Verfügung. 

TTN Mapper für Android und iOS 

Mit Hilfe der App TTN Mapper kann die aktuelle Abdeckung eines Gateways ermittelt werden. Die TTN Mapper App ist für Android und iOS in den einschlägigen Stores verfügbar. Die App abonniert (subscribe) Mitteilungen einer mitgeführten LoRaWAN-Node und verbindet diese mit den GPS-Daten eines ebenfalls mitgeführten Smartphones. 

Der Receive-Signal-Strength-Indicator (RSSI) als Indikator für die Empfangsfeldstärke wird mit einem Geotag versehen, gemappt und auf dem Server ttnmapper.org abgelegt. 

Zugriff auf TTN und Verarbeitung der Daten 

Nun, da die vom Temperatursensor TMP36 erfassten Daten auf dem TTN-Server verfügbar gemacht wurden, möchte ich diese auch weiter verarbeiten. TTN bietet für den Zugriff auf die Daten ein MQTT-Interface an (https://www.thethingsnetwork.org/docs/applications/mqtt/). 

Einen weiteren Raspberry Pi habe ich dazu mit einem MQTT-Client (Mosquitto) und dem JSON-Processor jq (https://stedolan.github.io/jq/) ausgestattet. Unter Raspbian erfolgen die Installation und das anschließende Abonnieren (Subscribe) der LoRa-Messages mit den entsprechenden Kommandos: 

$ sudo apt-get install mosquitto mosquitto-clients

$ sudo apt-get install jq

$ mosquitto_sub -h eu.thethings.network -t ‚+/devices/+/up‘ -u ‚<AppID>‘ -P ‚<AppKey>‘ -v 

Bei der Subscription müssen die betreffende AppID sowie der AppKey eingegeben werden. Bild 9 zeigt die erforderlichen Einträge, die aus der Application Overview (hier nicht gezeigt) entnommen werden können. Teilweise wurden die Einträge nachträglich unkenntlich gemacht. 

Die jeweils vom MQTT-Client empfangene Message wird im File TTN zwischengespeichert und kann von einem Shell-Script anschließend ausgewertet und an den Thingspeak-Server zur Visualisierung gesendet werden. Das Shell-Script ttn.sh wird als Cron-Job aufgerufen, damit jede empfangene Message auch bearbeitet und weitergeleitet wird. Das Script ist ebenfalls in Github abgelegt.Die Präsentation der Daten, die in Thingspeak noch weitgehend konfiguriert werden kann, zeigt Bild 10. Außerdem können die Grafiken auch sehr leicht in eine Website eingebaut werden. Unter »http://ckuehnel.ch/TMP36_LoRa_Node.html« ist ein solches Beispiel abrufbar. 

Schlussbemerkung 

Ziel dieses Beitrags zu LoRaWAN und TTN ist es, die von TTN zur Verfügung stehende Infrastruktur sowie die globale Community vorzustellen und Interesse am Mitmachen zu wecken. TTN lädt Maker und Entwickler ein, diese Technologie zu erschließen, zu verbessern und neue Use Cases zu entwickeln. Wenn die TTN-LoRaWAN-Hardware verfügbar ist, wird das Ausprobieren dieser interessanten Technologie einen weiteren Impuls erhalten. In der Zwischenzeit steht ausreichend Hardware anderer Hersteller zur Verfügung, so dass man nicht warten muss. (fr)