Reverse Engineer RF Remote Controller for IoT!

In this instructable, you will learn how to reverse engineer Radio Frequency (RF) remotes and how to implement in a very cheap WiFi enabled computer, the Node MCU. Using this technique you can IoT enable older appliances and devices!

I purchased this Harbor Breeze Kingsbury fan a while back. While it’s a nice looking fan, and quite large, I was disappointed to find that it is controlled with a remote. Main reason being, it is not possible to control the fan without a remote. And the problem with a remote is that it inevitably gets lost and/or broken. So, I decided to undertake a project to replace the remote.

I break down this project into a couple of challenges:

1. Capture what the remote control is sending to the fan
2. Analyze the signal and determine pattern
3. Figure out how to recreate the pattern
4. Transmit corresponding signal with Radio Frequency (RF) Transmitter (TX)
5. Make it easy to have this control available on my WiFi network
6. Put a nice UI on top of it so it’s very user friendly.

Step 1: Hardware

• NodeMCU Microcontroller. It costs a bit more than a simple ESP8266 but it is very easy to upload code and it also converts a normal USB voltage to 3.3v for the ESP. Alternatively you can get these direct from Chinese suppliers for very cheap, if you don’t mind waiting a couple of weeks.
• 315 Mhz transmitter
• RTL-SDR Software defined radio dongle
• Harbor Breeze Kingsbury Fan
• Some Breadboard Wire (one of these will serve as the antenna as well)

Step 2: Software

I am on OSX but most of this software (or functional equivalent) is available cross platform:

• Gqrx Software Defined Radio (SDR)
• rtl_fm - was installed with Gqrx, but needed to create a symbolic link to use it easily from command line:

sudo ln -s /Applications/Gqrx.app/Contents/MacOS/rtl_fm /usr/local/bin/rtl_fm 

• Sox Sound eXchange - swiss army knife utility for sound processing

brew install sox

• Audacity audio editor
• PlatformIO for editing, building, and uploading code

Step 3: Capture What the Remote Control Is Sending to the Fan.

First, we want to figure out what frequency the device is broadcasting on. In this case, I disabled the remote and found the transmitter and was able to identify it as 315 Mhz - the transmitter module actually had 315 printed on it.

Let’s fire up the Software Defined Radio (Gqrx) and have a look around 315 Mhz frequency, and start pressing buttons on the remote, to see what we can see.

Pressing the buttons and watching for patterns in the waterfall view will help you dial in the exact frequency that the remote is broadcasting on. Also if your squelch is set correctly, you can even hear the signal as you push the button. We have our frequency, so now let’s capture all of the buttons into a wav file so we can analyze.
Rtl_fm will capture the AM broadcast at the given frequency (315.03 Mhz) at a high sample rate, so we can look at exact timings of the signal to decode them. Sox will take the output from rtl_fm and put it into a wav format to analyze in a sound editor.

rtl_fm -M am -f 315030000 -s 2000000 - | sox -t raw -r 2000000 -e signed-integer -b 16 -c 1 -V1 - fancontrol.wav

You will need to quit entirely from Gqrx so that the USB device is released. So, run the above command, and give it a moment to identify your RTL SDR card. Once it is capturing, press each button on the remote in a specified order (write it down), giving a few seconds between button presses. When you have run through all of the buttons, press Ctrl-C to stop the program.

Step 4: Analyze the Signal and Determine Pattern.

Now find your fancontrol.wav file and open it in Audacity.

This shows Audacity with all of the button presses in a single view. Let’s zoom into the first set to get a better view.

Step 5: Zooming In...

So it appears that there are 6 bursts in a transmission. Are they 6 repeats of a single code, or are they all different? We’ll have to decode a few of them to find out. Let’s zoom in on the first message in the set.

Step 6: Zooming in Some More...

There are 16 On/Off pairs that look the same, then a few that look different. Let’s see if we can find any regular intervals or timing patterns. Zooming in again…

Step 7: Analysis of Signals & Figure Out How to Recreate the Pattern.

There are 4 distinct timings in play here, and by a lot of looking around and sampling, we can determine there’s not much more going on but patterns of Short ON, Short OFF, Long ON, and Long OFF, comprising the basic alphabet of the radio communication signal. Using Audacity, selecting an interval and subtracting end position from start position of that selection, we can determine the duration of each of the signals:

• Short ON: 400 μs (micro seconds)
• Short OFF: 500 μs
• Long ON: 850 μs
• Long OFF: 950 μs

Further analysis also revealed a few other interesting facts:

1. A single Transmission contains six Bursts, each burst has 50 Symbols in the Message.
2. The bursts are repeats, there is nothing unique between them.
3. There are six bursts of the same message in every transmission. There is a break or REST between the bursts, duration of 10,000 μs.
4. There are patterns which are common among every message. Each message contains a “preamble” of 16 pairs of “Short ON, Long OFF”. This alerts the receiver that a message (Payload) is going to arrive.
5. The Payload of the message is the next 16 symbols. There is always an ON followed by an OFF. The message symbol pairs then can be represented by SS (Short ON, Short OFF), LS (Long ON, Short OFF), SL (Short ON, Long OFF), and LL (Long On, Long OFF).
6. The “postamble” is a single Short ON, followed by the REST (if between bursts).

Now that we know the timings, we just need to figure out the payloads so that we can reproduce in our code.

