OH 4.0.4 Broadlink binding RM3 mini error

Hi Vini,

Which RM model are you using? The Broadlink RM4 Pro IR and RF Universal Remote Control?

Please see the documentation here that explains how things work:

If I look at the readme, it seems to focus on the IR capabilities of the RM4. I just ordered a RM4 Pro with RF, so I have some HW to play with. I hope to have some time this week to dive into the error you posted here.


What a surprize this monday evening. I’m more than happy, that I was just able to re-learn my OH 4.1.1-1 testsystem the new (old) comands for switching ON and OFF my climasystem in the wintergarden.

I’m fully flashed, that after a couple of years of waiting, the binding is back again, and in my case fully working.

THANK you so much @AntonJansen for the development.
Great, wonderful job done.


@hmerk : I think there is no need any more to re-develop something here in the binding from you.
Makes me so happy. One more construction site less on my system :slight_smile:


Thank you for sharing your positive feedback! I want to thank all the people who tirelessly worked on this binding. I am only doing a tiny bit to get it done. Let’s hope the binding makes it to the official distribution so we can easily evolve it to something even greater.


Hi Anton,

I’m using an old RM Pro+, which I think is ‘RM2’? I don’t doubt they’ll be there or thereabouts.

Appreciate the effort & dedication :ok_hand::+1:


I am using an RM4+ and my map file looks like this


and to send the RF code

It’s been a while but I learned the codes with the Python-Broadlink and then (I think) I converted them to base 64.


Hi Vini,

I did some early investigations, the error being thrown is an error message that is being send back from the Broadlink to openhab. However, the current code does not know this error. I tried to reason a bit what error it might be based on the errors mentioned in the python broadlink tool. However, I could not find the FFF6 error code back :frowning:

You could try to see if you could use the device as an RM4 Pro.

What would help me is if you could turn on the debug mode of the binding (put org.openhab.binding.broadlink into debug mode in the log4j.xml file in your site configuration). Then provide me with the complete log filtered on this binding.

What is interesting when browsing through the code is that they do mention IR and RF learning, so RF was not a forgotten thing. Hopefully before the weekend I will have a RM4 Pro S, so I can do some testing over the weekend.

1 Like

One more experience…

On my dev system I have delete all the staff with broadlink, (jar file, items, thing, commands, map-file etc)
and have addapped my rules, and created everything new.

Learned and stored new(old) commands for OFF/ON from my IR remote for my climasystem.

Everything fine as said before…

Today, I tried only to exchange the binding on my testsystem (same 4.1.1-1 as my dev system)
So stopped the OH service, and my zram.
Delete the old binding and copied the new binding to the addon folder.
Cleaned cache, started zram and the OH service again.

→ Everything works…

So I can use the long time ago created commands without any big trouble.
It seems fully operation again…

So nice, so far…


@AntonJansen log at 2024-01-18 22:14:14.519 [DEBUG] [ink.internal.BroadlinkHandlerFactory] - bundle - Pastebin.com

Probably not the cleanest log, on the basis I added an RM2/3/4 Thing.

RM4, couldn’t connect. Just sat in error.
RM3 connected, but didn’t help.
RM2 connected, but still no dice.

Being able to convert my acquired RF code from python-broadlink, might at least help to check that the Send Command is working, but I couldnt find a way to get a meaningful base64 output from what I have.

I couldnt find much online about the format I’ve received either, with all the slashes etc…I suspect its some kind of wrapped up Hex, but I’m not sure what all the \n \t \r params mean, so can’t clean it myself.

Hi Vini,

It is still the same error as before. Could we try the following?

  1. Remove your broadlink.map file from openhab
  2. Follow the instructions in the documentation on learning new commands
  3. Check if the RF command is learned by the binding creating new entry in a newly created broadlink.map file. If not, post DEBUG log file. Try to see if IR commands can be learned.
  4. Send out the RF command, as defined in the documentation. If not working, please post the DEBUG log file.

I’m just trying to see if the actual commands in the file you specify are the problem, or whether it is the communication of the binding with the device. If the problem is the first, the above steps would work. If the problem is the latter, I need to reverse engineer how the broadllink python binary works with your device.

If all fails, please use the broadlink python and post the output of the discovered device, i.e.:

import broadlink
devices = broadlink.discover()

This way I can see the device type and start reading the associated python code to see where it is different than the binding.

Hi @AntonJansen, I feel that the issue is to do with the learning, specifically around RF. There doesn’t seem to be many complaints from folks with IR devices… In relation to your test scenario, whereby I throw an IR command its way, I’ll see if I can work it through later.

I’ve no problem interacting/learning/sending via python-broadlink, so I think there’s likely just a small RF related tweak or something, to do with the learning aspect in the addon… anyway…

In relation to python-broadlink,

Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import broadlink
>>> devices = broadlink.discover()
>>> print(devices)
[broadlink.remote.rmpro(('', 80), mac=b'x\x0fw\xebI\x8a', devtype=10153, timeout=10, name='智能遥控', model='RM pro+', manufacturer='Broadlink', is_locked=False)]

Started working on replicating the issue on my own side. I already hit a wall, as my RM Pro 4 was not recognized. Fixed some bugs to make it work and I seem to be able to learn RF commands using the broadlink python program.

Investigating the python program, the conclusion is that we need to add an additional part for RF, as it uses a different command and learning cycle. I can test the learning part, but currently not verify the sending part.


Cool, this is kinda what I had assumed. Appreciate I’ve not been overly helpful, but happy to test anything I can.

After finishing up some review comments about the whole binding, I am now working on the RF part.


First step in RF learning is working; finding the correct frequency. I do run into issues with confirming the learned command, so it still needs more work.

1 Like

Glad it wasn’t just me/user error on my part. Good luck with your research!

I have managed to learn and send a RF command on a RM4 Pro. Next steps are to clean up the code and see if it works with a RM pro+ device as well. I have also changed the way commands are learned. It will now be completely possible through the web UI, without the need for the logging information.

These changes might come after the initial version has been accepted into openhab, we will see. Once I have a build ready for testing, I will post it here @Vini, so you can test it and let me know whether it works for you.


@Vini and others interested in RF functionality:

An alpha version of the binding with RF support is now available here. I have tested this with a RM Pro 4, please see if it also works with a classic RM Pro.

Please find the instructions on learning commands here, as I have made it more convenient to learn new commands.

Please let me know what you experience with this new alpha version!


Is this the same broadlink binding as discussed in the other thread?

Are there any migration steps required?