Broadlink IR/RF remotes integration (RM3 Mini, RM Pro, RM4 Mini/Pro)

Correct, unfortunately you can't do this kind of customization to Hubitat native dashboard tiles.

But copy/paste for the name isn't that bad if you keep the device page opened as a reference while you're configuring the dashboard.

I'm getting an Error Occurred During Installation

An error occurred while installing the package: Failed to install driver Please notify the package developer..

You need to be on a version of HPM that supports bundles. v1.8.7 is the latest. Which version of HPM are you using?

EDIT: alternatively, you could just install (and keep updated) my library bundle manually, and then your current HPM version should work. But I would encourage you to upgrade HPM.

1 Like

Thanks for the great app @tomw. I'm starting to migrate the various remotes over now. I noticed that the frequency value doesn't populate. Not a big one but thought you may want to know.
image
Just a FYI. This issue I also had with the previous Broadlink app so I think it may be due to hardware.
When learning RF for my blinds I normally get a code starting with 2600 which then doesn't work when tested. The 2600 code is always changing as well. About 1 out of 20+ presses I get a code starting with B2006 which then works. Very occasionally I get the B2006 code first go. I have tried rescanning for the frequecy but that doesn't seem to help.
Really just mentioning it here as it may help someone else if they are having issues. Perseverance is the key.
Thanks again I like wat you have done with the features to manage codes. Its great to see your important intergration being actively developed.

1 Like

Thank you for reporting this.

It does populate for my RM4 Pro and some older RM Pro devices that I have seen from other users. I am curious, like you said, if there is a difference in behavior with your hardware for some reason.

What kind of hardware do you have? If you have logging enabled on the driver and press Initialize, what firmware version does it indicate in the Logs? While you're at it, what does the Logs output look like while the rfSweep() is running (probably better to PM this part to me)?

When learning RF for my blinds I normally get a code starting with 2600 which then doesn't work when tested

2600... is the format for an IR code. It is extremely odd that you are getting this when doing an RF learn. Do you see this on multiple RF-capable remotes?

In my experience, if you can get the RF sweep to complete successfully (with accurate frequency reported), the RF learn works on the first try every time.

I have a RM pro+ Firmware 57. A different RF remote relay has a similar issue. Happy to post the test here in case it helps someone else.
debugauthResp = 070000006760AF056760AF056760AF059ED32575000000000000000000000000
debugscanResp = 0000000000000000000000000000000000000000000000000000000000000000ABC60000000007000000000000000000000000009D270C00A8C0274FB9770F780000000000000000000000000B180B18160D170C170D0A190B18160D160D0B18170C0B180B19160D0B180B18160D170C170C0B180B190B18170C170C0B180A18

Blinds
debugsweep successful: freq = 0
debugparseRF resp = 1A000000010000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 19000000000000000000000000000000

From now on I'll remove the repetitive same responses
RF Relay
debugsweep successful: freq = 0
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 19000000000000000000000000000000

Had to redo the sweep as the Broadlink locked up and got this result from the RF Relay
debugparseRF resp = 1A000000000000000000000000000000
debugparseRF resp = 19000000000000000000000000000000
debugparseRF resp = 1E000000000000000000000000000000
debugparseRF resp = 1B000000000000000000000000000000

After this sweep Learnt
260022000009B51E1D0B091F091E1E0A1E0A1E0A1E0A1E0A0A1E091E0A1E1E0A1D0B09000D05000000000000
260016000004621E091F1D0B091E0A0001331D0B1E0A09000D050000
260021000002F21E0A1D0B1E0A091F091E0A1E1D0B1D0B091E0A1E091F1D0B091F09000D0500000000000000
260015000B1D0B091E1E0A091F091F1D0B091E0A1E19000D05000000
260020000008080B1D0A1E0A0A1E0A1E0A1E1D0B1D0B091E0A1E0A1E1D0B091E0A000D050000000000000000

Pressed cancel and it is trying to cancel sweep but didn't succeed
After a while powered off and on did a new sweep
debugparseRF resp = 1B000000000000000000000000000000
debugsweep successful: freq = 0
debugparseRF resp = 19000000000000000000000000000000
debugparseRF resp = 1E000000000000000000000000000000
debugparseRF resp = 1B000000000000000000000000000000

learnt:B20534001F0B1E0B0A1E1E0B0B1F0B1F1E0B0A1F0B1F1E0B1E0B1E0B1E0B1E0B0B1F0B1E0A1F1E0B1E0B0B1F0A1F0A1F1E0B0A1F0A00013400000000
which tested ok

Ok, those are interesting, thank you.

One more question: does learnIR() work as expected?

Your welcome. Yes perfect not even one misread.

Ok, I have an experiment that I'd like to try, to see if we have an option to improve the learnRF reliability. I'll contact you via PM to discuss.

