Von The Things Network zu ChirpStack migrieren: Schritt für Schritt zur eigenen LoRaWAN-Instanz

WZ-IT führt chirphost weiter. Aktuelles Hosting ab 129,90 € netto/Monat; Einrichtung und Service Level gemäß Angebot. Frühere Paketpreise, Standortlisten und Kostenvergleiche in diesem datierten Artikel beschreiben das damalige Angebot, nicht die aktuellen WZ-IT-Konditionen. Aktuellen Leistungsumfang ansehen.

The Things Network ist für viele Teams der Einstieg in LoRaWAN, und das völlig zu Recht: kostenlos, weltweite Community, in Minuten startklar. Aber die Sandbox hat klare Grenzen: Die Fair Use Policy erlaubt im Schnitt 30 Sekunden Uplink-Airtime pro Gerät und Tag sowie maximal 10 Downlinks [1][2], und sie ist offiziell nur für nicht-kommerzielle Test- und Experimentiernutzung gedacht [3]. Der Wechsel auf The Things Stack Cloud löst das, koppelt die Kosten aber an die Gerätezahl: ab 230 US-Dollar pro Monat für 1.000 Geräte, als USD-Listenpreis mit Stand August 2026 [4]. Wer stattdessen auf eine eigene ChirpStack-Instanz wechselt, bekommt volle Kontrolle und planbare Kosten. Dieser Guide zeigt in vier Schritten, wie Sie Geräte exportieren, Gateways umstellen und die typischen Fallstricke vermeiden, und er sagt ehrlich, wann Sie besser bei TTN oder The Things Stack bleiben.

Warum Betreiber 2026 aus TTN herauswachsen

Die Fair Use Policy in Zahlen

Die Fair Use Policy der TTN Sandbox ist kein Kleingedrucktes, sie ist die Geschäftsgrundlage des Community-Netzes. Die TTN-Dokumentation nennt 30 Sekunden Uplink-Airtime pro Gerät und 24 Stunden sowie 10 Downlink-Nachrichten pro Gerät und Tag [1]. Der offizielle Fair-Use-Policy-Post des TTN-Teams präzisiert beide Werte: Die 30 Sekunden gelten im Durchschnitt, und in den 10 Downlinks sind die ACKs für Confirmed Uplinks ausdrücklich mitgezählt [2].

Was 30 Sekunden praktisch bedeuten, hängt am Spreading Factor. Die folgenden Werte sind berechnet (10 Byte Nutzlast plus 13 Byte LoRaWAN-Header, EU868, 125 kHz, Coding Rate 4/5) und lassen sich mit dem Airtime-Calculator von The Things Network nachrechnen [16]:

Die Konsequenz: Geräte am Zellrand mit SF11 oder SF12 kollidieren zuerst mit der Policy, und die 10 Downlinks disqualifizieren Confirmed-Uplink-Designs und aktorlastige Anwendungen. Ihr Selbstcheck vor der Migrationsentscheidung: Sendeintervalle und Spreading-Faktoren aus der TTN-Konsole ziehen und gegen die Tabelle halten.

Nicht-kommerziell heißt nicht-kommerziell

Die zweite Grenze ist die Zweckbindung. The Things Industries beschreibt die Sandbox als „free and limited version of The Things Stack" ohne Garantien und ohne SLA, gedacht für „non-commercial, small scale testing and experimentation" [3]. Ein produktives Smart-Metering-Projekt mit Kundenverträgen gehört dort nicht hin, und spätestens ein Audit oder eine Ausschreibung stellt genau diese Frage. Das ist kein Vorwurf an TTN: Das Community-Netz hat LoRaWAN groß gemacht und bleibt für Prototypen und Community-Projekte die richtige Wahl. Es ist nur kein Fundament für kommerziellen Betrieb.

The Things Stack Cloud: fair, aber pro Gerät

Der offizielle Graduation-Path führt zu The Things Stack Cloud. Der kostenlose Discovery-Tier deckt bis zu 10 Geräte und 10 Gateways ab, ohne SLA [4]. Cloud Standard kostet 230 US-Dollar pro Monat inklusive Lizenz für 1.000 Endgeräte, mit 99,9 Prozent SLA und unbegrenzten Gateways; danach staffelt der Preis nach Gerätezahl [4]. Die USD-Listenpreise bei monatlicher Abrechnung, Stand August 2026 [4]:

