Migracja Hue+Z2M -> samodzielny Z2M -> Z2M w Home Assistant OS
Ostatnimi czasy zdecydowałem się wprowadzić trochę zmian do mojego “smart home”. Postanowiłem w końcu połączyć dwie sieci Zigbee (jedna na zigbee2mqtt/Conbee II - tytułowe Z2M, druga Philips Hue) w jedną, aby poprawić zasięg niektórych czujników, zmiejszyć szum w powietrzu, a w końcu aby zwolnić jeden port w switchu :)
Bazowo w Z2M miałem już kilkanaście urządzeń:
- 6 głowic grzejnikowych typu Saswell SEA802 tutaj brandowanych jako TuYa GTZ03
- 2 czujniki temperatury i wilgoci TuYa TT001ZAV20
- 4 czujniki temperatury, wilgoci i ciśenienia atmosferycznego Aqara WSDCGQ11LM
- 2 czujniki temperatury i wilogci z wyświetlaczem LED TuYa TS0201 - nie polecam, żre baterie jak szalone, średnio wymieniam co 6-8 tygodni po 2xAAA do każdego, poza tym raportują zmianę temperatury dopiero jeśli wyniosła minimum 0.7°C od ostatniego raportowania
- “magiczną kostkę” Aqara Magic Cube MFKZQ01LM
- czujnik wstrząsów Aqara DJT11LM

