Learning a 433 MHz remote on a Broadlink RM4 Pro in Home Assistant could end with a success message and a code that did nothing when sent. Sometimes nothing was saved at all. Pull request #182652 by dustinreed-info fixes the Home Assistant side of the problem and stops several Broadlink actions from reporting success when they failed. Joost Lekkerkerker merged it into the development branch on 19 October 2026 at 22:06 Polish time, so it is headed for Home Assistant 2026.11. The bug was reported in issue #176041 in July.

Recording that starts mid-pulse

The cause is in how the RM4 Pro records RF. Its RF packets (type 0xB1) are a list of durations that alternate between carrier on and carrier off. Sometimes the device starts recording in the middle of a pulse, so every duration shifts by one slot. On replay, the RM4 Pro transmits during the gaps between frames and stays silent during the data, and the receiver ignores it.

At the Home Assistant reviewers' request, the correction went into the python-broadlink library maintained by DAB-LABS (library pull request #12, merged on 7 October). If all the long timings, about 3 ms or more and longer than any data pulse, fall on carrier-on slots and there are at least two of them, the library drops the first duration and fixes the length field. Packets that are already aligned, or where the pattern is ambiguous, are left alone. The library applies this when it checks for a learned packet, and the broadlink-async 1.1.1 package that Home Assistant's development branch has used since 18 October includes it.

In Home Assistant itself, the frequency found during the frequency sweep is now passed on when the device looks for the RF packet, as the broadlink_cli tool already did.

The author tested the approach on an RM4 Pro with a fixed-code 433.92 MHz remote for a patio heater. The code learned before the fix did nothing. After the fix, the button re-learned with remote.learn_command worked straight away with remote.send_command. The final library version was covered by tests but not run on the device, because the realignment moved there after the hardware test.

Codes that are already saved are not rewritten. If an RF command never worked, learn it again after the update.

Failures that stop looking like success

The same pull request removes several silent failures from the Broadlink remote actions:

  • a timeout or "Command not supported" during learning was only logged and the action still succeeded. It now raises an error with a translated message, and commands learned before the failure are still saved;
  • a failed send_command also reported success, and now raises an error;
  • sending a command that was never learned, sending RF to a model without RF, or deleting commands that do not exist used to end in "Unknown error". These now give a validation error that says what is wrong;
  • if checking the frequency fails after the sweep has started, the sweep is cancelled before the error is raised, so the device is not left sweeping.

For automations, a failing Broadlink step now returns an error, which stops the automation unless that step has continue_on_error set. Behaviour when the remote entity is turned off does not change: Home Assistant logs a warning and skips the action.