Shelly ThreadLink: Wird Thread zum lokalen IP-Netzwerk für Smart Homes?

Shelly ThreadLink verwandelt Thread nicht in ein IP-Netzwerk – Thread basiert von Anfang an auf IPv6. Geändert wird, wie Shelly dieses Netzwerk nutzen möchte. Anstatt Thread hauptsächlich für Matter zu reservieren und Hersteller-APIs, Cloud-Konnektivität sowie erweiterte Funktionen über WLAN bereitzustellen, soll ThreadLink mehrere dieser Pfade über dasselbe stromsparende Mesh-Netz übertragen.

Damit ist ThreadLink interessanter als eine weitere Ankündigung zur Matter-Kompatibilität. Wenn der Ansatz wie versprochen funktioniert, könnte Thread zur stromsparenden IP-Schnittstelle eines Smart Homes werden: Relais, Schalter, Sensoren und Steuerungen kommunizieren über Thread, während Home Assistant, Server, WLAN-Geräte und Ethernet-Systeme weiterhin Teil des größeren lokalen Netzwerks bleiben. Die Firmware ist jedoch noch nicht verfügbar – Shelly plant das Opt-in-Update derzeit ungefähr drei Monate nach der Ankündigung vom 3. September.

Was ist Shelly ThreadLink?

ThreadLink ist eine kommende alternative Firmware für berechtigte Shelly-Gen4-Geräte, die deren Thread-fähiges Funkmodul als umfassendere IP-Verbindung nutzt, anstatt es hauptsächlich auf einen einzigen Anwendungspfad zu beschränken.

In seiner offiziellen ThreadLink-Ankündigung erklärt Shelly, dass die Firmware IPv6-Netzwerke über Thread ausführen und dabei TCP sowie RPC-/UDP-Kommunikation unterstützen wird. Das gleiche stromsparende Funkmodul soll Folgendes übertragen:

• Matter-Konnektivität,
• Shelly-Cloud-Datenverkehr,
• Shelly-RPC- und API-Kommunikation,
• direkte Geräte-zu-Gerät-Steuerung,
• Konfiguration und Diagnose,
• und eine tiefere Home-Assistant-Integration.

Die entscheidende architektonische Änderung sieht folgendermaßen aus:

HEUTIGES GÄNGIGES MODELL

                    Matter
                      |
                    Thread

Shelly-Gerät ───── WLAN ───── Shelly-API
       |
       └─────────── WLAN ───── Cloud


THREADLINK-RICHTUNG

                    Matter
                      |
Shelly-API ─────── Thread ───── Cloud-Pfad
                      |
                  Lokales P2P

Anstatt für die herstellerspezifische Seite des Geräts WLAN vorauszusetzen, während Thread Matter überträgt, möchte Shelly Thread selbst als IP-Transport für mehrere Anwendungen gleichzeitig nutzen.

Dieser Unterschied ist wichtig, denn Matter und Thread sind nicht dieselbe Netzwerkschicht.

Ist Shelly ThreadLink jetzt verfügbar?

Nein. ThreadLink wurde angekündigt, aber die Produktionsfirmware ist noch nicht allgemein verfügbar.

Shelly zufolge wird es ungefähr drei Monate nach der Ankündigung vom 3. September 2026 als separate, kostenlose Opt-in-Firmware für berechtigte Gen4-Geräte bereitgestellt.

Nutzer wählen pro Gerät, ob es mit der standardmäßigen, auf WLAN ausgerichteten Firmware oder mit ThreadLink läuft.

Das bedeutet, dass ThreadLink derzeit eher als angekündigte Architektur denn als Funktion betrachtet werden sollte, die jeder Gen4-Besitzer heute aktivieren kann.

Das bedeutet auch, dass es zu früh ist zu behaupten, jedes Gen4-Modell werde die Firmware erhalten. Shelly sagt ausdrücklich geeignete Gen4-Geräte, daher ist die endgültige Kompatibilitätsliste entscheidend.

War Thread nicht bereits ein IP-Netzwerk?

Ja. Das ist das wichtigste Missverständnis, das ausgeräumt werden muss.

Thread wurde als IPv6-basiertes Mesh-Netzwerk konzipiert, das 6LoWPAN über IEEE-802.15.4-Funkmodule nutzt. Die Erklärung der Thread Group zur IPv6-Grundlage von Thread führt dieses Designprinzip auf Jahre vor der Entstehung von Matter zurück.