W sieci Hue miałem o wiele więcej urządzeń:
- 20 Hue white ambiance E14
- 3 Hue white ambiance E27 z Bluetooth
- Hue white ambiance E27
- Hue white with color ambiance E27
- Hue Go v2
- 4 Hue dimmer switch
- 2 Hue motion sensor
- 2 Lidl Silvercrest smart plug - tak, sparowały się bez problemów i działały ładnie w trybie on/off
- Ikea Tradfri E14 LED2002G5 - pamiętam że trudno było ją przełączyć w tryb parowania
Jak widać trochę tych urządzeń się namnożyło. Nie pamiętam jak dokładnie były ustawione kanały Zigbee, natomiast mam pewność, że się nie pokrywały. Co nie zmienia faktu, że współdzielą i tak już zatłoczone pasmo 2.4GHz z WiFi i Bluetooth. Mieszkam w bloku więc (jak można się domyślać) to pasmo jest bogate w zakłócenia. Możliwość zamiany świateł Hue w routery Zigbee pozwoliła na zwiększenie niezawodności sieci.
Skrócona teoria o sieci Zigbee⌗
Jeśli ktoś nie miał doświadczenia z siecią Zigbee śpieszę z tłumaczeniem, dlaczego użyłem liczby mnogiej przy “routery”. Jesteśmy przyzwyczajeni, że mówiąc “router” mamy w głowie obraz urządzenia od operatora internetu (albo własnego urządzenia sieciowego), które potocznie mówiąc - daje nam internet i jest zawsze jedno w domu. W sieci zigbee są trzy typy urządzeń: koordynator, router, urządzenie końcowe. Zawsze jest tylko jeden koordynator - on zarządza siecią (hasło, kanał, przyłączanie), może być wiele routerów (a raczej wzmacniaczy, ale to nie ja ustalałem terminologię) oraz wiele urządzeń końcowych, przy czym warto zaznaczyć, że router jest jednocześnie urządzeniem. Różnica? Router musi mieć stałe zasilanie z sieci elektrycznej - dlatego żarówki automatycznie stają się routerami. Urządzenia zasilane bateryjnie zatem nie mogą rozszerzać zasięgu sieci. Warto zaznaczyć, że sieć Zigbee jest siecią typu mesh, czyli jedno urządzenie może być połączone z wieloma innymi w tej samej sieci (ale oczywiście ze względów oszczędności baterii, te przeważnie łączą się tylko z najbliższym routerem).
Migracja etap 1: Hue -> Z2M⌗
Dużo się napisałem, ale nawet nie udało mi się przejść do meritum :)
Posiadając Home Assistanta, zastanawiałem się czy nie przejść na wbudowaną integrację ZHA. Z drugiej strony mam adapter ConBee II, więc miałem również do dyspozycji deconz. Kilka wieczorów później - po czytaniu wielu za i przeciw - zdecydowałem się pozostać przy Z2M z kilku powodów:
- mam już działającą sieć, a że jestem leniwy, to nie chce mi się parować na nowo obecnych urządzeń
- szybko dodawane nowe urządzenia do bazy
- niezależność od Home Assistant (co na pierwszy rzut oka jest dziwnym argumentem, ale jak sami zaczniecie restartować HA, żeby przeładować konfigurację, to zrozumiecie - ZHA też się restartuje)
- stabilność (w deconz wychodzi że to loteria, bo jednym regularnie się zawiesza, innym działa miesiące bez zająknięcia)
Jak wybór się dokonał - przyszedł czas na działanie. Na pierwszy rzut poszła żarówka Tradfri. Ona była… oporna. Gdybym miał więcej jej podobnych, płakałbym. Po pierwsze - musiałem ją jakoś przełączyć w parowanie. Sposób z instrukcji zadziałał mi dopiero z n-tym razem (przestałem liczyć) i opiera się na sekwencji wł/wył zasilania z przytrzymaniem chwilę w stanie wył. Po drugie - musiałem specjalnie wygrzebać jakąś lampkę z oprawką E14, żeby podłączyć ją koło koordynatora, bo oczywiście trzeba parować z odległości ok. 20 cm. Razem zajęło mi to jakieś 10 min. Przyznaję, że byłem zniechęcony.
Na szczęście nie na darmo się mówi że Hue to system premium. Gdyby podliczyć ile czasu zajęło mi sparowanie wszystkich Hue razem wziętych, to myślę że te 26 żarówek sparowałem w 15 min. Praktycznie od razu po usunięciu z mostka Hue przyłączały się do sieci Z2M i po kilku sekundach były już skonfigurowane. I to niezależnie jak daleko były od koordynatora. Podobnie gniazdka Silvercrest - pyk i już. Piloty dimmer switch oraz czujniki ruchu wymagały resetu przyciskiem “setup” z tyłu urządzenia, ale też nie sprawiły żadnych problemów. Polecam po dołączeniu każdego urządzenia nadać mu własną nazwę, aby nie zastanawiać się potem który identyfikator jest którym światłem.
Ze względów praktycznych migrowałem światła stopniowo przez kilka dni, zostawiając na koniec te które posiadały automatyzacje oparte o czas i czujniki ruchu. Dla nich musiałem pomyśleć od razu jak przenieść automatyzację na HA.
Migracja etap 2: urządzenia, grupy i sceny⌗
Grupy Zigbee są prostym konstruktem z punktu widzenia użytkownika. Bierzemy urządzenia (najlepiej jednakowego typu), przypisujemy im identyfikator grupy i gotowe. Co nam to daje? Polecenie wydane grupie jest jedno dla każdego urządzenia i mogą dzięki temu reagować od razu wszystkie naraz, np. światła w żyrandolu zapalają się jednocześnie. Podejrzewam (bo nie sprawdzałem), że właśnie tym są pomieszczenia i strefy w Hue Bridge. Do grup można przypisywać sceny (jak w Hue!), czyli zapamiętany stan urządzeń. Ja utworzyłem sobie grupy, a w nich sceny, per żyrandol lub funkcje. Np. dwa żyrandole korytarzowe z łącznie 6 żarówkami, ze scenami na dzień, wieczór i noc.
Przy okazji okazało się, że gniazdka Silvercrest są eksponowane do Home Assistant jako przełączniki (switch). Normalnie nie jest to problemem, natomiast u mnie sterują one światłem podszafkowym, więc wolałbym aby prezentowały się jako światła (light). Znalazłem gdzieś sposób wiążący się z ręczną edycją pliku konfiguracyjnego Z2M. Odnalazłem tam wpis odpowiadający urządzeniu i dopisałem do niego kilka linii związanych właśnie z jego prezentacją. Na zapas dodałem identyczne zapisy do konfiguracji grupy obejmujących te gniazdka. Potrzebne linie to sekcja homeassistant:
'0xbc33acfffe7035d4':
friendly_name: Kitchen Left
homeassistant:
switch:
type: light
object_id: light
light:
name: Kitchen Left
value_template: null
state_value_template: '{{ value_json.state }}'
Oczywiście 0x to identyfikator urządzenia. Standardowo posiadają jedynie wpis friendly_name (o ile został nadany w UI). Jedyne co można zmienić to name, czyli nazwa raportowana do Home Assitant.
Następny problem: światła Hue do parowania zostały zresetowane do ustawień fabrycznych, co oznacza że mają również zresetowany “power-on behavior after power loss”, czyli ogólnie - co mają zrobić jak zostanie im przywrócone zasilanie po zaniku napięcia. U mnie część świateł Hue cały czas jest wyłączana zwykłymi przełącznikami ściennymi, co z punktu widzenia Hue nie różni się niczym od takiego np. zaniku prądu w mieszkaniu. Domyślnym zachowaniem jest: zaświeć 100% jasnością z barwą neutralną (~3500K). Chciałem jednak takiego samego zachowania jak z mostkiem Hue, czyli “przywróć stan sprzed zaniku” (szczególnie jeśli mowa o świetle łazienkowym w trakcie niezamawianego spaceru o 3 w nocy). O ile dla Tradfri można po prostu kliknąć odpowiednią opcję w panelu Z2M, tak Hue wymaga jeszcze wysłania specjalnego komunikatu na MQTT lub właściwej komendy Zigbee. Opcja pierwsza wydawała się mniej problematyczna, więc za pomocą darmowego narzędzia MQTT Explorer autorstwa Thomasa Nordquista połączyłem się z serwerem MQTT, do którego są również podłączone Z2M i HA i dla każdej żarówki Hue wysłałem polecenie:
Temat: zigbee2mqtt/Przyjazna nazwa żarówki/set
Payload: {"hue_power_on_behavior": "recover"}
Po szczegóły i dostępne opcje dla tego wpisu odsyłam do sekcji Power on behavior dokumentacji Z2M dla dowolnego światła Hue. Zaznaczam, że Przyjazna nazwa żarówki musi być dokładnie podana, wliczając polskie znaki - jeśli takie w niej występują. MQTT Explorer upraszcza sprawę, ponieważ można w nim wygodnie skopiować właściwy prefix tematu, mając otwartą sekcję komunikatów danego urządzenia. Pamiętaj aby nie dodać przypadkiem na końcu ukośnika, bo to będzie wtedy zupełnie inny temat z punktu widzenia MQTT.
Ze scenami poszło już prosto, mając otwarte ustawienia grupy dostosowywałem ustawienia świateł i zapisywałem pod kolejnymi numerami scen w danej grupie. ID sceny w obrębie jednej grupy musi być unikalne. Jeżeli chcę coś zmienić w scenie, to muszę ją przywołać, zmienić co potrzeba, usunąć starą scenę i pod tym samym ID zapisać nową. ID będzie mi później potrzebne w Home Assistant do wprowadzenia bezpośredniej ich obsługi.

