Shelly ThreadLink: Czy Thread staje się lokalną siecią IP dla inteligentnych domów?

Shelly ThreadLink nie zmienia Thread w sieć IP — Thread od początku opiera się na IPv6. Zmienia się sposób, w jaki Shelly planuje korzystać z tej sieci. Zamiast rezerwować Thread głównie dla Matter, a interfejsy API producenta, łączność z chmurą i zaawansowane funkcje pozostawiać w Wi-Fi, ThreadLink ma obsługiwać kilka z tych ścieżek za pośrednictwem tej samej energooszczędnej sieci kratowej.

To sprawia, że ThreadLink jest ciekawszy niż kolejne ogłoszenie dotyczące zgodności z Matter. Jeśli rozwiązanie będzie działać zgodnie z zapowiedziami, Thread może stać się energooszczędną krawędzią IP inteligentnego domu: przekaźniki, przełączniki, czujniki i elementy sterujące będą komunikować się przez Thread, podczas gdy Home Assistant, serwery, urządzenia Wi-Fi i systemy Ethernet pozostaną częścią szerszej sieci lokalnej. Oprogramowanie układowe nie jest jednak jeszcze dostępne — Shelly planuje obecnie aktualizację wymagającą wyrażenia zgody mniej więcej trzy miesiące po ogłoszeniu z 3 września.

Czym jest Shelly ThreadLink?

ThreadLink to nadchodzące alternatywne oprogramowanie układowe dla kwalifikujących się urządzeń Shelly Gen4, które wykorzystuje ich moduł radiowy obsługujący Thread jako szersze połączenie IP, zamiast ograniczać go głównie do jednej ścieżki aplikacyjnej.

W oficjalnym ogłoszeniu ThreadLink firma Shelly informuje, że oprogramowanie układowe będzie obsługiwać sieci IPv6 za pośrednictwem Thread, a także komunikację TCP oraz RPC/UDP. Ten sam energooszczędny moduł radiowy ma obsługiwać:

• łączność z Matter,
• ruch Shelly Cloud,
• komunikację RPC i API Shelly,
• bezpośrednie sterowanie urządzeniami,
• konfigurację i diagnostykę,
• oraz głębszą integrację z Home Assistant.

Kluczowa zmiana architektoniczna wygląda następująco:

POPULARNY OBECNY MODEL

                    Matter
                      |
                    Thread

Urządzenie Shelly ───── Wi-Fi ───── Shelly API
       |
       └─────────── Wi-Fi ───── Chmura


KIERUNEK THREADLINK

                    Matter
                      |
Shelly API ─────── Thread ───── Ścieżka chmurowa
                      |
                  Lokalne P2P

Zamiast wymagać Wi-Fi po stronie urządzenia zależnej od producenta, podczas gdy Thread przenosi Matter, Shelly chce, aby sam Thread zapewniał transport IP dla kilku zastosowań jednocześnie.

To rozróżnienie jest istotne, ponieważ Matter i Thread nie są tą samą warstwą sieci.

Czy Shelly ThreadLink jest już dostępny?

Nie. ThreadLink został ogłoszony, ale produkcyjne oprogramowanie układowe nie jest jeszcze ogólnie dostępne.

Shelly informuje, że będzie ono dostarczane jako oddzielne, bezpłatne oprogramowanie układowe wymagające wyrażenia zgody, przeznaczone dla kwalifikujących się urządzeń Gen4, około trzech miesięcy po ogłoszeniu z 3 września 2026 r.

Użytkownicy będą wybierać dla każdego urządzenia, czy ma ono działać na standardowym oprogramowaniu układowym zoptymalizowanym pod kątem Wi-Fi, czy na ThreadLink.

Oznacza to, że ThreadLink należy obecnie traktować jako ogłoszoną architekturę, a nie funkcję, którą każdy posiadacz urządzenia Gen4 może dziś włączyć.

Oznacza to również, że jest zbyt wcześnie, aby twierdzić, że każdy model Gen4 otrzyma to oprogramowanie układowe. Shelly wyraźnie mówi o kwalifikujących się urządzeniach Gen4, dlatego ostateczna lista zgodności ma znaczenie.

Czy Thread nie był już siecią IP?

Tak. To najważniejsze nieporozumienie, które należy wyjaśnić.

