Broadlink

From a Home Assistant action to an IR or RF signal

Home Assistant communicates with the configured Broadlink device over the local network. The transmitter then emits the compatible IR or RF command. A receiver does not become a network device just because it can be controlled through that transmitter.

Home Assistant action → local Broadlink connection → IR or RF transmission → compatible receiver

IR and RF are different capabilities. My IR-only mini cannot perform the RF role used by Bark Alerts. The RM4 pro supports RF, but that does not make it compatible with every remote, frequency or encoding. Compatibility must be checked against the particular receiver and command.

The manufacturer's app is part of initial network provisioning. That is separate from Home Assistant's local command path once the device is configured and accessible. Commands stored only in the Broadlink app are not automatically available as named commands in Home Assistant.

Where Broadlink fits in my configuration

Scroll the table horizontally to compare all four columns.

Reusable commands instead of copied remote logic

My scripts call Home Assistant's remote send action. One configurable script selects among audio-control commands such as power, volume, mute and source. The script provides a reusable interface while the actual captured packets remain private.

Another configured path refreshes a connectivity sensor before deciding whether to request a transmission. If the reachability check does not pass, it takes a logging branch. This is a check of the network path, not a handshake with the final receiver.

Learning, naming and sending are separate operations

The standard Broadlink workflow learns a command, stores it under a device/group and command name, and sends it later using those names. Raw captured packets are another supported input to the remote send action. Neither method establishes what the receiving hardware will do without verification.

A clean send can still mean a bad capture. RF learning has two steps, a frequency sweep and a button press, and a code from a capture that went wrong can transmit without error while the receiver ignores it. When a receiver ignores a command, I check the capture before changing anything else.

I keep command identity separate from the physical result. A power-toggle command can switch equipment either on or off depending on its starting state. Repeating a toggle may undo the intended change. Repetitions that help one command are therefore not a general solution for every remote action.

Home Assistant's Broadlink documentation covers learning, storage and sending. It is the setup reference for a normal installation, while my local extensions are described separately below.

Broadlink is the output stage for Bark Alerts

My Bark Alerts integration listens to the selected Frigate audio-detection entities in Home Assistant. After its automatic-operation checks, it requests the configured beep command through Broadlink. Broadlink does not perform bark detection or decide whether a detection should result in a request.

Frigate bark detection → Bark Alerts controls → Broadlink RF transmitter → stored collar beep command

This is intended for beep-only use. The software cannot inspect a learned packet and establish that it represents a beep. The receiver must be checked with the collar off the animal, and checked again after changing the command, channel, receiver or configuration.

Arming, dry run and cooldown belong to Bark Alerts. Its explicit manual test bypasses arming and dry run, while still respecting cooldown. A direct Broadlink command from another script is outside those automatic-operation controls. The Bark Alerts guide explains these boundaries together.

My local component and the standard integration

This Home Assistant build currently contains a local custom Broadlink component. Its code includes command-listing and command-import actions in addition to the remote workflow. Those local capabilities should not be assumed to exist in every stock Home Assistant installation.

The presence of those actions also does not mean Bark Alerts reads Broadlink's private command storage. Bark Alerts uses its own configured command selection and the remote action interface. The two projects have different responsibilities even when they target the same transmitter.

I use the upstream documentation for standard installation instructions and keep this local implementation detail in the setup description. Reproducing the basic IR/RF architecture does not require copying my custom component or private command files.

Most of the commands described here provide no end-to-end acknowledgement from the receiver. Range, obstruction, interference, receiver power or standby, and command compatibility can all affect the outcome after Home Assistant has submitted a request.

Check reception, not just the service return

I first check whether Home Assistant can reach the intended transmitter and whether the script chose the intended command. For learned commands, the device/group and command names must match the Home Assistant storage entry. A similarly named command in the manufacturer's app is a different source.

Next I inspect the action result and Broadlink logs privately. A caller returning without an exception is useful evidence about that call, but some transmission failures may be logged without being raised to the calling integration. The physical receiver remains the final check.

For IR, I check positioning as well as the command. For RF, I check compatibility, receiver power and the observed result before altering repetition settings. For the collar path, manual verification remains off the animal, and a successful manual test does not prove that the Frigate detection path is working.