[APP][Pro] Broadlink RM4 Pro - RF & IR remote control for Homey

Apps
, , ,
1

I’ve built a Homey app that lets you control a Broadlink RM4 Pro directly from Homey - learn RF (315/433MHz) and infrared commands from your existing remotes, and send them from Homey flows. No cloud - everything runs locally between Homey and the RM4 Pro on your LAN.

Features

  • Learn RF commands - either via the standard two-phase sweep (like the official Broadlink app), or by entering the exact frequency manually (e.g. 315 or 433.92 MHz) to skip the sweep entirely when it’s unreliable.
  • Learn IR commands - single-press learning, same wizard.
  • Organise by remote - commands are grouped into named “remotes” (e.g. “Living room TV”, “Soundbar”), each locked to one technology (RF or IR), so things stay tidy even with dozens of learned commands.
  • One flow card - “For [remote], send command [command] via [sender]” - pick the remote, the command, and (for IR only) whether to send it via the RM4 Pro or Homey’s own built-in IR blaster (Homey Pro 2023).
  • Manage everything from the app settings page - collapsible remote groups, inline rename for both remotes and commands, per-command test buttons, delete.
  • Pairing - automatic network discovery, with a manual IP-address fallback (device Settings) if your Homey and RM4 Pro sit on different VLANs/subnets.

Requirements

  • A Broadlink RM4 Pro reachable on the same local network as Homey.
  • For the “send via Homey” IR option specifically: a Homey with a built-in IR blaster (Homey Pro 2023). This is optional - sending via the RM4 Pro always works regardless of your Homey model.

Known limitations

  • “Send via Homey” only works for NEC-style IR protocols (the most common one, used by most TVs/soundbars/projectors/AC remotes). Other encodings (e.g. Sony SIRC, Manchester-coded RC5/RC6) aren’t decoded correctly yet - sending via the RM4 Pro is unaffected and works for any protocol, since it just replays the raw captured signal. Working on that!
  • No import of existing Broadlink-app backups (yet) - commands are learned fresh through Homey.

Feedback welcome

This has been tested extensively against real hardware (RF sweep + manual frequency, IR learning, both send paths), but I’d love to hear how it holds up on other RM4 Pro units and remotes — especially reports on IR commands that don’t work via the “Homey” send option, since that’ll help figure out which other protocols are worth supporting.

With this app, the IR learning function returns to Homey; choose via the flow card whether you want to send the command from Homey or use the RM4 Pro as a satellite.

I am currently preparing the app so that I can have it reviewed. A test version will presumably be released later this week.

2

Reserved

3

Reserved second post

4

Hi Guust, just to check if I understand what your app is doing, by bringing it to my need:
I have an IR heating panel with a IR remote. I would like to control the panel from Homey.
No information can be found about the hex codes, so I’m stuck.
With a Broadlink RM4 pro and your app I can
Homey learn the codes
Make flows let homey turn the heater on, set the temperature and mode.
Is that correct?
Thanks for your work!

5

Just for my understanding: what is the difference with the existing Broadlink app?

6

Where can I download it? I see you can send IR directly from Homey, right? Is it also possible to capture the IR codes from Homey’s built in IR receiver?

7

My thought as well…

(uses local network only as well)

When I understood the store guidelines correctly, this app might not get past the “approval committee”:

8

because some apps are shit but were the first.. and don’t get any updates or the developer doesn’t want PR’s or its closed source..

9

In cases where an app is no longer maintained, is closed source, or the lead developer isn’t open to accepting PRs; whatever the situation may be, the Partnerships team and I are always happy to see how we can help.

That could mean facilitating an app transfer, reaching out to the developer for a conversation, or anything else that helps move things forward.

Ultimately, we want to encourage collaboration across the Homey platform. We recently sent out a survey to all Homey developers on this topic as well, as we’re always looking for ways to improve cooperation within the community.

The whole reason we want to keep fragmentation to a minimum is the user experience on the platform, having a bunch of apps for the same brand/devices doesn’t really help on that front.

10

Yes, that’s a reality as well, but totally isn’t applicable to the reanimated and massively improved Broadlink app by Sharkys.

11

May you point to your PR please? Ideally with GitHub links please, thanks

12

Sorry, I just see now you asumed by default this is the situation also for this case :wink:

@Guust_Flater , happy to review your PRs for the app I’m currently maintaining, unfortunately so far I haven’t seen any PR from you.

13

Thanks everyone for the questions and comments, good to see the interest. A few points:

@RuuduitdeG : Yes, that should work. Each individual command from your IR panel (temperature up/down, mode, on/off, …) is learned separately as its own command under one remote. You can then send that exact command from a flow, so temperature and mode control via separate flow cards is possible. One caveat: currently only the NEC IR protocol is supported (working on adding support for more protocols as I run into issues while going through my own remotes). Some heaters/AC units use more complex IR commands where multiple settings (temperature, mode, fan speed, …) are encoded into a single signal — those may not be recognized or sent correctly.

@smarthomesven : The app isn’t live yet, I’m still finishing a few things before the test link is ready; I’ll post it here as soon as it is. Sending IR works either way; I use not only the RM4 Pro but also the Homey Pro (2023)'s built-in IR blaster as an alternative send path. Learning commands happens via the RM4 Pro - Homey itself has no IR receiver, only a transmitter, so capturing via Homey’s own hardware isn’t possible.

@SunBeech / @Peter_Kawa : Honest answer: this isn’t an attempt to replace or compete with the existing Broadlink app. Two concrete reasons:

  1. It was a personal project for me to see if I could find a solution to the IR-learning problem that keeps coming up in various topics on this community - and to make those learned IR commands reusable so they can also be sent via Homey’s own IR blaster, not just via the RM4 Pro.
  2. I have a projection screen that’s controlled via RF, and I couldn’t get it learned with the existing Broadlink app - the frequency sweep didn’t work well for it. I used a different approach so can I skip that sweep and choose a frequency myself, which made it work.