To document this, I isolated the payload in each Transmission, and documented the symbols used. You will see all of this in the code shortly.

Step 8: Transmit Corresponding Signal With Radio Frequency (RF) Transmitter (TX)

I’m not going to duplicate information that’s easily available, so get PlatformIO working with your NodeMCU. For my system I had to search for and install CH304G drivers. Once they are installed you should see /dev/cu.wchusbserial1420 in your file system, when the NodeMCU is plugged in the USB port.

My platformio.ini settings are the following, so I can use Arduino code and libraries on NodeMCU:

[env:nodemcuv2]
platform = espressif
framework = arduino
board = nodemcuv2

Connect the NodeMCU to the 315 Mhz transmitter according to the diagram.

Step 9: Code and UI

The code itself is pretty simple. The device fires up and joins your wireless network. If you haven't configured it for your network yet, it spins up as its own "fancontrol" SSID and you can join it, navigate to 192.168.4.1, and configure the device to join your home WiFi network.

The device will now wait patently until someone goes to http://fancontrol.local -- if you are on windows you will want to install Bonjour for Windows. Otherwise on OSX and Linux you will be able to address the device in this way already.

The web interface is created with jQuery Mobile, and is hosted on the NodeMCU in SPIFFS image.

From the web based UI you can operate the fan, as long as the NodeMCU is in range - for me 15 feet is no issue.

You can also bookmark the site so it appears as an app on your IOS device.

Code can all be found at my Bitbucket Repository.

Step 10: Conclusion

Using these tools and techniques, it should be possible to reverse engineer many 315 Mhz and 433 Mhz remote controls.

Controlling these with cheap computers with REST and Web interfaces allows you to bring these things into Internet of Things realm, where they can be remotely controlled, monitored, and potentially exploited -- well, that’s another topic.

Thanks to Samy Kamkar for some ideas on the approach.

Comments

[AmuzB]

Is the Harbor Breeze Fan really necessary?
Can the signal(s) from a suitable television Remote Control be substituted?
Just saying . . .

[mcolacino]

This is just great. As in the other comments, very creative and clever. Question: I have a remote (Skytech 5310) used for my fireplace. It transmits on 303.8MHz according to the case and FCC filing. There are plenty of commercially available 315MHz transmitter modules for Arduino type devices but I haven't been able to find one for this frequency. Although I've read some posts that suggests that this should be "close enough" I wonder if the transmission at 315MHz will be heard by the receiver? Alternatively any thoughts on tuning the transmitter down to 303.8?

[jmattioni]

Thanks for this article. It inspired me to finally try to control a Luminoodle LED strip using an existing software program I use for IR control (IRCommand2). The LED strip uses a 432MHz RF remote. I breadboarded an RF to IR converter using a 432MHz RX module and was then able to train the remote buttons into the program as IR. An IR to RF converter built with a 432MHz TX module was then used to render the program IR output back to RF to control the LED strip. It worked. The IR signal has a 53kHz sub-carrier, which becomes part of the RF signal, but the sub-carrier doesn't seem to interfere with operation of the LED strip.

[McCahan]

For anyone who is able to get the fan commands to work fine using veggiebenz' code but cannot get the light to work, I found that my light on/light off command had a different sequence than the one in their code:

signal sig_light [] {

SHORT_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, SHORT_OFF,

LONG_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, LONG_OFF

};

[AmericanFoursquare]

Total noob here. I've been wanting to do this project for quite a while. I'm building my Amazon cart and I see you have breadboard wire and the NodeMCU but no breadboard listed in the hardware section. Does the breadboard come with the NodeMCU? Or do I need to get that separately?

[EdonP]

get is separately

[EdonP]

Where can I get all of the commands for the lights as a .wav

[jamied_uk]

I use windows and Linux not mac!

[JasonR273]

Turns out the breeze command also has discrete forward and reverse...

[CODE]signal sig_breeze [] { //forward direction

SHORT_ON, LONG_OFF,

SHORT_ON, LONG_OFF,

SHORT_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, SHORT_OFF,

LONG_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, LONG_OFF

};

signal sig_breeze_reverse [] { //reverse direction

SHORT_ON, LONG_OFF,

SHORT_ON, LONG_OFF,

SHORT_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, LONG_OFF,

SHORT_ON, LONG_OFF,

SHORT_ON, SHORT_OFF,

LONG_ON, LONG_OFF

};
[CODE]

[JasonR273]

This is a fantastic write up. Can you let me know if after the build, it would be possible to send simple web commands to control the fan instead of using the software interface? I would like to use IFTTT or Homeseer to control the fan. Thanks!

[SteveL206]

I'm working on running through this for my own fan. One method that helps shorten up the process a bit - you can search the FCC database for the FCC ID for the remote. It won't get you detail on the protocol but it will give you the frequency of the transmitter. Easier than taking the remote apart. :)

[Marbots]

Very Nice. Thanks for sharing g.
Thanks for introducing me to Gqrx.
M.

[gm280]

Okay, seem you went through a long process to "break the code" to be able to control your new ceiling fan in the event you loose your remote. And I certainly applaud your efforts and ideas. Very well investigated and solved the code issue I'd say. But if you wanted to control the fan via typical wall switches, you could have bypassed the receiver circuitry and wired direct for the fan and a light, if that was an option. Bravo either way.