Der Netzwerkstapel lässt sich wie folgt vereinfachen:

ANWENDUNGEN

Matter
Anbieterprotokolle
Andere IP-Dienste
       |
       v
TRANSPORT

UDP / TCP
       |
       v
NETZWERK

IPv6
       |
       v
ADAPTIERUNG

6LoWPAN
       |
       v
FUNK

IEEE 802.15.4

Thread ist daher kein funktionsspezifisches Matter-Funkprotokoll im selben Sinne, in dem viele Menschen es beiläufig beschreiben.

Es handelt sich um ein stromsparendes IP-Netzwerk, das darüberliegende Anwendungsprotokolle übertragen kann.

Matter ist derzeit seine sichtbarste Anwendung im Smart-Home-Bereich für Verbraucher, aber Thread selbst ist so konzipiert, dass es von der Anwendungsschicht unabhängig ist.

ThreadLink macht Thread nicht zu einem IP-Netzwerk. Es nutzt Thread eher so, wie das IP-Netzwerk, das es bereits ist, genutzt wird.

Was ist an ThreadLink tatsächlich neu?

Die Neuerung ist nicht IPv6 selbst. Es ist die Entscheidung, ein IoT-Verbrauchergerät Thread für mehrere Anwendungspfade nutzen zu lassen, die häufig noch von WLAN abhängen.

THREAD ALS MATTER-TRANSPORT

Matter
  |
Thread


             ↓


THREAD ALS NETZWERK

Matter ─────────┐
                |
Shelly-RPC ─────┤
                |
Lokale API ──────┼── IPv6 / Thread
                |
P2P-Logik ──────┤
                |
Cloud-Pfad ─────┘

Das verändert die Rolle des Funkmoduls.

Thread ist nicht mehr nur deshalb nützlich, weil ein anderes Ökosystem ein Relais über Matter steuern kann. Es kann auch Shellys eigenen Anwendungsdatenverkehr, lokale Logik, Konfigurationen, Diagnosen und möglicherweise Softwareupdates übertragen.

Shelly beschreibt ThreadLink als Unterstützung für UDP zur reaktionsschnellen lokalen Kommunikation und vollständige TCP-Unterstützung für größere oder zuverlässigkeitssensible Übertragungen wie Konfigurationsdaten und Diagnosen.

Das ist eine deutlich umfassendere Interpretation dessen, was ein mit Thread verbundenes Verbrauchergerät leisten kann.

Warum stellt Matter nicht jede Shelly-Funktion bereit?

Weil Interoperabilität und die Differenzierung von Anbietern unterschiedliche Probleme lösen.

Matter bietet Herstellern und Smart-Home-Plattformen ein standardisiertes Gerätemodell. Ein Matter-kompatibles Relais kann bekannte Funktionen auf eine Weise bereitstellen, die Apple Home, Google Home, Amazon Alexa, SmartThings oder Home Assistant ohne jeweils ein völlig anderes proprietäres Protokoll implementieren zu müssen, verstehen können.

Diese Standardisierung ist wertvoll.

Ein Anbieter kann jedoch weiterhin Funktionen offenlegen, die über das standardisierte Matter-Modell hinausgehen, etwa:

• detailliertere Energiemessungen,
• Diagnoseinformationen,
• spezielle Relaisfunktionen,
• gerätespezifische Konfiguration,
• Skript- oder Automatisierungsfunktionen,
• erweiterte Statusinformationen,
• und Herstellerverwaltungsfunktionen.

Das führt heute häufig zu zwei parallelen Pfaden:

GERÄT
  |
  +-- Matter
  |      |
  |      v
  |  Standardfunktionen
  |  Apple / Google / HA
  |
  +-- Hersteller-API
         |
         v
     Erweiterte Funktionen
     Diagnose
     Konfiguration

ThreadLink versucht, diese beiden Pfade beizubehalten, ohne zwei verschiedene Netzwerktransporte zu erfordern:

          Matter
            \
             \
              Thread
             /
            /
       Shelly RPC

Shelly zufolge wird ein dediziertes Home-Assistant-Modul den umfassenderen Funktionsumfang von Shelly verfügbar machen, der über das vom Matter-Datenmodell Bereitgestellte hinausgeht.

ThreadLink ist daher relevant, weil Matter als eine Anwendung auf Thread bestehen kann, ohne die einzige Anwendung auf Thread sein zu müssen.