So this app focuses specifically on IR/RF learning for Homey, not on broadly supporting Broadlink as a brand with more device types.

@Sharkys : See above: my approach isn’t “better than” the existing app, but a solution to two concrete problems I ran into myself (IR learning + reuse via Homey IR, and an RF device that couldn’t be learned due to the frequency sweep). I tackled these problems as a home project and started with a blank slate (so no risk of breaking existing support for devices I don’t own and can’t test). I am using a third-party Node.js package (kiwicam-broadlinkjs-rm) to communicate with the Broadlink RM4 Pro.

Finally: I noticed the IR-learning problem comes up in quite a few topics on this community. So what started out as just a project for myself, I figured, might be useful to other users too — that’s why I decided to share it here rather than keep it just for my own use.

14

Thanks for clarification @Guust_Flater . I understand that in your particular case the automatic RF frequency sweep did not work, while entering the frequency manually solved the problem. This can of course be a useful fallback.

However, so far I have never received any debug report showing that the frequency sweep is failing, so unfortunately I had no concrete case to investigate or reproduce. If you can share the device type, frequency and debug logs showing where the process fails, it would be helpful.

Naturally, if you already found and tested the improvement, it can be easily implemented into the existing app as an optional manual-frequency mode based on your PR, while keeping the automatic sweep as the default. This should also avoid any impact on the other currently supported Broadlink devices.

So my question is still why this improvement requires another Broadlink app instead of contributing it to the existing and actively maintained one. As already mentioned, I’m happy to review your PR and cooperate on integrating it.

15

Yes it does, at least on my Pro2019

image
image1919×982 84.5 KB

This is also what I used to capture the signals for my 2 IR apps.

16

You’re right, the Homey Pro (Early 2019) does have a built-in IR receiver. Since the Homey Pro (Early 2023), however, Homey no longer includes a built-in IR receiver - only an IR transmitter. So on the 2023 (and newer) models, you can’t learn signals directly from a remote anymore; you’ll need to find the codes online or capture them with another device.

Source: Homey Pro models compared (see the “Infrared” row: older models list “1× receiver”, the 2023/2026 models only list “1× power LED”).

17

Don’t take it personally. Besides, you should be happy that people/developers try and make something even tho it might exists already. Then there might not be a homey at all.

18

Yeah, tell me something about that :laughing:

Without me trying, I would not maintain or even develop some of those from scratch in my free time without really any (none) “significant” (any) appreciation - it’s mostly done just because / for the community.

But that’s for another discussion. :wink:

@Guust_Flater , up to you, I will be however not monitoring this thread anymore, my offer is on the table, reach out to me using standard channels if needed.

19

Thanks for the constructive reply, and fair point on the frequency sweep specifically - you’re right that adding an optional manual-frequency fallback for the RM4 generation, while keeping the automatic sweep as default, is realistic without touching the older-generation devices (RM3_mini, RM_plus, RM_pro use a separate, non-RM4 code path).

One nuance worth flagging though: the skip-sweep/custom-frequency logic in my app isn’t code I wrote from scratch - it comes from a third-party library, kiwicam-broadlinkjs-rm, which already implements it. Your app currently has minimal external dependencies for the protocol layer (just crc, for checksums) and otherwise a fully custom implementation, so “based on your PR” wouldn’t be a simple code port - it’d mean either adding that library as a new dependency, or re-implementing the equivalent logic natively against your own protocol stack. Either way, it’s a bigger lift than a straightforward code hand-off would be.

I won’t pretend that part alone justifies a whole new app.

Before writing the rest of this, I went through your repo’s code (DataStore.js, the RM4_pro driver, etc.) to check how commands are stored today. Here’s what that turned up, and why it matters for your question:

The core of my app is a different data model: commands are grouped into named categories (renamable, one technology - RF or IR - per category), rather than a flat list of individually named commands per device, which is what your DataStore.js currently implements. That’s what lets a category hold “temperature up/down/mode” as one logical remote, and it’s also what makes dual-path sending possible: for IR commands, you can choose to send via the RM4 Pro or via Homey’s own built-in IR blaster. That choice only works because each category (and therefore each command in it) carries an explicit technology tag - today’s flat {name, cmd} storage doesn’t record whether a command is RF or IR at all, so enabling “send via Homey” would first require adding that classification to every existing stored command before the feature could even be offered.

Mapping any of this onto the existing app isn’t an additive PR - it changes the stored data shape and the flow card itself (today: pick one command; with categories: pick a category, then a command within it; plus a new “send via” choice for IR). That’s a breaking change for every existing user’s saved flows, across every driver that stores learned commands (RM3_mini, RM4_mini, RM4_pro, RM_plus, RM_pro), not just RM4 Pro owners.

So to directly answer your question: it’s not that the individual pieces couldn’t technically be contributed one by one - the frequency fallback probably could, even if not as a direct code port as I mentioned above. It’s that the app as a whole is built around a data model and UX (categorized commands, dual-technology tagging, dual-target sending) that doesn’t fit as an incremental PR without breaking changes for your existing user base. Your app also spans a much broader set of Broadlink devices (A1, Dooya, Hysen, the SP series, …), where every change has to go through your review and priorities for all of them - a separate project lets me iterate on this narrower IR/RF-learning UX on its own terms. That’s why I think it’s better to keep it as a separate project rather than trying to retrofit it into yours.

Happy to share the device/frequency details from my own case if that’s useful for your users regardless of what I do with my app - separate question from whether it belongs in a PR.

20

Can it learn long press? That is sorely lacking in the existing app.