I’m trying to send 433MHz RF codes through my Broadlink RM4 Pro.
I already know the proper codes. I need to send 0x49C744 (24 bits). But all I am getting is either errors or what appears to be a success, except nothing works. I have verified the code works through other means.
I’ve read about using b64:. But that isn’t working. I saw on this page, that the code must include some flag about whether it is IR or RF, but nothing explains how to include that when doing the base64 encoding!?!
How do I base64 encode a known RF code including the RF flag?
You have a hex value and not a base64 value.
You either need to convert it, if that is possible, or find a base64 string for the signal you want to send.
Logs too. Return codes get us really excited. They give us a good warm feeling. You know, the kind as children, we felt, pausing in the playground, filling our shoes, looking around, hoping nobody would notice the slowly spreading stain…
We may be wunderkind, but not mind readers. We often tire of ‘twenty questions’ games.
Correct. And I have tried several different way of encoding it with base64. So far, they don’t work. And I suspect it has to do with the flag that tells HA whether to use RF or IR when sending the code. This: Broadlink - Home Assistant
“You don’t need to specify command_type to send them because this information is stored in the first byte of the code.”
Which tells me there is a flag baked into the b64 encoded value. So, I’m looking for info on how to do that.
Nor am I a mind reader. Happy to provide any and all info you might request.
I’ve already figured out that I am not providing the right command data. I can see that when I read the documentation. But the documentation doesn’t explain what needs to be done. Logs aren’t going to help this issue.
This is one example of what I’ve done in the Developer Tools screen. I’ve tried about 40 variations. And then I read the docs and found the sentence that made me come here for help.
I need to find out what is the right information and syntax that must be used when base64 encoding the RF code. This: Broadlink - Home Assistant says “You don’t need to specify command_type to send them because this information is stored in the first byte of the code.” (reading it in the context of the relevant section of the doc makes a lot more sense) But the doc does not explain how to store the RF flag in the first byte of the code, so that it can be base64 encoded.
As I stated in my first post, which I thought was a pretty straightforward question:
How do I base64 encode a known RF code including the RF flag?
Obviously you don’t trust that it does, or if it does, the outcome is different from what you desire. Such are the challenges of coding. Bug, debug, rebug. Curse, recurse, curse again, all helped with copious amounts of vodka and coffee, assisted (or completely trainwrecked usually) by ChatGPT and StackOverFlow and Reddit for the hair free desperates.
I find the act of sitting down with a printed copy of my code and gently explaining it to my grandmother is the best form of therapy. Copious “Yes dear” from her, plus the blinding shock of stumbling across the obvious errors as you cannot verbalise a subroutine to say what is does is something that cannot be replicated by artificial intelligence.
Ah, an inadequate documentation issue? Would asking the developer in GitGub help, for all the other knuckles-to-the-bone coders, rather than here?
I do not think you can just make a conversion like that.
The hex value you have might be for a certain RF protocol and that then needs to be translated in to a RF signal based on that protocol, which can then be converted to a base64 for BM4.
I’ve already worked through all that. I’ve captured the data with a logic analyzer, a SDR with rtl_433 and the Tasmota RF capabilities. All three sources agree on what the data is that’s being transmitted. Using that hardware and running through Tasmota, everything works fine. It’s just getting the RM4 Pro via Home Assistant to do it right that escapes me so far.
Are you going to provide even the slightest bit of help or just berate me for not standing up to your super secret expectations? In three posts on this thread, you have offered not one bit of positivity or assistance. Please just stop posting if you aren’t going to offer any assistance.
You’ve been very close chested with your code. Quite demanding, amusingly, actually. You are going to have to risk it and grudgingly release some more info if you want comments or useful help.
Go back and re-read - we don’t even know what language you are using!
I’m taking a break to play with the puppies. Maybe a break from the screen will help you see the forest from the trees.
I don’t even know what code you are talking about!! I’m not writing code. I don’t know how to do that! (EDIT: this is false, written out of exasperation. I write Python code sometimes. But I’m not very good at it, and reading others’ code is an exercise in futility) I’ve posted everything I know to provide. If you need something more, PLEASE ASK AND STOP ASSUMING I HAVE ANY IDEA WHAT YOU ARE THINKING.
Why don’t you make some more assumptions about me? Geezz.
Here is an expanded version of my original question:
How do take a known RF code and mix that with the RF flag that is “stored in the first byte of the code” (per the documentation) and then base64-encode all that together in a way that HA will be able to use it?
I’m typing this slowly so I can understand what you are trying to achieve.
Bear with me as I may not have understood everything you are trying to document. Please correct any false assumptions I have made, as this is an important part of problem isolation and solution. I’ve numbered each portion so you can refer back to the specific part I have misunderstood. Yes, this is mostly level 1 help desk questions and answers, but each and every item must be crossed off to be able to pinpoint the problem. Taking shortcuts or making assumptions can result in important steps being omitted, or done wrong, with subsequent issues.
1: You are trying to get some device to talk to the HomeAssistant Broadlink add-on via a Broadcom RM4 Pro device by emulating the codes it sends to HomeAssistant when you press the button on the remote control. The way it works is the Broadcom RM4 Pro pretends it is a remote control and sends identical signals to the receiving device which has no idea it is being tricked by a smart device. Behind the scenes, the Broadcom RM4 Pro can hook into other smart things, including HomeAssistant. This is what make it so powerful and popular (when it works well).
2: The button being pressed/emulated is from a GE device. Unspecified device. Buttons unknown. Would have been nice to know for interest sake. More relevant, somebody may have already decoded them, to save you this entire learning process of discovering the correct codes. Ecclesiastes 1:9 refers.
3: It uses 433Mhz carrier transmitted from the original remote control, with ASK modulation.
4: Back to basics at the current documentation (for the integration) If you have a dual display computer system, call this up on the second display and follow along. Broadlink - Home Assistant
5: We have to assume it works for others, otherwise there would be lots of bug reports we would have discovered from our problem research before posting. Problems such as RF Learning Issues on Broadlink RM4 Pro · Issue #149100 · home-assistant/core · GitHub are not relevant in your situation, are they? If they are, you have tried the workarounds suggested.
The manufacturer’s app is required in order to connect new devices to the network, successfully.
6: You installed the GE device via the app, and tested it and it connects and works using the BM4 Pro, and just the remote without the BM4 Pro powered on. Each button pressed on the remote results in the appropriate expected reaction.
7: Now you also want to intercept your BM4 Pro codes and get them into HomeAssistant to be able to do ‘smart things’ with each button press.
8: Yes, your BM4 Pro Universal Remotes is showing on the list of devices supported by the integration in the HomeAssistant documentation.
9: You added that GE remote control to your Broadlink network successfully, and it works well.
10: You have used three methods to capture the data.
11: If needed, you can replay the recording at will and it will be identical from that transmitted from the original GE remote control.
12: Good, so you know what the actual bits being transmitted are, including frequency (433Mhz), protocol (ASK), timing, and encoding. You have verified this ‘three ways’.
13: You have added Broadlink integration to your Home Assistant successfully?
14: What discovered entities are being displayed? Any?
I quote from the documentation:
Entities and subdomains
There is no more need to set up platforms, except for custom IR/RF switches. Once the device is configured, all entities will be created automatically.
The entities have the same name as the device by default. To change the name, icon or entity id, select the entity on the frontend and select the settings icon in the upper right. You can also disable the entity there if you don’t think it is useful. Don’t forget to select Update to save your changes when you’re done.
15: The remote entity (specifically) is successfully showing in HomeAssistant.
Now comes the interesting part.
Remote
The remote entities allow you to learn and send codes with universal remotes. They are created automatically when you configure devices with IR/RF capabilities.
16: So far, everything has happened automagically. No specific base64 code mentioned anywhere yet.
17: We are learning 433Mhz, not infrared, so we focus on RF Codes in the documentation, not IR codes.
18: We have to teach HomeAssistant what codes to remember and recognize.
Learning commands
Use remote.learn_command to learn IR and RF codes. These codes are grouped by device and stored as commands in the storage folder. They can be sent with the remote.send_command action later.
Data attribute
Optional
Description
entity_id
no
ID of the remote.
device
no
Name of the device to be controlled.
command
no
Names of the commands to be learned.
command_type
yes
Command type. ir (default) or rf.
alternative
yes
Toggle command indicator.
19: Storage Folder link: The codes are stored at:
Learned codes storage location
The learned codes are stored in /config/.storage/ in a JSON file called broadlink_remote_MACADDRESS_codes. You can open this file with a text editor and copy the codes to set up custom IR/RF switches or to send them as base64 codes, but beware: the files in the .storage folder should never be edited manually.
20: For your GE remote button, what base64 code is showing there?
21: Does it agree with what was extracted from the air (in three different ways)?
22: Great, we have a working system where the Broadcom RM4 Pro device is passing the codes to HomeAssistant.
23: Now we get to yaml code. The code in HomeAssistant that enables you to do awesome things.
Learning RF codes
Learning RF codes takes place in two steps. First call remote.learn_command with the command_type: rf option:
# Example configuration.yaml entry
script:
learn_car_unlock:
sequence:
- action: remote.learn_command
target:
entity_id: remote.garage
data:
device: car
command: unlock
command_type: rf
When the LED blinks for the first time, press and hold the button to sweep the frequency. Then wait for the LED to blink again and press the button a second time to capture the code.
The codes will be stored in the same way as the IR codes. You don’t need to specify command_type to send them because this information is stored in the first byte of the code.
Tip: Click Notifications in the sidebar after using the action and follow the instructions to make sure you are pressing the button at the right time.
Your code in the yaml will depend on the entities that were discovered in step 15 and 18.
24: What happened? Where did things stray from the steps documented here?
Don’t worry, we’ll focus on the base64 codes soon. If there were problems, there should be corresponding error log listings and return codes we can examine to see what went wrong.
Hint (yes, the documentation outlines many ways -some outdated- of getting those base64 values):
Sending a base64 code
Sometimes you may want to send a base64 code obtained elsewhere. Use the b64: prefix for this:
Those links explain that the data starts with 0xB2 for 433MHz or 0xD7 for 315MHz, then a byte for the number of repeats, then data length, and then the pulse data itself. And at the moment, I am assuming I need to line all that up in a single hex value and base64 encode it. Or maybe I need dump the hex as binary into a file and base64 encode that instead.
I’m going to experiment with this new information.
I will follow up on your 24 questions in a day or two, maybe, after I have worked a little on what I found.
Once you have discovered the actual values for each code, other than for interest, is there any reason to understand what the bit patterns mean? You are just retransmitting a bunch of [pre-defined] bits to prompt the receiving device to think a button on the remote control is being pressed.
Yes, so that I can programmatically construct my own codes. Just using the learn function gives zero insight to how the codes are constructed.
My HVAC system uses IR remotes, which send a massive number of values all at once (every value in fact). If I can understand what parts of the learned commands are for what parameters (mode, temp, swing, fan speed), I don’t have to learn 10,000 combinations of IR codes just to cover 74 degrees with high fan AND 74 degrees with low fan AND 74degrees with medium fan AND… ad nauseam… I would just say “give me the values for 74 deg, low fan, cooling, no swing, etc”, then smash all that together into an encoded string and ship it off to the Broadlink to set the temperature.
But I’m learning first on a much simpler device: a GE wireless outlet that has no smarts at all. Just a 433MHz transmitter and the outlet with its receiver, which I have cracked open and attached things to investigate how it works.
