Some hardware links on this page are affiliate links. As an Amazon Associate I earn from qualifying purchases. We may earn a commission if you buy through them, at no extra cost to you. See the affiliate disclosure.
Learning a 433 MHz button on an RM4 Pro means holding the remote through a frequency sweep, then pressing it again when the LED blinks. A button that does not repeat while you hold it is easy to miss, and a capture that runs for most of a second makes two dashboard taps look like one long press. If the remote is a fixed 24-bit code, you can build a short packet instead of learning one.
The remote entity id is an input. Do not publish which hub or which outlet this is.
What problem it solves
You already know the code a 433 MHz lamp, socket, or doorbell sends, and you want the Broadlink integration to transmit a short, repeatable packet without remote.learn_command.
How it works
The usual cheap fixed-code remote is Princeton / EV1527 at 433.92 MHz. The payload is 24 bits: a 16-bit address and one button byte. A DIP switch on a socket is often just that address written in hardware. The tool does not read the switch for you. You pass the code you already worked out, or a Flipper .sub file that already contains it.
- Generate — one Python file, no extra packages.
python3 rf2broadlink.py CODE --te TE --haprints a line that starts withb64:.TEis the bit time in microseconds. The packet is six frames, about 0.2 seconds, plus a short silence, so a second press stays a second press. - Send — a template button calls
remote.send_commandon the Broadlink remote entity. The command is thatb64:line. The Broadlink integration is already set up. This pack does not learn, and it does not store codes inside the Broadlink app. - A step that is too small — some lamps treat one transmission as one tiny step, and a longer packet still counts as one.
num_repeatswithdelay_secs(pack example 0.3 seconds) sends the short packet several times. A small step uses 1, a medium step 4, a large step 12. Put those on separate buttons. - A
.subfile — the same script accepts the file instead of the hex code. Princeton / EV1527 from that path was checked on hardware. FlipperRAWfiles are generated and unit-tested, and they are not yet confirmed on a real hub. Try a RAW file only after the hex path works.
Rolling-code remotes (many garage doors, cars, and alarms) change the code every press. Generating yesterday’s code does not open them. This pack does not try. The hex path was verified on an RM4 Pro with Home Assistant 2026.10. Other Broadlink models that speak the same RF packet format may work. They were not part of that test.
Hardware notes
- Hub. An RM4 Pro, or another Broadlink remote that already shows up as a
remoteentity and can send 433 MHz fixed codes. The linked model is the RM4 Pro. It does not learn or send rolling codes. Power is 5 V. The hub wants 2.4 GHz Wi-Fi for its own setup. That setup is the Broadlink integration, done before this pack. - The remote you are copying. Fixed code only. If the original remote has to be paired before its first use, assume rolling code and stop. A socket with a DIP switch is a candidate only after you know the 24-bit value those switches represent.
- No extra radio. The Broadlink is the transmitter. You do not add a second 433 MHz module.
Snippet
The generator runs on a computer, once per button. The entity id stays an input.
python3 rf2broadlink.py ABCDEF --te 263 --ha
ABCDEF stands in for the 24-bit hex code. 263 is a bit time in microseconds that matched one verified lamp. Use the time your remote actually uses. The script prints one b64: line.
template:
- button:
- name: "RF power"
press:
- action: remote.send_command
target:
entity_id: !input broadlink_remote
data:
command: !input b64_command
num_repeats: 1
delay_secs: 0.3
Leave num_repeats at 1 until a single packet is too small a step. Do not paste a learned capture into command and also run this generator. Pick one.
Setup outline
- Confirm the Broadlink integration already has a
remoteentity, and that a known IR button still sends. This pack does not fix a hub that is offline. - Run the script with one known code and the bit time. Copy the
b64:line. - Create one template button pointed at that remote. Press it once. The outlet or lamp should respond once.
- Press it twice, quickly. You should get two reactions. If they merge, the packet you sent is not the short one from this tool.
- For a dimmer that barely moves, duplicate the button with
num_repeatsof 4 and of 12. Do not lengthen the code itself.
Troubleshooting
- Nothing happens. The code is wrong, the bit time is wrong, or the hub is out of range. Confirm the same outlet still works from its original remote while you are standing at the hub. Then try one neighboring bit time, not a sweep of every value.
- One dashboard tap does a lot.
num_repeatsis still high from a dimmer button. The power button wants 1. - Two taps become one. You sent a long learned capture, or
delay_secsis 0 on a device that merges frames. Use the generated packet and a gap of about 0.3 seconds. - The original remote is a roller. Stop. A fixed packet will not track a rolling code, and retrying it can desynchronize a receiver that is counting. Use the receiver’s own integration.
- A
.subRAW file is silent. That path is not confirmed on hardware. Generate from the 24-bit hex code first. - You wanted the hub to learn a button you do not have a code for. That is
remote.learn_commandwithcommand_type: rfin the Broadlink integration. This pack starts only after the code is known.
Credits
Based on the community project rf2broadlink. That one-file tool turns a 24-bit Princeton / EV1527 code, or a Flipper .sub file, into a short Broadlink b64: packet for remote.send_command. This write-up is an original overview of that path: the hex command, the template button, and the repeat gap. The author’s lamp keymap is not included. Rolling-code remotes are out of scope there, and here.