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
host: 192.168.0.230
mac: 'xx:xx:xx:xx:xx:xx'
friendly_name: 'Broadlink Sensor'
monitored_conditions:
- '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:
slsqABMGBgcGBgYLBwUMBgYLBwYHBgcGBgYHBQcFDQsHBgcGBwYHBQcFBwUGBgAAAAAAAAAAAAAAAAAA
and sometimes this length:
sgCeAA8GBQYFBgULBgUKBwQLBhsGBQUGBQYKDAU0BAUFBhIFBQYFBgQMBQULBwQLBQYFBgUGBQYFBgUFCwsGBQUGBQYFBgUGBQUFBhEGBQYFBQYLBQYKBgULBgUGBQUGBQUGBQYFCwsGBQUGBQYFBgUFBgUFBhEGBQUFBgUMBQULBgULBQYFBgUFBgUGBQYFCwsFBgUGBQYFBQYFBgUFAAXcAAAAAAAAAAAAAA==
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:
snIoABMGBgcGBgYLBwUMBgcLBwYHBQcFBwUIBQgFDAsHBgcGDAsHBQcFBwY=
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.