I pushed this feature live in v0.9.4. I wanted to post here with some introductory instructions. This documentation will eventually live in the readme.


I use it to configure multiple devices in my setup with a single command call, which makes writing automations simpler.

I also prefer that the sequence itself is edited as a string, which I find faster to iterate on compared to building that same logic in either of the rule or flow execution engines that I use.


All of the previous features still work. You can sendSavedCode and push with a single code name.

The sequence feature is also accessed using push. The string contents define the sequence like this (you must use the whole line, including the sequence: part:

sequence: term=value; term=value; ... ; term=value

  • term can be any of code, delay or repeatN, in any mixture and order.
  • value is:
    • the saved IR or RF code name (for code)
    • number of milliseconds up to 5000 (for delay)
    • a saved IR code name (for repeatN, where you also replace N with the number of repeats of that IR code).
  • You can have as many entries as you want in a given sequence.
    • Use this carefully because once you start executing the sequence it will keep going until it completes.
  • When one sequence is executing the driver won't let you start another one, but there is no limitation on sending a single code while a sequence is executing.
    • This can lead to unexpected behavior, and I would recommend trying to make sure that you don't run any other commands while a sequence is executing.
2 Likes

Here's what a sequence looks like in a Rule Machine button controller:

Here's what a sequence looks like in a node-red flow:

I just checked in v0.9.5, which adds a periodic keep-alive ping in the driver for RM3 and RM Pro devices.

Prior to this fix, Broadlink devices totally isolated from the cloud would reboot every 3 minutes or so.

In order to activate the fix you need to update the driver code and then hit Initialize on your virtual devices.

I am still investigating to find the equivalent fix for RM4 devices, but in the meantime this is really only a cosmetic issue because the device and Hubitat driver will recover automatically without noticeable downtime.

2 Likes

Just wondering how you found the reboot, and if it's possibly the reason for those occasional command failures?

I noticed that they were reconnecting to my network frequently after I blocked WAN traffic, and I eventually found this protocol workaround online in another integration.

It works perfectly for my RM3 Minis to prevent reboots, but to be clear even before this I wasn't actually seeing any issues with sending codes even in my relatively aggressive testing.

Nobody that I saw has figured out the equivalent RM4 bits yet, so I am trying to track that down myself.

Which command failures are you referring to?

2 Likes

A while back and prior to using your driver, I had occasional commands issued with no mini-split response. I was thinking perhaps when a command is issued while the device is rebooting, it would be ignored, but I do not block my RM3s from the WAN.

Well, you wouldn't be affected by this particular issue if your device wasn't blocked and was still getting the cloud ping packets.

However, if the driver command went out to the device at just the right instant while it was rebooting for some other reason, it would indeed just get dropped. The device uses UDP which doesn't have any retry mechanisms built in if a packet is missed.

The window to miss would be really small, though. It seems to take only a couple of seconds to reboot and you'd have to get fairly unlucky to hit that window. Not impossible, but I'd be surprised if you saw it frequently enough to notice it.


It might be more likely that there was IR interference occasionally or that the AC sometimes needed to get hit with the IR blast twice for some reason (I have seen some "sleepy" behavior with some of my IR devices, for example sometimes needing to wake up a screen with any old command before the specific one I want to send with have its effect).

1 Like

Hi. First thanks for developing this @tomw. I successfully am using the driver which works well with my RF controlled lights.

Scratching my head though: what attributes of it are exposed to the platform so I can use rule machine to control it? Looked through many action types in rule machine yet the virtual device doesn’t show up with switch/dimmer/button properties.

1 Like

Use device type Actuator to select the device, then use a custom action (or custom command) to actually execute commands, like sendSavedCode or push, in your automations.

1 Like

I'm having a strange issue with the remote driver that may have more to do with my browser than the driver but either way.... any help would be great.

After running the Learn IR command, the device page becomes unresponsive and nothing I do will bring it back. Every time I back out to the device list and go back to the device, it hangs and Chrome eventually shows me a message saying I can wait or kill the page. I rebooted HE, even rolled back firmware. The only way I could access the device again was to create a second Virtual remote device, but then as soon as I ran the learn IR command the same thing happened to that one too.

I finally thought to try loading the page in Edge and everything works fine, so its not HE, it's my browser. But it's still strange and a bit inconvenient. I also dumped the browser cache, didnt help.

Which browser?

And just to make sure I understand where it is hanging -- how far into learning, testing, and saving do you get before you leave the device page and then encounter the hang? Or does it hang even before you leave the device page?

Very peculiar behavior, but unless you're doing a Save Preferences somewhere in the process, there is basically no interaction between the web page and the driver, other than updating attributes in Current States.

Have you seen this behavior with any other drivers or virtual devices?