Können Shelly-Geräte einander ohne WLAN steuern?

Nach Shellys ThreadLink-Design: ja.

Shelly zufolge können ThreadLink-Geräte über die Thread-Mesh mithilfe seiner API direkt miteinander kommunizieren, sodass Szenen, Verriegelungen und Automatisierungen Peer-to-Peer ausgeführt werden können.

Wichtig ist der Fehlerpfad.

Shelly zufolge können diese Beziehungen zwischen Geräten fortbestehen, selbst wenn:

• die Internetverbindung ausfällt,
• Shelly Cloud nicht erreichbar ist,
• oder das WLAN-Netzwerk des Zuhauses ausfällt.

Eine einfache Beziehung könnte daher so aussehen:

Wandschalter
     |
   Thread
     |
     v
    Relais

statt immer Folgendes zu benötigen:

Wandschalter
     |
     v
WLAN / Router
     |
     v
Heimserver
     |
     v
WLAN / Router
     |
     v
Relais

Dadurch wird der Serverpfad nicht falsch.

Das bedeutet, dass nicht jede lokale Aktion es verwenden muss.

Benötigt lokale Steuerung weiterhin Home Assistant?

Für einfache Gerätebeziehungen nicht immer. Für eine umfassendere Orchestrierung hat Home Assistant weiterhin eine ganz andere Aufgabe.

Dass ein lokaler Wandschalter ein Relais einschaltet, unterscheidet sich grundlegend von einer Automatisierung, die mehrere Systeme kombiniert.

Logik auf Geräteebene kann Folgendes übernehmen:

• einfache Beziehungen zwischen Schaltern und Relais,
• Verriegelungen,
• einfache Szenen,
• und ein sofortiges Fallback-Verhalten.

Ein Heimautomatisierungsserver eignet sich besser für Logik wie:

WENN

Solarüberschuss > 3000 W

UND

Batterie-Ladezustand > 80 %

UND

der Raum ist belegt

UND

der Strompreis ist niedrig

DANN

Heizungs-, Lüftungs- und Klimaanlagen- / Geräteverbrauch aktivieren

Dieser Ablauf umfasst Energie, Belegung, Preise, Zeitpläne und möglicherweise mehrere Protokolle.

Sie gehört auf eine übergeordnete Orchestrierungsebene. Der umfassendere Trend zur lokalen Verarbeitung durch Home Assistant folgt demselben Prinzip: Geeignete Entscheidungen sollen im Zuhause bleiben, während Cloud-Abhängigkeiten für Workloads reserviert werden, die sie tatsächlich benötigen.

LOKALE STEUERUNG AUF GERÄTEEBENE

Schalter
   |
 Thread P2P
   |
Relais


LOKALE STEUERUNG AUF SERVER-EBENE

Solar ───────┐
Energiezähler ┤
Anwesenheit ────┼── Home Assistant ── Heizung, Lüftung und Klimaanlage
Zeitplan ────┤
Andere IoT ───┘

Lokale Verarbeitung bedeutet nicht immer serverbasierte Verarbeitung.

Ein robustes Smart Home kann lokale Gerätebeziehungen für einfache Aktionen nutzen und den Heimserver auf systemübergreifende Logik, Verlauf, Richtlinien, Dashboards und Zustände konzentrieren.

Wie kann ThreadLink ohne WLAN die Cloud erreichen?

Ein besonders ungewöhnliches Versprechen von ThreadLink besteht darin, dass der Endpunkt ein Thread-Gerät bleiben und dennoch auf Shelly Cloud zugreifen kann.

Das Gerät selbst benötigt für diesen Pfad keine WLAN-Zugangsdaten.

Shelly beschreibt die Architektur wie folgt:

Shelly-ThreadLink-Gerät
          |
          v
     IPv6 / Thread
          |
          v
 Thread-Border-Router
          |
          v
        NAT64
          |
          v
   IPv4-Internetdienst
          |
          v
      Shelly Cloud

Diese Idee passt zur weiteren Entwicklung von Thread. Thread 1.4 hat zusätzliche Arbeiten rund um einen standardisierten Pfad von Thread-Netzwerken zu Internetdiensten formalisiert, einschließlich der IPv6-zu-IPv4-Konnektivität am Netzwerkrand.

Die wichtige konzeptionelle Änderung lautet:

Cloud-Konnektivität muss nicht mehr bedeuten, dass der Endpunkt über WLAN verbunden ist.