Migracja etap 3: samodzielna instancja Z2M + MQTT -> Addony w HA OS⌗
Do tej pory Z2M i MQTT działały na Raspberry Pi Zero W. Home Assitant na Raspberry Pi 4. Jak można się domyślać, automatyzacje były zatem zależne od połączenia sieciowego. Posiadając sprzęt prosumencki (UniFi), nie uruchamia się on przeciętne urządzenia do domu, tylko startuje powoli, dokonując diagnostyki. I tak ze względu na specyficzny rozkład sieci, po powrocie zasilania AP mam dostępny po około 4-5 minutach. Tyle zatem HA nie wie co się dzieje w sieci Zigbee. Chcąc uniknąć ponownego parowania i ustawiania sieci Zigbee postanowiłem przenieść kombinację Mosquitto (broker MQTT) + zigbee2mqtt do oficjalnych addonów w Home Assistant Operating System (HAOS). Zrobiłem to w dwóch krokach:
- Migracja Mosquitto
- Migracja zigbee2mqtt

Moquitto⌗
Pierwszy krok był bajecznie prosty: instalacja addonu Mosquitto broker, utworzenie użytkownika w HA (wybrałem nazwę mqtt i dowolne hasło, które za chwilę będzie potrzebne, użytkownik tylko lokalny, bez administratora), ponieważ ten addon potrafi wykorzystać system użytkowników HA. W konfiguracji addonu dopisałem w konfiguracji
logins:
- username: zigbee2mqtt
password: hasło_zigbee2mqtt
abym mógł połączyć się zewnętrzną instancją Z2M. Z perspektywy czasu i zrozumienia dokumentacji, podejrzewam że równie dobrze mogłem utworzyć analogicznie użytkownika w HA i on również by działał ¯\(ツ)/¯. Następnie w konfiguracji Z2M na RPi0 zmieniłem wskazanie na broker MQTT na nową instancję. Restart Z2M i chwila prawdy. MQTT Explorer podłączony również do nowej instancji (z lenistwa na tych samych hasłach co Z2M) po chwili pokazał napływające komunikaty. Skierowałem się następnie do konfiguracji integracji MQTT w HA i zrobiłem jej rekonfigurację ze wskazaniem adresu instancji na core-mosquitto (sieć wewnętrzna dockera HAOS) oraz użytkownika i hasła mqtt. Poczekałem na nowe odczyty sensorów, sprawdziłem kilka świateł na wyrywki - działa.
Zigbee2mqtt⌗
Drugi krok budził we mnie niepokój. Addon Z2M wymaga części konfiguracji w UI, a części w osobnych plikach YAML. Nie będę już wnikał w szczegóły, podam tylko finalne wnioski. W folderze konfiguracji HA należy utworzyć folder zigbee2mqtt (domyślna z konfiguracji addona), a w nim dwa pliki: devices.yaml i groups.yaml. Jak można się domyślić do pierwszego z nich należy przekopiować sekcję devices, a do drugiego groups ze źródłowego pliku configuration.yaml. Następnie należy przyrównać ekran konfiguracji addona z plikem tym samym plikiem configuration.yaml i przenieść odpowiednie wartości pól. U mnie to było: user, password, port (gdzie wskazałem /dev/serial/by-id/MOJE_CONBEE), musiałem także zaraz pod port wskazać adapter: deconz, bo inaczej Z2M nie wstawało. Kolejne: pan_id, channel, network_key. Pamiętaj że część
frontend:
port: 8099
experimental:
new_api: true
musi pozostać bez zmian, aby można było załadować UI Z2M w HA (a nie będzie ono bezpośrednio dostępne - ustawienia addonu nie pzwalają na wystawienie portu UI poza sieć dockera).

Test⌗
Wyłączenie RPi0, przepięcie Conbee II do RPi4 na przedłużaczu USB (z doświadzenia oraz komentarzy w internecie wiem, że bazpośrednie wpięcie będzie powodowało za duże zakłócenia spowodowane chyba wbudowanym WiFi i BT w RPi4, ale nie sprawdzałem jeszcze czy wyłączenie w konfiguracji startowej jakoś na to wpłynie).
Start addonu Z2M iii… fiasko. Ale jeśli czytasz to po kolei, to już wiesz że pierwsza próba była bez adapter: deconz. Dopisane, restart addonu iii… chyba działa. Wartości na sensorach się zaczynają aktualizować, ale UI Z2M się nie ładuje. Okazało się że z rozpędu próbowałem ustawić port jak na poprzedniej instancji. Przywróciłem 8099 i finalnie już wszystko działa jak należy.

Jeszcze tylko zrobić pełny backup i mogę odpocząć :)