Do gałęzi rozwojowej ESPHome trafiły 19 października 2026 cztery drobne poprawki dla radarów milimetrowych (mmWave) firmy Hi-Link. Wszystkie zgłoszenia zmian przygotował ten sam autor, fallenmi, a bdraco scalił je między 20:22 a 23:29 czasu polskiego. Każda dotyczy innego modułu: LD2410, energooszczędnego LD2410S, LD2420 i LD2460, który śledzi kilka osób naraz. Żadna nie wymaga zmian w konfiguracji YAML. Poprawki trafią do ESPHome 2026.11, chyba że część z nich wejdzie jeszcze do wersji testowej 2026.10.

LD2420: radar milknie po poleceniu bez odpowiedzi

ESPHome wysyła każde polecenie konfiguracyjne do LD2420 maksymalnie trzy razy. Jeśli na żadną z trzech prób nie przyszła odpowiedź, znacznik „polecenie w toku” zostawał ustawiony. Gdy zdarzyło się to przy ostatnim poleceniu konfiguracyjnym, główna pętla komponentu za każdym razem kończyła się przedwcześnie, więc ESPHome przestawał czytać raporty radaru i czujnik milkł. Poprawka (#21131) kasuje znacznik po wyczerpaniu prób. Tę samą zmianę zawierało wcześniejsze zgłoszenie bdraco, które zamknięto bez scalania.

LD2410S: zmiana ustawień opóźniona nawet o 24,9 dnia

LD2410S zachowuje 300 ms przerwy po każdym potwierdzeniu polecenia. Jeśli zmieniłeś parametr później niż mniej więcej 24,9 dnia (2^31 ms plus te 300 ms) po ostatnim potwierdzeniu, przy porównaniu czasów na liczbach ze znakiem stary termin wychodził jako przyszły. Zapis mógł wtedy czekać nawet około 24,9 dnia. Problem trafia więc akurat w czujniki, które pracują tygodniami bez zmiany ustawień. Poprawka (#21121) rozpoczyna oczekujący zapis od bieżącej chwili, chyba że 300-milisekundowa przerwa jeszcze trwa.

LD2410: odpowiedź ucięta przez własne dane

Odpowiedź LD2410 na zapytanie o parametry ma 38 bajtów, ale wartości konfiguracji mogą zawierać ciąg bajtów 04 03 02 01, taki sam jak ten, który kończy ramkę. Parser brał go za koniec odpowiedzi, potem publikował nieaktualne albo brakujące wartości parametrów i wyrzucał resztę danych. Poprawka (#21145) czeka na co najmniej 38 bajtów, zanim odczyta wartości. Autor podkreśla, że to nie jest ogólna naprawa dzielenia strumienia na ramki.

LD2460: ramki gubione przy przepełnieniu bufora

Gdy 32-bajtowy bufor linii w LD2460 się przepełniał, parser czyścił cały bufor, zanim przyjął kolejny bajt. Część poprawnej ramki mogła już w nim być, na przykład po ramce z dwoma celami, której zabrakło ostatniego bajtu stopki. Wyczyszczenie usuwało nagłówek tej ramki, a razem z nim cały raport. Poprawka (#21123) zostawia w buforze fragment od następnego możliwego nagłówka. Sprawdzanie ramek działa tak samo, a bufor się nie powiększa.

Testy na komputerze, nie na radarze

Wszystkie cztery poprawki sprawdzono na komputerze na sztucznych danych z portu szeregowego, w testach jednostkowych albo integracyjnych, i opisy mówią o tym wprost. Nikt nie podłączał prawdziwego radaru, a w ramach tych testów nie budowano też pełnego oprogramowania dla płytek. Autor ujawnia ponadto, że przy diagnozie, kodzie i testach pomagały mu Claude i Codex. Każde zgłoszenie dodaje test, który na starym kodzie się nie udaje, a na nowym przechodzi.