Thread został zaprojektowany jako sieć kratowa oparta na IPv6, wykorzystująca 6LoWPAN za pośrednictwem modułów radiowych IEEE 802.15.4. Wyjaśnienie fundamentów IPv6 w Thread przedstawione przez Thread Group sięga do zasady projektowej opracowanej wiele lat przed powstaniem Matter.

Stos sieciowy można uprościć następująco:

APLIKACJE

Matter
Protokoły producenta
Inne usługi IP
       |
       v
TRANSPORT

UDP / TCP
       |
       v
SIEĆ

IPv6
       |
       v
ADAPTACJA

6LoWPAN
       |
       v
RADIO

IEEE 802.15.4

Thread nie jest więc protokołem radiowym przeznaczonym wyłącznie dla Matter, w tym samym sensie, w jakim wiele osób potocznie go opisuje.

Jest energooszczędną siecią IP zdolną do przenoszenia znajdujących się nad nią protokołów aplikacyjnych.

Matter jest obecnie jego najbardziej widoczną konsumencką aplikacją inteligentnego domu, ale sam Thread został zaprojektowany jako niezależny od warstwy aplikacji.

ThreadLink nie sprawia, że Thread staje się siecią IP. Wykorzystuje Thread bardziej tak, jak sieć IP, którą już jest.

Co właściwie nowego wnosi ThreadLink?

Nowością nie jest samo IPv6. Jest nią decyzja, aby jedno konsumenckie urządzenie IoT używało Thread do obsługi kilku ścieżek aplikacyjnych, które wciąż często zależą od Wi-Fi.

THREAD JAKO WARSTWA TRANSPORTOWA MATTER

Matter
  |
Thread


             ↓


THREAD JAKO SIEĆ

Matter ─────────┐
                |
Shelly RPC ─────┤
                |
Lokalne API ──────┼── IPv6 / Thread
                |
Logika P2P ──────┤
                |
Ścieżka chmurowa ─────┘

Zmienia to rolę modułu radiowego.

Thread nie jest już użyteczny wyłącznie dlatego, że inny ekosystem może sterować przekaźnikiem za pośrednictwem Matter. Może także przenosić własny ruch aplikacyjny Shelly, lokalną logikę, konfigurację, diagnostykę i potencjalnie aktualizacje oprogramowania.

Shelly opisuje ThreadLink jako rozwiązanie obsługujące UDP na potrzeby responsywnej komunikacji lokalnej oraz pełną obsługę TCP w przypadku większych lub wymagających niezawodności transferów, takich jak dane konfiguracyjne i diagnostyka.

To znacznie szersza interpretacja tego, co może robić urządzenie konsumenckie połączone z Thread.

Dlaczego Matter nie udostępnia wszystkich funkcji Shelly?

Ponieważ interoperacyjność i wyróżnianie się producenta rozwiązują różne problemy.

Matter zapewnia producentom i platformom inteligentnego domu ustandaryzowany model urządzenia. Przekaźnik zgodny z Matter może udostępniać znane funkcje w sposób zrozumiały dla Apple Home, Google Home, Amazon Alexa, SmartThings czy Home Assistant, bez konieczności implementowania przez każdą platformę zupełnie innego, zastrzeżonego protokołu.

Taka standaryzacja jest cenna.

Jednak producent może nadal udostępniać funkcje wykraczające poza ustandaryzowany model Matter, takie jak:

• bardziej szczegółowe pomiary energii,
• informacje diagnostyczne,
• specjalne działanie przekaźnika,
• konfiguracja specyficzna dla urządzenia,
• funkcje skryptów lub automatyzacji,
• zaawansowane informacje o stanie,
• oraz funkcje zarządzania producenta.

Obecnie często tworzy to dwie równoległe ścieżki:

URZĄDZENIE
  |
  +-- Matter
  |      |
  |      v
  |  Standardowe funkcje
  |  Apple / Google / HA
  |
  +-- API producenta
         |
         v
     Zaawansowane funkcje
     Diagnostyka
     Konfiguracja

ThreadLink stara się zachować obie te ścieżki bez konieczności korzystania z dwóch różnych transportów sieciowych:

          Matter
            \
             \
              Thread
             /
            /
       Shelly RPC

Shelly twierdzi, że dedykowany moduł Home Assistant udostępni szerszy zestaw funkcji Shelly, wykraczający poza możliwości modelu danych Matter.

