I have central air-conditioning in my apartment, and it’s controlled by a remote, employing IR signals to send commands to the A/C control unit.

As any decent geek would, I’d like to be able to control my A/C using other means (e.g., a smartphone).

In a previous post, I went into detail about reverse engineering the remote. Now it’s time to proceed to actually using these powers to replace the original A/C remote with my own Arduino-controlled thingie!

The gist: using an Arduino Uno board with a IR-LED circuit (see below), along with Ken Shirriff’s Arduino IRremote library (slightly modified), I was able to transmit the A/C commands that were analyzed in the previous post in lieu of the original remote.

Keep reading for a full drill down, or jump straight into my home-control-arduino GitHub project for the actual code and documentation.

Building the IR Transmitter Circuit

Buy list:

• SparkFun Inventor’s Kit for Arduino (available in Israel via 4Project.co.il, or via friends who sell their own kits 🙂 (h/t YoniC) ) (also see a similar Arduino starter kit on Amazon or on eBay), that comes with Arduino UNO R3 (Amazon, eBay), breadboard and a convenient holder for both (and lots of other useful stuff to get you going).
• A simple IR LED (like this one, also from 4Project.co.il).

Assemble the components according to the schematic shown above, which will look something like this:

(side notes: I used three 330ohm resistors in parallel instead of a single 100ohm, because I only had 330ohm & 10kohm resistors; I also used two IR LEDs because I had two 🙂 )

Connect the Arduino to the PC via USB, and compile and upload my IRACsender sketch to the board:

Open the Arduino Serial Monitor, that will greet you with a welcome message:

Type a state-setting command and send it to the board (see the project README for details about the commands) – it will reply with feedback about the state changes:

Type the IR transmission initiation command (S) to send the a preconfigured IR signal:

And there you have it – a working Arduino-powered IR transmitter that sends A/C commands that were previously analyzed and preconfigured in the IRACsender project.

Preconfiguring IR A/C Commands

As you can see in the code (relevant snippet below), each supported A/C command is represented by a large array – with the first element specifying the number of elements in the rest of the array, and the following elements specifying the duration (in microseconds) of consecutive IR marks and spaces, as described in the documentation of the Arduino IRremote library.

PROGMEM prog_uint16_t uSendBuff_Toggle_Cool_Auto_25[] = {181, 3000, 3700, 2050, 900, 1050, 1850, 1050, 850, 1100, 850, 2050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 1850, 1950, 1850, 2050, 850, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 850, 1050, 900, 1050, 850, 1050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 1750, 2050, 800, 3000, 3750, 2050, 900, 1050, 1800, 1050, 850, 1100, 800, 2050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 1800, 2000, 1850, 2050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 800, 1050, 900, 1050, 900, 1050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 800, 1050, 900, 1050, 900, 1050, 850, 1050, 1750, 2050, 850, 3000, 3750, 2050, 900, 1050, 1850, 1050, 850, 1100, 800, 2050, 900, 1050, 800, 1050, 900, 1050, 900, 1050, 1800, 2000, 1800, 2050, 900, 1050, 800, 1050, 900, 1050, 900, 1050, 900, 1050, 850, 1050, 900, 1050, 850, 1050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 850, 1050, 900, 1050, 900, 1050, 900, 1050, 1750, 2050, 850, 3950};
PROGMEM prog_uint16_t uSendBuff_Leave_Cool_Auto_25[] = {187, 2950, 2850, 1000, 950, 1050, 900, 1050, 1850, 1000, 850, 1100, 850, 2000, 950, 1050, 850, 1000, 950, 1000, 950, 1050, 1850, 1950, 1850, 2000, 950, 1000, 850, 1000, 950, 1000, 950, 1050, 900, 1050, 850, 1000, 950, 1050, 900, 1000, 950, 1000, 850, 1050, 900, 1000, 950, 1000, 950, 1050, 850, 1000, 950, 1050, 900, 1050, 950, 1000, 1800, 2000, 900, 3000, 2850, 1000, 950, 1050, 900, 1000, 1900, 1050, 850, 1050, 900, 2000, 950, 1050, 850, 1000, 950, 1050, 900, 1000, 1900, 2000, 1850, 2000, 950, 1050, 850, 1000, 950, 1050, 950, 1050, 900, 1000, 900, 1050, 900, 1000, 950, 1000, 950, 1050, 850, 1000, 950, 1000, 950, 1050, 900, 1000, 900, 1050, 950, 1050, 900, 1000, 950, 1000, 1800, 2000, 900, 3000, 2850, 1050, 900, 1000, 950, 1000, 1850, 1050, 900, 1050, 900, 2050, 900, 1000, 900, 1050, 900, 1050, 950, 1000, 1900, 1950, 1900, 2050, 900, 1050, 900, 1000, 950, 1050, 900, 1000, 950, 1000, 850, 1050, 950, 1000, 950, 1000, 950, 1050, 850, 1000, 950, 1050, 900, 1050, 950, 1000, 900, 1050, 900, 1000, 950, 1000, 950, 1050, 1800, 2000, 850, 3900};
PROGMEM prog_uint16_t uSendBuff_Toggle_Cool_Auto_24[] = {181, 3000, 3750, 2000, 900, 1050, 1850, 1000, 850, 1100, 850, 2000, 900, 1000, 850, 1000, 900, 1000, 900, 1050, 1850, 1950, 900, 1050, 1850, 2000, 850, 1050, 900, 1000, 900, 1000, 900, 1050, 850, 1000, 900, 1050, 900, 1000, 950, 1000, 850, 1050, 900, 1000, 900, 1000, 900, 1050, 850, 1000, 900, 1000, 900, 1050, 900, 1000, 1800, 2000, 850, 3000, 3750, 2050, 900, 1000, 1850, 1000, 850, 1100, 850, 2000, 900, 1050, 850, 1000, 900, 1000, 900, 1050, 1850, 1950, 900, 1000, 1850, 2000, 850, 1000, 900, 1000, 900, 1050, 900, 1000, 850, 1000, 900, 1000, 950, 1000, 900, 1000, 850, 1000, 900, 1000, 900, 1000, 900, 1000, 850, 1000, 900, 1050, 900, 1000, 950, 1000, 1800, 2000, 850, 2950, 3750, 2000, 950, 1000, 1850, 1000, 900, 1050, 850, 2000, 900, 1000, 850, 1000, 950, 1000, 950, 1000, 1850, 1950, 950, 1000, 1850, 2000, 900, 1000, 950, 1000, 900, 1000, 950, 1000, 850, 1000, 950, 1000, 950, 1000, 900, 1050, 850, 1000, 900, 1000, 900, 1000, 950, 1000, 850, 1050, 900, 1000, 900, 1000, 900, 1000, 1800, 2000, 850, 3900};

