Thread w praktyce, czyli jak testowałem przyszłości HomeKit

HomePod mini to produkt, który wyznacza przyszłość Apple. Przynajmniej jeżeli chodzi o smart home. Pisałem już wielokrotnie, że jego najważniejszą dla mnie funkcją jest Thread. Teraz po testach praktycznych mogę to potwierdzić.

Przed praktyką ciut teorii: Co to jest Thread?

Do grupy Thread Apple przystąpiło dwa lata temu, a sama grupa została powołana w 2015 roku. Samo Thread powstało jako odpowiedź na potrzeby sprawnego systemu komunikacji dla urządzeń IoT, Smart Home i automatyki. Priorytetem w projektowaniu była niezawodność, zasięg i niskie zużycie energii.

Thread pracuje tak, jak Bluetooth, ZigBee, czy część Wi-Fi w paśmie 2,4 GHz. Jednak z definicji jest, to siatka (mesh) urządzeń, które pełnią rolę repeterów i w razie awarii szukają obejścia. 

Urządzenia mające stałe lub pojemne źródło zasilania i niemuszące oszczędzać energii, pełnią w Thread rolę Routerów (urządzenia z pełnym wątkiem – FTD). Inne są akcesoriami końcowymi (minimalne urządzenie wątku – MTD). Te dzielą się na minimalne urządzenia końcowe (MED) i uśpione urządzenia końcowe (SED). Te ostatnie mogą wyłączać swój odbiornik w celu oszczędzania baterii, ale po przebudzeniu muszą odpytywać swój router, czy są dla nich jakieś wiadomości.

W Thread stosowana jest adresacja ip6, a router może być też routerem brzegowym łączącym sieć Thread z inną np. Wi-Fi czy Ethernet. Taką rolę pełnią HomePody mini i na razie są to jedyne oficjalne routery brzegowe Thread dla HomeKit. W jednej sieci Thread może być kilkaset urządzeń. Tyle teorii.

Ważne: W HomeKit każde akcesorium Thread musi być też zgodne z Bluetooth LE i działać w tym standardzie bez sieci Thread.

Thread w praktyce

Na razie akcesoria Thread nie są dostępne masowo. Na rynku są dwa od Eve (gniazdko i czujnik otwarcia), a dwa kolejne niebawem staną się Thread, po aktualizacji oprogramowania. Jest też żarówka i taśma LED Nanoleaf.  Dlatego postanowiłem zrobić swoje własne akcesoria Thread. Padło na sensor temperatury, wilgotności i ciśnienia jako uśpione urządzenie końcowe i sterownik taśmy LED jako urządzenie z pełnym wątkiem. Całość oparłem na oficjalnych bibliotekach od Apple ADK 5.1, czyli wszystko jest zgodnie z dokumentacją. 

Po kilku dniach walki z przenoszeniem kodu z poprzedniego SDK, który miałem już gotowy dla Bluetooth LE i lutowaniu płytek, zmajstrowałem trzy urządzenia: sensor na baterię, symulator żarówki na płytce deweloperskiej i sterownik LED 100 W na własnej płytce.

Apple w dokumentacji dopuszcza nawet minutowe okresy uśpienia. W przykładach stosuje 30 sekund, ja zdecydowałem się na 15 sekund, głównie, aby nie czekać tak długo podczas testów. Zużycie prądu przez urządzenie śpiące jest znikome. Bateria powinna spokojnie wystarczyć na dwa lata (15 sek.) lub dłużej przy większych czasach uśpienia.

I tu bardzo ważna rzecz, do której użytkownicy HomeKit mogli nie przywyknąć. Urządzenia śpiące, jeżeli wyślemy do nich jakieś polecenie lub zapytanie, odpowiedzą dopiero po „pobudce”. Może to być w pechowym układzie np. 30 sekund, jeżeli taki okres uśpienia został wybrany przez producenta. Oczywiście, jeżeli sensor wykrył zdarzenie, np. ruch, czy otwarcie okna, wysyła informacje natychmiast. Uśpienie dotyczy tylko odbierania. Wysyłanie powiadomienia jest wręcz natychmiastowe.

Zasięg Thread jest lepszy, ale porównywalny z Bluetooth LE. W moim przypadku tak o około 30% dalej od HomePoda mini w roli centrum akcesoriów. Pamiętać jednak należy o mesh i sieci repeterów, jeżeli urządzeń będziemy mieć więcej.

Sterownik LED (z pełnym wątkiem – FTD) na polecenia reaguje natychmiast. Jednak maiłem wątpliwości, jak zachowa się, gdy będzie za repeterem. 

Sporo czasu zajęło mi poszukiwanie miejsca, gdzie sensor i LED tracą kontakt z HomePodem mini. Wyniosłem je aż za altankę. Gdy upewniłem się, że straciły zasięg Thread i oczywiście Bluetooth LE, to symulator żarówki wystawiłem na taras. Po jego włączeniu w mniej-więcej pół minuty sensor i taśma LED zaczęły reagować. Ponieważ nadal nie było zauważalnych opóźnień w komunikacji ze sterownikiem LED, upewniłem się, czy transmisja na pewno odbywa się przez repeter. Wyłączyłem mu zasilanie i komunikacja siadła. 

Naprawdę jestem pod dużym wrażeniem działania Thread, choć to na razie tylko 3 urządzenia plus HomePod mini.

Thread i Bluetooth

Jak już wspomniałem, każde akcesorium Thread w HomeKit musi też być zgodne z Bluetooth LE. Proces parowania odbywa się po Bluetooth i jeżeli w domu mamy sieć Thread (HomePoda mini), to HomeKit wysyła przy parowaniu dane sieci Thread. Po zakończeniu parowania akcesorium próbuje się do sieci Thread zalogować. Jeśli jej nie ma, to działa normalnie jako Bluetooth. 

Jeżeli wyłączymy HomePody mini, to akcesoria przełączą się na Bluetooth LE. Zajmuje im to około minuty. Ponowne włączenie HomePoda mini powoduje, że akcesoria znów staną się Thread, ale zajmuje im to nawet kilkanaście minut. Jest to normalne, bo stosunkowo rzadko podejmowana jest próba podpięcia do Thread. W czasie prób akcesorium może wolniej odpowiadać po Bluetooth.

Thread to przyszłość HomeKit?

Jak już pisałem kilak razy, zgadzam się z tą tezą. Jednak Thread nie zastąpi wszystkiego. Z racji ograniczonej przepustowości i wielkości pakietów nie nadaje się do np. kamer. Jednak 90% urządzeń powinno bardzo dobrze z tym systemem komunikacji pracować i skończą się problemy z zasięgiem. Oczywiście nie dyskwalifikuje to innych systemów już sprawdzonych.

Dodatkowo jak podkreśla Eve na swojej stornie opisującej Thread, jest on „odporny na przyszłość”. Chodzi o to, że inicjatywa Connected Home over IP (CHIP), w której Apple gra główne skrzypce, też zaadoptowała Thread. Jeżeli CHIP stanie się standardem w praktyce, wystarczy wgrać nowe oprogramowanie w akcesoria Thread.

To tylko bardzo pobieżny opis Thread i jedynie moje pierwsze wrażenia z dwudniowych testów. Jednak wygląda to bardzo obiecująco, a ja dam Wam znać, jak się sprawy mają, gdy zawita do mojego domu więcej akcesoriów Thread.