ThreadLink ma więc znaczenie, ponieważ Matter może pozostać jedną z aplikacji działających w Thread, bez konieczności bycia jedyną aplikacją w Thread.

Czy urządzenia Shelly mogą sterować sobą nawzajem bez Wi-Fi?

Zgodnie z projektem ThreadLink firmy Shelly — tak.

Shelly twierdzi, że urządzenia ThreadLink mogą komunikować się bezpośrednio za pośrednictwem siatki Thread z użyciem swojego API, dzięki czemu sceny, blokady i automatyzacje mogą działać w trybie peer-to-peer.

Kluczowa jest ścieżka działania w przypadku awarii.

Shelly twierdzi, że te zależności między urządzeniami mogą działać dalej, nawet jeśli:

• połączenie z internetem ulegnie awarii,
• chmura Shelly będzie nieosiągalna,
• lub sieć Wi-Fi w domu przestanie działać.

Prosta zależność mogłaby więc wyglądać tak:

Przełącznik ścienny
     |
   Thread
     |
     v
    Przekaźnik

zamiast zawsze wymagać:

Przełącznik ścienny
     |
     v
Wi-Fi / Router
     |
     v
Serwer domowy
     |
     v
Wi-Fi / Router
     |
     v
Przekaźnik

Nie oznacza to, że ścieżka przez serwer jest niewłaściwa.

Oznacza to, że nie każda lokalna akcja musi z niego korzystać.

Czy lokalne sterowanie nadal wymaga Home Assistant?

W przypadku prostych zależności między urządzeniami — nie zawsze. W przypadku szerszej orkiestracji Home Assistant nadal pełni zupełnie inną funkcję.

Włączenie jednego przekaźnika przez lokalny przełącznik ścienny zasadniczo różni się od automatyzacji łączącej wiele systemów.

Logika na poziomie urządzenia może obsługiwać:

• proste zależności przełącznik–przekaźnik,
• blokady,
• podstawowe sceny,
• oraz natychmiastowego działania awaryjnego.

Serwer automatyki domowej lepiej nadaje się do logiki takiej jak:

JEŚLI

eksport energii słonecznej > 3000 W

ORAZ

SOC akumulatora > 80%

ORAZ

w pomieszczeniu ktoś jest

ORAZ

cena energii elektrycznej jest niska

NASTĘPNIE

włączyć obciążenie HVAC / urządzenia

Ten przepływ obejmuje energię, obecność, ceny, harmonogramy i potencjalnie kilka protokołów.

Należy do warstwy wyższej orkiestracji. Szerszy zwrot w kierunku lokalnego przetwarzania w Home Assistant opiera się na tej samej zasadzie: odpowiednie decyzje powinny być podejmowane w domu, a zależności od chmury należy zachować dla zadań, które rzeczywiście ich wymagają.

LOKALNE STEROWANIE NA POZIOMIE URZĄDZENIA

Przełącznik
   |
 Thread P2P
   |
Przekaźnik


LOKALNE STEROWANIE NA POZIOMIE SERWERA

Energia słoneczna ───────┐
Licznik energii ┤
Obecność ────┼── Home Assistant ── HVAC
Harmonogram ────┤
Inne urządzenia IoT ───┘

Podejście local-first nie zawsze oznacza podejście server-first.

Solidny inteligentny dom może wykorzystywać lokalne relacje między urządzeniami do prostych działań, a serwer domowy pozostawić do obsługi logiki między systemami, historii, zasad, pulpitów nawigacyjnych i stanu.

Jak ThreadLink może łączyć się z chmurą bez Wi-Fi?

Jedną z bardziej nietypowych obietnic ThreadLink jest to, że urządzenie końcowe może pozostać urządzeniem Thread, a jednocześnie uzyskiwać dostęp do Shelly Cloud.

Samo urządzenie nie potrzebuje danych uwierzytelniających Wi-Fi dla tej ścieżki.

Shelly opisuje tę architekturę następująco:

Urządzenie Shelly ThreadLink
          |
          v
     IPv6 / Thread
          |
          v
 router brzegowy Thread
          |
          v
        NAT64
          |
          v
   Usługa internetowa IPv4
          |
          v
      Shelly Cloud

Ta koncepcja wpisuje się w szerszy rozwój Thread. Thread 1.4 sformalizował dodatkowe prace nad standardową ścieżką z sieci Thread do usług internetowych, w tym łącznością IPv6–IPv4 na brzegu sieci.

