ESP32 z ESPHome będzie mógł pracować jako router brzegowy Thread. Zmianę #18104, pierwszy wkład Pawła Puterli w ESPHome, scalono z gałęzią rozwojową 15 października 2026, a dokumentacja trafiła tego samego dnia do gałęzi next serwisu esphome.io. Gałąź rozwojowa ma już numer 2026.11.0-dev, więc funkcja powinna się pojawić w ESPHome 2026.11. W wydaniu 2026.10, które wciąż jest w fazie beta, jej nie będzie.

Do tej pory komponent openthread potrafił zrobić z węzła ESPHome wyłącznie urządzenie Thread, a dokumentacja odsyłała po osobny router brzegowy, bez którego węzeł nie połączy się z Home Assistantem. Router brzegowy przekazuje ruch IPv6 między siecią Wi-Fi a energooszczędną siecią kratową Thread. Teraz tę funkcję może pełnić sam ESP32.

Wbudowane radio albo zewnętrzny koprocesor

Router brzegowy da się zbudować na dwa sposoby.

ESP32-C5 i ESP32-C6 mają w jednym układzie Wi-Fi i radio 802.15.4, więc wystarczy im jeden dodatkowy klucz w konfiguracji:

network:
  enable_ipv6: true

openthread:
  border_router: {}
  network_key: !secret thread_network_key

Każdy inny ESP32 z Wi-Fi, na przykład ESP32-S3, może korzystać z zewnętrznego koprocesora radiowego OpenThread (RCP) podłączonego przez UART. Dokumentacja podaje jako jedną z możliwości przykładowy program ot_rcp z ESP-IDF uruchomiony na ESP32-H2. Domyślna prędkość UART to 460800 bodów i musi się zgadzać z ustawieniem w oprogramowaniu koprocesora. Jeśli się nie zgadza, koprocesor w ogóle nie odpowie. Gdy podłączysz opcjonalny reset_pin, ESPHome zresetuje sprzętowo koprocesor, który przestał odpowiadać, najwyżej pięć razy. Koprocesor zajmuje bezpośrednio UART1, dlatego nie da się go używać razem z komponentem uart, a dziennik (logger) musi korzystać z USB albo innego UART-u.

Czego wymaga konfiguracja

Tryb routera brzegowego działa tylko z ESP-IDF. Trzeba włączyć IPv6 w komponencie network i zostawić domyślne device_type: FTD. W sekcji wifi: musi być co najmniej jedna sieć, do której ESP32 się łączy, ustawienie enable_on_boot: true i żadnego punktu dostępowego, także awaryjnego. Thread startuje przy uruchomieniu tak jak dotąd, a przekazywanie ruchu zaczyna się, gdy ESP32 dostanie adres w sieci Wi-Fi. Po utracie połączenia Wi-Fi router wstrzymuje pracę i wznawia ją, gdy połączenie wróci.

Na razie eksperymentalnie

Autor przez dwa tygodnie testował wariant z wbudowanym radiem na ESP32-C6. Nie było ani restartu, ani zawieszenia routera, choć jeden przycisk IKEA BILRESA czasem reagował wolniej. Wariant z zewnętrznym koprocesorem na ESP32-S3 działał około trzech tygodni i w tym czasie układ główny zawiesił się dwa albo trzy razy. Przyczyny nie ustalono, możliwe, że winny jest sprzęt testowy. W opisie zmiany funkcja jest oznaczona jako eksperymentalna, zwłaszcza tryb z koprocesorem. Na razie lepiej się sprawdzi w sieci testowej albo jako drugi router brzegowy niż jako jedyne połączenie z zamkiem Thread w drzwiach.

Zmiana także dla obecnych urządzeń Thread

Ta sama zmiana podnosi minimalną wersję ESP-IDF dla OpenThread na ESP32 do 5.5.5, również w zwykłych urządzeniach Thread. Starsze wydania 5.5 potrafią zostawić blokadę OpenThread zajętą, a to kończy się awarią. ESP-IDF 5.5.5 jest wersją domyślną od kilku wydań, więc problem dotyczy tylko konfiguracji, w których na sztywno ustawiono starszą wersję w esp32: framework: version:. Przed aktualizacją do 2026.11 usuń to ustawienie albo podnieś wersję do 5.5.5. Konfiguracje oparte na Arduino, z którym OpenThread nigdy nie działał, zostaną odrzucone.