Jährliche Abrechnung ist günstiger, der Basis-Tier entspricht dann 190 Dollar pro Monat [4]. Das ist ein faires Cloud-Angebot mit SLA, nur eben ein Modell, bei dem die Kosten mit der Flottengröße wachsen. Die grundsätzliche Architektur- und Feature-Gegenüberstellung finden Sie im Beitrag ChirpStack vs. The Things Stack; dieser Guide behandelt den Umzug selbst.

Vor der Migration: die Inventur

Eine saubere Inventur entscheidet über die Migrationsdauer. Diese fünf Punkte gehören auf die Liste:

• Geräteliste mit Schlüsselmaterial: DevEUI, JoinEUI (AppEUI) und Application-Key je Gerät, bei LoRaWAN 1.1 zusätzlich der Network-Key. Root-Keys, die nur beim Hardware-Hersteller liegen, jetzt anfordern, nicht erst am Migrationstag.
• LoRaWAN-Versionen je Gerätetyp: MAC-Version (1.0.2, 1.0.3, 1.0.4 oder 1.1.0) und Regional-Parameters-Revision, wie in der TTN-Konsole hinterlegt.
• Gateways samt Zugriff: Modell, Packet-Forwarder-Typ (Semtech UDP oder Basics Station) und ob die Konfiguration remote oder nur vor Ort änderbar ist.
• Integrationen: Webhooks, MQTT-Subscriber, Payload-Decoder und nachgelagerte Systeme, die nach dem Umzug auf die neuen Endpunkte zeigen müssen.
• Downlink- und Rejoin-Realität: Welche Geräte lassen sich per Power-Cycle oder Kommando neu joinen, welche hängen schwer erreichbar im Feld? Diese Antwort bestimmt, ob Sie mit dem Standardweg OTAA-Rejoin auskommen.

Schritt 1: Zielumgebung aufsetzen

Die Zielplattform ist ChirpStack, ein quelloffener LoRaWAN Network Server unter MIT-Lizenz, geschrieben in Rust, mit Unterstützung für LoRaWAN 1.0.x und 1.1, die Geräteklassen A, B und C sowie Multi-Tenancy. Das Projekt liefert in hoher Taktung: Die aktuelle stabile Version v4.19.0 erschien am 9. Juli 2026, unter anderem mit per-Tenant-DevAddr-Ranges und verbesserter Downlink-Gateway-Auswahl [9]. Ob Sie die Instanz selbst betreiben (PostgreSQL, Redis, MQTT-Broker, Updates, Monitoring) oder als Managed-Instanz beziehen, ist eine Betriebsentscheidung; die Abwägung behandelt ausführlich der Beitrag ChirpStack-Hosting: Managed vs. Self-Hosted. Hardware-Grundlagen für Gateway-Beschaffung und Funkplanung stehen im Leitfaden Privates LoRaWAN-Netzwerk aufbauen.

In der frischen Instanz legen Sie zuerst die Device Profiles an, sie definieren MAC-Version, Regional-Parameters-Revision und Aktivierungsart je Gerätetyp. Handarbeit lässt sich dabei sparen: ChirpStack importiert das lorawan-devices-Repository per Kommandozeile als Device-Profile-Templates [12], aus denen Sie die Profile für Ihre Gerätetypen ableiten.

Schritt 2: Geräte aus TTN exportieren

Für den Export gibt es ein offizielles Werkzeug: ttn-lw-migrate exportiert einzelne Geräte, ID-Listen oder ganze Applications als JSON, konfiguriert über Umgebungsvariablen und die Cluster-Adresse, etwa eu1.cloud.thethings.network:8884 [5]. Die Dokumentation empfiehlt, Kommandos zuerst mit --dry-run zu prüfen (ergänzt um --verbose für mehr Ausgabe) [5]:

export TTS_APP_ID="mein-projekt"
export TTS_APP_API_KEY="NNSXS...."   # API-Key mit Geräte-Leserechten

# Erst der Probelauf:
ttn-lw-migrate application --source tts "mein-projekt" --dry-run --verbose

