Broadlink RM Pro + Livolo Switches + RF learning woes

Tags: #<Tag:0x00007f77fdb073f0>

I apologize beforehand for including mixed questions and findings in the same post, but since they are all related they might prove useful to people pursuing similar configurations (and of course to me while I’m searching for solutions). Some of the issues mentioned, are also not HA related, but more Broadlink+Livolo related.

First my setup consists of the following:

  • HA 0.38.3 running on a Raspberry Pi
  • Broadlink RM Pro
  • Broadlink A1 Sensor
  • Livolo (original) switches
  • Dubious quality third party RF controlled wall socket
  • Third party RF controlled LED strip
  • Amazon Echo

I am using broadlink component’s learn service in HA to learn the RF codes. In learning mode, I discovered that I practically need to have the remote right next to the RM Pro so it can detect them. Additionally, I discovered that even if the targeted device receives the signal and turns on or off when I press a button on the remote, I have to keep it pressed longer than that until the RM Pro manages to record it.

Issue 1 (HA Related)

If HA has just started, the broadlink component’s learn service works like a charm every time. However, if at any point I send a code to broadlink (i.e. through the buttons on the dahboard), then the learn service will stop working afterwards alternating between two behaviors every time I click the CALL SERVICE button. It will either print an error saying that it cannot connect to the device, or go into learning mode and immediately print that the code received was AAAAAAAAAAA (i.e. a series of 0 bytes), without having the time to press any button on any remote.

It works fine again, if I restart HA.

Issue 2 (HA/Configuration Related)

No matter what I do, I cannot get the A1 sensor to show up on HA’s dashboard. It appears as a target device though in the broadlink service with learn/send commands. My configuration for it is as follows:

switch 2:
  platform: broadlink
  mac: 'xx:xx:xx:xx:xx:xx'
  friendly_name: 'Broadlink Sensor'
      - 'temperature'
      - 'humidity'
      - 'air_quality'
      - 'light'
      - 'noise'

I’m using “switch:” for the RM Pro, and it works as expected.

Update: My bad. I had to declare it as a sensor and not as a switch. Switching it to sensor solved the problem.

I noticed during learning RF codes, that they are never the same for the same remote control button. I have absolutely no clue about how RF works, but I guess there must be a pattern to the byte code, and the byte code might be changing depending on maybe distance? signal strength? signal duration?.

Now, for the cheap wall socket and the LED strip, reproducing the RF signals from RM Pro works every single time flawlessly. But when it comes to the Livolo switches, things are getting very messy and the behavior is erratic at least.

After learning the RF codes for every single switch in my house, I discovered that the behavior is as follows:

  • Some switches will work flawlessly every single time. (Curtain switches for instance work every time, and some light switches too)
  • Some switches will work most of the time, but sometimes they won’t trigger, in which case I’ll have to issue the command twice or thrice until they do
  • Some switches will sometimes work, but most of the time they won’t. Command has to be issued multiple times until they do, which ranges randomly between 2 or 20 times.
  • Some switches will downright refuse to work at all.

I have tried learning codes for the same switch again and again to various degrees of success, but since I don’t know how to format the JSON data in the broadlink service’s send command it is a really tedious process to learn the code, copy it in the config, restart hass, test it, and restart hass again to learn a new code (due to the issue mentioned above), which brings me to:

Question 1 (HA Related)

Could someone provide an example of the JSON structure for the SEND command for the broadlink service? There is mention of it in HA’s help page for the service, but no actual example.

Update: I found out the structure. Here’s an example

{"packet": ["base64 encoded packet"]}

I have two Livolo remotes, a small one that has 10 buttons and 4 scenes split into two room settings and a big one with 40 buttons and 16 scenes split into 4 rooms. As the pairing/syncing information for livolo switches is actually stored on the switch rather than the remote, a switch can sync with multiple remotes and multiple buttons. Initially, I had switches synced to both remotes, which apparently makes things more difficult into copying/reproducing RF codes that work.

While the switches were synced to more than one remote, the code being sent by the remote was of the following format and length:


and sometimes this length:


As soon as I cancelled all switch pairings, and resynced them with only one button, the RF code sent changed in length to this format:


This resulted into more switches working ok, or “upgrading” from not working at all to working sometimes. A couple of switches, even if desynced and resynced to one remote only, will still be sent the long code.

I recorded the RF signal of a single button multiple times, and converted the base64 string into hex to get a better look at the data being sent. Note that Livolo switches are toggle ones, so the same RF code switches them on and off.

B2 5F 28 00 13 06 060606 06 06 0B 0C06060B07 06 07 05 07 05 07 05 07050705 07 06 0C0B0C060606 07 0B 07 05 07 05 06 06
B2 79 28 00 13 06 060606 06 06 0B 0C06060B07 05 07 05 07 05 07 05 07050705 07 05 0C0B0C060606 06 0B 07 05 07 06 06 06
B2 67 28 00 13 05 060606 07 07 0B 0C06060B07 05 07 06 07 06 07 05 07050705 07 05 0C0B0C060606 06 0B 07 05 07 05 06 06
B2 7B 28 00 12 06 060606 06 06 0B 0C06060B07 05 07 06 06 05 07 05 07050706 07 05 0C0B0C060606 06 0B 07 06 07 05 06 06
B2 53 28 00 12 06 060606 06 06 0B 0C06060B07 06 06 06 06 06 06 06 07060706 07 05 0C0B0C060606 06 0C 07 06 06 05 06 06
B2 21 28 00 12 06 060606 06 06 0B 0C06060B07 05 07 05 07 05 07 05 07060705 07 05 0C0B0C060606 06 0B 07 05 07 05 06 06
B2 7B 28 00 13 06 060606 06 06 0C 0C06060B07 05 07 06 06 06 07 05 07050705 07 05 0C0B0C060606 06 0B 08 05 07 05 07 06
B2 36 28 00 12 06 060606 06 06 0B 0C06060B07 05 07 05 07 05 06 06 07060705 07 06 0C0B0C060606 06 0B 07 05 07 05 06 06

I’ve separated the bytes to try and identify the ones that are the same every time from the ones that differ. Maybe someone who’s way more savvy about RF codes than I am (which is next to none), could identify something in these.

For reference, here’s one more code from a different button (which resulted in to the medium length code)

B2 5B 2A 00 13 06 06 07 06 06 06 0B 07 05 0C 06 06 0B 07 06 07 06 07 06 06 06 07 05 07 05 0D 0B 07 06 07 06 07 06 07 05 07 05 07 05 06 06 0000000000000000000000000000
B2 1E 2A 00 12 06 06 06 06 06 06 0C 07 06 0C 06 07 0B 07 05 07 06 07 06 07 06 07 05 07 05 0C 0B 07 05 07 06 07 06 07 06 07 05 06 05 06 06 0000000000000000000000000000
B2 6E 2A 00 12 06 06 06 06 06 06 0B 07 05 0C 06 06 0C 07 06 06 06 06 05 07 05 07 05 07 05 0C 0C 07 06 07 05 07 05 07 05 07 05 06 06 06 06 0000000000000000000000000000
B2 60 2A 00 12 06 07 06 06 06 06 0C 07 06 0C 06 06 0B 07 05 06 06 07 06 07 06 07 06 07 06 0C 0B 07 05 07 05 07 05 07 06 07 06 07 05 06 06 0000000000000000000000000000

I should note at this point, that the issues are not limited to HA. Broadlink’s eControl app protrays the very same behavior when it comes to Livolo switches.

Which brings me to my final question

Question 2 (RM Pro/Livolo related)

Has anyone tackled with this before and faced similar issues, or might have an idea that would make this work solidly as with other RF devices?

Thank you for your patience reading through this, and apologies if I somehow broke posting/formatting rules as this is my first time posting here.

I found in another post that you have to repeat the hex code multiple times then encode it to base64 and send that as a packet. The HEX code must be a multiple of 16, and for some reason I had to repeat the code 4 times (or multiples of 4) after the first time (i.e. either 1 time, 5 times, 9 times, 13 times etc).

While this seems to work for Broadlink’s TC2 switches, it does not work with Livolo ones.

What I did find out though, is that for one switch having recorded a few RF codes of the same button, and trying them out afterwards, one of the codes turned out to work every time. Interestingly enough, one of the recorded codes for the light switch I was testing before finding the “good” one, triggered a different curtain switch, which makes me worrisome about the RF quality in terms of frequency clashing of the Livolo switches after all.

As that particular switch had demonstrated good behavior before (i.e. always working), I’ll try recording a boatload of codes (let’s say 100) for a switch that currently misbehaves and try them out afterwards, so I can test the theory that in the series of codes, at least one of those works always.

It looks that the theory of trying multiple codes works for some of the switches. I managed to get a few more switches to work all of the time (or almost all of the time).

Apparently though, 2 way switches blatantly refuse to work at all. I tried more than 50 codes recorded, I even try binding the switches to different remote buttons to no avail. They didn’t work at all, not a single time.

I’m suspecting that the RM Pro’s firmware is somewhat incompatible with livolo’s RF protocol. I’m going to fire an e-mail to Broadlink’s support and see if they have an insight about it.

After a few e-mails exchanged with Livolo’s and Broadlink’s customer support, I’ve learned that when learning RF codes in RM Pro, you have to use e-Control’s “Sweep Frequency” function. This basically learns the RF code in two steps. In the first step you have to keep the remote control’s button that you want RM Pro to learn pressed down so it sends the signal continously until RM Pro learns it (or most probably collects enough data about the signal), and in the second step you just have to tap on the remote button to send it once.

I tried the sweep frequency method with my RF controlled led strip, which had an issue with the on/off command (i.e. it would somtimes turn the strip on and off, or on and off and on again etc), and now it works perfectly.

However, the livolo remotes that I have, will not send the signal continuously no matter how much time you hold the button pressed (or if they do send it continuously, there’s a cutoff point in the signal transmission, the duration of which is less than the time required by RM Pro to learn it in frequency sweep mode. I kind of circumvented this by pressing the button repeatedly, (which at least had RM Pro complete the frequency sweep learning process), and although it still doesn’t work perfectly, it has shown improvement in the replicated codes. Now switches that never worked before started to work 20-30% of the time, and the ones that intermittently worked, will work more frequently.

As such, I suspect that if I manage to find a livolo switch compatible remote that broadcasts the RF signal continuously when the button is held pressed, then I might find a robust solution to my problem.

I’m investigating the vl-rmt-02 remote and if indeed it works as I suspect it might, then I’ll get myself one and go in a daunting process of syncing a switch to one of the rmt02 buttons, learning that code in the RM Pro, then desync the switch from the remote, and sync it to the code transmitted by RM Pro… for all of my switches.

1 Like

Hi, lots of good stuff learned from you, especially the scan before code learn. I had to do this for a 315MHz device I have.

How do you record the TC2 codes? I can only create them using the e-Control software which uses the RMPro to send the codes, so I can’t record them if the RMPro is transmitting. I did consider buying a learning remote but that is yet another step removed and another variable.

I’ve tried complaing about the lack of examples and proper exhaustive definitions of the setup details for YAML but it falls on deaf ears. Also agree that having to restart HA every time to test something is painful, It’s worse when you acceidentally mess up the YAML with a ‘space’ or other formatting issue!!

There is one issue for me were I to choose TC2, and that is there is no feedback of the light status which makes guaranteed operation dififcult for repeat codes. I have some success with the Sonoff switches which operate using WIFI amd provide status data but you have to reflash the software on the switch. Currently there is only a single gang switch.

I don’t have TC2 switches, so I don’t know how they work exactly, but there’s a very detailed thread about TC2 switches which offers very useful information.

The lack of feedback on the switches is a really major gripe for 100% robust remote operation. I stumbled upon the products by GeekLink, especially their FB1 light switch, which offers feedback. They also have an IR/RF hub called RemoteBox which looks promising. Of course, it’s out of the question for me as I’ve invested heavily on Livolo light switches, and I’d have to spend another 1k to change the switches to GeekLink ones (and I have no idea how well they work), but it’s worth taking a look.

Speaking of feedback, here’s the thing I don’t understand. If a switch is feedback capable, then I suppose that the transmitter will keep sending the same code, until it receives feedback from the switch that it has received the signal and performed the operation.

So basically, that’s the primary reason why the RMPro fails to work 100% of the time. But if the Livolo switches do not send feedback, how does the Livolo remote work 100% of the time with no issue at all?? I asked the Livolo support if there is some kind of feedback between the switch and the remote, but they haven’t replied to that query 2 weeks later…

Another interesting thing that I’ve noticed, is that if I group multiple switches together and fire them up one after the other (I use Amazon Echo for voice control), they tend to have a much greater success rate. For instance, I have a specific switch in my living room that in order to work through RMPro I have to send the RF code, 4 or 5 times until it works. But if I put it in a group with 4 more switches on the living room and the RF codes are being rapidly sent for all switches in quick succession, it will work 90% of the time.

This is very puzzling…


Sorry I misread your post which mentions the TC2 (thought you had one). I followed up on the Geeklink devices which do indeed seem to have two way communication, a must if dealing with sensors such as their door/window device. For such devices to successfully exist as part of an RF network they must use either a protocol similar to CSMA (carrier Sense Multiple Access). This protocol allows multiple transmitters to share a common channel. They do this by waiting for the channel to be free and then sending their data. There is always the chance that two devices will transmit simultaneously and this is either detected in which case each device waits a random interval and then repeating thier data until it is acknowledged. The other solution would be to poll the devices but that results in slow response and knowing what devices you are looking for!

In the case of Livolo and other one way devices it is possible that there is a sleep condition (unlikely for mains powered devices) or that the transmitter/receiver have to synchronize before data can be recognised. I guess that a batch of messages might make the synchonising more reliable (each receiver still needs to recognise its address before actioning a command). Some devices seem to use a ‘rolling’ code where there are perhaps four possible command sequences and the receiver will only respond to the next one in the sequence after the last one it recognised. Which is why sending all the variants might work better. There also seem to be some devices that use the ‘rolling code’ and also will respond to an override where say one button operates four devices.

I wasn’t clear from your samples whether the data was a recording of a single sequence of button presses or a composite from different times. My guess is you will need to record a lot of button presses begore you can start to understand the data. You might expect the data to 1) Have a common start character 2) Have a device address or identifier 3) Have a button address or identifier 4) Have a command byte or bytes 5) Either repeat or invert the data as a check 6) End with special character. I did this with some Lidl Silvercrest power sockets that had a ‘rolling code’. I find I can send one sequence (from the four used) reliably just once and it doesn’t seem to matter which one.

Bit rambling but hope it adds to the knowledge base

I cannot say with certainty that Livolo does not use rolling codes, but my trials suggest that they don’t.

First, since the Livolo switches offer no feedback, how does the remote and switch agree on what the next rolling code is going to be? I have two livolo remotes, and they both work 100% of the time, even if I alternate button presses between the two remotes.

Second, there are a couple of Livolo switches in my house for which I have recorded a single RF code in RM Pro, and it works reliably 100% of the time. So that same code working every single time, suggest there’s no rolling code for them.

Now Livolo switches synchronize in reverse. i.e. you set the switch into learning mode, and you press the remote button. Then the switch will respond to that remote’s keypress. One switch can actually be bound to multiple remotes. I’ve actually set a switch into learning mode, I broadcasted the RF code through RM Pro, and the switch synched with the RM Pro.

All of the RF hex data that I provided, are from the same remote button. The procedure was to Set the RM Pro in learning mode through HA, press the button on the remote next to RM Pro, see the result in the log and write it down, then repeat the process until I get a sample of 10 or 20 codes.

Some more information I managed to gather.

Livolo switches can work without a null line, because essentially they always close the circuit. It’s as if the light they control is always on, but the current they let through is really small, just enough to get the switch working. This is why, some people get weird flashing on their lights if they use low wattage led lamps, and this is why livolo offers an extra filter for these cases.

Apparently, what the livolo remote does is transmit the code 100 times in quick succession in order to ensure that the switch will pick up one of those. As soon as the switch picks it up and performs the operation, it enters a 2 second timeout mode, where it ignores any signals, so that it doesn’t switch back off on the same button press. And that makes me think that the RMPro does not send the signal enough times, or is not as fine tuned as the remote. Which is again quite puzzling, considering the switches that work 100% of the time. What’s so magical about them?!?!?

You got me worried. I have ordered 4 of livolo switches and they are on the way. I didn’t realize such problems.

Have you tried Livolo code recorded by other people? e-control search has more than a dozen of livolo remotes registered. Maybe pairing Livolo with their code might help? Not sure they would help the situation though.

Yes, I’ve tried several of those. The result is pretty much the same

My Livolo switches and their new remote VL-RMT-04 have arrived.

This is my initial test result.

It seems the switch is capable of pairing with more than one RF signals simultaneously. I tried one of Broadlink RM Pro’s online remote library uploaded by users, found with ‘livolo’ keyword. There are more than a dozen. At least one of them, which I tried works well. I also paired the switch with VL-RMT-04 remote, they seem all working together well.

There seems to be some instances that either RM Pro’s signal or VL-RMT-04 remote’s signal does not work, but maybe that’s because of the switch’s 2 seconds non-responsive period or just weak signal. (Yes, Livolo’s own new remote control sometimes does not work as it seems, but not with sufficient tests yet, so this is not definite)

My plan is to bypass learning RF signals altogether since aMUSiC’s attempts revealed rather troublesome nature of the process. I am going to just extract working remote data signal strings from the e-control app to implement to the script.

But since the switch is capable of learning any RF signals - well, not any, I meant something not from Livolo’s own remote products, their 4 button remote looks very generic - as its toggle signal, I might as well use any signal from common sources or uploaded online VL-RMT-02, 03 remote’s signal data. Please comment if I am missing something here. – OOPS. I just tested a generic RF remote for pairing, it did not work.

I sincerely hope Broadlink provides some official captured RF data for other’s products like Logitech does with Harmony remote, not just depending on users’ efforts.

BTW, I don’t think Livolo swhitches do feedback.

Which cheap wall switches you used, links?

Wouyld you recommend Livolo switches.

I am using the TC2 and I like them. But the wall plugs and the possibility of using 2way and a mix of plugs and switches is cool

FThe quality of Livolo switches is to me, a bit mixed. Some are ok and some are not receiving the remote RF signal well.

The reason I bought Livolo is that they have long line of DIY components - that’s what they call them - of US type swtiches, up to six gangs on one panel. Circuits and panel separately. I needed 4 gangs switch with form factor of US standard, square but bigger than EU standard. They are the only one I could find.

Beside that TC2 uses IC type relay, soundless. Livolo uses some kind of physical relay, it makes click sound inside when touched. Not sure which one is better.

Livolo also sells separate physical RF remote, which has not very strong RF signal it seems, at least for their newest remote model, so that would be something there.

To me TC2 was much better choice as long as the form factor matches. I just feel TC2 is more reliable for I have some trouble with RF signal from their own remote not reaching reliably with Livolo.

For me both Livolo’s RF remote work perfectly. The occasions that a switch might miss the command are extremely rare.

For the rm pro now, I’ve concluded that it’s a matter of signal strength and local radio interference. The way to go about it is to use the e-Control app and keep recording the same button until the rmpro captures a code that is well within the switch’s fault tolerence thresholds. Then dump the codes and use those in HA.

Use a 2.1A usb adapter for the RMPro (the one provided is a 1A one) and pray/wait for broadlink to release a firmware upgrade with better livolo support.

where do you live?

I live in Italy and their (TC2) so called “US” type fits perfectly in our “503 wall case” which is the standard de facto in Italy.

While their “EU” type has an 86x86 measure that is not used in Italy, and I am not sure is even used in Europe …

I have the Broadlink RMPRO in one room around 20 meters and 3 walls away from a TC2 socket and it works perfectly.

ONly issue is no device status like in zwave projects. Even the phisical press of the switch is not updating the broadlink app and viceversa

One plus to Livbolo is the ability to do 2 way and 3 way. Is there any way to make 2way and 3way also for the TC2?

I don’t think so.

I thought EU and UK uses similar standard. But I guess EU standard is relatively new I guess.

I live in South Korea. Uses US standard. We usually have 3,4,6 gangs switch on the wall. Something to do is saving electrocity by not lighting all the bulbs. It is problematic since not many countries uses those complex-gangs switches, thus not having enough related products. I have 12 light switches in my house and only one switch is 1-gang switch. Average 3-gangs, a couple of 4-gangs switches, which limits the product choices.

Livolo sent me another 3-gang switch after I sent them several videos showing the switch or the remote is not working well from 3m away. They were at first reluctant to send a replacement as they were not sure which of switch or remote was malfunctioning. But since the other 2-gang switches I own worked very well from a distance, 7m (not very big house), behind wall, from another room, etc., they sent me 3 gang switches. Anyway the replacement circuit has arrived and it works well with the remote now.