Kilka oddzielnych sieci Thread w jednym domu – co zmienia credential sharing w Thread 1.4 i dlaczego SmartThings może dołączyć do istniejącej sieci?

Kilka urządzeń z funkcją Thread Border Router nie oznacza automatycznie jednej dużej sieci Thread. Przez pierwsze lata Matter w praktyce często było odwrotnie: Apple TV tworzył własną sieć, Google Nest własną, SmartThings własną, a kolejny hub dokładał następną. Wszystkie działały w tym samym domu, czasem nawet obsługiwały te same urządzenia przez Matter Multi-Admin, ale radiowo pozostawały osobnymi wyspami.

To właśnie ten problem próbuje uporządkować Thread 1.4. Najważniejszą zmianą z punktu widzenia typowego domu nie jest większa prędkość ani nowy typ urządzenia, lecz Thread Credentials Sharing – ustandaryzowany sposób przekazania danych potrzebnych do dołączenia do już istniejącej sieci. Dzięki temu nowy Border Router nie musi odruchowo zakładać kolejnej sieci.

SmartThings jest dobrym przykładem, bo Samsung wdrożył dwukierunkową unifikację: odpowiedni hub SmartThings może dołączyć do istniejącej sieci Thread, a zgodny Border Router innego producenta może zostać wpuszczony do sieci utworzonej wcześniej przez SmartThings. To zmienia sposób, w jaki warto projektować instalację z Matter-over-Thread.

Trzy Border Routery nie muszą oznaczać jednej sieci Thread

Najpierw trzeba oddzielić dwie rzeczy, które w aplikacjach smart home są skutecznie ukrywane przed użytkownikiem: Matter Fabric i sieć Thread.

Matter odpowiada za warstwę aplikacyjną – czyli między innymi za to, który kontroler ma prawo sterować żarówką, gniazdkiem albo czujnikiem. Funkcja Matter Multi-Admin pozwala temu samemu urządzeniu należeć do więcej niż jednego fabricu, np. równocześnie do SmartThings i Apple Home.

Thread jest niżej. To sieć IP działająca bezprzewodowo w paśmie 2,4 GHz, oparta na IEEE 802.15.4 i mechanizmie mesh. Urządzenie Thread musi znać parametry konkretnej sieci, aby się do niej przyłączyć. Te informacje znajdują się w Operational Dataset.

Wśród parametrów sieci są m.in.:

• Network Key – 16 bajtów, czyli 128 bitów; zapisany szesnastkowo ma 32 znaki,

• kanał radiowy,

• PAN ID,

• Extended PAN ID,

• nazwa sieci,

• Mesh-Local Prefix,

• PSKc,

• Security Policy,

• Active Timestamp.

Dwa Border Routery mające inne zestawy tych parametrów należą do dwóch różnych sieci Thread, nawet jeśli stoją pół metra od siebie i oba są podłączone do tego samego routera domowego.

To jest źródło problemu.

Wyobraźmy sobie mieszkanie, w którym działają SmartThings Station, HomePod mini i Google Nest Hub. Jeżeli każdy z nich utworzył własną sieć, można mieć trzy poprawnie działające sieci Thread. Matter nadal może pozwalać na sterowanie urządzeniami z różnych aplikacji, ale same sieci mesh nie wzmacniają się wzajemnie.

Żarówka będąca routerem Thread w sieci A nie rozszerza zasięgu czujnika znajdującego się w sieci B. Border Router sieci C nie staje się automatycznie zapasową drogą dla urządzeń z sieci A.

Przy jednej wspólnej sieci sytuacja wygląda inaczej. Kilka zgodnych Border Routerów widzi tę samą sieć i może zapewniać wiele dróg między Thread a domowym Ethernetem lub Wi-Fi. Zasilane urządzenia Full Thread Device mogą dodatkowo uczestniczyć w mesh i rozszerzać jego zasięg.

To jest główny techniczny argument za unifikacją: większa liczba Border Routerów zaczyna zwiększać odporność tej samej sieci zamiast budować kilka równoległych wysp.

Kilka sieci nie jest jednak z definicji błędem. Ma to sens w laboratorium, podczas testowania urządzeń, przy celowej separacji instalacji albo wtedy, gdy producenci nie obsługują jeszcze wspólnego mechanizmu zarządzania poświadczeniami. W zwykłym mieszkaniu sytuacja jest jednak trudniejsza do uzasadnienia.