# Dann der Export als JSON:
ttn-lw-migrate application --source tts "mein-projekt" > devices.json

# Ohne aktive Sessions exportieren (passend zum OTAA-Rejoin):
ttn-lw-migrate application --source tts "mein-projekt" --tts.no-session > devices.json

Seit Version 0.9.0 vom Oktober 2023 beherrscht das Tool den Export aus The Things Stack; aktive Sessions werden dabei standardmäßig mitexportiert und lassen sich mit --tts.no-session ausschließen [8]. Ein Punkt gehört ehrlich dazu: ttn-lw-migrate ist von The Things Industries für Migrationen zu The Things Stack beziehungsweise zwischen TTS-Deployments gebaut. Einen offiziellen TTS-zu-ChirpStack-Importer gibt es nicht. Das exportierte JSON dient auf dem Weg zu ChirpStack als sauberer, vollständiger Datenexport (DevEUI, JoinEUI, Keys, LoRaWAN- und Regional-Version); den Import erledigen Sie über die ChirpStack-Web-UI, bei größeren Beständen über die gRPC-API oder ein kleines Skript.

Schritt 3: Gateways umstellen

Gateways sind Paket-Weiterleiter, die Migration ist deshalb eine Konfigurationsänderung, kein Hardware-Tausch. Die ChirpStack Gateway Bridge unterstützt drei Backends: den Semtech UDP Packet Forwarder (Standard-Bind UDP-Port 1700), ChirpStack Concentratord und Basics Station mit einem WebSocket-Listener auf :3001, optional mit TLS [10]. Konkret heißt das: Beim Semtech UDP Packet Forwarder tragen Sie die Adresse Ihrer Gateway Bridge als Server ein, bei Basics Station stellen Sie die LNS-URI auf den WebSocket-Endpunkt um. Einen eigenen Gateway-Migrationsleitfaden stellt auch The Things Industries bereit [7]; das Prinzip ist dasselbe, es ändert sich der Endpunkt, nicht das Funkverhalten.

Wichtig ist die Reihenfolge. Sobald ein Gateway umzieht, erreichen noch nicht migrierte Sandbox-Geräte in dessen Umgebung das TTN-Netz nur noch über andere Community-Gateways, falls vorhanden. Planen Sie deshalb: erst die Zielinstanz, dann das Gateway, dann die Geräte in Wellen. Bei kritischen Beständen lohnt ein gestaffelter Umzug mit einem zweiten Gateway, sodass beide Netze während der Übergangsphase Coverage haben.

Schritt 4: Geräte in ChirpStack anlegen und neu joinen

Der Standardweg ist der OTAA-Rejoin. Sie legen jedes Gerät in ChirpStack mit DevEUI und passendem Device Profile an und hinterlegen den Application-Key im Tab „Keys (OTAA)", bei LoRaWAN-1.1-Geräten zusätzlich den Network-Key [11]. Danach lösen Sie einen neuen Join aus, per Power-Cycle, Downlink-Kommando auf dem alten Netz oder Rejoin-Funktion der Firmware. Das Ergebnis ist eine frische Session mit sauberen Frame-Countern und korrekten regionalen Parametern aus dem Join-Accept.

Sonderfall Session-Migration

Für Geräte, die sich nicht neu joinen lassen, etwa fest verbaute Sensoren ohne erreichbaren Rejoin-Mechanismus, bleibt die Session-Migration: DevAddr, Session-Keys und Frame-Counter aus dem Export übernehmen und in ChirpStack als Aktivierung setzen, analog zur ABP-Aktivierung über den Activation-Tab oder die API [11]. The Things Industries selbst schreibt dazu wörtlich: „Please keep in mind that migrating active sessions is not recommended." [6] Behandeln Sie diesen Weg als Ausnahme mit erhöhter Sorgfaltspflicht: Frame-Counter müssen exakt fortgeführt werden, der MAC-State passt nie eins zu eins, und RX-Parameter-Differenzen führen zu stillen Downlink-Fehlern.

Die fünf häufigsten Fallstricke