Najważniejsza zmiana koncepcyjna jest następująca:

Łączność z chmurą nie musi już oznaczać łączności Wi-Fi urządzenia końcowego.

Urządzenie o niskim poborze energii może korzystać lokalnie z Thread, podczas gdy trasowanie IP w dalszej części sieci obsługuje dostęp do usług zewnętrznych.

Nie oznacza to, że ThreadLink działa wyłącznie lokalnie.

Pokazuje to coś przeciwnego: lokalna komunikacja urządzeń i opcjonalna łączność z chmurą mogą współdzielić tę samą architekturę IP.

Co właściwie robi router brzegowy Thread?

Router brzegowy Thread łączy sieć kratową Thread z szerszą siecią IP. Zasadniczo jest routerem, a nie tłumaczem każdego polecenia inteligentnego domu.

Wyjaśnienie roli routera brzegowego Thread przedstawione przez Thread Group wyraźnie pokazuje to rozróżnienie.

Tradycyjne architektury inteligentnego domu często wyglądają tak:

Urządzenie Zigbee
     |
     v
Sieć Zigbee
     |
     v
Hub producenta
     |
tłumaczenie protokołów
     |
     v
Sieć IP

Thread używa natomiast protokołu IP bezpośrednio w samej sieci urządzeń:

Urządzenie Thread
     |
 IPv6 / Thread
     |
     v
Router brzegowy
     |
 Trasowanie IP
     |
     v
Domowa sieć LAN

Router brzegowy przekazuje pakiety między fizycznymi segmentami sieci.

Nie musi tłumaczyć każdego polecenia aplikacji z Thread na zastrzeżony protokół LAN.

Oznacza to, że Home Assistant może znajdować się w innym miejscu lokalnej sieci:

Urządzenie Thread
     |
Sieć kratowa Thread
     |
Router brzegowy
     |
Sieć LAN Ethernet / Wi-Fi
     |
     +-- Home Assistant
     +-- Serwer domowy
     +-- Inne usługi IP

Kontroler Matter i router brzegowy Thread pełnią zatem różne role. Router brzegowy zapewnia dostępność sieciową, natomiast Matter zapewnia relację aplikacji i kontrolera ponad tą siecią. Jeśli kilka platform niezależnie steruje tymi samymi urządzeniami Matter, wiele kontrolerów Matter wprowadza odrębną warstwę zaufania i własności, której samo trasowanie Thread nie rozwiązuje.

Gdy ruch opuści sieć Thread mesh, nadal obowiązują zwykłe zasady IP. Osiągalność sieciowa Home Assistant nadal zależy od prawidłowego adresowania, routingu, zasad oraz działającej ścieżki zwrotnej między kontrolerem a urządzeniem końcowym.

Czy ThreadLink oznacza, że Thread zastąpi Wi-Fi?

Nie. Thread i Wi-Fi są zoptymalizowane pod kątem różnych rodzajów ruchu.

Obecna dokumentacja Thread w Home Assistant opisuje Thread jako rozwiązanie zarówno energooszczędne, jak i niskoprzepustowe, dzięki czemu szczególnie dobrze nadaje się do urządzeń wymieniających stosunkowo niewielkie ilości danych.

Energooszczędny przekaźnik nie potrzebuje przepustowości Wi-Fi.

Kamery bezpieczeństwa 4K nie należy przenosić do Thread tylko dlatego, że Thread jest oparty na IP.

Thread nie staje się nowym Wi-Fi. Może stać się energooszczędną krawędzią IP tej samej sieci domowej.

Czy Thread staje się energooszczędną warstwą brzegową domowej sieci LAN?

Właśnie dlatego ThreadLink staje się ciekawszy niż sama zapowiedź oprogramowania układowego Shelly.

Przyszła sieć lokalna może przypominać mniej kilka odizolowanych ekosystemów inteligentnego domu, a bardziej jedną architekturę IP rozciągniętą na kilka fizycznych typów transmisji:

                     SERWER DOMOWY
                          |
                          |
                    DOMOWA SIEĆ IP
                          |
        +-----------------+----------------+
        |                 |                |
     ETHERNET           WI-FI            THREAD
        |                 |                |
       NAS             Kamery          Przekaźniki
     Serwery           Telefony           Czujniki
   Stacje robocze          Telewizory            Przełączniki
                                       Zamki

Urządzenie końcowe nie musi korzystać z tego samego interfejsu radiowego co każde inne urządzenie.

Ważniejsze jest, aby wyższe warstwy mogły komunikować się za pośrednictwem standardowego routingu tam, gdzie jest to właściwe.

To zasadniczo różni się od próby zmuszenia Thread, Wi-Fi i Ethernetu do rywalizacji o wybór jednego zwycięzcy.

Przyszły inteligentny dom może nie mieć jednej sieci bezprzewodowej. Może mieć jedną architekturę IP obejmującą kilka sieci fizycznych.

Co ThreadLink zmienia w Home Assistant?

ThreadLink potencjalnie zapewnia Home Assistantowi dwie przydatne ścieżki dostępu do tego samego fizycznego urządzenia Shelly.

Pierwsza kwestia to standard Matter:

urządzenie Shelly
      |
Matter przez Thread
      |
router brzegowy Thread
      |
Kontroler Matter w Home Assistant
      |
Standardowe funkcje Matter

Druga ścieżka to planowana przez Shelly ścieżka specyficzna dla dostawcy:

urządzenie Shelly
      |
RPC Shelly przez Thread
      |
router brzegowy Thread
      |
Home Assistant
      |
funkcje specyficzne dla Shelly

Oficjalna architektura Matter w Home Assistant już jasno rozróżnia sieć i aplikację: Matter to protokół sterowania na poziomie aplikacji, który może komunikować się przez Wi-Fi, Ethernet lub Thread, zależnie od urządzenia.

ThreadLink opiera się na tej warstwowej architekturze.

Matter może zapewnić interoperacyjność ekosystemów, a integracja Shelly może zachować bardziej zaawansowane funkcje charakterystyczne dla konkretnych urządzeń.

To architektura lepsza niż zmuszanie użytkowników do wyboru między interoperacyjnością a zaawansowanymi funkcjami dostawcy.

Czy jedna sieć Thread jest dziś naprawdę możliwa?

Nie zawsze. Dzisiejsze wdrożenia Thread mogą nadal być bardziej rozdrobnione, niż sugeruje to idealna architektura.

Home Assistant obecnie opisuje swoją integrację z Thread jako będącą w toku i wyraźnie śledzi różne sieci Thread obecne w domu.

Gospodarstwo domowe może odkryć coś takiego:

Sieć Thread Apple
       |
różne dane uwierzytelniające


Sieć Thread Google
       |
różne dane uwierzytelniające


Sieć Thread Home Assistant
       |
different credentials

Urządzenia w oddzielnych sieciach Thread nie stają się automatycznie jedną dużą siecią mesh tylko dlatego, że wszystkie korzystają z Thread.

Home Assistant może pomóc użytkownikom sprawdzać istniejące sieci, a w obsługiwanych przypadkach dołączać router brzegowy Home Assistant do wybranej istniejącej sieci. Jednak ekosystem urządzeń konsumenckich nie jest jeszcze równoznaczny z jedną, w pełni ujednoliconą siecią Thread mesh w każdym domu.

To ważny test rzeczywistości dla ThreadLink.

Nawet technicznie elegancka architektura IP nadal zależy od zgodności routerów brzegowych, współdzielonych danych uwierzytelniających, topologii sieci i rzeczywistej obsługi po stronie implementacji.

Jak Thread 1.4 zmienia sytuację?

Thread 1.4 przybliża ekosystem do idei ujednoliconej sieci.

Grupa Thread opisuje jedną z głównych usprawnień jako łatwiejsze tworzenie jednej sieci mesh.

Celem jest umożliwienie zaktualizowanym urządzeniom i routerom brzegowym z różnych ekosystemów rozpoznawania istniejącej sieci Thread i dołączania do niej zamiast niepotrzebnego tworzenia kolejnej sieci mesh.

Thread 1.4 dodaje również nowe funkcje lub ulepsza istniejące:

• znormalizowana ścieżka do łączności z chmurą,
• Thread ponad infrastrukturą,
• widoczność diagnostyki i rozwiązywania problemów z siecią,
• konwergencja sieci między ekosystemami,
• oraz usprawnienia procesu dołączania.

Daje to ThreadLink szerszy kontekst.

WCZEŚNIEJSZY THREAD

