Du hast einen Raumluftsensor wie den Milesight AM307 an der Bürowand, aber keinen eigenen Netzwerkserver und vielleicht noch nicht einmal ein eigenes Gateway. Trotzdem sollen CO2, Temperatur und Luftfeuchte irgendwo ankommen, wo du sie auswerten kannst. Genau dafür gibt es The Things Network, kurz TTN: ein öffentliches LoRaWAN Netz, das von einer Community aus Privatleuten, Hochschulen, Vereinen und Firmen getragen wird. Du legst kostenlos ein Konto an, registrierst deinen Sensor in der Web-Konsole, und sobald irgendein TTN-Gateway in Reichweite seine Funknachricht hört, landen die Daten in deiner Anwendung, zum Beispiel per MQTT oder Webhook.
Wie viele Nachrichten dein Gerät senden darf, ob in deiner Straße überhaupt Empfang besteht und ab wann ein eigener Netzwerkserver sinnvoller ist, entscheidet darüber, ob TTN für dein Projekt passt. Hier kommen die Antworten, mit konkreten Zahlen.

Wie funktioniert The Things Network?
TTN folgt demselben Aufbau wie jedes LoRaWAN Netz: Endgeräte senden kurze Funknachrichten, Gateways empfangen sie und reichen sie über das Internet an einen Netzwerkserver weiter. Der Unterschied liegt darin, wem die Teile gehören. Die Gateways stellen Mitglieder der Community auf, auf dem Dach, im Büro oder im Wohnzimmerfenster. Den Server-Teil betreibt die niederländische Firma The Things Industries. Die Software dahinter heißt The Things Stack; die öffentliche Instanz, auf der TTN läuft, trägt seit Ende 2023 den Namen The Things Stack Sandbox (vorher Community Edition). Es gibt regionale Cluster für Europa (eu1), Nordamerika (nam1) und Australien (au1). Nach eigenen Angaben zählt das Projekt rund 249.000 registrierte Mitglieder in 153 Ländern.
Wichtig für das Verständnis: Ein Sensor ist nicht mit einem bestimmten Gateway gekoppelt. Er sendet einfach, und jedes TTN-Gateway in Hörweite leitet das Paket weiter, egal wem es gehört. Der Netzwerkserver sortiert Duplikate aus, prüft die Integrität und übergibt die Nachricht an deine Anwendung. LoRaWAN verschlüsselt die Nutzdaten Ende-zu-Ende mit einem Schlüssel, den nur dein Gerät und der Anwendungsserver kennen. Der Betreiber des Gateways sieht, dass ein Paket ankam und wie stark das Signal war, aber nicht deine Messwerte.
Daraus ergibt sich das Prinzip des Teilens: Wer ein Gateway bei TTN anmeldet, versorgt nicht nur die eigenen Sensoren, sondern alle TTN-Geräte im Umkreis. Umgekehrt profitierst du von Gateways, die andere aufgestellt haben.
TTN Abdeckung: Gibt es ein LoRaWAN Netz in deiner Nähe?
Die erste Anlaufstelle ist die Gateway-Karte auf der TTN-Website. Sie zeigt registrierte Gateways, die öffentlich sichtbar sein sollen. Aussagekräftiger ist oft TTN Mapper, ein Community-Projekt, bei dem Leute mit einem mobilen Sensor herumlaufen oder -fahren und jeden empfangenen Punkt eintragen. Dort siehst du nicht nur, wo ein Gateway steht, sondern wo tatsächlich Pakete angekommen sind.
Beide Karten sind ein guter Anfang, aber keine Garantie. Ein Gateway kann seit Monaten offline sein, auch wenn es noch auf der Karte erscheint. Vor allem misst TTN Mapper meist im Freien, während dein Sensor vielleicht im Keller oder hinter einer Stahlbetonwand sitzt. Als grobe Orientierung gelten in Städten wenige hundert Meter bis einige Kilometer, auf dem Land mit freier Sicht auch deutlich mehr.
Der verlässlichste Test ist deshalb der praktische: Registriere einen Sensor, bring ihn an den geplanten Ort und schau in der Konsole, ob und mit welcher Signalstärke seine Nachrichten ankommen. Erscheint nichts oder nur sporadisch etwas, bleibt dir der klassische TTN-Weg: ein eigenes Gateway aufstellen. Damit löst du dein Problem und verbesserst nebenbei die Abdeckung für alle in deiner Nachbarschaft.
Wie meldest du ein LoRaWAN Gateway bei The Things Network an?
Am Beispiel des RAKwireless RAK7268V2, eines Indoor-Gateways mit acht Kanälen für EU868, sieht die Anmeldung so aus. Das Gerät hängt per Ethernet oder WLAN am Internet und wird über seine Weboberfläche (WisGateOS 2) eingerichtet. Im Dashboard findest du die Gateway-EUI, eine 16-stellige Hex-Kennung.
In der TTN-Konsole wählst du den Cluster eu1, klickst auf „Register gateway“ und trägst die EUI ein. Dazu vergibst du eine Gateway-ID (nur Kleinbuchstaben, Ziffern und Bindestriche) und wählst den Frequenzplan „Europe 863-870 MHz (SF9 for RX2 – recommended)“. Ein falscher Frequenzplan ist einer der häufigsten Gründe, warum ein Gateway zwar verbunden ist, aber keine Pakete richtig zustellt.
Für die Verbindung zwischen Gateway und Server stehen zwei Wege zur Wahl. Der ältere ist der Semtech UDP Packet Forwarder: Im Gateway stellst du als Server eu1.cloud.thethings.network mit Port 1700 ein, fertig. Er ist schnell eingerichtet, überträgt aber unverschlüsselt und ohne Authentifizierung. Der empfohlene Weg ist LoRa Basics Station. Hier trägst du wss://eu1.cloud.thethings.network:8887 als LNS-Adresse ein, hinterlegst das Root-Zertifikat und einen API-Schlüssel, den du in der Konsole für das Gateway erzeugst. Den Schlüssel siehst du nur einmal, kopiere ihn also sofort.
Nach wenigen Sekunden sollte die Konsole das Gateway als verbunden anzeigen. Die hier vertriebene Variante des RAK7268V2 wird über ein 12-V-Netzteil versorgt. Plane also eine Steckdose am gewünschten Platz ein.
Wie registrierst du einen Sensor in The Things Network?
Sensoren organisiert TTN in Anwendungen (Applications). Lege zuerst eine Anwendung an, etwa „buero-raumklima“. Darin klickst du auf „Register end device“. Der bequemste Weg führt über das LoRaWAN Device Repository: Du wählst Hersteller, Modell, Hardware- und Firmware-Version sowie das Frequenzband aus. Der Milesight AM307 ist dort gelistet. Die Konsole übernimmt dann LoRaWAN-Version, Geräteprofil und, besonders praktisch, einen fertigen Payload Formatter.
Anschließend gibst du drei Kennungen ein: die JoinEUI (früher AppEUI), die DevEUI des Geräts und den AppKey. Diese Werte stehen je nach Hersteller auf dem Gerät, im Begleitdokument oder lassen sich mit der Konfigurations-App des Herstellers auslesen und ändern. Der AppKey muss auf Gerät und Server identisch sein. Ein einziges vertauschtes Zeichen, und der Beitritt scheitert, ohne dass die Konsole dir den Grund verrät. Verwende die Over-the-Air-Aktivierung (OTAA). Die ältere ABP-Methode mit festen Sitzungsschlüsseln macht im öffentlichen Netz mehr Ärger, als sie spart.
Danach schaltest du den Sensor ein oder löst einen Neustart aus. In der Live-Ansicht erscheint zuerst ein Join-Request, dann ein Join-Accept und schließlich das erste Uplink-Paket. Der Payload Formatter ist ein kleines JavaScript, das die Rohbytes in lesbare Felder wie Temperatur, Luftfeuchte und CO2 übersetzt. Ein Hinweis aus dem TTN-Forum: Formatter aus dem Repository werden gelegentlich aktualisiert, und dabei können sich Feldnamen ändern. Wenn deine Anwendung auf bestimmte Namen angewiesen ist, kopiere den Formatter einmal als eigenen Code in die Anwendung, dann ändert er sich nur, wenn du es willst.