1. MAC-Version und Regional-Revision falsch gesetzt: Das Device Profile muss zur Firmware passen. Eine falsche MAC-Version (1.0.2 statt 1.0.4) oder Regional-Parameters-Revision äußert sich in fehlschlagenden Joins oder MIC-Fehlern und kostet erfahrungsgemäß die meiste Debugging-Zeit.
2. Key-Zuordnung bei 1.0.x vs. 1.1: LoRaWAN 1.0.x kennt einen Root-Key (AppKey), LoRaWAN 1.1 trennt AppKey und NwkKey und teilt die Session-Keys auf [11]. Beim Übertragen aus dem TTS-Export die Felder nicht verwechseln.
3. Frame-Counter bei Session-Migration: Werden die Zähler nicht exakt fortgeführt, verwirft der Server die Frames. Geräte mit 16-Bit-Countern und Reset-Verhalten sind besonders fehleranfällig, ein weiteres Argument für den OTAA-Rejoin.
4. JoinEUI/AppEUI vergessen: Manche Firmware akzeptiert Join-Accepts nur mit exakt der einprogrammierten JoinEUI. Die bei TTN registrierten Werte gehören unverändert in die ChirpStack-Geräteanlage.
5. RX1-Delay-Differenz: The Things Stack konfiguriert das RX1-Delay standardmäßig auf 5 Sekunden, laut Dokumentation wegen latenzstarker Backhauls und des Peerings mit Packet Broker [13]. Die ChirpStack-Region-Konfiguration für EU868 setzt dagegen rx1_delay = 1, einstellbar von 1 bis 15 Sekunden [14]. Session-migrierte Geräte funken weiter mit dem alten 5-Sekunden-Wert, während der neue Server nach 1 Sekunde antwortet: Downlinks und MAC-Kommandos laufen ins Leere. Abhilfe: In der ChirpStack-Region-Konfiguration das RX1-Delay auf 5 Sekunden setzen oder die Geräte schlicht neu joinen lassen.

Sandbox, Staffel oder Flatrate: die Kosten-Einordnung

Leistungsumfang und Bereitstellung mit WZ-IT abstimmen. Bereitstellung und Vertragsbedingungen werden mit WZ-IT im Angebot vereinbart. Es gibt kein Self-Service-Portal und kein automatisches Testabonnement.

Wann Sie nicht migrieren sollten

Drei Fälle sprechen klar gegen die Migration:

• Sie brauchen fremde Community-Coverage. Wearables, Asset-Tracking quer durch Städte, Projekte, deren Abdeckung von Community-Gateways lebt: Das leistet nur das TTN-Ökosystem. Eine eigene ChirpStack-Instanz sieht ausschließlich die eigenen Gateways.
• Sie brauchen Roaming über Netzgrenzen. Wenn Peering und netzübergreifendes Roaming über das Packet-Broker-Ökosystem ein Muss sind, ist The Things Stack Cloud das passende Zuhause; ChirpStack hat kein globales Settlement-Netz.
• Ihre Flotte ist klein. Für Prototypen, Ausbildung und Community-Projekte bleibt die Sandbox ideal, und bis 10 Geräte und 10 Gateways reicht auch der kostenlose Discovery-Tier der TTS Cloud [4].

Wenn keiner dieser Punkte greift und Limits, Zweckbindung oder Per-Device-Staffel drücken, spricht viel für den Umzug. Die grundsätzliche Plattform-Abwägung jenseits der Migrationsmechanik liefert der Vergleich ChirpStack vs. The Things Stack.

DSGVO und EU Data Act in Kürze

Für DACH-Betreiber hat der Umzug eine Compliance-Seite. LoRaWAN-Nutzdaten können Personenbezug haben, etwa bei Smart Metering oder Präsenzsensorik. Eine dedizierte Instanz in einem deutschen Rechenzentrum vereinfacht die Dokumentation: klarer Auftragsverarbeiter, AV-Vertrag, kein geteiltes Community-Netz im Datenpfad. Das ist kein Compliance-Urteil über TTN oder The Things Industries, die als niederländisches Unternehmen EU-Cluster wie eu1 betreibt; es geht um Kontrolle, Mandantentrennung und Vertragsklarheit. Parallel verschärft der EU Data Act die Anforderungen an Datenzugang und Portabilität bei vernetzten Produkten; die Details samt Frist finden Sie im Beitrag EU Data Act und LoRaWAN. Dieser Abschnitt ist eine technisch-organisatorische Einordnung und kein Rechtsrat; verbindliche Bewertungen gehören in Ihre Datenschutz- und Rechtsberatung.