Ein Gerät mit geringem Energieverbrauch kann Thread lokal nutzen, während das IP-Routing weiter oben im Netzwerk den Zugriff auf externe Dienste übernimmt.

Das macht ThreadLink nicht zu einer rein lokalen Lösung.

Es zeigt das Gegenteil: Lokale Gerätekommunikation und optionale Cloud-Konnektivität können dieselbe IP-Architektur nutzen.

Was macht ein Thread Border Router tatsächlich?

Ein Thread Border Router verbindet das Thread-Mesh mit dem umfassenderen IP-Netzwerk. Im Wesentlichen ist er ein Router und kein Protokollübersetzer für jeden Smart-Home-Befehl.

Die Erklärung der Thread-Border-Router-Rolle durch die Thread Group macht diese Unterscheidung ausdrücklich.

Traditionelle Smart-Home-Architekturen sehen oft so aus:

Zigbee-Gerät
     |
     v
Zigbee-Netzwerk
     |
     v
Hersteller-Hub
     |
Protokollübersetzung
     |
     v
IP-Netzwerk

Thread verwendet stattdessen IP direkt im Gerätenetzwerk:

Thread-Gerät
     |
 IPv6 / Thread
     |
     v
Border-Router
     |
 IP-Routing
     |
     v
Heimnetzwerk

Der Border Router leitet Pakete zwischen physischen Netzwerksegmenten weiter.

Es muss nicht jeden Anwendungsbefehl von Thread in ein proprietäres LAN-Protokoll übersetzen.

Das bedeutet, dass Home Assistant an anderer Stelle im lokalen Netzwerk betrieben werden kann:

Thread-Gerät
     |
Thread-Mesh
     |
Border-Router
     |
Ethernet-/WLAN-LAN
     |
     +-- Home Assistant
     +-- Heimserver
     +-- Andere IP-Dienste

Ein Matter-Controller und ein Thread Border Router erfüllen daher unterschiedliche Aufgaben. Der Border Router stellt die Netzwerkerreichbarkeit bereit; Matter definiert darüber eine Anwendungs- und Controller-Beziehung. Wenn mehrere Plattformen unabhängig voneinander dieselben Matter-Geräte steuern, führen mehrere Matter-Controller eine separate Vertrauens- und Besitzebene ein, die durch Thread-Routing allein nicht gelöst wird.

Sobald der Datenverkehr das Thread-Mesh verlässt, gelten weiterhin die üblichen IP-Regeln. Die Netzwerkerreichbarkeit von Home Assistant hängt weiterhin von nutzbarer Adressierung, Routing, Richtlinien und einem funktionierenden Rückweg zwischen Controller und Endpunkt ab.

Bedeutet ThreadLink, dass Thread WLAN ersetzen wird?

Nein. Thread und WLAN sind für unterschiedliche Arten von Datenverkehr optimiert.

Die aktuelle Thread-Dokumentation von Home Assistant beschreibt Thread sowohl als stromsparend als auch als bandbreitenarm und damit als besonders geeignet für Geräte, die relativ kleine Datenmengen austauschen.

Ein stromsparendes Relais benötigt nicht die Bandbreite von WLAN.

Eine 4K-Überwachungskamera sollte nicht einfach deshalb über Thread angebunden werden, weil Thread IP-basiert ist.

Thread wird nicht zum neuen WLAN. Es könnte zum stromsparenden IP-Rand desselben Heimnetzwerks werden.

Wird Thread zum stromsparenden Rand des Heim-LANs?

Hier wird ThreadLink interessanter als die einzelne Ankündigung zur Shelly-Firmware.

Ein zukünftiges lokales Netzwerk könnte weniger wie mehrere isolierte Smart-Home-Ökosysteme aussehen und eher wie eine IP-Architektur, die sich über mehrere physische Übertragungswege erstreckt:

                     HEIMSERVER
                          |
                          |
                    HEIM-IP-NETZWERK
                          |
        +-----------------+----------------+
        |                 |                |
     ETHERNET           WLAN            THREAD
        |                 |                |
       NAS             Kameras          Relais
     Server           Telefone           Sensoren
   Workstations          Fernseher            Schalter
                                       Schlösser

Der Endpunkt muss nicht für jedes Gerät dasselbe Funkprotokoll verwenden.

Wichtiger ist, dass die höheren Schichten bei Bedarf über standardmäßiges Routing kommunizieren können.

