Hub producenta czy własny koordynator?

Ta lekcja nie jest kolejnym katalogiem protokołów. Powstała z analizy realnych pytań z Home Assistant Community i r/homeassistant: czy sceny Hue przejdą do ZHA, czy można przenosić urządzenia SmartThings po jednym, czy DIRIGERA przez Matter Bridge wystarczy, co stracę po usunięciu Aqara Hub, dlaczego po migracji automatyzacje odwołują się do starych urządzeń i czy da się zachować aktualizacje firmware.

Zobaczysz cztery różne operacje, które często są wrzucane do jednego worka: integrację istniejącego huba, użycie Matter Bridge, prawdziwą migrację urządzenia do własnego koordynatora oraz całkowitą wymianę rozwiązania. To ważne, bo każda z nich ma inny poziom ryzyka.

Na przykład Philips Hue może pozostać na swoim Bridge i działać z Home Assistant lokalnie. HA importuje sceny Hue, widzi sensory i piloty, a sam Bridge nadal zarządza oświetleniem. Przeniesienie wszystkich lamp do ZHA lub Zigbee2MQTT może dać jeden wspólny mesh, ale oznacza także odtworzenie scen i części funkcji producenta.

IKEA DIRIGERA może udostępnić urządzenia Zigbee do Home Assistant przez Matter Bridge, bez ich resetowania. Aqara Hub również może pełnić rolę lokalnego bridge, ale nie każda funkcja producenta musi być widoczna przez Matter. W przypadku SmartThings dochodzi jeszcze aktualny w 2026 temat zmian w dostępie do API, dlatego migracja lokalnych urządzeń Zigbee i Z-Wave może mieć dziś większy sens niż kilka lat temu.

Osobno rozbieramy Tuya, bo urządzenie Wi‑Fi Smart Life i czujnik Zigbee podłączony do bramki Tuya to dwie zupełnie różne sytuacje. Pokazujemy też HomeKit Device i HomeKit Bridge, w tym bardzo ważną zasadę: zanim usuniesz urządzenie HomeKit z Apple Home, upewnij się, że masz jego kod parowania.

Dużo miejsca poświęcamy też temu, czego użytkownicy często dowiadują się dopiero podczas migracji: urządzenie o tej samej nazwie nie musi mieć tego samego wewnętrznego identyfikatora w Home Assistant, więc automatyzacja odwołująca się do device_id może wymagać poprawki. Pokazujemy, jak przed resetem zapisać entity_id, powiązania, sceny, dashboardy i ekspozycję do asystentów głosowych.

Jest też osobna sekcja o Google Home, Alexa i Apple Home. Po migracji bardzo łatwo przypadkowo wystawić to samo urządzenie dwa razy: raz przez stary hub, a drugi raz przez Home Assistant. Efektem są duplikaty, błędne pokoje i komendy kierowane do starej encji. Lekcja prowadzi przez czyszczenie takich zależności bez kasowania wszystkiego naraz.

Zamiast wielkiego „weekendu migracyjnego” proponujemy przeprowadzkę funkcjonalną: jedno niekrytyczne urządzenie, potem jeden pokój, potem kolejne strefy. Stary i nowy system mogą przez pewien czas działać równolegle. Dzięki temu nie wyłączasz całego domu tylko po to, żeby sprawdzić, czy nowy koordynator i nowa integracja faktycznie są lepsze.

Dostajesz również macierz decyzji dla Hue, DIRIGERA, Aqara, SmartThings, Tuya i HomeKit: co domyślnie zostawić, kiedy integrować, kiedy warto migrować oraz co koniecznie sprawdzić przed factory resetem. To nie jest ranking producentów, tylko narzędzie do podejmowania decyzji we własnym domu.

Dostajesz także gotową kartę migracji huba oraz test odbiorowy jednego urządzenia. Po tej lekcji nie będziesz pytać „jak pozbyć się wszystkich hubów?”, tylko „które huby są nadal użyteczną częścią architektury, a które rzeczywiście warto zastąpić?”.

Lekcja zawiera też proste drzewko decyzji. Jeżeli hub ma dobrą lokalną integrację, zaczynamy od niej. Jeżeli może działać jako Matter Bridge, sprawdzamy bridge. Dopiero gdy obecna architektura ma konkretny problem i docelowa integracja obsługuje potrzebne funkcje, przechodzimy do prawdziwej migracji urządzenia.

Przed pierwszym resetem tworzysz minimalną dokumentację: stary hub, model urządzenia, entity_id, automatyzacje, sceny, ekspozycję do głosu, wersję firmware i procedurę resetu. To kilka minut pracy, które przy większej instalacji może uratować wiele godzin późniejszego odtwarzania konfiguracji.

Na końcu nie oceniamy sukcesu po samym komunikacie „urządzenie dodane”. Po siedmiu dniach porównujesz stabilność, funkcje, wygodę domowników, aktualizacje i zachowanie po restarcie. Jeżeli nowa architektura jest bardziej skomplikowana i niczego realnie nie poprawia, powrót do starego huba jest poprawną decyzją.

Osobna procedura dotyczy zamków, bram, alarmu, ogrzewania i zaworów. Zanim je ruszysz, musisz znać metodę ręcznego sterowania, awaryjny dostęp, właściciela konta, użytkowników i PIN-y, zachowanie po awarii HA oraz sposób powrotu do poprzedniej konfiguracji.

Pokazujemy też, jak nie pomylić problemu radiowego z problemem IP: koordynator PoE, Zigbee2MQTT, MQTT, Z-Wave JS i Home Assistant działają po sieci, więc zanim ponownie zresetujesz czujnik, sprawdzasz VLAN-y, firewall, DHCP i łączność usług.

Cel nie brzmi: najmniej pudełek. Cel brzmi: najmniej niepotrzebnych zależności i pewny plan awarii.