Thanks, this is indeed a bug in the documentation. I have created a pull request to fix it.
1 Like
I donât have access to this device, so you will need to help me out to resolve this. Can you put the binding in DEBUG mode and share with us the log files?
When I disable an enable the device this all I get in the log for the binding
2025-01-05 08:32:44.621 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' updated: UNKNOWN
2025-01-05 08:32:44.621 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' changed from INITIALIZING to UNKNOWN
2025-01-05 08:32:44.629 [DEBUG] [ink.internal.BroadlinkMappingService] - notifying framework about 32 commands: [LIVINGROOM_TV_HDMI4, LIVINGROOM_TV_HDMI3, LIVINGROOM_TV_HDMI2, GUESTROOM_SOUNDBAR_POWER, SOUND_BAR_VOLUME_DOWN, LIVINGROOM_TV_HDMI1, SOUND_BAR_MUTE, KITCHEN_TV_ENTER, GAME_COMPONENT, SOUND_BAR_VOLUME_UP, LIVINGROOM_TV_SOUNDBAR_POWER, GAME_COMPOSITE, GAME_SVIDEO, LIVINGROOM_TV_COMPONENT1, GAME_RGB, SOUND_BAR_POWER, KITCHEN_TV_INPUT, GAME_HDMI1, GAME_HDMI2, ELECTRIC_HEATER_POWER, GUESTROOM_TV_POWER, KITCHEN_TV_VOLUME_DOWN, KITCHEN_TV_MUTE, BEDROOM_TV_SLEEP, AV_BOX_POWER, KITCHEN_TV_POWER, KITCHEN_TV_BUTTON3, KITCHEN_TV_BUTTON1, LIVINGROOM_TV_HOME, BEDROOM_TV_POWER, KITCHEN_TV_VOLUME_UP, GAME_POWER] for single IR device
2025-01-05 08:32:44.630 [DEBUG] [ink.internal.BroadlinkMappingService] - notifying framework about 0 commands: [] for single RF device
2025-01-05 08:32:44.630 [DEBUG] [ink.internal.BroadlinkMappingService] - BroadlinkMappingService constructed on behalf of broadlink:rm3-q:24-df-a7-50-3d-f4:command and broadlink:rm3-q:24-df-a7-50-3d-f4:rf-command
2025-01-05 08:32:44.630 [INFO ] [event.ChannelDescriptionChangedEvent] - Description for field 'COMMAND_OPTIONS' of channel 'broadlink:rm3-q:24-df-a7-50-3d-f4:rf-command' changed from '{"options":[]}' to '{"options":[{"command":"LIVINGROOM_TV_HDMI4"},{"command":"LIVINGROOM_TV_HDMI3"},{"command":"LIVINGROOM_TV_HDMI2"},{"command":"GUESTROOM_SOUNDBAR_POWER"},{"command":"SOUND_BAR_VOLUME_DOWN"},{"command":"LIVINGROOM_TV_HDMI1"},{"command":"SOUND_BAR_MUTE"},{"command":"KITCHEN_TV_ENTER"},{"command":"GAME_COMPONENT"},{"command":"SOUND_BAR_VOLUME_UP"},{"command":"LIVINGROOM_TV_SOUNDBAR_POWER"},{"command":"GAME_COMPOSITE"},{"command":"GAME_SVIDEO"},{"command":"LIVINGROOM_TV_COMPONENT1"},{"command":"GAME_RGB"},{"command":"SOUND_BAR_POWER"},{"command":"KITCHEN_TV_INPUT"},{"command":"GAME_HDMI1"},{"command":"GAME_HDMI2"},{"command":"ELECTRIC_HEATER_POWER"},{"command":"GUESTROOM_TV_POWER"},{"command":"KITCHEN_TV_VOLUME_DOWN"},{"command":"KITCHEN_TV_MUTE"},{"command":"BEDROOM_TV_SLEEP"},{"command":"AV_BOX_POWER"},{"command":"KITCHEN_TV_POWER"},{"command":"KITCHEN_TV_BUTTON3"},{"command":"KITCHEN_TV_BUTTON1"},{"command":"LIVINGROOM_TV_HOME"},{"command":"BEDROOM_TV_POWER"},{"command":"KITCHEN_TV_VOLUME_UP"},{"command":"GAME_POWER"}]}' for linked items: []
2025-01-05 08:32:44.631 [INFO ] [event.ChannelDescriptionChangedEvent] - Description for field 'COMMAND_OPTIONS' of channel 'broadlink:rm3-q:24-df-a7-50-3d-f4:rf-command' changed from '{"options":[{"command":"LIVINGROOM_TV_HDMI4"},{"command":"LIVINGROOM_TV_HDMI3"},{"command":"LIVINGROOM_TV_HDMI2"},{"command":"GUESTROOM_SOUNDBAR_POWER"},{"command":"SOUND_BAR_VOLUME_DOWN"},{"command":"LIVINGROOM_TV_HDMI1"},{"command":"SOUND_BAR_MUTE"},{"command":"KITCHEN_TV_ENTER"},{"command":"GAME_COMPONENT"},{"command":"SOUND_BAR_VOLUME_UP"},{"command":"LIVINGROOM_TV_SOUNDBAR_POWER"},{"command":"GAME_COMPOSITE"},{"command":"GAME_SVIDEO"},{"command":"LIVINGROOM_TV_COMPONENT1"},{"command":"GAME_RGB"},{"command":"SOUND_BAR_POWER"},{"command":"KITCHEN_TV_INPUT"},{"command":"GAME_HDMI1"},{"command":"GAME_HDMI2"},{"command":"ELECTRIC_HEATER_POWER"},{"command":"GUESTROOM_TV_POWER"},{"command":"KITCHEN_TV_VOLUME_DOWN"},{"command":"KITCHEN_TV_MUTE"},{"command":"BEDROOM_TV_SLEEP"},{"command":"AV_BOX_POWER"},{"command":"KITCHEN_TV_POWER"},{"command":"KITCHEN_TV_BUTTON3"},{"command":"KITCHEN_TV_BUTTON1"},{"command":"LIVINGROOM_TV_HOME"},{"command":"BEDROOM_TV_POWER"},{"command":"KITCHEN_TV_VOLUME_UP"},{"command":"GAME_POWER"}]}' to '{"options":[]}' for linked items: []
2025-01-05 08:32:45.644 [DEBUG] [r.BroadlinkRemoteModel3V44057Handler] - Authenticated with id '01000000' and key '212C3CEAC1760737E52DA8A9E40BE457'
2025-01-05 08:32:45.661 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' updated: OFFLINE (COMMUNICATION_ERROR): Cannot establish a communication channel with the device: Response from device is not valid. (0x22=0xFB,0x23=0xFF)
2025-01-05 08:32:45.661 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Cannot establish a communication channel with the device: Response from device is not valid. (0x22=0xFB,0x23=0xFF)
2025-01-05 08:32:45.691 [DEBUG] [r.BroadlinkRemoteModel3V44057Handler] - Authenticated with id '01000000' and key '212C3CEAC1760737E52DA8A9E40BE457'
2025-01-05 08:32:45.706 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' updated: OFFLINE (COMMUNICATION_ERROR): Cannot establish a communication channel with the device: Response from device is not valid. (0x22=0xFB,0x23=0xFF)
2025-01-05 08:32:45.732 [DEBUG] [r.BroadlinkRemoteModel3V44057Handler] - Authenticated with id '01000000' and key '212C3CEAC1760737E52DA8A9E40BE457'
2025-01-05 08:32:45.747 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' updated: OFFLINE (COMMUNICATION_ERROR): Cannot establish a communication channel with the device: Response from device is not valid. (0x22=0xFB,0x23=0xFF)
2025-01-05 08:32:45.769 [DEBUG] [r.BroadlinkRemoteModel3V44057Handler] - Authenticated with id '01000000' and key '212C3CEAC1760737E52DA8A9E40BE457'
2025-01-05 08:32:45.784 [INFO ] [openhab.event.ThingStatusInfoEvent ] - Thing 'broadlink:rm3-q:24-df-a7-50-3d-f4' updated: OFFLINE (COMMUNICATION_ERROR): Cannot establish a communication channel with the device: Response from device is not valid. (0x22=0xFB,0x23=0xFF)
Hello!
Thank you for this binding! Itâs been working great for my RM4MINIâs org.openhab.binding.broadlink-4.2.0-SNAPSHOT.jar, but I recently purchased RM4PRO for the RF features and could not get the RF Learning function to receive any input through itâit just quickly switches to RF command learnt (the light on the RM4PRO does change to red and eventually goes out). The Adding RF command exits with No data found.
The latest org.openhab.binding.broadlink-4.3.0-SNAPSHOT.jar does the same thing.
I found that I could capture the remotes RF using the app, but only after telling the app which frequency to look at. (The appâs scan feature gave me the frequency.) Once I entered that, it all worked as it should (except I couldnât find a way to export that out in a format this binding would work with).
python-broadlink cli allows entering the frequency (443.89) for its rflearn. It saves to file and plays back from file fine.
to learn:
python broadlink_cli --device "0x520b 192.168.X.X abcdefghijkl" --rflearn --frequency "433.89" --learnfile Guest.blinds
to send command from file:
python broadlink_cli --device "0x520b 192.168.X.X abcdefghijkl" --send @Guest.blinds
Pasting the contents of output file (Guest.blinds) into â/var/lib/openhab/jsondb/broadlink_rf.jsonâ with the
"class": "java.lang.String", "value":
parts works great.
Is the RF Learning function working for anyone? Perhaps it just wonât work unless the frequency is given? I donât see any way to insert that in the binding to test it.
Thanks!
The code is doing a frequency scan to find the right frequency. During learning, you need to keep triggering the RF command / key to ensure the device can locate the frequency. I have to take a look at the python broadlink code, I did not know you can specify a RF frequencyâŠ
Thanks for the information. Can you share with me the information you have of the thing you created under the âInformationâ section? I need to know the Thing type and the 3 Thing properties.
Thanks! I believe the app is supposed to work like that too, but it didnât register anything until I entered the frequency in the app.
The binding just immediately displays âRF command learntâ and the âAdding RFâ command exits with âNo data foundâ for me no matter how long or early I press the remote button.
Thanks again, wonderful work!
Hello All,
Very happy to see this binding finally merged to OpenHAB.
For a number of reasons, both personal and professional, i had to take a break from looking into it, so, apologies @AntonJansen for not responding to the last couple of git requests you had. I only just started looking at this again.
While it is really good to see the binding merged, sadly it is not working great for my use case, as i still see delays of a number of seconds sometimes when using it. This is especially problematic when emulating remote controls for media devices (TVs, Media Centers, etc.), and is mostly visible when changing channels, navigating the cursor, etc. etc.
I did try the previously merged (broadlinkthermostat) binding, and i noticed this delay to be significantly, better, so to me that indicates an implementation issue.
I would be happy to put the work on debugging this, but i have no idea where to start. If someone could point me out on the right direction, i could start poking around. The functions that send the commands through the network are async, so once the function is called, i loose visibility on where the issue with the delay could be.
@matt1 , from OH 4.0.4 Broadlink binding RM3 mini error
If you need help with the delay, I could spend some $$ getting one and help out, but I am going to take the stance that I want it merged first due to the history of getting it merged.
No need to get the device (at least not yet) but would you be willing to help me navigate how to track down this issue?
Thanks!
1 Like
Iâm using this broadlink binding since a couple of years already with two rm3 mini.
Since the beginning Iâm facing those terrible delays sometimes as well.
Happy to support in troubleshooting this issue
Any update on getting my RM3 variant working? Anything else you need from me?
Thanks, interesting enough I have the same device and it used to work, but it no longer does 
Hence, something must have changed / is broken now. I would have to spend some time the coming weeks to figure out what is going wrong. My guess is that I swapped some bytes around that made it work for the other models I have (RM4 pro, and the original Pro), but I broke stuff for the RM3 mini.
Welcome back @ricardol! Please develop against the main branch of openhab now, as we are part of this. With respect to the delay issue, I have not really looked into the performance. Have you considered whether your WiFi environment might be causing the issue? In other words, does it work fast and quick with the official app, but not with this binding?
I played around with my mini RM3 and found some interesting things. Firstly, did you re-create the thing when migrating to a new binding/openHaB version? Secondly, for me it seemed when I disconnected the power and reconnected the RM3 mini, it suddenly started to work. Did you try to reconnect the power?
Hey @AntonJansen ,
Thanks! I will make sure I develop against OpenHAB main.
Yes, i have looked at the wifi environment, it is clearly not the issue. I moved houses twice and still have the same issues.
Not only the device works faster and more reliably with the App, It also works faster and more reliably if you use the broadlinkthermostat binding instead of the broadlink one. It looks to me like there is something in the way the network communication is implemented.
The issue is very simple to reproduce. Just try to use the binding to change channels on a tv, as if you were doing zapping with a regular remote control. The issue should show up fairly easily.
Thanks
I have tried removing it and re-adding it to Openhab. And I have rebooted it. I had to reboot all of them to get the others to talk. But only the RM3 v44057 that has issues. My others are just RM2 and RM3 and they work fine.
This seems to indicate that there is a problem with the network socket implementation causing delays. If I look in the code inside the binding, I do not see a lot of things that might cause these delays. I would first try out if differfent Java Runtime Environments have different performances this might resolve the issue. If it doesnât, we should explore whether switching to the java.nio package brings any significant gains.
@AntonJansen I have upgraded to OH 4.3.5 today and replaced the 0.5 jar file with the binding from the addon store.
I deleted the old items and things and recreated the things.
Unfortunately, the old RM Pro does not offer an RF channel anymore 
Why?
You fixed that a year ago:
@Bernd_Ritter I had enabled the RF for the alpha versions of the binding, but did not do this in production, as there is a mix-up of the devices and a bug that prevents devices from using. I still need to resolve this bug and hope to have it part of the 5.0.0 release.
1 Like
Thank you for the feedback. I hope you get this sorted out, since I had zero problems with the 0.5 alpha .jar
I am lucky that I also have an RM 4 Pro, which I now need to use for the RF stuffâŠ