Broadlink binding for RMx, A1, SPx and MP. Any interest?

EUREKA!!! It works!!!
I’m using beta12 with RM4pro (6026) and I can send IR signals to my air conditioner…but winter is coming :frowning:

I’ve tried to learn RF code but “No data received…” …is there an other “learning mode” for RM signals?

thanks!!!

themillhousegroup any help?

here we are:
./broadlink_cli --device "0x6026 192.168.82.160 936de4a7df24" --rfscanlearn Learning RF Frequency, press and hold the button to learn... Found RF Frequency - 1 of 2! You can now let go of the button Press enter to continue... To complete learning, single press the button you want to learn Found RF Frequency - 2 of 2!

If I add like RM3 it is online but can’t send signal.
rm3
If I add as RM4 then “Response from device is not valid. (0x22 = 0xFB, 0x23 = 0xFF, 0x24 = 0x00)”
There may be a problem in B12 because 0x5f36 RM3 should send the signal with the parameters of RM4.
Openhab automatically recognizes the device as RM4.

broadlink_discovery:
###########################################
RM4
broadlink_cli --type 0x5f36 --host 192.168.1.238 --mac 24dfa77ac05b
Device file data (to be used with --device @filename in broadlink_cli) :
0x5f36 192.168.1.238 24dfa77ac05b

The problem is “BroadlinkProtocol.class”:

final boolean error = packet[34] != 0 || packet[35] != 0;
if (error) {
throw new ProtocolException(String.format(“Response from device is not valid. (0x22=0x%02X,0x23=0x%02X,0x24=0x%02X)”, packet[34], packet[35], packet[36]));
}

@themillhousegroup

I’m running a RM4 but the temperature/humidity channels seem to be wrong. Actually humidity delivers the temperature and temperature is 0… Instead the broadlink_cli output seems to be right:

./broadlink_cli --type 0x62bc --host 192.168.103.9 --mac 24dfa74***** --sensors
temperature 24.27
humidity 60.57

Running on BETA 12

Thanks for the bug report @Flip, you were exactly right. The RM4 devices have 2 more bytes in their protocol responses. This is now fixed in Beta 13:

https://github.com/themillhousegroup/openhab2-addons/releases/download/BROADLINK_2.5.BETA_13/org.openhab.binding.broadlink-2.5.1-SNAPSHOT.jar

Cheers,
John

1 Like

Hello, any news for openhab3 binding?
Thank you.

1 Like

Thanks John for the quick fix - now it looks much better :slight_smile:

Hi Viktor, I’m experiencing the same issue with the same device (type 5f36). Conversely, the device works as expected with the Python Control for Broadlink library.

I also found it easier to switch Python Control for Broadlink.

Edit: @Viktor_Olah and @mleon71 - Looking at the code its “treated as an RM4 due to sendCode quirk” as mentioned and yep, device firmware will be V44057. I turned off lock device thanks Viktor and it does give me the same error you have. I am going to look at the code further and see if there’s something straightforward that needs to be tweaked to get it working again, referencing your notes.

@Viktor_Olah and @mleon71 - I got it working! You can try BETA 14 below, it will auto-detect as a Broadlink RM3 v11057 device.

@Cossey - Great, thanks Cossey. I made some tests and everything is working fine.

Thanks to @Cossey 's excellent work which is now merged into the main repository, Beta 14 now supports those quirky RM3 devices:

https://github.com/themillhousegroup/openhab2-addons/releases/download/BROADLINK_2.5.BETA_14/org.openhab.binding.broadlink-2.5.1-SNAPSHOT.jar

Thanks again Stewart :smiley:

1 Like

thank you john!

HI, Do you plan to move the binding to OH3?

Regards
Lorenzo

2 Likes

@themillhousegroup I’m looking at doing some more tidying up. Looking at removing the IV and keys from config as Caro had them, thinking about placing them in the constants class instead.

Looking at going over the thing-types.xml again to tidy up a bit more, it’s really large, and might need to be split out to make it more easier to work with.

Can you look at resolving those problems in ThingLogger.java, I didn’t want to touch that code as I wasn’t 100% sure as to your approach with that class - once those 5 issues are sorted it’ll make things a lot easier to work with. You may also want to pull in the most recent changes from the 2.5.x branch from the new add ons repo as they started using spotless to style the code, and Jenkins will fail its checks if spotless has errors (https://github.com/openhab/openhab-addons/pull/8401).

Thanks for your efforts so far, this saves me having to use MQTT for the RM3 mini. I’m using this to automate my heat pump and old CD Player unit.

I am trying to get this setup and I am probably missing something very simple.

I have downloaded the version of the binding posted 5 days ago, moved it into my addons folder but can’t get any further.

After moving the jar file I got this in my log: -
2020-11-05 16:31:13.976 [INFO ] [.discovery.BroadlinkDiscoveryService] - BroadlinkDiscoveryService - Constructed

But when I try to discover anything the Broadlink binding isn’t showing.

What am I doing wrong?

Thanks.

Try hitting the ‘Scan’ icon on top right.

Hello,
I’m newbie and having problems with sending codes. I followed all steps and seems everything fine but openhab throwing error when I try to send codes. How can I fix the error?

2020-11-07 19:20:35.678 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.broadlink.handler.BroadlinkRemoteModel4Handler@1b49c7c’: hexString needs to have an even length: