HTTP/MQTT/LIRC bridge for Broadlink devices, supports Pronto hex codes

I have a Broadlink RM-PRO+ and I must say I’m not a big fan of the existing broadlink switch component. My main gripe with it is because it requires the use of the awkward Broadlink-specific format for codes. What I really wanted to do is to use the widely known Pronto hex codes from specialized forums and many IR databases such as irdb.tk.

There’s also this amazing program called IrScrutinizer which allows you to “play” with IR codes: analyze and generate them, etc. It has integration with IR databases and it can transmit IR codes through many output devices (one of them being a LIRC daemon). I wanted to be able to use my RM-PRO+ as such a device.

So to scratch my own itch I have written broadlink-bridge and an accompanying hass.io add-on, and I hope it may be useful to others. It can “talk” HTTP, MQTT and LIRC (for IrScrutinizer) and it accepts not only codes in Broadlink base64 format ( JgAcAB0...), but also Pronto hex ( 0000 006C 0022...) and allows specifying repetitions as well (2*JgAcAB0...).

Although it also works standalone, I presume most here are interested in using it together with Home Assistant. You can use the bridge as a replacement for the broadlink switch in one of two ways:

  1. By combining RESTful commands, a boolean input and an automation:

    rest_command:
      my_device_on:
        url: http://BRIDGE_HOST:PORT/device/DEVICE
        method: post
        payload: CODE
      my_device_off:
        url: http://BRIDGE_HOST:PORT/device/DEVICE
        method: post
        payload: CODE
    input_boolean:
      my_device:
        name: My Device
    automation:
      trigger:
        platform: state
        entity_id: input_boolean.my_device
      action:
        service_template: rest_command.my_device_{{ trigger.to_state.state }}
    
  2. Or via a MQTT switch:

    switch:
    - platform: mqtt
      command_topic: broadlink/device/DEVICE/transmit
      payload_on: CODE
      payload_off: CODE
    

More details in the project README.

Please note that this project is in early stages, so do not expect it to be free of bugs. Have fun.


9 Likes

Wow! Thank you so much for doing this! Thank you, also, for mentioning irdb and IrScrutinizer - I wasn’t aware of either one. I have an RM-Pro+ and it has been nothing short of a pain in the neck (other areas as well) - but I’ve always resisted the urge to smash it with a hammer. I look forward to installing and playing with your add-on. Will this also work with an RM Mini? Also, is this purely for IR? I’m planning to use my RM-Pro+ to control some ceiling fans/lights (via RF) as well.

Note that irdb.tk is (very) outdated compared to the Git repository at https://github.com/probonopd/irdb, so what I do is to get the codes from the Git sources and use IrScrutinizer to generate the Pronto hex representation. Then the codes can be submitted directly to the bridge (via LIRC protocol) for testing. Once you have confirmed that they work, just use the Pronto hex when sending to the bridge or put it into the config file and give it a name and use the name instead.

Regarding the RM Mini, because the bridge is simply a fancy network wrapper over https://github.com/mjg59/python-broadlink I believe it should just work. You should give it a shot.

Regarding RF, this bridge was really meant for the IR use case so there’s no explicit support. However, if you use the normal Home Assistant way (or any other way) to learn an RF packet, and you have it in Broadlink format, you should be able to send that packet via the bridge. (I didn’t really test RF packets and it might be the case that the bridge is rejecting them when validating input packets, but if that’s the case I can fix the code.)

1 Like

Thanks! I’ll test/try that and report back.

Hi Ibshenkel, thank you so much for writing this, I have just been looking at different ways to get broadlink to work and all of them seemed quite long winded. his method seems so universal, its great. The only thing is after installing the Hassio add on, I am not quite sure what to do next as there are so many options. I have the list of promto codes I want to add and I can see that you can use the restfulapi but not sure of what the Hassio configuration yaml code should look like. If you could give one formatted example I could go from there. Also is restful the best method for simply adding commands in HA?

I’ll explain the RESTful way because that’s the way that will require the least amount of configuration, at least to get you started. I’m assuming that you have the add-on running.

Let’s say you have two codes in Pronto hex, the code for on and the code for off (I will call them CODE_ON and CODE_OFF)

switch:
- platform: rest
  resource: http://HOMEASSISTANT:8780/device/DEVICE
  body_on: CODE_ON
  body_off: CODE_OFF

HOMEASSISTANT is the address of the host in which you’re running hass.io.

I’m not sure if your Broadlink device was auto-detected during discovery, so for DEVICE you can try first specifying default (literal). If that doesn’t work, then try specifying the hostname or IP address of your Broadlink device (you’ll need to check your router to figure that out): http://...:8780/device/1.2.3.4

To see if it works, check if the LED of your Broadlink device blinks when you transmit the code. If it does, then it is working. If the LED blinks but the device being controlled via IR doesn’t respond, then it’s the Pronto code that is wrong.

You can also check via curl: curl -d 'CODE_ON' http://HOMEASSISTANT:8780/device/DEVICE (remember to replace the uppercase words, those are not literal)

Once you have this basic set-up working, you can do more (MQTT, defining named commands) by creating a configuration file.

P.S.: Example of a Pronto hex code, this one to turn on a Denon receiver:

0000 006D 0000 0020 000A 001E 000A 001E 000A 0046 000A 0046 000A 001E 000A 001E 000A 001E 000A 001E 000A 0046 000A 001E 000A 0046 000A 0046 000A 001E 000A 001E 000A 001E 000A 0677 000A 001E 000A 001E 000A 0046 000A 0046 000A 001E 000A 0046 000A 0046 000A 0046 000A 001E 000A 0046 000A 001E 000A 001E 000A 0046 000A 0046 000A 0046 000A 0677

Unless you’re already using MQTT for other purposes and prefer it, I recommend sticking to the HTTP protocol since it is easier.

If you have commands that are not on/off which you would like to transmit, then you can use RESTful command:

rest_command:
  my_command:
    url: http://HOMEASSISTANT:8780/device/DEVICE
    method: post
    payload: CODE

Thank you so much for such a detailed response. This makes so much sense now.

Please report back if you managed to get it working.

Unfortuantly in the addon I get the following errors

2019-09-18 20:53:05,329 WARNING HTTP: GET /device/192.168.1.190 HTTP/1.1 code 501, message Unsupported method (‘GET’)
2019-09-18 21:05:45,543 WARNING HTTP: GET /device/default HTTP/1.1 code 501, message Unsupported method (‘GET’)

I tried both the IP address and typing default.

In HA I get
Got non-ok response from resource: 501.
Im searching around for troubleshooting options.

I installed the add on, didnt chagne the config file in this addon and put the following code in my HA configuration file

switch:
- platform: rest
resource: http://192.168.1.38:8780/device/192.168.1.190
body_on: 0000 006d 0026 0000 0155 00aa 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0015 0016 0014 0016 0015 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0014 0016 0015 0016 060b 0155 0055 0016 0e58 0155 0055 0016 00aa
body_off: 0000 006d 0026 0000 0155 00aa 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0014 0016 0015 0016 0015 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0014 0016 0040 0016 0015 0016 0015 0016 0014 0016 0040 0016 0040 0016 0014 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0014 0016 0015 0016 060b 0155 0055 0016 0e58 0155 0055 0016 00aa

Cheers

I forgot to mention that you have to specify the method as well (I mistakenly assumed that when there’s a body, the method defaults to post):

switch:
- platform: rest
  resource: ...
  method: post
  body_on: ...
  body_off: ...

Remember that when using the HTTP protocol to send commands, the method will always be POST.

Thanks Leonardo, I thought that the default was for post. I did add this line to the configuration but it still comes up with same error. I tried searching and cant see much information on this error. Not sure why it is trying to do a GET.

Quick update. The rest command option works fine.

rest_command:
my_command_off:
url: ‘http://192.168.1.38:8780/device/192.168.1.190
method: post
payload: ‘0000 006d 0026 0000 0155 00aa 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0014 0016 0015 0016 0015 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0014 0016 0040 0016 0015 0016 0015 0016 0014 0016 0040 0016 0040 0016 0014 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0014 0016 0015 0016 060b 0155 0055 0016 0e58 0155 0055 0016 00aa’

my_command_on:
url: ‘http://192.168.1.38:8780/device/192.168.1.190
method: post
payload: ‘0000 006d 0026 0000 0155 00aa 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0015 0016 0014 0016 0015 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0040 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0015 0016 0040 0016 0040 0016 0040 0016 0040 0016 0015 0016 0040 0016 0040 0016 0040 0016 0014 0016 0015 0016 060b 0155 0055 0016 0e58 0155 0055 0016 00aa’

Hi Leonardo,

I just tried your updated add-on and this has stopped the error inside the add-on page, but I still get a 501 error in HA log.

Got non-ok response from resource: 501
5:52 PM components/rest/switch.py (ERROR)

I’m still happy with the service command feature anyway it works great, but thought I would let you know. ( this error also stops the rest api switch from appearing as an entity in HA)

I realized that the version I’m running has a few changes that I forgot pushing to GitHub, that’s why you’re encountering this problem. I’ll push an update.

The problem you’re encountering was not the missing post. It is because the RESTful switch tries to unconditionally query the state of the switch by performing a GET. The version currently in GitHub doesn’t have the GET implemented. Once I push the update this exact problem will disappear.

However, this made me think a little bit and I think I’ll not document the RESTful switch and change the documentation. The main problem with the RESTful switch is that it assumes that the switch is “two-way” and it does not implement the optimistic and assumed state that for example the MQTT switch has, and this results in confusing UI. I’ll try to document an alternate snippet that relies on the template sensor instead.

So, I have updated the initial post here and in the project README. I came to the conclusion that the REST switch way is not really helpful, so I documented an alternative way to do the same.

Giving up on the REST switch support allows me to remove the GET workarounds from the code, which makes my life easier from the maintenance perspective.

The updated add-on is working well still. The using restful commands is a good options. Thanks for all the effort.

Hi!
is installed in Docker, Hassio, and Mosquitto broker .
and “https://github.com/lbschenkel/hass-addon-broadlink-bridge” it also.
unfortunately i don’t understand these could you describe step by step and help
what’s next?
Thank you!!

Next steps:

  • Have you installed the add-on? What’s the host and port?
  • Do you have the IR codes that you intend to transmit?

I recommend setting it up via REST first because it’s simpler, and only when you have it confirmed working you should try changing to MQTT (but there’s nothing wrong in keep using REST).

Can this bridge automaticali recieve ir code from remote when user press button and send code to HA?

I use my ir kitchen hood and some ir lights in HA. ( rm pro and rm mini + broadlink switch), but I have problem when user control ir hood or ir lights trough ir remote controller because change is not synced with HA.