Dochodzi jeszcze radio. Thread wykorzystuje pasmo 2,4 GHz, w którym działają także Wi-Fi i Zigbee. Kilka niezależnych sieci Thread może pracować na różnych kanałach, ale nie oznacza to automatycznie mniejszych zakłóceń. Przy źle dobranym planie radiowym dokładamy kolejne transmisje w już zatłoczonym paśmie. Tworzenie dodatkowej sieci tylko dlatego, że kupiliśmy kolejny hub, zwykle nie daje żadnej przewagi.

Credential sharing w Thread 1.4 nie jest „udostępnianiem Matter”

To istotne rozróżnienie. Thread Credentials Sharing nie przekazuje uprawnień Matter do sterowania urządzeniami. Przekazuje informacje pozwalające urządzeniu lub Border Routerowi wejść do określonej sieci Thread.

Problem istniał wcześniej dlatego, że potrzebne dane były zazwyczaj przechowywane w zabezpieczonym magazynie systemu telefonu. Jeśli odpowiednia aplikacja mogła odczytać zapisane poświadczenia Thread, nowy sprzęt można było skierować do istniejącej sieci.

Jeżeli ich nie miała – na przykład pierwszą sieć skonfigurowano innym telefonem albo aplikacja producenta nie współpracowała prawidłowo z magazynem systemowym – najprostsza dla producenta droga polegała na stworzeniu nowej sieci.

Thread 1.4 dodaje standardową ścieżkę odzyskania takich danych od działającego Border Routera.

Proces jest bardziej konkretny, niż sugeruje określenie „sharing”.

1. Aplikacja wykrywa w sieci lokalnej zgodny Thread 1.4 Border Router obsługujący Credentials Sharing. Do wykrywania wykorzystywane jest DNS-SD/mDNS.

2. Użytkownik świadomie uruchamia tryb udostępniania. Producent powinien wcześniej uwierzytelnić użytkownika w swojej aplikacji lub interfejsie urządzenia.

3. Border Router generuje Thread Administration One-Time Passcode – OTPC.

4. Kod ma postać dziewięciu cyfr, prezentowanych jako trzy grupy po trzy cyfry. Może być również pokazany w postaci QR.

5. Na podstawie OTPC obie strony wyprowadzają tymczasowy klucz ePSKc – Ephemeral Pre-Shared Key for the Commissioner.

6. Aplikacja będąca kandydatem na dostęp zestawia z Border Routerem zabezpieczone połączenie DTLS.

7. Po poprawnym uwierzytelnieniu może pobrać Active Operational Dataset, a w razie potrzeby również Pending Operational Dataset, czyli dane potrzebne do pracy w istniejącej sieci.

8. Uzyskane dane mogą zostać zapisane w bezpiecznym magazynie systemu albo bezpośrednio przekazane nowemu urządzeniu czy Border Routerowi.

9. Po zakończeniu sesji lub przekroczeniu czasu dostępu tryb ePSKc zostaje zamknięty, a tymczasowy sekret usunięty.

To ważne z punktu widzenia bezpieczeństwa. Dziewięciocyfrowy kod nie jest stałym hasłem do domowej sieci Thread. Otwiera krótkotrwałą, jednorazową ścieżkę administracyjną, po której właściwe poświadczenia przesyłane są przez zabezpieczone połączenie.

Nie należy też traktować tej procedury jako mechanizmu, który magicznie scala dowolne dwie istniejące sieci wraz ze wszystkimi urządzeniami. Jeżeli mamy sieć A z kilkunastoma urządzeniami i sieć B z kolejnymi kilkunastoma, przekazanie danych sieci A Border Routerowi B rozwiązuje problem Border Routera. Urządzenia końcowe znajdujące się nadal w starej sieci B nie teleportują się automatycznie do A.

Migracja istniejącej, rozbudowanej instalacji pozostaje znacznie trudniejsza niż prawidłowe wybranie sieci na początku.

Dlatego najlepsza kolejność instalacji jest prosta: najpierw ustalić, która sieć Thread ma być główna, później dodawać Border Routery, a dopiero na końcu urządzenia końcowe. Robienie tego odwrotnie potrafi skończyć się resetowaniem kilkunastu czujników tylko po to, aby posprzątać topologię, której użytkownik wcześniej nawet nie widział.

Dlaczego SmartThings może teraz wejść do istniejącej sieci Thread

