Four small fixes for Hi-Link mmWave radar modules landed in ESPHome's development branch on 19 October 2026. All four pull requests come from the same contributor, fallenmi, and bdraco merged them between 20:22 and 23:29 Polish time. Each covers a different module: the LD2410, the low-power LD2410S, the LD2420 and the multi-target LD2460. None of them changes the configuration, so existing YAML stays as it is. They are set for ESPHome 2026.11, unless some are carried into the 2026.10 beta.
LD2420: radar reports stop after a silent command
ESPHome sends each configuration command to the LD2420 up to three times. If none of the three attempts got a reply, a flag marking a command as in progress stayed set. When that happened on the last configuration command, the component's main loop kept returning early and stopped reading radar reports, so the sensor went quiet. The fix (#21131) clears the flag once the retries are over. The same change had appeared in an earlier pull request by bdraco that was closed without merging.
LD2410S: a settings change delayed by up to 24.9 days
The LD2410S keeps a 300 ms gap after each command acknowledgement. If you changed a parameter more than about 24.9 days (2^31 ms plus those 300 ms) after the last acknowledgement, a signed time comparison read the old deadline as a time in the future. The write could then wait for up to roughly 24.9 days. A sensor that runs for weeks without anyone touching its settings is exactly the case this hits. The fix (#21121) starts a pending write at the current time unless the 300 ms gap is still running.
LD2410: a response cut short by its own data
A query-parameters response from the LD2410 is 38 bytes long, but its configuration values can contain the byte sequence 04 03 02 01, the same one that ends a frame. The parser treated that sequence as the end of the response, then published stale or missing parameter values and threw the rest away. The fix (#21145) waits for at least 38 bytes before it reads the values. The author stresses that this is not a general framing fix.
LD2460: frames lost on buffer overflow
When the LD2460's 32-byte line buffer overflowed, the parser cleared the whole buffer before taking the next byte. A valid frame could already be partly in there, for example after a two-target frame that lost its last footer byte. Clearing dropped that frame's header and with it the report. The fix (#21123) keeps the part of the buffer that starts at the next possible header. Frame checks stay the same, and the buffer does not grow.
Tested on a computer, not on a radar
All four were tested with synthetic serial data on a computer, using host unit or integration tests, and the descriptions say so plainly. No physical radar was used, and full firmware builds were not run as part of that testing. The author also discloses that Claude and Codex helped with the diagnosis, the code and the tests. Each pull request adds a regression test that fails on the old code and passes on the new one.