Piloty i przyciski IKEA w Zigbee2MQTT i Home Assistant: modele, akcje, binding i sterowanie bez chmury
Piloty i przyciski to kategoria urządzeń IKEA, w której najwięcej zależy od wersji firmware: dosłownie ten sam model, kupiony rok wcześniej i rok później, potrafi zachowywać się inaczej, wspierać inny zestaw akcji i inaczej reagować na binding. To nie jest niedopatrzenie z mojej strony: to fakt, z którym trzeba się zmierzyć, bo IKEA regularnie aktualizuje firmware, zmieniając realne zachowanie przycisków.
Łączę tu dwa nierozłączne tematy: konkretne modele pilotów wraz z ich akcjami, oraz binding: mechanizm, dzięki któremu pilot steruje żarówką czy roletą bezpośrednio, bez pośrednictwa Home Assistant.
12
Modeli pilotów
4
Sposoby komunikacji
SOMRIG
Bez wsparcia bindingu
21658
Stała grupa BILRESA
Seria: IKEA Smart Home × Home Assistant
Jak pilot komunikuje się z systemem
Action
Pilot wysyła komendę lub zdarzenie na określonym klastrze Zigbee, konwerter Zigbee2MQTT tłumaczy to na pole
action w stanie MQTT urządzenia. Sam fakt braku klasycznej encji sensor…action w HA nie oznacza, że pilot nie działa: patrz niżej.Binding
Wpis w tabeli bindingów urządzenia źródłowego: endpoint źródłowy, adres docelowy (urządzenie, endpoint albo grupa) i klaster, którego dotyczy. Po skonfigurowaniu pozwala wykonać podstawowe komendy bez udziału automatyzacji HA i MQTT, ale urządzenia nadal należą do sieci utworzonej i utrzymywanej przez koordynator.
Touchlink
Mechanizm commissioning/inter-PAN z rodziny Zigbee Light Link, używany m.in. do identyfikacji, resetu fabrycznego, dołączania do sieci i manipulowania grupami z bliskiej odległości. Ryzyko: wykonany na urządzeniu należącym do innej sieci może je z tej sieci usunąć: to nie jest niewinna alternatywa dla Permit Join.
Matter event
Dotyczy nowszych pilotów jak BILRESA w natywnym trybie: komunikacja przez Thread, nie Zigbee, obsługiwana przez kontroler Matter, do którego urządzenie zostało dodane.
Pełna droga komendy wygląda tak: pilot Zigbee → komenda na klastrze → konwerter Zigbee2MQTT → pole
action w MQTT → MQTT Device Trigger / event entity / legacy sensor → automatyzacja Home Assistant. To trzy różne, niezależnie skonfigurowane warstwy: MQTT Device Trigger to obecnie zalecany mechanizm, encja event jest eksperymentalna (wymaga homeassistant.experimental_event_entities: true), a klasyczny sensor action jest zdeprecjonowany. Więcej o każdym z nich w sekcji o Zigbee2MQTT 2.x niżej.Jak czytać akcje
Nazwy akcji nie są jednym, zunifikowanym standardem IKEA: zależą od konkretnego modelu, firmware, konwertera Zigbee2MQTT, klastra i generacji urządzenia. SOMRIG publikuje
1_initial_press, E1812 publikuje on/off, E1766 publikuje open/close, a BILRESA on_double/off_double. Traktuj poniższą tabelę jako mapę pojęć, nie listę realnych wartości jednego modelu.Czas oczekiwania przed zarejestrowaniem podwójnego kliknięcia zależy od konkretnego firmware: nie ma jednego typowego zakresu dla całej kategorii. Może wynosić od kilku dziesiątych sekundy (E1812 ok. 0,6 s, BILRESA E2490 ok. 0,5 s) do około jednej sekundy (BILRESA E2489). Pilot z
initial_press (np. SOMRIG) pozwala obejść to opóźnienie, ale wtedy automatyzacja musi uważać, aby nie wykonać tej samej funkcji ponownie po short_release: patrz sekcja SOMRIG.STYRBAR (E2001/E2002/E2313): najbardziej kapryśny pilot w ofercie
Czteroprzyciskowy pilot (włącz/wyłącz, jasność góra/dół, strzałki lewo/prawo) z akcjami
on, off, brightness_move_up/down, brightness_stop, arrow_left/right_click/hold/release, i najdłuższą historią problemów po aktualizacjach firmware udokumentowaną na GitHubie. Aktualna dokumentacja Zigbee2MQTT grupuje pilota pod jedną stroną modelu E2001/E2002/E2313: E2313 to nowsza wersja na baterie AAA (starsze E2001/E2002 korzystają z ogniwa guzikowego), z zestawem akcji identycznym dla wszystkich trzech wariantów. Ponieważ zestaw akcji i wymogi bindingu zmieniały się wraz z konwerterami i firmware, przed ręcznym wpisywaniem listy akcji zawsze sprawdź pole Exposes na stronie własnego egzemplarza w Zigbee2MQTT.Brak akcji po aktualizacji firmware: po aktualizacji część lub wszystkie przyciski przestają cokolwiek wysyłać, mimo że urządzenie pozostaje online. Zigbee2MQTT dostosowuje domyślną konfigurację bindingu z opóźnieniem względem premiery nowego firmware: stąd cykliczny powrót tego problemu przy każdej większej aktualizacji.
Binding: nie jest to proste „dodaj genScenes”. Aktualna dokumentacja opisuje bardziej specyficzną logikę zależną od celu:
Jeśli chodziło Ci o pilota dwuprzyciskowego z funkcją koloru: to nie jest STYRBAR (ten jest zasadniczo czteroprzyciskowy). Dwuprzyciskowe piloty IKEA to RODRET i E1743, opisane niżej; żaden z nich standardowo nie steruje CCT. Nie nazywaj tej wersji STYRBAR bez potwierdzenia dokładnego numeru modelu.
Kolejność działań po utracie akcji: zanim sięgniesz po
force remove: wybudź pilota, wykonaj Reconfigure, sprawdź zakładkę Bind i porównaj listę bindingów z wymogami aktualnej wersji firmware, wykonaj bindingi na nowo zgodnie z dokumentacją, a jeśli endpointy lub klastry się zmieniły: wykonaj Re-interview. Dopiero gdy żaden z tych kroków nie pomaga, usuń urządzenie i sparuj je od nowa: pamiętając, że ponowne parowanie może zmienić device ID, encje, MQTT Device Triggers, grupy i bindingi, więc trzeba będzie poprawić powiązane automatyzacje.Restart całego kontenera Zigbee2MQTT po ręcznej zmianie external convertera to procedura deweloperska, nie standardowa ścieżka diagnostyczna: dotyczy głównie osób testujących własne poprawki konwertera, nie typowej diagnostyki STYRBAR.
RODRET (E2201): prosty kontroler światła, nie tylko włącz/wyłącz
Dwuprzyciskowy kontroler światła: poza prostym
on/off obsługuje też przytrzymanie: brightness_move_up/brightness_move_down ze brightness_stop po puszczeniu, a podwójne naciśnięcie każdego przycisku po prostu powtarza on/off. Nie sprowadzaj go więc do prostego, binarnego przycisku: ma mniej rozbudowaną logikę niż STYRBAR, ale nie jest od niej pozbawiony.Wsparcie bindingu jest obecne od pierwszej udokumentowanej wersji firmware i rzadko pojawia się w zgłoszeniach problemów po aktualizacjach: jest jednym z prostszych modeli do bezpośredniego sterowania światłem, w praktyce poleciłbym go osobie, która potrzebuje tylko włączania i ściemniania. Można go bindować do wielu standardowych lamp Zigbee obsługujących klastry On/Off i Level Control: nie jest to jednak gwarancja zadziałania z dowolną żarówką: wymaga zgodnych endpointów, wspieranych klastrów po stronie lampy i braku nietypowych ograniczeń producenta. To jedna z ważniejszych różnic względem SOMRIG, o czym niżej.
SOMRIG (E2213): pilot bez wsparcia bindingu
Dwuprzyciskowy „shortcut button”. Fakt potwierdzony w dokumentacji Zigbee2MQTT: SOMRIG nie może bezpośrednio kontrolować urządzeń ani grup przez binding ani przez Touchlink: urządzenie w ogóle nie eksponuje takiej możliwości. Wniosek praktyczny: całą logikę trzeba oprzeć na automatyzacjach HA, traktując SOMRIG jako kontroler serwerowy. Nie jest to jednak potwierdzona, oficjalna filozofia projektowa IKEA: to obserwacja zachowania urządzenia, nie deklaracja producenta.
Zestaw akcji jest bogatszy:
1_initial_press, 1_short_release, 1_long_press, 1_long_release, 1_double_press (analogicznie dla przycisku 2). initial_press wysyłane jest natychmiast po naciśnięciu, zanim urządzenie ustali, czy nastąpi double czy hold: ale jeśli automatyzacja reaguje na initial_press i jednocześnie na double_press lub long_press tą samą funkcją, wykonają się obie: np. najpierw zapali się główne światło, a potem uruchomi scena nocna. Wybierz jeden z dwóch wzorców: szybki (reakcja tylko na initial_press, ignorowanie reszty, najkrótsze opóźnienie) albo wielofunkcyjny (brak reakcji na initial_press, reakcja dopiero na short_release/double_press/long_press, większe opóźnienie, brak konfliktów).Urządzenie śpi: podobnie jak inne baterie IKEA, SOMRIG trzeba wybudzić naciśnięciem przycisku przed OTA, identify, Reconfigure czy próbą bindingu (który i tak się nie powiedzie). Używaj świeżej baterii AAA: niski poziom baterii utrudnia komunikację z Z2M jeszcze bardziej niż w innych modelach. Brak bindingu mimo aktywnego, sparowanego urządzenia to normalne zachowanie, nie usterka: użytkownicy narzędzi jak ControllerX czasem oczekują domyślnie zachowania typowego dla RODRET czy E1743. Ze względu na bogaty zestaw zdarzeń SOMRIG ma dobre wsparcie gotowych blueprintów w społeczności.
Starsze piloty: E1524/E1810 (TRADFRI remote control)
Klasyczny, pięcioprzyciskowy pilot pierwszej generacji (przycisk centralny plus jasność góra/dół i strzałki lewo/prawo), z akcjami
toggle, brightness_up/down_click/hold/release, toggle_hold, arrow_left/right_click/hold/release.IKEA zmieniła w międzyczasie schemat numerowania firmware z
2.x.x na 24.x.x: wersja 24.4.5 w tabeli niżej to nie literówka, tylko nowszy, wyższy numer niż 2.3.080.Jeśli binding „nie działa”, zanim zaczniesz szukać błędu w konfiguracji, sprawdź dokładną wersję firmware i porównaj z tabelą: bardzo możliwe, że próbujesz wykonać operację niewspieraną w Twojej wersji.
Binding działa nie jako „wszystko albo nic”, lecz per funkcja: nawet po udanym zbindowaniu do grupy czy urządzenia część funkcji pilota może pozostać niedostępna:
Na firmware
24.4.5 udokumentowana ścieżka do pełnego bindingu grupowego to: zbindować genBasic do grupy, a następnie odpiąć wszystko inne, łącznie z koordynatorem (na starszym firmware ten drugi krok bywa zbędny): to włącza toggle, ściemnianie i sceny naraz, a akcje nadal trafiają do Zigbee2MQTT.Środkowy przycisk: toggle przed toggle_hold: przy przytrzymaniu środkowego przycisku pilot wysyła zarówno
toggle, jak i toggle_hold: nie da się pominąć wcześniejszego toggle, a pilot nie wysyła osobnego zdarzenia puszczenia. Automatyzacja uruchamiana przez toggle wykona się też przed toggle_hold: nie projektuj dla nich osobnych, sprzecznych funkcji bez uwzględnienia tego zachowania.Tryb automatyzacji ma znaczenie: dokumentacja E1524/E1810 ostrzega, że automatyzacje reagujące na click/release nie powinny być ustawione w trybie
restart, bo szybko po sobie następujące zdarzenia mogą przerwać wcześniejsze wykonanie. Dla pilotów sensowniejszy bywa tryb single (ignoruje kolejne szybkie kliknięcia) albo queued (zachowuje kolejność): parallel może uruchomić sprzeczne akcje naraz.Zigbee2MQTT 2.0.0: legacy action sensor: od tej wersji domyślnie wyłączono publikowanie klasycznych encji
sensor.*_action, zastępując je MQTT Device Trigger. Dla automatyzacji opartych o stary format oznaczało to nagłe, całkowite zniknięcie reakcji na przyciski, mimo że pilot fizycznie działał. Funkcja jest zdeprecjonowana, domyślnie wyłączona i ma zostać usunięta w przyszłości: Zigbee2MQTT zaleca migrację do MQTT Device Trigger.homeassistant: enabled: true legacy_action_sensor: true
enabled: true pokazane jest tu dla kompletności przykładu, nie dlatego, że trzeba je dopisywać przy każdej instalacji: samo legacy_action_sensor nie włącza integracji z Home Assistant. Warto też wiedzieć, że po każdej publikacji akcji Zigbee2MQTT publikuje pustą wartość action, aby wymusić zmianę stanu encji przy kolejnym identycznym kliknięciu: sekwencja {"action":"on"} → {"action":""} to normalne zachowanie, nie zgubione zdarzenie.E1743 (on/off switch) i E1812 (shortcut button)
E1743 to prosty, dwuprzyciskowy przełącznik ścienny na baterie, z akcjami
on, off, brightness_move_up/down, brightness_stop. Parowanie: czterokrotne naciśnięcie pod pokrywą baterii: czerwona dioda mignie, zgaśnie, po chwili zapulsuje (łatwiej ją zaobserwować od tyłu obudowy); po połączeniu gaśnie na dobre. Po wymianie baterii raportowanie procentu potrafi przestać działać: czasem pomaga usunięcie i ponowne dołączenie urządzenia.Binding E1743 nie działa według tej samej logiki co E1524/E1810: ma własny, węższy zakres wersji: poniżej
2.3.075 obsługuje tylko binding do grup, od 2.3.075 wzwyż: tylko do urządzeń. W obecnej dokumentacji nie ma dla E1743 odpowiednika wersji 24.4.5, która u E1524/E1810 pozwala na oba scenariusze naraz.Model eksponuje przestarzały format
click obok action: warto ustawić legacy: false w opcjach urządzenia, żeby nie zaśmiecać logu. Nie myl tego z homeassistant.legacy_action_sensor: devices: {'0x...': {legacy: false}} steruje starym polem click konkretnego urządzenia, a homeassistant.legacy_action_sensor tworzy w Home Assistant osobny, zdeprecjonowany sensor action. To dwa różne mechanizmy.E1812 to pojedynczy, okrągły przycisk do bezpośredniego sterowania (jak RODRET). Na starszym firmware pojedyncze kliknięcie jest wysyłane natychmiast, ale urządzenie ma bardzo długi, 0,4-sekundowy debounce blokujący kolejne naciśnięcia: to blokada, nie zaleta: nie da się na tej wersji wiarygodnie wykryć podwójnego kliknięcia. Na firmware od 24.4.6 dochodzi rozpoznanie podwójnego kliknięcia (
off), kosztem ok. 0,6-sekundowego opóźnienia przed zarejestrowaniem pojedynczego kliknięcia jako on. Trzecie i kolejne kliknięcia nie mają odrębnej akcji: mogą wygenerować serię naprzemiennych off/on, to nie jest użyteczna obsługa „kliknięć wielokrotnych”.Binding też ewoluował: starsze wersje pozwalały bindować do wielu urządzeń i grup jednocześnie; najnowsze ograniczają to do wielu urządzeń (klastry
genOnOff i genLevelCtrl) albo jednej grupy: dla grupy jedynym udokumentowanym rozwiązaniem jest zbindowanie genBasic po odpięciu wszystkiego innego, łącznie z koordynatorem.Nie przenoś tej konfiguracji na inne piloty: binding grupowy przez samo
genBasic to udokumentowany, model-specyficzny wyjątek E1812, nie ogólna zasada bindingu Zigbee.Ryzyko drenażu baterii: E1812 zbindowany bezpośrednio do urządzenia, które jest offline, może spamować sieć i szybko rozładowywać baterię. Binding do grupy jest pod tym względem bezpieczniejszy.
Touchlink znika po aktualizacji: pierwotne firmware udostępniało Touchlink (bez komendy Off), a od wersji 24.4.6 Touchlink został z urządzenia usunięty. To dobry przykład, że OTA może zabrać funkcję, nie tylko ją dodać.
ICTC-G-1: pokrętło, które zalewa system wiadomościami
Okrągłe pokrętło obrotowe do ściemniania, znane z problemu udokumentowanego jeszcze w 2019 roku: podczas obracania może generować gęsty strumień zdarzeń Zigbee w krótkim czasie. Wpływ na system zależy od konwertera, konfiguracji MQTT, liczby uruchamianych automatyzacji, poziomu logowania i mocy hosta: na słabszym sprzęcie (starszy Raspberry Pi) potrafi obciążać MQTT, logi i źle zaprojektowane automatyzacje, ale nie należy zakładać, że sam pilot zwykle zawiesza cały Home Assistant.
Filtrowanie mechanizmem
debounce (opisanym szerzej przy SYMFONISK niżej) nie zawsze jest właściwym rozwiązaniem dla płynnego pokrętła: może powodować skokową regulację, utratę końcowego położenia, pominięcie stop albo nierówną responsywność. Warto rozróżnić debounce całej wiadomości od ignorowania wybranych pól (debounce_ignore), throttling po stronie automatyzacji, użycie brightness_step zamiast wartości absolutnych, simulated_brightness albo bezpośredni binding: każde z tych podejść ma inny kompromis między płynnością a obciążeniem sieci.SYMFONISK: obrót, debounce, multimedia, dot buttons
E1744 (generacja 1) to obrotowy pilot z przyciskiem centralnym:
toggle, brightness_move_up/down, brightness_stop, brightness_step_up/down. Jego akcje i ergonomia wynikają jednak z przeznaczenia multimedialnego (sterowanie głośnikiem SYMFONISK): może pełnić rolę uniwersalnego kontrolera automatyzacji, w tym światła, ale nie wszystkie jego akcje odpowiadają natywnym komendom lamp.Podczas obracania generuje wiele komunikatów z tym samym payloadem, bo urządzenie nie wysyła zdarzenia rozpoczęcia obrotu: samo
debounce bez dodatkowych ustawień przepuściłby tylko ostatni komunikat (rotate_stop). Dokumentacja Z2M zaleca dodać debounce_ignore: [action]: pole action jest wtedy chronione przed nadpisaniem w oknie debounce, więc każda unikalna wartość action (np. pierwsze rotate_left i końcowe rotate_stop) zostanie opublikowana osobno: to nie oznacza automatycznie „zachowaj akcje, odfiltruj resztę”, tylko konkretny mechanizm ochrony jednego pola przed deduplikacją:'0xTWOJADRESIEEE':
friendly_name: symfonisk_pokretlo
debounce: 0.5
debounce_ignore:
- action
Jeśli potrzebujesz też każdego pojedynczego kroku jasności (a nie tylko unikalnych wartości akcji), dodaj do listy również
brightness i skróć czas debounce (np. do 0.1 s): to kompromis między płynnością reakcji a liczbą wiadomości; warto sprawdzić efekt na własnym egzemplarzu, zanim skopiuje się gotowy przykład z innego źródła.E2123 (generacja 2) ma klasyczne przyciski multimedialne (play/pause, następny/poprzedni, głośność) oraz dwa dodatkowe „dot buttons” z pełnym zestawem:
initial_press, short_release, double_press, long_press, long_release. Binding światła nie ma tu zastosowania: możliwe jest jedynie sterowanie server-side przez akcje.Dot buttons po OTA: po aktualizacji firmware (np. do 1.0.32/1.0.35) przyciski kropkowe wielokrotnie przestawały poprawnie raportować akcje, mimo że reszta pilota działała normalnie: zgłoszenia dotyczyły zarówno całkowitego braku zdarzeń, jak i zniknięcia części z nich (np.
short_release/long_release). Przyczyną bywało przeniesienie obsługi przycisków na inne endpointy albo rozjazd między firmware a zestawem konwerterów Z2M/quirków. Najpierw spróbuj zwykłego Reconfigure oraz aktualizacji Zigbee2MQTT do najnowszej wersji: część tych problemów została naprawiona po stronie konwertera. Jeśli to nie pomoże, pełne usunięcie z bazy i ponowne sparowanie od zera pozostaje najbardziej niezawodnym rozwiązaniem udokumentowanym w zgłoszeniach społeczności.E1766 (open/close remote): rolety
Dwuprzyciskowy pilot dedykowany roletom:
open lub close po naciśnięciu odpowiedniego przycisku; gdy przycisk jest trzymany dłużej niż ok. 0,5 s, stop jest generowane dopiero po jego puszczeniu. To rezultat długiego naciśnięcia i puszczenia jednego z dwóch przycisków, nie osobne, ukryte trzecie zdarzenie.Inny klaster niż przy żarówkach: standardowe podejście (
genOnOff/genLevelCtrl) w ogóle nie steruje pozycją rolety. W interfejsie Zigbee2MQTT wybierz klaster closuresWindowCovering z listy dostępnych klastrów (nie trzeba ręcznie wpisywać identyfikatora): technicznie odpowiada to klastrowi Zigbee 0x0102.Wersje firmware liczone są w nowym schemacie IKEA: poniżej
23.0.75 pilot wspiera tylko binding do grup (trzeba najpierw odpiąć default_bind_group), od 23.0.75 wzwyż: tylko do urządzeń. Dokumentacja nie podaje żadnej motywacji tej zmiany (np. optymalizacji pod konkretny scenariusz): traktuj to jako fakt, nie interpretację.Część użytkowników zgłaszała, że zatrzymanie rolety podczas bezpośredniego bindingu działało gorzej niż sterowanie przez koordynator i MQTT. Binding wysyła standardową komendę Stop: jeśli roleta jej nie respektuje płynnie, przyczyną może być firmware konkretnej rolety, dobór pary urządzeń, konfiguracja klastra czy opóźnienie w sieci. Traktuj to jako problem konkretnego firmware lub pary urządzeń, nie jako ogólną cechę mechanizmu bindingu Zigbee.
BILRESA: Matter, nieoficjalny Zigbee, stałe grupy
Pod nazwą BILRESA kryją się dwa różne urządzenia, oba natywnie na Matter over Thread, oba z zachowanym, nieoficjalnym trybem Zigbee: tym samym mechanizmem kompatybilności wstecznej co żarówki KAJPLATS (artykuł o żarówkach). Tryb Zigbee nie jest oficjalnie wspierany przez IKEA: to efekt uboczny kompatybilności wstecznej Touchlink, nie zamierzona funkcja.
BILRESA E2489: dwa przyciski
Dostęp do trybu Zigbee wymaga pełnej, wieloetapowej procedury: zdjęcia obudowy baterii, przytrzymania przycisku parowania ok. 10 s (factory reset, dioda pulsuje bursztynowo), odsunięcia pilota od innych urządzeń Zigbee, czterokrotnego szybkiego naciśnięcia przycisku parowania (uruchomienie Touchlink), a następnie ośmiokrotnego naciśnięcia (wejście do sieci Zigbee, sygnał: diody gasną całkowicie). Odsunięcie od innych urządzeń jest ważne: Touchlink wykonany w pobliżu obcego urządzenia może przypadkiem dodać je do ukrytej grupy albo, jeśli urządzenie należy już do innej sieci, usunąć je z niej.
Wszystkie egzemplarze E2489 sterują bezpośrednio tą samą, stałą grupą Zigbee o identyfikatorze 21658 i nie da się ich przypisać do innej grupy ani odpiąć: bindingi/unbindingi wykonane przez interfejs Z2M bywają zgłaszane jako udane, ale w praktyce nie mają żadnego efektu.
Opóźnienie każdej akcji wynosi ok. jednej sekundy: pilot musi poczekać na ewentualne drugie naciśnięcie, zanim opublikuje wynik.
BILRESA E2490: pokrętło i trzy kanały
E2490 steruje trzema stałymi grupami naraz: 21658, 21659, 21660 (kanały 1–3, przełączane dolnym przyciskiem): z których grupa 21658 koliduje z E2489: jeśli w sieci są oba warianty, sterują częściowo tym samym celem.
Pilot przechowuje własny, lokalny stan on/off i jasności dla każdego kanału. Ten stan może rozjechać się ze stanem rzeczywistym grupy sterowanej równolegle z Home Assistant: np. pilot „myśli”, że lampa jest zgaszona, choć w HA świeci, i naciśnięcie wyśle komendę niezgodną z oczekiwaniem. Długie przytrzymanie pokrętła nie generuje żadnego zdarzenia Zigbee.
Wspólne ograniczenia obu modeli
To nie jest tylko ograniczony binding: jeżeli w jednej sieci Zigbee znajduje się kilka pilotów E2489, wszystkie sterują tą samą, sztywno przypisaną grupą i nie da się ich sensownie przypisać do różnych pomieszczeń przez binding. E2490 ma analogiczny problem dla trzech stałych kanałów. Nie buduj wielopokojowego systemu na nieoficjalnym bindingu BILRESA Zigbee: dwa egzemplarze nie mają niezależnych grup, jedynym praktycznym obejściem są automatyzacje po stronie Home Assistant.
Oba modele używają też niestandardowych, specyficznych dla IKEA komend do przechodzenia między scenami, opartych o grupę 65289: dodaj żarówki IKEA do tej grupy i utwórz w niej sceny, aby nadpisać domyślne (nowsze żarówki IKEA mogą tworzyć domyślne sceny automatycznie). Zgodność zależy od generacji żarówek; inne marki mogą po prostu ignorować te komendy.
Bindowanie pilota do grupy nie gwarantuje, że Home Assistant zobaczy aktualny stan sterowanych lamp: grupa w Z2M ma stan wirtualny, a przy BILRESA reporting celów trzeba skonfigurować ręcznie, inaczej HA może pokazywać nieaktualną jasność mimo poprawnego działania samego sterowania.
Aktualizacje firmware BILRESA są dostarczane przez Matter, nie przez Zigbee OTA: urządzenie trzeba dodać do zgodnego kontrolera Matter działającego przez sieć Thread (np. Apple TV/HomePod jako Thread Border Router, Home Assistant Matter Server albo DIRIGERA), który obsłuży dystrybucję aktualizacji producenta. Jeśli zależy Ci na solidnej, wielopokojowej integracji, sensowniejszym wyborem jest właśnie natywny tryb Matter (opisany w artykule o DIRIGERA i nowej generacji urządzeń): tryb Zigbee traktuj jako rozwiązanie awaryjne, nie podstawę architektury.
Binding kontra automatyzacja: kiedy wybrać co
Binding może działać bez udziału HA i MQTT, ale nie daje pełnego zestawu funkcji automatyzacji:
Binding awaryjny i automatyzacja mogą wykonać akcję podwójnie: jeżeli pilot jest jednocześnie zbindowany do lampy i wyzwala automatyzację sterującą tą samą lampą, jedno naciśnięcie może spowodować dwie komendy: toggle wykonany dwa razy (lampa wraca do stanu początkowego), podwójny krok jasności, rozjazd scen albo nieprzewidywalny transition. Binding jako plan awaryjny nie może bezrefleksyjnie działać równolegle z automatyzacją wysyłającą tę samą komendę. Rozwiązania: automatyzacja tylko dla funkcji dodatkowych (nie On/Off); binding on/off, automatyzacja tylko dla double/hold; brak automatyzacji dla akcji już obsłużonych sprzętowo;
initial_press wyłącznie do funkcji niezwiązanych z lampą docelową.Binding do grupy nie gwarantuje raportowania aktualnego stanu: pilot wysyła groupcast, a Home Assistant nie musi od razu wiedzieć, jaki stan ma każda lampa. Skonfiguruj reporting lamp, używaj grup Zigbee w Zigbee2MQTT (nie polegaj wyłącznie na wirtualnym stanie grupy) i sprawdzaj, czy wszystkie lampy faktycznie odpowiedziały; przy BILRESA reporting celów trzeba skonfigurować ręcznie.
Praktyczna zasada: podstawowe funkcje oświetlenia w krytycznych miejscach (główne światło w pokojach, korytarzu) warto zabezpieczyć bindingiem, nawet jeśli na co dzień sterujesz nimi przez bardziej rozbudowaną automatyzację, o ile zadbasz o rozdzielenie odpowiedzialności opisane wyżej. Binding pełni wtedy funkcję planu awaryjnego, nie głównego mechanizmu: szerzej w artykule wprowadzającym do serii.
Coordinator binding, endpointy i grupy: o czym łatwo zapomnieć
Binding do koordynatora a binding bezpośredni: pilot może mieć jednocześnie binding do koordynatora (żeby Zigbee2MQTT widział akcje i mógł je przekazać dalej) oraz do lampy lub grupy (żeby sterowanie działało bez HA). Usunięcie bindingu do koordynatora nie psuje sterowania bezpośredniego, ale odcina akcje od Zigbee2MQTT i automatyzacji: to szczególnie ważne przy instrukcjach nakazujących „unbind everything, including coordinator”, bo dotyczą tylko konkretnych klastrów, nie całej komunikacji z pilotem.
Source endpoint i target endpoint: pilot może mieć kilka endpointów, a różne przyciski mogą korzystać z różnych endpointów. Po aktualizacji firmware (jak w przypadku SYMFONISK E2123 wyżej) endpointy mogą się zmienić: niewłaściwy endpoint daje pozornie poprawny binding bez realnego działania. Zawsze testuj fizyczne działanie po bindingu, nie tylko komunikat sukcesu w interfejsie.
Bind do grupy ≠ dodanie urządzeń do grupy: to dwa osobne kroki: najpierw trzeba utworzyć grupę i dodać do niej lampy, dopiero potem zbindować pilota do tej grupy. Samo utworzenie pustej grupy nie sprawia, że pilot ją kontroluje, a zbindowanie pilota do pustej grupy też niczego nie steruje.
Hold/release w automatyzacjach, MQTT Device Trigger i stare blueprinty
Zdarzenia
hold i release wymagają innego podejścia niż proste click, ale nazwy tych zdarzeń różnią się między modelami: E1812 publikuje brightness_move_up + brightness_stop, SOMRIG long_press + long_release, STYRBAR move/stop i strzałki click/hold/release, a E1766 open/close, ze stop dopiero po długim trzymaniu i puszczeniu. Nie każdy pilot publikuje osobne zdarzenia rozpoczęcia i zakończenia: sprawdź to na własnym egzemplarzu przed projektowaniem automatyzacji.Pętla co ułamek sekundy może zalać sieć: skrypt cyklicznie zwiększający jasność co ułamek sekundy generuje nadmierną liczbę wywołań usług HA, wiadomości MQTT, komend Zigbee i potwierdzeń APS. Lepsze warianty: jedna komenda ruchu (
brightness_move) na start i brightness_stop na release; większe kroki co 200–500 ms; brightness_step zamiast małych zmian absolutnych; blueprinty używające natywnych komend ruchu. Zasada: nie wysyłaj kilkunastu wywołań light.turn_on na sekundę.Dokładnie ten mechanizm ruchu realizuje binding na poziomie Zigbee (komenda
MoveWithOnOff trwająca do Stop), ale jeśli zdarzenie kończące (release) zgubi się po stronie HA/MQTT, skrypt może pracować dalej, a lampa dojść do skrajnej jasności. Zabezpiecz automatyzację maksymalnym czasem pętli, timeoutem, zatrzymaniem po osiągnięciu 0/100%, resetem pomocniczego input_boolean i świadomie dobranym trybem automatyzacji (restart lub queued): warto też rozważyć osobną automatyzację bezpieczeństwa.Zalecanym sposobem reagowania na akcje w HA jest MQTT Device Trigger: Zigbee2MQTT publikuje metadane w formacie rozpoznawanym natywnie przez rejestr urządzeń, pozwalając wybrać konkretne zdarzenie wprost z listy w edytorze automatyzacji. Trigger pojawia się dopiero po tym, jak dana akcja zostanie wykonana co najmniej raz: po sparowaniu pilota naciśnij każdy przycisk i każdą kombinację, której chcesz używać, zanim zaczniesz szukać jej na liście wyzwalaczy urządzenia. Jeżeli zamiast tego chcesz użyć eksperymentalnej encji
event, potrzebna jest osobna konfiguracja:homeassistant: enabled: true experimental_event_entities: true
Nazwy typów zdarzeń i atrybuty tej encji mogą się zmieniać wraz z kolejnymi wersjami Zigbee2MQTT: traktuj ją jako rozwiązanie eksperymentalne, nie docelowe.
Stare blueprinty po Z2M 2.0.0: zmiana wyłączająca domyślnie
sensor.*_action dotyka bezpośrednio starszych blueprintów pobranych przed tą aktualizacją. Przy każdym polecanym blueprincie warto sprawdzić datę aktualizacji, wersję Zigbee2MQTT, dla której był pisany, oraz sposób obsługi zdarzeń (legacy sensor, MQTT Device Trigger czy event entity): jeśli automatyzacje przestały działać po update, sprawdź, czy nie korzystają z encji sensor.*_action, włącz tymczasowo legacy_action_sensor: true albo poszukaj zaktualizowanej wersji blueprinta z MQTT Device Trigger.Drenaż baterii i stare bindingi po migracji
Piloty generujące dużo komunikatów w krótkim czasie (ICTC-G-1, SYMFONISK gen. 1 przy intensywnym obracaniu) zużywają baterię szybciej: to fizyczna konsekwencja częstszej transmisji, nie usterka. Częstsze użycie nie jest jednak jedyną przyczyną szybkiego rozładowania: podobny efekt dają binding do urządzenia offline (udokumentowane wprost dla E1812), wielokrotne próby retransmisji, słaby rodzic w sieci mesh, problemy z rejoin, niekończące się OTA, wadliwy firmware, niezgodny typ baterii, słaby kontakt baterii czy ciągłe wybudzanie urządzenia.
Zamiast od razu resetować pilota, przejdź proste drzewo diagnostyczne: sprawdź napięcie baterii i jej rodzaj, usuń bezpośredni binding do urządzeń, które są offline, sprawdź LQI i parenta w sieci, sprawdź liczbę wiadomości wysyłanych przez pilota, upewnij się, że żadne OTA nie utknęło w trakcie: dopiero na końcu zresetuj i sparuj pilota ponownie.
Nie wszystkie urządzenia są dostrojone do akumulatorów: BILRESA raportuje procent baterii poprawnie głównie dla ogniw alkalicznych 1,5 V; przy akumulatorach NiMH 1,2 V wynik bywa mniej wiarygodny, bo dokumentacja obu modeli BILRESA wskazuje strojenie raportowania pod baterie alkaliczne. Rozróżnij napięcie rzeczywiste, procent wyliczony przez firmware i typ zastosowanej baterii, zanim uznasz niskie wskazanie za usterkę.
Jeśli migrowałeś koordynator (procedura w artykule o diagnostyce parowania): bindingi urządzenie–urządzenie są zapisane w urządzeniu źródłowym (pilocie), więc kopia koordynatora nie musi ich „odtwarzać”, ale sterowanie może przestać działać, jeśli zmienił się IEEE koordynatora, pilot był zbindowany także do koordynatora, grupa nie została odtworzona z tym samym ID, urządzenia docelowe zmieniły adres IEEE po ponownym sparowaniu albo baza Zigbee2MQTT straciła wiedzę o bindingach. Bezpośredni binding zwykle pozostaje zapisany w pilocie, ale jego cel musi nadal istnieć pod tym samym IEEE lub ID grupy: po migracji zweryfikuj zarówno rzeczywiste działanie pilota, jak i wpisy widoczne w zakładce Bind w Zigbee2MQTT. W szczególnych przypadkach (jak BILRESA) operacja bind/unbind może wyglądać na udaną w interfejsie, a mimo to nie mieć żadnego efektu: zawsze testuj fizyczne działanie, nie tylko komunikat sukcesu.
Simulated brightness, identify i bezpieczne OTA pilotów
simulated_brightness: wiele pilotów (m.in. E1812, BILRESA) ma tę opcję, dzięki której Zigbee2MQTT symuluje wartość jasności na podstawie zdarzeń move up/down i stop. To nie jest odczyt rzeczywistej jasności lampy, tylko wartość liczona po stronie Zigbee2MQTT: może rozjechać się z rzeczywistym stanem urządzenia, ale bywa użyteczna w automatyzacjach. Wymaga ustawienia parametrów
delta i interval.identify: większość nowszych pilotów udostępnia komendę identyfikacji, przydatną do odszukania konkretnego egzemplarza, potwierdzenia komunikacji albo testu po wymianie baterii. Urządzenie trzeba wcześniej wybudzić naciśnięciem przycisku: to nie to samo co parowanie ani Touchlink.
Bezpieczne OTA pilota: zanim zaczniesz aktualizację: sprawdź changelog i znane problemy, zapisz aktualną wersję firmware, zapisz bindingi i zrób zrzut realnych akcji, włóż świeżą baterię, umieść pilota blisko dobrego routera lub koordynatora, wybudzaj go co 1–2 s aż aktualizacja ruszy i nie przerywaj procesu. Po aktualizacji wykonaj Re-interview/Reconfigure, sprawdź endpointy i bindingi, przetestuj wszystkie przyciski: dopiero potem aktualizuj kolejne egzemplarze tego samego modelu. Najprostszy sposób na zarejestrowanie realnych akcji własnego pilota to nasłuch jego topicu w MQTT i obserwacja pola
action (albo lista MQTT Device Triggers w narzędziach deweloperskich HA): to ważniejsze niż ślepe przepisywanie tabeli akcji z internetu, bo firmware i konwertery zmieniają się częściej, niż mogłoby się wydawać.Gotowe wzorce automatyzacji
Tabela doboru pilota do zastosowania
Czego nie znajdziesz w tym artykule
Pełną teorię działania bindingu na poziomie klastrów i grup w kontekście awaryjnego sterowania rozwijam głębiej w artykule o architekturze systemu. Ogólne zasady bezpiecznego OTA opisuję w artykule o diagnostyce parowania. Pełną konfigurację sterowania roletami (kalibracja, pozycjonowanie) znajdziesz w artykule o roletach IKEA.
Co dalej
Źródła: oficjalna dokumentacja urządzeń na zigbee2mqtt.io, zgłoszenia w repozytorium
Koenkk/zigbee2mqtt na GitHubie, wątki na forum Home Assistant Community oraz dyskusje deweloperów Zigbee2MQTT.W następnym artykule tej serii zajmiemy się czujnikami (ruchu, otwarcia, zalania) oraz jakością powietrza, wraz z pełną diagnostyką problemów zgłaszanych najczęściej przez społeczność. Przejdź do artykułu o czujnikach i jakości powietrza →
