Arduino AC Remote

My house does not have central air but instead has a couple of window AC units. The main cooling for the central part of the house is controlled with a single window AC unit made by Friedrich. It has an IR remote and is programmable, but it's still fairly limited. There's no way to turn it on remotely should I come home early, or vice versa and waste power cooling the house when I come home later than usual. This project is an Arduino RF based IR extender which also allows PC control of the AC unit. I can ssh into a box on my home network and issue commands to control the AC from there.

Prototype

Initial build with an Arduino, SparkFun ProtoShield, Radio Shack IR receiver, IR emitter, and a cheap KLP style RF receiver (434MHz). The IR receiver was used to catch and decode signals from the remote using the IRemote library for Arduino. I was a little afraid of this process but the library made this the easiest part of the project. It automatically decodes several IR protocols and has a great set of example programs which did all the heavy lifting. Now all I have to do is go back and look at the library closer because I'd like to know how it works. But I'll settle for having a working project first ;-). I also use a library called RFDriver for the RF bits. Place the IR emitter somewhere in front of the AC unit and tape it down.

File:Blah.jpg text

File:Blah.jpg text

IR Commands

The Friedrich IR remote uses RC-5 IR protocol and sends these commands out:

• 40 - power (toggle)
• 41 - cooler
• 42 - warmer
• 43 - set hr/clock (press twice to initialize-then increment)
• 44 - AC start hour increment (press twice to initialize-then increment)
• 45 - AC stop hour increment "
• 46 - timer on/off (toggle)
• 47 - cool button - unknown function?
• 48 - MoneySaver (toggle)
• 49 - fan only (toggle?)
• 4A - fan speed

You should note that some buttons when pressed put the 2 digit display on the AC unit into the mode for that button first just to display the current value (like the clock) and you have to press the button a second time to increment the value (like the AC start or stop times). This is important should you attempt to issue commands like setting the AC start or stop hour remotely. However I don't intend to use these functions as there is no feedback to tell what the initial setting is and could easily get out of sync from your remote end. I will most likely be using cron from the system the TX arduino is connected to and manually running the power on/off command.

If you are decoding the protocol for your own Friedrich AC remote, note that each time a remote button is pressed it alternates between "40" and "840" at each press of the same button. My understanding of RC-5 IR protocol is that it adds a toggle each time a button is pressed so the receiving device can distinguish between holding a button down and separate button presses. The IRemote library seems to handle this properly and the Record sketch seems to automatically add this toggle effect in for you when transmitting.

Code

I have a sketch written which compiles but I've not had time to actually run it, I'm sure it needs some debugging time yet.

• My code (To Be Completed): File:FriedrichACremote.pde

Libraries I used:

• IRemote http://www.arcfn.com/2009/08/multi-protocol-infrared-remote-library.html
• RFDriver http://www.glacialwanderer.com/hobbyrobotics

Usage Notes

It is important to note that commands like power are a toggle and there is no feedback in this system. So if you accidentally issue a command twice you could end up with nothing happening, or if you don't know the initial state you may be doing the opposite of what you want. One simple way to get some feedback is a remote temp sensor. That is part of another project I intend to build out into the house, better environmental monitoring. However for now, just being able to turn the AC on an hour before I get home (after having been gone for a few days) is all I need.

RF Notes

One thing I've noticed with these KLP boards is that it's a good idea to issue RF commands multiple times to get a better chance of the transmission being picked up. Even in a small environment like a single room RF commands can be eaten by static and noise from the microcontroller. I need to add a simple retry system into the RF stack with the ability to guarantee that multiple commands are not issue by the receiver. TBD.

I've been using the RFDriver library for a while and am very comfortable using it, however at some point I intend to work with VirtualWire and switch to that for my low-baud rate data needs. Currently RFDriver has limitations such as only supporting numerics (which could probably be fixed with some small tweaking) but I'm lazy. Also, you will note that I run the KLP RF module at 1200baud rather than the 2400 or 4800 which some models support. Running them at lower baud rates increases your range and for single digit transmissions like this is not at all noticeable. If I need more range I'd be tempted to try 300 baud.