| AardRemote: The open source, off the shelf hardware, arduino based universal remote control project. | |
 |
|
Overview
Everyone seems to walk around with a smartphone in their pocket all the time, and smartphones can all talk bluetooth, so why not make a little box that can talk bluetooth to all these phones and send remote commands to all the electronics in the room? And there is no reason to restrict it to phones. Tablets or even desktop computers could also talk to the box. You'd have a different box in each room and could connect to different boxes as you roam your home.
The user interface and complicated control software could live on the phones and the low level IR send and receive could live in the AardRemote box.
That is the basic idea. Once you start with that, things can easily get more complicated. A common gadget to connect to an arduino is a radio module, so the sort of high end remotes that can communicate across a house are well within the range of the project once it gets going. The possibilities are really endless.
Arduino microcode
The simplest part of this project (and therefore the one I am tackling first) is the microcode for the arduino (or sketch in arduino speak).
The current progress on it can be monitored at Remote Software.
Protocol specification
For the AardRemote, I'll want to define a formal communications protocol with the primary goal of reducing the load on the arduino. The phones that talk to it have lots more processing power than the poor little atmel 8 bit microprocessor has.
Progress on the software is also progress on the protocol since the software implements the protocol. The current version of the protocol is fairly well defined by files in the source tarball. It uses a binary format communication with all messages a multiple of 16 bit words (which is a convenient size to hold raw IR timing data).
Linux interface software
I'm doing all my development on my linux desktop zooty, so linux is probably going to get my attention first, but since I tend to do a lot of development using the Qt toolkit, the odds are good that a lot of the software will port to windows as well (not that I'm likely to be doing the port).
The current software contains both an elementary linux test program that simply exercises some of the protocol messages as well as a fancier (but not very fancy) GUI app written in Qt which I salvaged from an old LIRC project I was writing once upon a time.
The GUI app is mostly concerned with learning remote codes, but can also send the codes for testing.
Android interface software
Now we are in uncharted territory. I start reading up on android programming every once in a while, and my head explodes, so it may take a while.
I've decided to approach learning Android as though I'm writing MyAndroidBook, the Android book I keep looking for which utterly ignores that horrible IDE system which is not to be named.
In Chapter 4 I even managed to get a crude demo program working that proves I can learn a remote code and send it back out from my android phone.
I certainly have a goal of having some sort of plugins in a generalized remote framework so not only will the phone be able to talk bluetooth to the aardremote, it will be able to talk over the network to a linux box to send LIRC command, or to a TiVo box via the network, or integrate with Z-Wave home automation devices, or even with other events on the phone itself (automatically mute the TV when you get a phone call for instance), etc.
Another interesting plugin would be a query to find out if a device is on already or not so you can build in appropriate delays for a cold start. My experiments indicate that both my TV and my Blu-Ray player (which have ethernet ports) do not respond to ping when they are turned off, but do respond to ping when on :-).
iOS interface software
Even more uncharted than android are iPhone and iPad devices. I am highly unlikely to ever have any incentive to develop for these platforms. Worse yet, apparently iHardware devices don't support the simpler RFCOMM bluetooth profile (or maybe they support it, but you have to pay big bucks to license your app to use it, which amounts to the same thing), so that would put an even bigger crimp in iOS development.