Kratowa sieć IPv6 o niskim poborze energii
      |
Matter zyskuje dominującą pozycję
aplikacja konsumencka


THREAD 1.4

Lepsza konwergencja sieci
Lepsza infrastruktura routerów brzegowych
Ścieżka chmurowa
Diagnostyka
      |
      v


KONCEPCJA THREADLINK

Matter
API producenta
Chmura
P2P
      |
ten sam transport IP o niskim poborze energii

ThreadLink nie jest zatem dowodem na to, że każdy producent przyjmie takie samo podejście.

Jest to jednak konkretny przykład różnorodności zastosowań, którą architektura sieci Thread zawsze umożliwiała.

Czy każda automatyzacja inteligentnego domu powinna przechodzić przez serwer domowy?

Nie. Odporne systemy mogą rozdzielać logikę zgodnie ze złożonością i znaczeniem działania.

Prosta blokada wzajemna niekoniecznie potrzebuje komunikacji zwrotnej z serwerem.

Automatyzacja zarządzania energią w całym domu prawdopodobnie tego wymaga.

Taki podział może zwiększyć odporność sieci, ponieważ awaria jednej warstwy nie powoduje automatycznie usunięcia każdej lokalnej funkcji. Wyjaśnia też, dlaczego rzeczywista ścieżka wydajności Home Assistant obejmuje radia, sieci, brokery, urządzenia docelowe i pamięć masową, a nie tylko procesor uruchamiający Home Assistant.

Czy ThreadLink sprawia, że serwer domowy jest mniej ważny?

Może to sprawić, że serwer domowy będzie mniej ważny jako brama protokołów, ale wyraźniej zdefiniowany jako warstwa orkiestracji.

Tradycyjne inteligentne domy gromadziły mosty, ponieważ wiele sieci urządzeń nie mogło bezpośrednio uczestniczyć w domowej sieci IP.

STARY MODEL

Urządzenia Zigbee ── Hub producenta ──┐
                               |
Inne urządzenia ─── Brama ────────┼── Serwer domowy
                               |
Urządzenia Wi‑Fi ─────────────────┘

Architektura bardziej zorientowana na IP może wyglądać inaczej:

WARSTWA URZĄDZEŃ

Urządzenia Thread
Urządzenia Wi‑Fi
Urządzenia Ethernet
       |
       v

WARSTWA SIECI IP
       |
       v

WARSTWA STEROWANIA

Home Assistant
       |
       +-- Automatyzacje
       +-- Stan
       +-- Historia
       +-- Zasady
       +-- Panele
       +-- Logika międzyprotokołowa
       |
       v

WARSTWA DANYCH

Kopie zapasowe
NAS
Pamięć trwała

Serwer nie musi już przepuszczać przez siebie każdego pakietu, aby uzasadniać swoje istnienie.

Jego wartość coraz bardziej wynika z utrzymywania szerszego obrazu:

• jakie urządzenia istnieją,
• w jakim są stanie,
• jak współdziałają niepowiązane systemy,
• co wydarzyło się wczoraj,
• które automatyzacje powinny zostać uruchomione,
• co powinno się stać w przypadku awarii usługi,
• i jak chroniona jest konfiguracja oraz historia.

Te zadania mają różne wymagania dotyczące pamięci masowej i odzyskiwania danych. Oddzielenie trwałych danych Home Assistant od tymczasowego stanu środowiska uruchomieniowego znacznie ułatwia ochronę warstwy danych w tej architekturze.

Thread zmniejsza potrzebę translacji protokołów, ale nie eliminuje potrzeby korzystania z oprogramowania do automatyki domowej.

Nie oznacza to również, że Home Assistant nagle potrzebuje wydajnego sprzętu. Obecne wymagania dotyczące sprzętu serwera Home Assistant pozostają niewielkie w przypadku zwykłej automatyzacji; to kamery, długa historia, lokalne sterowanie głosowe, bazy danych i dodatkowe usługi zwykle zwiększają obciążenie serwera.

Jeśli kilka z tych usług ma działać razem, dobór serwera dla inteligentnego domu powinien uwzględniać cały stos usług, a nie liczbę urządzeń Thread.

Czy właściciele Shelly Gen4 powinni przejść z Wi‑Fi na ThreadLink?

Na wydanie takiej rekomendacji jest jeszcze za wcześnie.