Ausblick: Migration wird zum Standard-Feature

Der Netzwechsel, den dieser Guide beschreibt, ist heute Handarbeit, aber die Branche hat das Thema offiziell auf der Agenda. Die LoRa Alliance hat am 1. Juni 2026 eine 3-Jahres-Roadmap vorgestellt, die für 2026 ausdrücklich „new features for supporting migration of IoT-connected devices from one network to another" ankündigt [15]. Migration zwischen LoRaWAN-Netzen soll damit vom Projekt zur Standardfähigkeit werden. Auf der Zielplattform passiert parallel viel: Nach v4.18.0 vom 11. Mai 2026 und v4.19.0 vom 9. Juli 2026 lief Ende Juli bereits der Test von v4.20.0 [9]. Und der Betreibermarkt konsolidiert sich rasant, wie die Netmore-Actility-Übernahme zeigt; warum das für die Kontrollfrage relevant ist, analysiert der Beitrag Netmore übernimmt Actility. Wer den Umzug jetzt sauber plant, profitiert später doppelt: von den kommenden Standard-Features und von einem Stack, der schon heute portabel ist.

Fazit

Die Migration von The Things Network zu ChirpStack ist kein Hexenwerk, sondern ein planbarer Prozess in vier Schritten: Inventur und Zielumgebung, Geräte-Export mit ttn-lw-migrate, Gateway-Umstellung auf die Gateway Bridge, dann OTAA-Rejoin in Wellen. Der Rejoin ist der Standardweg, die Session-Migration bleibt der dokumentierte Sonderfall mit RX1-Delay-Vorsicht. Bleiben sollte, wer Community-Coverage oder Packet-Broker-Roaming braucht oder mit 10 Geräten im Discovery-Tier gut fährt. Migrieren sollte, wer kommerziell betreibt, an Fair-Use-Grenzen stößt oder der Per-Device-Staffel eine Flatrate vorziehen will: mit eigener Instanz, eigenen Keys und eigener Datenhaltung.

Was der laufende Betrieb einer eigenen Instanz umfasst, steht auf der Seite LoRaWAN Network Server mieten, die Compliance-Seite dazu unter Sicherheit und Datenstandorten.

The Things Network, The Things Stack, The Things Industries, LoRa, LoRaWAN und LoRa Alliance sind Marken ihrer jeweiligen Inhaber. ChirpStack ist ein unabhängiges Open-Source-Projekt; chirphost ist nicht mit The Things Industries oder der LoRa Alliance affiliiert. Nennungen dienen ausschließlich der sachlichen Einordnung.

Quellen

1. The Things Network Docs: Duty Cycle und Fair Use Policy
2. TTN-Forum: Fair Use Policy explained (offizieller Post des TTN-Teams)
3. The Things Industries Docs: The Things Stack Sandbox (Konzept und Zweckbindung)
4. The Things Industries: The Things Stack Plans (Preise und Tiers)
5. The Things Industries Docs: Export Devices from The Things Stack (ttn-lw-migrate)
6. The Things Industries Docs: Migration FAQ (Session-Migration nicht empfohlen)
7. The Things Industries Docs: Gateway Migration
8. GitHub: TheThingsNetwork/lorawan-stack-migrate, Changelog (tts-Quelle seit v0.9.0, --tts.no-session)
9. ChirpStack: GitHub Releases (v4.19.0 vom 09.07.2026, MIT-Lizenz)
10. ChirpStack Gateway Bridge: Dokumentation (Backends und Konfiguration)
11. ChirpStack Docs: Devices (OTAA-/ABP-Keys und Aktivierung)
12. ChirpStack Docs: Device-Profile-Templates (Import des lorawan-devices-Repos)
13. The Things Industries Docs: Device MAC Settings (RX1-Delay-Default 5 s)
14. ChirpStack: region_eu868.toml (rx1_delay-Default 1 s)
15. LoRa Alliance: 3-Year Roadmap for Scaling LoRaWAN Globally (01.06.2026)
16. The Things Network: Airtime Calculator