prog_uint16_t * getAcSendBuff() {

if ( (Toggle == pwr) && (Cool == mode) &&(Auto == fan) && (25 == temp) ) { return uSendBuff_Toggle_Cool_Auto_25; }
if ( (Leave == pwr) && (Cool == mode) &&(Auto == fan) && (25 == temp) ) { return uSendBuff_Leave_Cool_Auto_25; }
if ( (Toggle == pwr) && (Cool == mode) &&(Auto == fan) && (24 == temp) ) { return uSendBuff_Toggle_Cool_Auto_24; }
return 0;
}

Following the hard-coded arrays, you can see a “selector-function”, that given a valid power-mode-fan-temp state returns a pointer to the array that represents that state.

This code could become hard to maintain, when supporting many A/C commands, which is the reason I decided to automate the generation of this code using my IRAnalysis Python script, that was mentioned in the previous post.

I will not reiterate the description of the script, so please refer to the previous post for further information on building and passing a data-set to the script. I will just add here the part that was not mentioned in the previous post – the script also has a code command (in addition to the graph command) that generates the code above, whose output can be pasted directly into the IRACsender project.

IRACsender Design Consideration

The program is a simple state-machine, with the state and parameters stored in global variables.

The basic (and initial) state is Ready. In that state, the program waits for a single character from the serial port that determines the transition to the next state:

• One of the characters P, M, F and T transits to a parameter-reading state (power toggle, A/C mode, fan speed, and temperature, respectively).
• The character S initiates an attempt to transmit an IR signal as defined by the state parameters that were set.
• In the P/M/F parameter reading states, the program expects one ASCII digit representing the value for the parameter, as defined in the respective enums.
• In the T parameter reading state, the program expects (exactly) two ASCII digits representing the desired temperature (this is actually implemented as two distinct states – read first digit, and read second digit).

In every state where some input is expected, if the character read is not valid in that state (e.g., not an ASCII digit in the allowed range), the state machine transits to Error. In Error state, the program will clear out the incoming buffer, and set back to Ready (but the global parameters will remain as they were before encountering the error).

Also, after transmitting an IR signal, the global parameters are NOT reset – they remain as they were, so further commands can be sent just by changing a selected parameter, and not setting all of them.

If the IR transmission command is initiated before all state parameters are set, the transmission fails and the state is set to Error.

Also – even if the parameters are set, but the IR signal representing this state is not defined by the hard-coded arrays, the transmission will fail and the state will be set to Error.

Finally, the program does its best to print back helpful messages, in happy flows as well as when errors occur.

Arduino Memory Caveats

During initial testing phases I implemented just one A/C command, with a single hard-coded array, declared simply with int sendBuff[] = { ... };, and it worked just fine.

When I advanced to three A/C commands, as shown in the examples above, suddenly the Arduino stopped behaving properly.

The symptoms were strange – compile and upload would complete successfully, but the program would just do nothing – not even the “Welcome” print in the setUp() function!

Common wisdom in such cases says: go back to the last working state, and try adding the changes one by one to see which one breaks.

This debugging technique didn’t fail here – I quickly found that with two hard-coded arrays everything works peachy, but adding the third one breaks it all.

Obviously this was not a problem with the specific array, because the program broke before even starting (but I still verified by checking that every combination of two commands works).

My experience in embedded development started shouting in my head – it must be memory-related!

And indeed, a short search reminded me that the Arduino UNO comes with just 2KB of SRAM memory, and by default all data segments (stack, heap, BSS) goes to SRAM, which fills up pretty quickly if I start using lots of big arrays… (and the symptoms match)

The same search also mentioned that that model is equipped with 32KB of Flash, and I can store my data in Flash instead of SRAM by using the PROGMEM keyword, and utilizing special functions to access that memory.

Conclusion

That sums up the drill down into my Arduino-powered A/C control project, building on the previous post about Arduino-powered IR analysis.

The project, along with detailed documentation, is available on GitHub for you to clone, fork, hack, modify and improve (and share back!).

Go ahead and read my other A/C-control project posts:

• Using an Arduino to Reverse Engineer My A/C Remote
• Controlling My A/C With an Arduino
• Using “Beeps” for Feedback from A/C commands
• A/C Control Project: Bringing it all Together