IoT-Systeme scheitern selten an nur einer Funktechnik. Meist entscheidet das Zusammenspiel aus Reichweite, Energieverbrauch, Backhaul, Sicherheitskonzept und Betriebskosten darüber, ob aus einem Pilotprojekt ein belastbarer Betrieb wird. Genau deshalb ist die The Things Conference interessant: Dort treffen LoRaWAN, Cellular IoT, Edge AI und Embedded Systems aufeinander, also genau die Bausteine, die in echten Deployments den Unterschied machen.
Die wichtigsten Fakten für eine schnelle Einordnung
- Termin und Ort: 22. bis 23. September 2026 in Amsterdam, mit einer klaren Ausrichtung auf den praktischen IoT-Einsatz.
- Größenordnung: Mehr als 100 Sessions und eine internationale Community aus 80+ Ländern machen das Event deutlich größer als eine Nischenveranstaltung.
- Inhaltlicher Fokus: Nicht nur LoRaWAN, sondern der gesamte IoT-Stack von Konnektivität über Embedded Systems bis Edge AI.
- Für wen es relevant ist: Für Netzbetreiber, Systemintegratoren, Gerätehersteller, Produktteams und öffentliche Infrastrukturprojekte.
- Worauf es wirklich ankommt: Nicht auf die schönste Demo, sondern auf Skalierung, Wartbarkeit und TCO - also die Gesamtkosten über den Lebenszyklus.
Warum dieses Event für IoT-Teams Gewicht hat
Ich lese diese Konferenz nicht als klassische Messe, sondern als Arbeitsraum für Leute, die aus einer Idee ein tragfähiges System machen müssen. Die offizielle Veranstaltungsseite spricht für 2026 von über 100 Content-Sessions und mehr als 2000 Fachleuten aus über 80 Ländern, und genau diese Mischung aus Breite und Praxisnähe macht das Format wertvoll.
Interessant ist dabei vor allem die Zielgruppe: Integratoren, Entwickler, Produktverantwortliche und Betreiber sitzen dort nicht getrennt voneinander, sondern im selben Raum. Das ist wichtig, weil IoT-Projekte fast immer an der Schnittstelle zwischen Gerät, Netz, Plattform und Betrieb entschieden werden. Wer nur die Funktechnik betrachtet, plant zu kurz. Wer nur auf Business Cases schaut, übersieht die technischen Grenzen. Genau zwischen diesen Polen liegt der praktische Nutzen der Veranstaltung. Damit ist klar, warum die Konferenz mehr ist als eine Produktschau. Entscheidend ist jetzt, welche Themen sie tatsächlich abdeckt.
Welche Themen dort wirklich zählen
Der Mehrwert liegt nicht in einem einzelnen Schlagwort, sondern im Zusammenspiel der Themen. Die Konferenz behandelt den IoT-Stack so, wie er in echten Projekten aussieht: von der Konnektivität bis zur Auswertung, von der Hardware bis zum Betrieb.
| Thema | Wofür es im Projekt wichtig ist | Was du daraus mitnehmen solltest |
|---|---|---|
| LoRaWAN | Geeignet für Sensoren mit kleinen Datenmengen, großer Reichweite und langer Batterielaufzeit. | Wenn du seltene Messwerte statt Dauerstrom brauchst, ist das oft die ökonomischere Wahl. |
| Cellular IoT | Nützlich für mobile Assets, verteilte Standorte und Projekte, die auf bestehende Mobilfunknetze setzen. | Gut, wenn Abdeckung und Mobilität wichtiger sind als die absolute Sparsamkeit beim Energieverbrauch. |
| Edge AI | Analysiert Daten näher am Gerät und reduziert damit Latenz und Datenvolumen. | Hilfreich, wenn nicht jede Rohdatenmenge in die Cloud muss. |
| Embedded Systems | Bestimmen, wie zuverlässig ein Gerät startet, misst, aktualisiert und im Feld überlebt. | Hier entscheidet sich oft, ob ein Prototyp später wartbar bleibt. |
| Energy Harvesting | Gewinnt Energie aus Umgebungseinflüssen wie Licht, Vibration oder Temperaturdifferenzen. | Spannend, wenn Batteriewechsel teuer, schwierig oder logistisch aufwendig ist. |
| Sicherheit und Gerätelebenszyklus | Schützt Identitäten, Provisionierung und Updates über die gesamte Laufzeit. | Ohne sauberes Security- und Update-Konzept wird Skalierung teuer und riskant. |
Der Punkt ist nicht, dass jedes Projekt all diese Bausteine braucht. Der Punkt ist, dass man dort schnell erkennt, wie sie zusammenhängen. Genau diese Systemperspektive fehlt in vielen Produktdemos. Wer nur eine einzelne Komponente bewertet, unterschätzt die Komplexität des Gesamtbilds. Und genau daraus ergibt sich die nächste Frage: Was bedeutet das konkret für die Architektur eines IoT-Systems?
Was das für IoT-Systeme praktisch bedeutet
Wenn ich ein IoT-Projekt strukturiere, teile ich es in drei Ebenen: Gerät, Transport und Plattform. Auf der Geräteebene geht es um Sensorik, Firmware, Stromverbrauch und Gehäuse. Auf der Transportebene entscheidet sich, ob LoRaWAN, Mobilfunk oder ein lokales Funknetz wirklich passt. Auf der Plattformebene laufen dann Network Server, Gerätemanagement und Integration zusammen. Ein Network Server ist die Schicht, die LoRaWAN-Nachrichten verwaltet, Geräte authentifiziert und Daten an Anwendungen weitergibt. Backhaul bezeichnet wiederum den Weg vom Gateway ins übrige Netz, also die Anbindung an Internet oder Unternehmenssysteme.
| Kriterium | LoRaWAN | Cellular IoT | WLAN oder BLE |
|---|---|---|---|
| Reichweite | Stark bei weiter Fläche und kleinen Datenpaketen. | Gut für verteilte Standorte und mobile Anwendungen. | Eher lokal und räumlich begrenzt. |
| Energiebedarf | Sehr niedrig, ideal für batteriebetriebene Sensoren. | Mittlerer Bedarf, abhängig von Sendeverhalten und Netzprofil. | Meist höher, vor allem bei dauerhafter Verbindung. |
| Datenmenge | Klein bis moderat. | Moderat, teilweise auch höher. | Je nach Aufbau deutlich höher möglich. |
| Mobilität | Begrenzt, eher für feste Sensoren geeignet. | Sehr gut für bewegliche Assets. | Eher für feste oder nahe Umgebungen. |
| Typische Stärke | Sensorik mit langer Laufzeit und niedrigen Betriebskosten. | Breite Abdeckung und bessere Eignung für unterwegs. | Hohe Datenraten auf kurzer Distanz. |
Für Sensorik mit kleinen Datenmengen ist LoRaWAN oft die sauberere und günstigere Lösung. Für Fahrzeuge, Container oder verteilte Betriebsstandorte ist zellulare Konnektivität häufig robuster. Und wenn ein Use Case ständig große Datenmengen liefert, sind WLAN oder kabelgebundene Varianten meist sinnvoller. Genau deshalb ist die Konferenz so nützlich: Sie zwingt dazu, nicht in Technikschubladen zu denken, sondern in Systemgrenzen. Von dort ist es nur noch ein Schritt zu der Frage, welche Projekte davon am meisten profitieren.
Welche Projekte besonders profitieren
Besonders stark ist der Ansatz dort, wo Daten klein sind, Geräte lange laufen sollen und Wartung teuer ist. Das gilt für viele reale Szenarien, gerade auch in Regionen mit dünner Infrastruktur, verstreuten Siedlungen oder hohen Transportkosten für Serviceeinsätze.
- Landwirtschaft und Umweltmonitoring: Bodenfeuchte, Wetter, Wasserstände oder Bewässerung lassen sich mit wenig Energie erfassen und zentral auswerten.
- Asset Tracking: Container, Werkzeuge, Paletten oder Maschinen können über längere Strecken überwacht werden, ohne dass jedes Objekt eine schwere Datenverbindung braucht.
- Cold Chain und Temperaturüberwachung: Bei Kühltransport und Lagerung zählt nicht Bandbreite, sondern zuverlässige, kleine Statusmeldungen in festen Intervallen.
- Utilities und Smart Metering: Zählerstände, Ausfälle oder Störungen lassen sich effizient melden, wenn das Netz auf viele kleine Telegramme ausgelegt ist.
- Entfernte Standorte und Inselregionen: Genau dort zahlt sich niedriger Strombedarf aus, weil Batteriewechsel, Wartung und Backhaul-Anbindung schnell zum Kostentreiber werden.
Ich würde allerdings klar trennen: Für Video, Live-Steuerung oder Datenströme mit hoher Dichte ist dieser Ansatz nicht gedacht. Dann braucht es andere Netze oder eine hybride Architektur. Der echte Wert liegt also nicht darin, LoRaWAN als Allzwecklösung zu verkaufen, sondern darin, den passenden Einsatzbereich sauber zu erkennen. Und genau an dieser Stelle passieren die häufigsten Fehler.
Typische Fehler bei Planung und Skalierung
Die besten IoT-Projekte beginnen nicht mit der Funktechnik, sondern mit einem präzisen Problem. Wer das umdreht, baut schnell an der Realität vorbei. Aus meiner Sicht sind das die fünf häufigsten Fehler:
- Mit dem Protokoll statt mit dem Use Case starten: Erst die Frage klären, welches Ereignis gemessen oder welche Entscheidung unterstützt werden soll.
- Funkplanung unterschätzen: Reichweite ist kein Versprechen auf der Verpackung, sondern Ergebnis von Standort, Antenne, Gebäudegeometrie und Interferenzen.
- TCO kleinrechnen: Hardware ist nur ein Teil. Installation, Wartung, Ersatzteile, Betrieb und Support laufen über Jahre weiter.
- Sicherheit als Zusatz sehen: Provisionierung, Identitäten und Updates müssen von Anfang an eingeplant werden, nicht erst nach dem ersten Pilot.
- Pilot und Rollout verwechseln: Eine Demo kann beeindruckend sein, aber ein Feldbetrieb braucht Monitoring, Ersatzprozesse und klare Zuständigkeiten.
Ein weiterer Punkt, den viele Teams erst spät sehen, ist OTA - also Over-the-Air-Updates. Ohne das wird ein verteiltes System schnell zum Wartungsproblem. Wer diese Dinge früh klärt, spart sich später teure Umbauten. Genau deshalb lohnt es sich, die Konferenz nicht nur als Event, sondern als Denkanstoß für die eigene Roadmap zu lesen.
Was ich aus der Konferenz in ein echtes Projekt mitnehmen würde
Wenn ich ein Team zu so einem Event schicke, erwarte ich nicht nur Notizen zu Produkten. Ich will Antworten auf ganz konkrete Fragen sehen: Welche Datenrate braucht der Use Case wirklich? Wie oft sendet ein Gerät, und wie lange soll es laufen? Wer betreibt den Network Server, wer patcht die Geräte und wer verantwortet den Backhaul? Und wie sieht die Rechnung nach drei bis fünf Jahren aus, wenn Wartung, Austausch und Support dazugerechnet werden?
Genau darin liegt der Wert dieser Konferenz auch für Unternehmen außerhalb der großen IoT-Hotspots: Sie hilft, zwischen Demo und belastbarer Architektur zu unterscheiden. Für deutsche Teams, für Betreiber in infrastrukturell schwierigen Regionen und für Projekte mit begrenztem Budget ist das die eigentliche Botschaft. Erst den Betrieb denken, dann die Funktechnik auswählen. Dann wird aus einem Messebesuch ein echter Plan für ein System, das im Feld bestehen kann.