Das unterscheidet sich grundlegend von dem Versuch, Thread, WLAN und Ethernet um einen einzigen Sieger konkurrieren zu lassen.

Das Smart Home der Zukunft hat möglicherweise nicht nur ein drahtloses Netzwerk. Es könnte eine gemeinsame IP-Architektur über mehrere physische Netzwerke hinweg geben.

Was ändert ThreadLink für Home Assistant?

ThreadLink bietet Home Assistant möglicherweise zwei nützliche Wege zu demselben physischen Shelly-Gerät.

Das Erste ist Standard-Matter:

Shelly-Gerät
      |
Matter über Thread
      |
Thread-Border-Router
      |
Matter-Controller für Home Assistant
      |
Standard-Matter-Funktionen

Der zweite Weg ist der herstellerspezifische Ansatz, den Shelly plant:

Shelly-Gerät
      |
Shelly-RPC über Thread
      |
Thread-Border-Router
      |
Home Assistant
      |
Shelly-spezifische Funktionen

Die offizielle Matter-Architektur von Home Assistant macht die Unterscheidung zwischen Netzwerk- und Anwendungsebene bereits deutlich: Matter ist ein Steuerungsprotokoll auf Anwendungsebene, das je nach Gerät über WLAN, Ethernet oder Thread kommunizieren kann.

ThreadLink baut auf diesem Schichtendesign auf.

Matter kann die Interoperabilität zwischen Ökosystemen ermöglichen, während die Shelly-Integration umfassendere gerätespezifische Funktionen beibehalten kann.

Das ist eine leistungsfähigere Architektur, als Nutzer dazu zu zwingen, zwischen Interoperabilität und erweiterten Herstellerfunktionen zu wählen.

Ist heute wirklich ein einziges Thread-Netzwerk möglich?

Nicht immer. Die heutigen Thread-Implementierungen können noch stärker fragmentiert sein, als es die ideale Architektur vermuten lässt.

Home Assistant bezeichnet seine Thread-Integration derzeit als in Arbeit befindlich und erfasst ausdrücklich die verschiedenen Thread-Netzwerke, die in einem Haushalt vorhanden sind.

Ein Haushalt könnte etwa Folgendes vorfinden:

Apple-Thread-Netzwerk
       |
unterschiedliche Zugangsdaten


Google-Thread-Netzwerk
       |
unterschiedliche Zugangsdaten


Home-Assistant-Thread-Netzwerk
       |
different credentials

Geräte in getrennten Thread-Netzwerken werden nicht automatisch zu einem großen Mesh-Netzwerk, nur weil sie alle Thread verwenden.

Home Assistant kann Nutzern helfen, bestehende Netzwerke zu überprüfen und in unterstützten Fällen einen Home-Assistant-Border-Router mit einem bevorzugten bestehenden Netzwerk zu verbinden. Das Verbraucherökosystem entspricht jedoch noch nicht in jedem Haushalt einem vollständig einheitlichen Thread-Mesh-Netzwerk.

Das ist ein wichtiger Realitätscheck für ThreadLink.

Eine technisch elegante IP-Architektur hängt weiterhin von der Kompatibilität der Border Router, gemeinsamen Zugangsdaten, der Netzwerktopologie und der tatsächlichen Implementierungsunterstützung ab.

Wie verändert Thread 1.4 die Situation?

Thread 1.4 bringt das Ökosystem der Idee eines einheitlichen Netzwerks näher.

Die Thread Group beschreibt eine ihrer wichtigsten Verbesserungen als einfacher nutzbares Mesh-Netzwerk.

Das Ziel besteht darin, dass aktualisierte Geräte und Border Router aus verschiedenen Ökosystemen ein bestehendes Thread-Netzwerk erkennen und ihm beitreten, anstatt unnötigerweise ein weiteres Mesh-Netzwerk zu erstellen.

Thread 1.4 ergänzt oder verbessert außerdem:

• ein standardisierter Weg zur Cloud-Konnektivität,
• Thread über die Infrastruktur,
• Einblick in Netzwerkdiagnose und Fehlerbehebung,
• ökosystemübergreifende Netzwerkkonvergenz,
• und Verbesserungen bei der Inbetriebnahme.

Dies gibt ThreadLink einen breiteren Kontext.

FRÜHERES THREAD

IPv6-Mesh mit geringem Energieverbrauch
      |
Matter wird dominant
Verbraucheranwendung


THREAD 1.4