Samsung wprowadził w SmartThings funkcję two-way Thread network unification. Jej znaczenie jest większe, niż sugeruje dodatkowa pozycja w ustawieniach huba.

Dotychczas częstym scenariuszem było kupienie Aeotec Smart Home Hub albo innego urządzenia pełniącego funkcję SmartThings Hub już po urządzeniach Apple, Google czy innego producenta. W domu działała więc sieć Thread, ale SmartThings potrafił utworzyć następną.

Po wdrożeniu unifikacji zgodny hub SmartThings może otrzymać dane sieci, która już istnieje, zamiast koniecznie budować własną.

SmartThings przewiduje dwie drogi.

Pierwsza to poświadczenia przechowywane przez system telefonu. Jeżeli właściwa sieć Thread oraz jej dane znajdują się w systemowym magazynie poświadczeń i aplikacja może z nich skorzystać, SmartThings wykorzystuje je podczas dołączania.

Druga to właśnie Thread 1.4 Credentials Sharing. W aplikacji SmartThings wybierana jest opcja dołączenia do innej sieci, a aplikacja drugiego ekosystemu udostępnia QR lub jednorazowy kod OTPC. SmartThings pobiera wówczas parametry sieci i konfiguruje swój Border Router do pracy w niej.

Mechanizm działa także w przeciwną stronę. SmartThings może uruchomić Share SmartThings network, wygenerować kod/QR i udostępnić swoją sieć kompatybilnemu Border Routerowi innego producenta.

To nie jest już wyłącznie scenariusz laboratoryjny. W 2026 roku Samsung i IKEA publicznie uruchomiły taki model współpracy dla SmartThings i IKEA DIRIGERA: hub IKEA może wejść do sieci Thread SmartThings albo SmartThings może korzystać z sieci Thread utworzonej po stronie IKEA.

Są jednak trzy ograniczenia, o których łatwo zapomnieć.

Po pierwsze: Thread 1.4 w specyfikacji nie wystarczy. Drugi producent musi faktycznie zaimplementować mechanizm w firmware, aplikacji i interfejsie użytkownika. Jeżeli aplikacja nie potrafi wygenerować OTPC ani odczytać odpowiednich credentials z systemu, sam napis „Thread 1.4” na urządzeniu niczego nie rozwiąże.

Po drugie: wsparcie zależy od konkretnego huba. Na starcie funkcji SmartThings w 2025 roku Samsung wymieniał m.in. Aeotec Smart Home Hub i Aeotec Smart Home Hub 2, a wymaganiem była wtedy linia firmware 0.58.x oraz aplikacja SmartThings co najmniej 1.7.37.x na iOS i 1.8.37.x na Androidzie. To numery startowe, nie wersje, których należy dziś ręcznie szukać – oprogramowanie jest dalej rozwijane.

Nie należy natomiast utożsamiać każdego urządzenia oznaczonego jako „SmartThings Hub” z pełnoprawnym Thread Border Routerem. Przykładowo stary SmartThings Hub 2015 może współpracować z Matter-over-Thread za pośrednictwem zewnętrznego Border Routera, ale nie daje to nagle wbudowanego radia Thread.

Po trzecie: migracja działającego huba jest bardziej ryzykowna niż konfiguracja nowego. Pierwotne wdrożenie SmartThings ograniczało dołączanie do innej sieci przede wszystkim do huba bez podłączonych urządzeń. W wersjach beta firmware 0.62.x testowanych latem 2026 roku interfejs rozszerzano również na huby z istniejącą konfiguracją. Bety nie należy jednak traktować jako gwarancji identycznego zachowania na każdym modelu i stabilnej wersji oprogramowania.

W praktycznej instalacji nie zaczynam więc od naciskania „Unify Thread Network”. Najpierw sprawdzam, która sieć zawiera najwięcej urządzeń Thread i które Border Routery są dla niej krytyczne. Przenoszenie pustego Border Routera do sieci z 30 urządzeniami jest logiczne. Próba przebudowania sieci z 30 urządzeniami tylko po to, aby dopasować ją do nowo kupionego huba, to znacznie gorszy układ.

Jeżeli urządzenia działają stabilnie, nie należy też scalać sieci wyłącznie dla porządku w aplikacji. Największy sens ma to wtedy, gdy występuje przynajmniej jeden z konkretnych powodów:

• w domu jest kilka Border Routerów, ale zasięg Thread nadal ma martwe strefy;

• nowe urządzenia regularnie trafiają do niewłaściwej sieci;

• po awarii jednego Border Routera część urządzeń traci łączność;

• chcemy, aby urządzenia zasilane sieciowo budowały jeden większy mesh, zamiast kilku małych;

• dokładamy kolejny ekosystem i możemy jeszcze zdecydować o jego sieci Thread przed sparowaniem urządzeń końcowych.

Jest też irytująca strona całej technologii: aplikacje konsumenckie nadal pokazują użytkownikowi znacznie mniej informacji o Thread niż zaawansowany panel Wi-Fi. Nazwa sieci, Extended PAN ID, używany kanał, lista Border Routerów i stan routingu powinny być łatwo dostępne, a często nie są. Gdy wszystko działa, niewidoczność infrastruktury jest zaletą. Gdy coś się psuje, staje się problemem diagnostycznym.

Dlatego przed jakąkolwiek migracją dobrze zapisać przynajmniej nazwy istniejących sieci Thread, ich Border Routery i urządzenia zależne od każdego z nich. Jeżeli używane narzędzie udostępnia Extended PAN ID i kanał, również je zapisuję. Sama identyczna nazwa dwóch sieci nie dowodzi, że to ta sama sieć.

FAQ

Czy kilka Thread Border Routerów w jednym domu jest czymś złym?
Nie. W jednej sieci jest to wręcz pożądane, ponieważ awaria jednego Border Routera nie musi odcinać urządzeń od reszty sieci IP. Problemem jest kilka Border Routerów tworzących kilka niepotrzebnych, odseparowanych sieci.

Czy Thread 1.4 automatycznie połączy sieci Apple, Google, IKEA i SmartThings?
Nie. Protokół dostarcza mechanizm credential sharing, ale każdy producent musi go zaimplementować. Potrzebna jest zgodność po obu stronach oraz odpowiednia wersja firmware i aplikacji.

Czy Matter Multi-Admin i Thread Credentials Sharing robią to samo?
Nie. Multi-Admin daje kolejnemu ekosystemowi uprawnienia do urządzenia Matter. Thread Credentials Sharing umożliwia urządzeniu lub Border Routerowi otrzymanie danych konkretnej sieci Thread.

Czy dziewięciocyfrowy OTPC jest hasłem do mojej sieci Thread?
Nie. Jest jednorazowym kodem administracyjnym służącym do utworzenia tymczasowego poświadczenia ePSKc i zabezpieczonej sesji, przez którą przekazywany jest Operational Dataset.

Czy po dołączeniu SmartThings do sieci Apple lub IKEA wszystkie urządzenia przejdą do niej automatycznie?
Nie należy tego zakładać. Dołączenie Border Routera do wybranej sieci i migracja urządzeń końcowych z innej istniejącej sieci to dwa różne problemy. W rozbudowanej instalacji migracja urządzeń może wymagać dodatkowych operacji, a w najgorszym przypadku ponownego onboardingu.

Czy wspólna sieć Thread oznacza, że IKEA, SmartThings i Apple widzą wszystkie moje urządzenia Matter?
Nie. Wspólny transport Thread nie zmienia uprawnień Matter. To, który ekosystem może kontrolować urządzenie, nadal wynika z jego członkostwa w odpowiednich Matter Fabrics.

Co sprawdzić przed zakupem kolejnego huba?
Nie samo logo Matter. Sprawdź, czy urządzenie jest Thread Border Routerem, jaką wersję Thread obsługuje i – co najważniejsze – czy producent faktycznie udostępnia Thread Credentials Sharing albo możliwość dołączenia Border Routera do istniejącej sieci.

Pierwsza decyzja powinna więc dotyczyć nie urządzeń Matter, lecz infrastruktury: ustal, która działająca sieć Thread ma pozostać siecią główną i nie twórz kolejnej, dopóki nie sprawdzisz, czy nowy Border Router może do niej dołączyć. Jeżeli w domu istnieją już dwie lub trzy sieci, najpierw zidentyfikuj ich Border Routery i urządzenia zależne od każdej z nich. Dopiero potem uruchamiaj unifikację. Najgorszym pierwszym ruchem jest resetowanie urządzeń bez wiedzy, do której sieci są obecnie przyłączone.

Więcej informacji na: https://househub.pl