Jeśli w Home Assistancie uczyłeś Broadlink RM4 Pro kodów z pilota 433 MHz, mogłeś dostać komunikat o powodzeniu i kod, który po wysłaniu nic nie robił. Czasem nie zapisywało się zupełnie nic. Zgłoszenie zmian #182652 od użytkownika dustinreed-info naprawia ten problem po stronie Home Assistanta, a przy okazji sprawia, że kilka akcji Broadlinka przestaje zgłaszać sukces, gdy coś poszło nie tak. Joost Lekkerkerker scalił je do gałęzi rozwojowej 19 października 2026 o 22:06 czasu polskiego, więc poprawka trafi do Home Assistanta 2026.11. Problem opisano w lipcu w zgłoszeniu błędu #176041.

Nagranie zaczęte w połowie impulsu

Przyczyna leży w tym, jak RM4 Pro nagrywa sygnał radiowy. Jego pakiety RF (typ 0xB1) to lista czasów trwania, na przemian z włączoną i wyłączoną falą nośną. Czasem urządzenie zaczyna nagrywać w połowie impulsu i wtedy każdy czas przesuwa się o jedną pozycję. Przy odtwarzaniu RM4 Pro nadaje w przerwach między ramkami i milczy wtedy, gdy powinny iść dane, więc odbiornik nie reaguje.

Na prośbę recenzentów Home Assistanta poprawka trafiła do biblioteki python-broadlink, którą rozwija DAB-LABS (zgłoszenie zmian #12 w bibliotece, scalone 7 października). Jeśli wszystkie długie czasy, od około 3 ms wzwyż, czyli dłuższe niż jakikolwiek impuls danych, wypadają na pozycjach z włączoną nośną i są co najmniej dwa, biblioteka usuwa pierwszy czas i poprawia pole długości. Pakiety już wyrównane albo niejednoznaczne zostają bez zmian. Biblioteka robi to przy sprawdzaniu nauczonego pakietu, a pakiet broadlink-async 1.1.1, którego gałąź rozwojowa Home Assistanta używa od 18 października, już tę funkcję zawiera.

W samym Home Assistancie częstotliwość znaleziona podczas skanowania jest teraz przekazywana dalej, gdy urządzenie szuka pakietu RF. Tak samo działało już narzędzie broadlink_cli.

Autor sprawdził to na RM4 Pro z pilotem do grzejnika tarasowego, który nadaje stały kod na 433,92 MHz. Kod nauczony przed poprawką nic nie robił. Po poprawce przycisk nauczony od nowa przez remote.learn_command od razu zadziałał z remote.send_command. Ostateczną wersję w bibliotece sprawdzono tylko testami, bez urządzenia, bo wyrównywanie przeniesiono tam dopiero po próbie na sprzęcie.

Poprawka nie zmienia kodów zapisanych wcześniej. Jeśli jakieś polecenie radiowe nigdy nie działało, po aktualizacji naucz je od nowa.

Błędy przestają udawać sukces

To samo zgłoszenie usuwa z akcji pilota Broadlink kilka cichych awarii:

  • przekroczenie czasu albo odpowiedź „Command not supported” podczas uczenia trafiały tylko do dziennika, a akcja i tak kończyła się powodzeniem. Teraz kończy się błędem z przetłumaczonym komunikatem, a polecenia nauczone przed awarią zostają zapisane;
  • nieudane send_command też zgłaszało sukces, a teraz zwraca błąd;
  • wysłanie polecenia, którego nigdy nie nauczono, wysłanie sygnału radiowego do modelu bez nadajnika RF i usuwanie nieistniejących poleceń kończyły się komunikatem „Unknown error”. Teraz kończą się błędem, który mówi, co jest nie tak;
  • jeśli sprawdzanie częstotliwości zawiedzie po rozpoczęciu skanowania, Home Assistant najpierw je przerywa, a dopiero potem zgłasza błąd, więc urządzenie nie zostaje w trybie skanowania.

W automatyzacjach nieudany krok z Broadlinkiem zwróci teraz błąd i zatrzyma automatyzację, chyba że ten krok ma ustawione continue_on_error. Bez zmian zostaje zachowanie przy wyłączonej encji pilota: Home Assistant zapisuje ostrzeżenie w dzienniku i pomija akcję.