Bessere Netzwerkkonvergenz
Bessere Border-Router-Infrastruktur
Cloud-Pfad
Diagnose
      |
      v


THREADLINK-IDEE

Matter
Hersteller-API
Cloud
P2P
      |
derselbe IP-Transport mit geringem Energieverbrauch

ThreadLink ist daher kein Beweis dafür, dass jeder Hersteller denselben Ansatz übernehmen wird.

Es ist jedoch ein konkretes Beispiel für die Art von Anwendungsvielfalt, die Threads Netzwerkarchitektur schon immer ermöglicht hat.

Muss jede Smart-Home-Automatisierung über den Heimserver laufen?

Nein. Ein widerstandsfähiges System kann die Logik entsprechend der Komplexität und Wichtigkeit der Aktion verteilen.

Eine einfache Verriegelung benötigt nicht unbedingt eine Server-Rückfrage.

Eine ganzheitliche Energieautomatisierung wahrscheinlich schon.

Diese Trennung kann das Netzwerk widerstandsfähiger machen, da der Ausfall einer Ebene nicht automatisch jede lokale Funktion entfernt. Sie erklärt außerdem, warum der tatsächliche Leistungspfad von Home Assistant Funkmodule, Netzwerke, Broker, Zielgeräte und Speicher umfasst und nicht nur die CPU, auf der Home Assistant ausgeführt wird.

Macht ThreadLink einen Heimserver weniger wichtig?

Dadurch wird der Heimserver möglicherweise als Protokoll-Gateway weniger wichtig, aber klarer als Orchestrierungsebene definiert.

Traditionelle Smart Homes sammelten Bridges an, weil viele Gerätenetzwerke nicht direkt am heimischen IP-Netzwerk teilnehmen konnten.

ALTES MODELL

Zigbee-Geräte ── Hersteller-Hub ──┐
                               |
Andere Geräte ─── Gateway ─────┼── Heimserver
                               |
WLAN-Geräte ─────────────────┘

Eine stärker IP-orientierte Architektur kann anders aussehen:

GERÄTEEBENE

Thread-Geräte
WLAN-Geräte
Ethernet-Geräte
       |
       v

IP-NETZWERKEBENE
       |
       v

STEUERUNGSEBENE

Home Assistant
       |
       +-- Automatisierungen
       +-- Zustand
       +-- Verlauf
       +-- Richtlinien
       +-- Dashboards
       +-- Protokollübergreifende Logik
       |
       v

DATENEBENE

Backups
NAS
Dauerhafter Speicher

Der Server muss nicht mehr jedes Paket durch sich hindurchleiten, um seine Existenz zu rechtfertigen.

Sein Wert ergibt sich zunehmend daraus, den größeren Zusammenhang zu wahren:

• welche Geräte vorhanden sind,
• in welchem Zustand sie sich befinden,
• wie unabhängige Systeme miteinander interagieren,
• was gestern passiert ist,
• welche Automatisierungen ausgeführt werden sollen,
• was passieren soll, wenn ein Dienst ausfällt,
• und wie Konfiguration und Verlauf geschützt werden.

Diese Aufgaben haben unterschiedliche Anforderungen an Speicher und Wiederherstellung. Die Trennung von dauerhaften Home-Assistant-Daten und temporärem Laufzeitstatus erleichtert den Schutz der Datenebene in dieser Architektur erheblich.

Thread verringert den Bedarf an Protokollübersetzung, nicht den Bedarf an Smart-Home-Software.

Das bedeutet auch nicht, dass Home Assistant plötzlich leistungsstarke Hardware benötigt. Die aktuellen Hardwareanforderungen für Home-Assistant-Server bleiben für gewöhnliche Automatisierungen moderat; Kameras, lange Verlaufsdaten, lokale Sprachsteuerung, Datenbanken und zusätzliche Dienste sorgen in der Regel für eine höhere Serverauslastung.

Wenn mehrere dieser Dienste gemeinsam betrieben werden sollen, sollte die Dimensionierung des Smart-Home-Servers auf dem gesamten Service-Stack und nicht auf der Anzahl der Thread-Geräte basieren.

Sollten Shelly-Gen4-Besitzer von WLAN zu ThreadLink wechseln?

Für diese Empfehlung ist es noch zu früh.

Die Firmware ist noch nicht allgemein verfügbar, die endgültige Liste der berechtigten Geräte ist entscheidend, und die tatsächliche Interoperabilität mit bestehenden Thread-Netzwerken und Border Routern muss noch außerhalb von Demonstrationen getestet werden.

