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:
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.)
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)
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:
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.
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.
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!!
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.