Oprogramowanie układowe nie jest jeszcze ogólnie dostępne, znaczenie ma ostateczna lista obsługiwanych urządzeń, a rzeczywistą interoperacyjność z istniejącymi sieciami Thread i routerami granicznymi trzeba jeszcze przetestować poza demonstracjami.

Gdy ThreadLink stanie się dostępny, właściciele urządzeń Gen4 powinni ocenić:

• czy ich konkretny model Shelly jest objęty obsługą,
• czy odpowiedni router graniczny Thread już istnieje,
• czy sieci Thread w domu są zunifikowane, czy rozproszone,
• czy wymagane funkcje Shelly działają za pośrednictwem nowego modułu Home Assistant,
• czy potrzebny jest dostęp do chmury,
• czy przydatna jest bezpośrednia logika między urządzeniami,
• i tego, czy istniejąca instalacja Wi‑Fi już działa niezawodnie.

Dlatego właściwe stanowisko na 2026 rok to obserwowanie wdrożenia, a nie migracja działającej instalacji wyłącznie na podstawie ogłoszenia.

Czy Thread staje się lokalną siecią IP dla inteligentnych domów?

Thread raczej nie stanie się jedyną siecią lokalną w inteligentnym domu. Ma większe szanse stać się energooszczędną warstwą brzegową IP tej sieci.

Ethernet pozostaje naturalnym sposobem transmisji dla serwerów, urządzeń NAS i stacjonarnych systemów o dużej przepustowości.

Wi-Fi pozostaje naturalną siecią bezprzewodową dla telefonów, laptopów, kamer, wyświetlaczy i urządzeń wymagających znacznie większej przepustowości.

Thread dobrze sprawdza się na energooszczędnej warstwie brzegowej:

• czujnikami,
• przekaźnikami,
• przełącznikami,
• zamkami,
• steruje,
• i inne urządzenia, które wymieniają stosunkowo niewielkie ilości danych.

Shelly ThreadLink jest interesujący, ponieważ przestaje traktować tę warstwę brzegową jako izolowane środowisko jednej aplikacji.

Matter może zapewniać ustandaryzowane sterowanie w ekosystemie.

Shelly RPC może zapewniać bardziej rozbudowane funkcje producenta.

Komunikacja między urządzeniami może utrzymywać proste działania lokalnie.

Router brzegowy może połączyć siatkę z większą siecią LAN.

Home Assistant może koordynować działanie różnych protokołów.

Łączność z chmurą może pozostać opcjonalna, zamiast wymagać od samego urządzenia końcowego dołączenia do Wi-Fi.

Dla użytkowników, którzy chcą takiej warstwy orkiestracji na dedykowanym systemie lokalnym, ZimaBoard 2 do inteligentnego domu jest przykładem rozwiązania, w którym kontroler działa na rozbudowywalnym, stale włączonym serwerze, a routery brzegowe Thread i radia urządzeń końcowych pozostają oddzielnymi elementami sieci.

Przyszłość inteligentnego domu może więc w mniejszym stopniu polegać na wyborze między Thread, Wi-Fi i Ethernetem, a w większym na przypisaniu każdemu z nich roli w ramach tej samej architektury IP.

Na tym właśnie polega główna idea ThreadLink.

Thread od zawsze był siecią IP.

Shelly po prostu zaczyna używać jej w ten sposób.

FAQ: Shelly ThreadLink i sieć Thread dla inteligentnego domu

Czym jest Shelly ThreadLink?

ThreadLink to zapowiedziane oprogramowanie układowe dostępne dobrowolnie dla kwalifikujących się urządzeń Shelly Gen4. Shelly twierdzi, że wykorzysta radio Thread w urządzeniach do przesyłania Matter, ruchu Shelly RPC/API, łączności z chmurą oraz bezpośredniej komunikacji między urządzeniami za pośrednictwem tej samej energooszczędnej siatki IP.

Czy Shelly ThreadLink jest już dostępny?

Nie. Shelly ogłosiło ThreadLink 3 września 2026 r. i obecnie planuje udostępnić bezpłatne oprogramowanie układowe w modelu dobrowolnego wdrożenia około trzy miesiące później dla kwalifikujących się urządzeń Gen4.

Czy każde urządzenie Shelly Gen4 będzie obsługiwać ThreadLink?