Sobald ThreadLink verfügbar ist, sollten Gen4-Besitzer Folgendes prüfen:

• ob das jeweilige Shelly-Gerät dafür geeignet ist,
• ob bereits ein geeigneter Thread Border Router vorhanden ist,
• ob die Thread-Netzwerke im Zuhause vereinheitlicht oder fragmentiert sind,
• ob die erforderlichen Shelly-Funktionen über das neue Home-Assistant-Modul funktionieren,
• ob Cloud-Zugriff benötigt wird,
• ob eine direkte Geräte-zu-Geräte-Logik nützlich ist,
• und ob die bestehende WLAN-Installation bereits zuverlässig funktioniert.

Die richtige Einschätzung für 2026 lautet daher, die Umsetzung zu beobachten, statt eine funktionierende Installation allein aufgrund der Ankündigung umzustellen.

Wird Thread zum lokalen IP-Netzwerk für Smart Homes?

Thread wird wahrscheinlich nicht zum einzigen lokalen Netzwerk in einem Smart Home werden. Es hat jedoch gute Chancen, zur stromsparenden IP-Randebene dieses Netzwerks zu werden.

Ethernet bleibt das natürliche Transportmedium für Server, NAS-Geräte und stationäre Systeme mit hoher Bandbreite.

WLAN bleibt das natürliche drahtlose Netzwerk für Smartphones, Laptops, Kameras, Displays und Geräte, die erheblich mehr Bandbreite benötigen.

Thread eignet sich für die stromsparende Randebene:

• Sensoren,
• Relais,
• Schalter,
• Schlösser,
• Steuerungen,
• und andere Geräte, die relativ kleine Datenmengen austauschen.

Shelly ThreadLink ist interessant, weil es diese Randebene nicht mehr als auf eine einzige Anwendung beschränktes Silo behandelt.

Matter kann eine standardisierte Steuerung innerhalb des Ökosystems ermöglichen.

Shelly RPC kann umfangreichere Herstellerfunktionen bereitstellen.

Die Kommunikation zwischen Geräten kann einfache Aktionen lokal halten.

Ein Border Router kann das Mesh mit dem größeren LAN verbinden.

Home Assistant kann protokollübergreifend orchestrieren.

Auch die Cloud-Konnektivität kann optional bleiben, anstatt zu erfordern, dass sich das Endgerät selbst mit dem WLAN verbindet.

Für Nutzer, die diese Orchestrierungsebene auf einem dedizierten lokalen System wünschen, ist ZimaBoard 2 Smart Home ein Beispiel dafür, den Controller auf einem erweiterbaren, dauerhaft laufenden Server zu betreiben, während Thread Border Router und Endgeräte-Funkmodule getrennte Bestandteile des Netzwerks bleiben.

Das Smart Home der Zukunft könnte daher weniger davon handeln, zwischen Thread, WLAN und Ethernet zu wählen, sondern vielmehr jedem eine Rolle innerhalb derselben IP-Architektur zu geben.

Das ist die zentrale Idee hinter ThreadLink.

Thread war schon immer ein IP-Netzwerk.

Shelly beginnt einfach, es wie eines zu nutzen.

FAQ: Shelly ThreadLink und Thread-Netzwerke für Smart Homes

Was ist Shelly ThreadLink?

ThreadLink ist eine angekündigte Firmware zur optionalen Aktivierung für berechtigte Shelly-Gen4-Geräte. Shelly zufolge wird sie das Thread-Funkmodul der Geräte nutzen, um Matter, Shelly-RPC-/API-Datenverkehr, Cloud-Konnektivität und die direkte Kommunikation zwischen Geräten über dasselbe stromsparende IP-Mesh-Netzwerk zu übertragen.

Ist Shelly ThreadLink jetzt verfügbar?

Nein. Shelly hat ThreadLink am 3. September 2026 angekündigt und plant derzeit, die kostenlose Firmware zur optionalen Aktivierung etwa drei Monate später für berechtigte Gen4-Geräte zu veröffentlichen.

Werden alle Shelly-Gen4-Geräte ThreadLink unterstützen?

Shelly hat das Update bisher nur für berechtigte Gen4-Geräte zugesagt. Eine vollständige, endgültige Kompatibilitätsliste sollte geprüft werden, sobald die Firmware verfügbar ist.