The Things Network MQTT: Wie holst du die Sensordaten in deine Anwendung?
The Things Stack bringt einen eigenen MQTT-Broker mit. Du musst also keinen Server aufsetzen, um die Daten abzuholen. Deine Anwendung, ein Node-RED-Flow oder Home Assistant verbindet sich als Client mit eu1.cloud.thethings.network, verschlüsselt über Port 8883 (unverschlüsselt über 1883, was du nur zum Testen nutzen solltest). Der Benutzername ist die Anwendungs-ID mit dem Zusatz „@ttn“, also zum Beispiel buero-raumklima@ttn. Als Passwort dient ein API-Schlüssel, den du in der Konsole unter „Integrations → MQTT“ erzeugst.
Die Uplinks eines Geräts erscheinen auf dem Topic v3/buero-raumklima@ttn/devices/am307-raum-1/up. Mit v3/+/devices/+/up abonnierst du alle Geräte der Anwendung. Jede Nachricht ist ein JSON-Dokument. Die Messwerte stehen unter uplink_message.decoded_payload, daneben findest du Empfangszeit, Signalstärke und die Gateways, die das Paket gehört haben.
Eine Eigenschaft solltest du kennen, bevor du dich darauf verlässt: Der Broker arbeitet nur mit QoS 0 und speichert nichts für dich zwischen. Ist dein Client gerade offline, sind die Nachrichten aus dieser Zeit für ihn verloren. Dagegen hilft die Storage Integration, die Uplinks in der Sandbox allerdings nur 24 Stunden vorhält, oder ein Webhook. Bei einem Webhook schickt TTN jede Nachricht per HTTP-POST an eine Adresse, die du festlegst. Das ist robuster, wenn deine Gegenstelle ein Webserver oder eine Cloud-Funktion ist. Der umgekehrte Weg funktioniert auch: Über das Topic …/down/push stellst du einen Downlink in die Warteschlange, etwa um das Meldeintervall eines Sensors zu ändern. Ausgeliefert wird er erst nach dem nächsten Uplink des Geräts, weil Sensoren der Klasse A nur kurz danach empfangsbereit sind.
TTN Fair Use Policy: Wie viele Nachrichten darfst du senden?
Weil sich alle Geräte die Funkkanäle teilen, begrenzt TTN die Nutzung pro Gerät: höchstens 30 Sekunden Sendezeit (Airtime) im Uplink pro 24 Stunden und höchstens 10 Downlinks pro Tag, Bestätigungen eingeschlossen. Das ist keine Zahl an Nachrichten, sondern Funkzeit. Wie viele Pakete daraus werden, hängt vom Spreading Factor ab, also davon, wie langsam und robust das Gerät sendet. Ein weit entferntes Gerät braucht einen hohen Spreading Factor, und jede Stufe verdoppelt grob die Sendezeit.
Die folgende Tabelle rechnet das für eine Nachricht mit 30 Bytes Nutzdaten durch, eine Größe, die ein Mehrfachsensor schnell erreicht. Die letzte Spalte zeigt die tägliche Sendezeit bei einem Meldeintervall von zehn Minuten, der Werkseinstellung des AM307.
| Spreading Factor | Sendezeit pro Nachricht | Nachrichten pro Tag im 30-s-Budget | Airtime bei 10-Minuten-Intervall |
|---|---|---|---|
| SF7 | ca. 87 ms | ca. 340 | ca. 13 s |
| SF8 | ca. 164 ms | ca. 180 | ca. 24 s |
| SF9 | ca. 288 ms | ca. 100 | ca. 41 s |
| SF10 | ca. 535 ms | ca. 56 | ca. 77 s |
| SF12 | ca. 2,1 s | ca. 14 | ca. 308 s |
Die Tabelle zeigt, wo die Grenze verläuft: Bei guter Verbindung (SF7 oder SF8) passt ein Zehn-Minuten-Intervall bequem ins Budget. Ab SF9 überschreitest du es, bei SF12 um das Zehnfache. Liegt dein Sensor weit vom nächsten Gateway entfernt, verlängere das Intervall auf 20 oder 30 Minuten oder sorge mit einem eigenen Gateway für bessere Verbindung. Lass Adaptive Data Rate (ADR) aktiviert, damit der Server das Gerät so schnell einstellt, wie es der Empfang erlaubt. Verzichte außerdem auf bestätigte Uplinks: Jede Bestätigung ist ein Downlink und frisst eines der zehn täglichen Kontingente. Unabhängig von TTN gilt zusätzlich die gesetzliche Duty-Cycle-Grenze im 868-MHz-Band, meist 1 Prozent Sendezeit pro Stunde.
Ist The Things Network kostenlos?
Ja, für die Netznutzung zahlst du nichts. Konto, Konsole, MQTT-Broker, Webhooks und Payload Formatter kosten kein Geld. Deine Ausgaben beschränken sich auf Hardware: den Sensor und, falls in deiner Gegend kein Empfang besteht, ein Gateway. Ein Indoor-Gateway wie das RAK7268V2 liegt preislich im unteren dreistelligen Bereich und versorgt danach viele deiner Sensoren in Reichweite gleichzeitig.
Kostenlos heißt allerdings nicht, dass TTN für alles gedacht ist. The Things Industries beschreibt die Sandbox ausdrücklich als Umgebung für nicht-kommerzielle Tests und Experimente in kleinem Maßstab. Es gibt keine Verfügbarkeitsgarantie, gelegentliche Ausfälle sind möglich. Die Einstiegsseite von TTN nennt das Netz wegen der Fair Use Policy ausdrücklich ungeeignet für Unternehmen. Für den Hobbykeller oder einen Prototyp passt das, für die Heizungssteuerung eines Mietshauses nicht.
Für den gewerblichen Betrieb bietet The Things Industries mit The Things Stack Cloud eine kostenpflichtige Variante mit Verfügbarkeitszusage. Die Alternative ist ein eigener Netzwerkserver, und damit sind wir bei der letzten Grundsatzfrage.
TTN oder ChirpStack: öffentliches Netz oder eigener Netzwerkserver?
ChirpStack ist ein quelloffener LoRaWAN-Netzwerkserver, den du selbst betreibst: auf einem kleinen Linux-Rechner, in einem Docker-Container oder auf einem gemieteten Server. Es gibt keine Fair Use Policy außer dem gesetzlichen Duty Cycle, keine Abhängigkeit von einem Cluster in der Cloud und keine Frage, ob Daten außer Haus gehen. Der Preis dafür ist Arbeit: Updates, Backups, Zertifikate und Überwachung erledigst du selbst. Außerdem empfängt ChirpStack nur über deine eigenen Gateways. Die Community-Abdeckung von TTN fällt weg.
Die folgende Gegenüberstellung fasst die Unterschiede zusammen, die in der Praxis den Ausschlag geben.
| Kriterium | The Things Network | ChirpStack (selbst betrieben) |
|---|---|---|
| Einrichtung | Konto anlegen, sofort startklar | Server installieren und pflegen |
| Abdeckung | Alle Community-Gateways | Nur eigene Gateways |
| Nutzungsgrenzen | 30 s Airtime, 10 Downlinks pro Gerät und Tag | Nur gesetzlicher Duty Cycle |
| Verfügbarkeit | Keine Garantie | So gut wie dein eigener Betrieb |
| Gedacht für | Tests, Hobby, Prototypen | Dauerbetrieb, gewerbliche Projekte |
Für einen einzelnen Standort gibt es noch einen Mittelweg: Das RAK7268V2 hat einen eingebauten Netzwerkserver und kann damit ganz ohne externen Server arbeiten. Die Daten gibt das Gateway dann selbst per MQTT aus. Ein bewährter Ablauf sieht so aus: Du testest Sensoren und Reichweite bei TTN, weil das in einer Stunde erledigt ist. Wenn das Projekt in den Dauerbetrieb geht, ziehst du auf ChirpStack, den eingebauten Netzwerkserver oder eine kommerzielle Lösung um. Gateway und Sensoren nimmst du mit, du registrierst sie nur neu.
LoRaWAN Geräte für The Things Network kaufen: Worauf solltest du achten?
Die wichtigste Regel steht ganz am Anfang: Für Europa brauchst du Geräte für das Frequenzband EU868, sonst sieht dich kein einziges TTN-Gateway. Bei Sensoren lohnt sich ein Blick, ob das Modell im LoRaWAN Device Repository gelistet ist. Dann bekommst du Geräteprofil und Payload Formatter ohne eigene Programmierung. Achte auf ein einstellbares Meldeintervall, damit du bei schwacher Verbindung im 30-Sekunden-Budget der Fair Use Policy bleibst, und auf eine Konfigurationsmöglichkeit für JoinEUI, DevEUI und AppKey.
Brauchst du ein eigenes Gateway, entscheiden Standort und Anbindung: Indoor-Gateways mit Ethernet oder WLAN genügen für ein Gebäude, für Außenstandorte und große Flächen brauchst du ein wetterfestes Modell. Unterstützung für LoRa Basics Station ist ein Pluspunkt, weil die Verbindung zu TTN dann verschlüsselt läuft. Ein eingebauter Netzwerkserver hält dir den späteren Umzug weg von TTN offen.
Wenn du Sensoren oder ein Gateway für The Things Network suchst, findest du passende Modelle in unserer Kategorie LoRaWAN.
FAQ zu The Things Network
Brauche ich für The Things Network ein eigenes Gateway?
Nicht zwingend. Wenn ein TTN-Gateway eines anderen Mitglieds deinen Sensor zuverlässig empfängt, genügen ein Konto und ein registriertes Gerät. Fehlt die Abdeckung, ist ein eigenes Gateway der übliche Weg.
Was ist The Things Stack?
The Things Stack ist die Netzwerkserver-Software von The Things Industries, auf der The Things Network läuft. Die öffentliche, kostenlose Instanz heißt The Things Stack Sandbox. Daneben gibt es kostenpflichtige Varianten als Cloud-Dienst oder zum Selbstbetrieb, die sich an gewerbliche Nutzer richten.
Kann ich Daten aus The Things Network per Webhook abrufen?
Ja. In der Konsole richtest du unter den Integrationen einen Webhook ein und gibst eine HTTPS-Adresse an. TTN schickt dann jede Uplink-Nachricht als JSON per HTTP-POST dorthin. Das eignet sich gut für Webserver und Cloud-Funktionen, die nicht dauerhaft mit einem MQTT-Broker verbunden bleiben sollen.