Shelly obiecało aktualizację wyłącznie dla kwalifikujących się urządzeń Gen4. Pełną, ostateczną listę zgodności należy sprawdzić po udostępnieniu oprogramowania układowego.

Czy ThreadLink zmienia Thread w sieć IP?

Nie. Thread od zawsze opiera się na IPv6, 6LoWPAN i IEEE 802.15.4. ThreadLink zmienia sposób, w jaki Shelly zamierza korzystać z tej istniejącej sieci IP, uruchamiając za jej pośrednictwem nie tylko Matter.

Czy Matter to to samo co Thread?

Nie. Matter to standard sterowania inteligentnym domem na poziomie aplikacji. Thread to energooszczędna sieć mesh IPv6, która może przenosić Matter lub inne zgodne protokoły aplikacyjne.

Czy Thread może działać bez Matter?

Tak. Thread jest niezależny od warstwy aplikacji. Obecnie konsumenckie produkty Thread są silnie kojarzone z Matter, ale sam Thread może przenosić inne aplikacyjne protokoły oparte na IP.

Czy urządzenia ThreadLink mogą działać bez Wi‑Fi?

Shelly twierdzi, że urządzenia ThreadLink mogą używać Thread do Matter, lokalnej komunikacji za pośrednictwem API, automatyzacji peer-to-peer oraz łączności z chmurą przez router brzegowy Thread, bez konieczności dołączania samego urządzenia końcowego do Wi‑Fi.

Czy ThreadLink może działać bez internetu?

Shelly twierdzi, że bezpośrednie sceny między urządzeniami, blokady wzajemne i automatyzacje mogą działać lokalnie wewnątrz sieci mesh Thread, nawet jeśli połączenie z internetem lub sieć Wi‑Fi przestanie działać.

Czy ThreadLink wymaga routera brzegowego Thread?

Router brzegowy jest wymagany, gdy urządzenia ThreadLink muszą komunikować się z szerszą domową siecią LAN, aplikacjami, Home Assistantem lub usługami w chmurze. Shelly twierdzi, że sceny między urządzeniami mogą działać w samej sieci mesh Thread.

Czy ThreadLink zastępuje Home Assistant?

Nie. Bezpośrednia logika komunikacji równorzędnej może wyeliminować potrzebę korzystania z serwera w prostych relacjach między urządzeniami, podczas gdy Home Assistant pozostaje przydatny do automatyzacji między protokołami, historii, pulpitów, zasad, harmonogramów i orkiestracji całego domu.

Czy Thread zastąpi Wi‑Fi?

Prawdopodobnie nie. Thread został zaprojektowany dla energooszczędnych urządzeń IoT o stosunkowo niskiej przepustowości. Wi‑Fi nadal lepiej nadaje się do produktów wymagających większej przepustowości, takich jak kamery, wyświetlacze, telefony i komputery.

Jaka jest różnica między routerem brzegowym Thread a hubem inteligentnego domu?

Router brzegowy Thread przede wszystkim routuje ruch IPv6 między siecią mesh Thread a szerszą siecią IP. Tradycyjny hub lub most często tłumaczy komunikację między nieopartą na IP siecią urządzeń a siecią LAN lub aplikacją opartą na IP.

Czy w domu może działać więcej niż jedna sieć Thread?

Tak. Współczesne domy mogą zawierać oddzielne sieci Thread firmy Apple, Google, Home Assistant lub innych dostawców, korzystające z różnych danych uwierzytelniających. Thread 1.4 ma ułatwić połączenie z jedną istniejącą siecią mesh, ale działanie w rzeczywistych warunkach nadal zależy od obsługi po stronie urządzeń i ekosystemów.

Co zmienia Thread 1.4?

Thread 1.4 usprawnia dołączanie do sieci między ekosystemami, infrastrukturę routerów brzegowych, łączność z chmurą, diagnostykę, uruchamianie, niezawodność oraz możliwość utrzymywania większej, ujednoliconej sieci mesh Thread.

Dlaczego ThreadLink jest ważny dla serwerów domowych?

Sugeruje to, że serwer domowy może w mniejszym stopniu zajmować się tłumaczeniem sieci zastrzeżonych urządzeń, a bardziej orkiestracją, stanem, historią, zasadami, automatyzacją między systemami i trwałymi danymi, podczas gdy Thread, Wi‑Fi i Ethernet obsługują leżący u podstaw transport IP.