Verwandelt ThreadLink Thread in ein IP-Netzwerk?

Nein. Thread basiert seit jeher auf IPv6, 6LoWPAN und IEEE 802.15.4. ThreadLink verändert, wie Shelly dieses bestehende IP-Netzwerk nutzen will, indem darüber mehr als nur Matter ausgeführt wird.

Sind Matter und Thread dasselbe?

Nein. Matter ist ein Smart-Home-Steuerungsstandard auf Anwendungsebene. Thread ist ein stromsparendes IPv6-Mesh-Netzwerk, das Matter oder andere kompatible Anwendungsprotokolle übertragen kann.

Kann Thread ohne Matter funktionieren?

Ja. Thread ist anwendungsprotokollunabhängig. Verbraucherprodukte mit Thread werden heute stark mit Matter in Verbindung gebracht, doch Thread selbst kann andere IP-basierte Anwendungsprotokolle übertragen.

Können ThreadLink-Geräte ohne WLAN funktionieren?

Shelly zufolge können ThreadLink-Geräte Thread für Matter, lokale API-Kommunikation, Peer-to-Peer-Automatisierung und die Cloud-Konnektivität über einen Thread Border Router nutzen, ohne dass das Gerät selbst dem WLAN beitreten muss.

Kann ThreadLink ohne Internet funktionieren?

Shelly zufolge können direkte Geräte-zu-Gerät-Szenen, Verriegelungen und Automatisierungen lokal innerhalb des Thread-Mesh ausgeführt werden, selbst wenn die Internetverbindung oder das WLAN ausfällt.

Erfordert ThreadLink einen Thread Border Router?

Ein Border Router ist erforderlich, wenn ThreadLink-Geräte mit dem größeren Heim-LAN, Apps, Home Assistant oder Cloud-Diensten kommunizieren müssen. Shelly zufolge können Geräte-zu-Gerät-Szenen innerhalb des Thread-Mesh selbst ausgeführt werden.

Ersetzt ThreadLink Home Assistant?

Nein. Eine direkte Peer-to-Peer-Logik kann bei einfachen Gerätebeziehungen den Bedarf an einem Server beseitigen, während Home Assistant weiterhin für protokollübergreifende Automatisierung, Verlauf, Dashboards, Richtlinien, Zeitpläne und die Orchestrierung des gesamten Hauses nützlich bleibt.

Wird Thread WLAN ersetzen?

Wahrscheinlich nicht. Thread ist für stromsparende IoT-Geräte mit relativ geringer Bandbreite ausgelegt. WLAN eignet sich weiterhin besser für Produkte mit höherer Bandbreite wie Kameras, Displays, Smartphones und Computer.

Was ist der Unterschied zwischen einem Thread Border Router und einem Smart-Home-Hub?

Ein Thread Border Router leitet hauptsächlich IPv6-Datenverkehr zwischen dem Thread-Mesh und dem größeren IP-Netzwerk weiter. Ein herkömmlicher Hub oder eine Bridge übersetzt häufig zwischen einem Nicht-IP-Gerätenetzwerk und einem IP-basierten LAN oder einer Anwendung.

Kann ein Haushalt mehr als ein Thread-Netzwerk haben?

Ja. In heutigen Haushalten können separate Thread-Netzwerke von Apple, Google, Home Assistant oder anderen Anbietern mit unterschiedlichen Zugangsdaten vorhanden sein. Thread 1.4 soll die Zusammenführung in ein bestehendes Mesh erleichtern, doch die praktische Umsetzung hängt weiterhin von der Unterstützung durch Geräte und Ökosysteme ab.

Was ändert sich mit Thread 1.4?

Thread 1.4 verbessert den netzwerkübergreifenden Beitritt, die Border-Router-Infrastruktur, die Cloud-Konnektivität, die Diagnose, die Inbetriebnahme, die Zuverlässigkeit und die Möglichkeit, ein größeres einheitliches Thread-Mesh aufrechtzuerhalten.

Warum ist ThreadLink für Heimserver wichtig?

Es deutet darauf hin, dass sich der Heimserver weniger auf die Übersetzung proprietärer Gerätenetzwerke und stärker auf Orchestrierung, Zustände, Verlauf, Richtlinien, systemübergreifende Automatisierung und langlebige Daten konzentrieren kann, während Thread, WLAN und Ethernet den zugrunde liegenden IP-Transport übernehmen.