Go Down

Topic: Thermostat / Home Security / Automation project (Read 4362 times) previous topic - next topic


Dec 27, 2012, 06:16 am Last Edit: Dec 27, 2012, 07:00 am by djjoshuad Reason: 1

I'm new to the world of arduino, but for the past few days I've been doing some research and I think arduino is the answer for what i'm trying to accomplish.  I'm undertaking this project first for its ultimate functionality, and second as a learning exercise.  I don't intend to ask for people do do any of the design or coding for me, but I'm also not above asking for some advice to get started down the right path :).  Here's what I want to do:

_High Level_
centralized control of the whole system, most likely in a web interface
security camera feeds (android phones)
security sensor data (existing security system in my home)
thermostat control
potentially other home automation controls

_Android Phones_
I have four retired phones at my disposal.  Two will be used purely as security cameras (HTC Hero US), and two others (Samsung Galaxy S Epic) as thermostat controls, security keypads, *and* security cameras.  The intention is to mask their use as cameras by displaying the thermostat controls and security keypads while also employing a feed from the front-facing cameras.

_Home Security_
My home was built in 1999 and has an existing, currently unused, security system that was installed when the house was built.  I would like to replace the existing control panel with an arduino device, interfacing with the siren and sensors (not the keypad).  This arduino device will need an ethernet shield, I think.  I'm also considering picking up another android phone to handle interfacing with the central server.

I have two thermostats controlling two separate HVAC units.  I'd like to replace both thermostats with arduino devices.  These devices should be able to act as thermostats without the android devices (should they die or otherwise be unavailable), operating on configuration data received from the android device.  There will be multiple methods of telling the android device to update the thermostat config, but ultimately only one way to talk to the thermostat.  This keeps the arduino device simple... and honestly that's mostly because I'm a lot better with java than with C :).  At some point I think it would be interesting to implement multiple temp sensors throughout the house and using a weighted average to determine HVAC use... but I digress.  It would be nice if the arduino device also powered the android phone via USB, which will already be connected as an interface between the two.

_Centralized Server Control_
This server will act as a main repository for all sensor data (temperature, security, camera) and a normalized interface for everything else.  Not really relevant to this forum, but worth mentioning for the sake of completeness.

I know that there are open source and free solutions for much if not all of what I want to do.  That's a testament to the open source community, and I will surely learn from the experiences of those devs in this undertaking.  That said, I want to code as much of it myself as I possibly can.  I am doing this to learn, after all :)

My questions for you kind people surround the arduino parts (of course!): which arduino platform seems most suitable for each purpose?  I had originally wanted to use the IOIO board for android, but I think arduino is not only a better solution but the lessons learned could be applied to more future projects.  With that in mind, I've been leaning towards the amarino project and a pair of arduino unos for the thermostats.  A Mega seems appropriate for the security panel.  I defer to the experience of this group, however.  What do you think?

Thanks in advance!


The more I look around on the 'net, the more it seems like I need to just buy arduino mega ADK units.  I was hoping to use USB host shields, but I'm afraid that will limit my ability to use other shields with the device.  The unfortunate part of this realization is that the overall cost of the project goes up... but I guess not by too much.  Another option is to make the thermostats completely self-contained and interface with them over ethernet, bluetooth, or wifi.  I guess that just loses some of the cool factor for me :).  I'm going to do this one way or the other.  Still hoping for some sage advice from you, the more experienced.


This is the kind of project I am looking to do.  My wife wanted to get a Nest Thermostat.  They are cool, and I love my wife for giving me the green light to get one, but then I got thinking: "I could make one myself, and add more functionality to it!"  We use X-10 home automation throughout the house, and I'd love to include those in with the project.

I like your idea of using decommissioned Android phones for touch displays, doubling as a security camera.  Plus, you can offload a lot of processing and storage onto the phone(s) so the Arduino can be more dedicated to reading sensors and controlling relays.  I have a Droid X I'm not using anymore, and though it doesn't have a front-facing camera, I plan on using that for the touch display, plus hosting the website from it to be able to access controls from the Web.

I am also fairly new to the Arduino world, so I'm not sure which Arduino controller would be the best in this situation.  I will do some more research and post my findings if I come up with anything conclusive.  Or I'll start dabbling with the hardware itself and let you know.


I just noticed that someone actually replied to this thread :)

As an update, I successfully replaced my alarm panel with an arduino.  It has a Seeed studios ethernet shield and a custom shield I built to break pins out to a floppy drive connector.  I built another board that has all the screw terminals on it for the alarm sensors and another floppy drive connector.  Of course I then connected the two using a floppy cable.

I also got the basics up and running for the central server.  It runs on a Raspberry Pi and listens for TCP connections from my alarm panel.  It's multithreaded and extensible, creating a new thread for each device that connects to it.  Right now that's just the alarm panel but ultimately the thermostats and other things will connect in the same way.  It's moving along, but I've changed my mind a dozen times on how I want to do the thermostats.  In the meantime I built a cat-entertaining laser that will also get tied into this device... so the wife can play with our cat while we're away from home :)


That's awesome! I love the idea of the Cat entertainer laser.  It just goes to show that when you're working with Arduino, the sky is the limit. LOL.

I've been stuck just mapping out on paper how the system will work, and designing the Android interface.  The question I face is: should I write a full blown Android app that will talk to the controller (Arduino or RasPi), or should I host the GUI on a webserver (RasPi or PC)?  I have some prototypes written up in HTML with jQuery of how I might want the UI to work, but still undecided on the implementation.  What are your thoughts on that?


I've been struggling with the same thing, and putting off the UI decision until I get other stuff done  :smiley-mr-green:

ultimately I think an app will be best for realtime control, but I will almost certainly have some sort of status page in PHP to go with it.  If I want to really do it right, I can write an API that the app and site both consume.  I really like the work that's going on over at androidthermostat.com and may try to fork his code for the thermostat interface.  If I do that it would make sense to extend it to include the other devices.

FWIW, a lot of this work could be condensed if I was using one of the standardized home automation protocols.  Those are very useful and there is one (the name escapes me) that seems pretty mature and well-written.  I'm not going that route b/c I want to force myself to sharpen some skills I either haven't used in a while or am just starting to develop.  forking and extending the code I mentioned above goes against that grain... we'll see where I end up :)

For now it's just about getting the basics up and running.  OH! I also added an on-demand garden watering system to the list for my wife.  I haven't installed it yet (weather related) but I have the design done and have acquired nearly all the pieces.  This isn't you average indoor drip-to-one-plant setup, either.  I'm feeding 6 zones with PVC, controlling flow with sprinkler valves, and measuring temp, light, and soil moisture levels.  It's going to be cool, if I do say so myself :D


Wow! How is it that I've never heard of that website.  Plus, I've never heard of the IOIO for Android; it's a pretty cool device for us DIY types.  It seems like could remove the need for the Arduino.  I may consider trying out one to see what I can do with it.

However, I really like your idea of a two way API.  If it is standard enough, then you could swap out devices as newer things become available, and change the interfaces often, without starting the whole project over.

As far as Home Automation goes, I played around with controlling my X-10 devices with Arduino through the PL513 (http://www.x10.com/automation/x10_pl513.htm), using an Arduino Library built for it (http://arduino.cc/en/Tutorial/x10).  It works quite well, so I'm excited to get that part of the system going soon. 

Have you found a way to work on the thermostat without breaking current functionality of the existing system?  I tend to take a long time with projects, and I'd hate to have to disable the thermostat for longer than a couple hours.


well a thermostat is actually a really simple device, so it's pretty easy to test on a workbench without needing to connect to your HVAC.  Either simulate temp changes with a pot or use a heat lamp and fan, and you're off and running.  For mine I have a 24VAC power supply (which is what the HVAC supplies) on my workbench and some lights connected to the relays.  In theory it should translate pretty well to actual installation on the wall, when the time comes.  To more directly answer your question, I have not tried to run it in tandem with the existing thermostat.  In practice it might be feasible but in my mind it seems like unnecessary complication :)

I like the IOIO too, but the issue I have with just implementing the androidthermostat.com project as it stands is the android device itself.  I don't want to rely on the android to keep my HVAC running, especially since the phones are aging and could potentially fail at any time.  The IOIO doesn't work without an android device, so I want to use an arduino.  The code he wrote is pretty good, especially the API.  I just need to port it such that instead of handling all of the scheduling and decision making itself, it sends an updated schedule to the arduino when changes are made.  Rather than directly turning things off or on, it tells the arduino that the action has been requested.  That sort of thing.  If I'm successful with that, the android device can fail without the HVAC control being completely lost or worse, leaving the heater or AC on well past it's defined shutoff point. 

One perceived advantage of using the android device to control the arduino thermostat was the built-in wifi radio.  That should alleviate the need to connect the arduino directly to my network... but the more I think about it I may end up doing that anyway.  I'm using Due boards, so I don't have to worry about stacking a host shield and an ethernet shield - the host capability is built on to the Due mainboard. 

So many projects, so little free time :)


A couple of years ago I took on the project of replacing my thermostats for two heat pumps.  I used arduinos with ethernet shields since I had hardwired ethernet reasonably close.  I also used the 24VAC supplied by the heat pumps to the thermostats.  It was a bit of a chore getting the 24VAC down to 5VDC to run the arduinos, but there are solutions out there.  I needed three relays, fan, hot/cool switch, and compressor to actually operate the heat pumps.  Since this was an early project of mine and the impetus was total control of my heat pumps to save power, they ain't very pretty, but they are functional and can be controlled over the ethernet inside my house.  I may come back at some point in the future and make a prettier version of them with nice graphic displays, but I can get nice displays any time I want to by using an android tablet and talking to them over the network.

A couple of really nice features of doing your own thermostats is that you can have them do anything you want them to.  Change the hysteresis from 1 degree to 2 or 3 anytime you want to.  Tell them to shut the pumps off when the doors are open for more than a couple of minutes.  Sample the temperature outside to see if heat or cold is needed.  Kick the fan on to equalize the temperature if one room gets too hot or cold.  In my case, with demand billing, have them shut off completely to control power costs during peak periods.

The nice thing about separating the thermostats from the display device is that you can use any display device you want to, or as many as you want to.  If you're fond of android, use an android tablet.  If you like apple stuff, us an iPhone or iPad.  If you want it in a little window on your laptop, use javascript.  You get the idea.  In this age of networked devices, we don't have to put all our eggs in one basket; spread it around.  I can change the temperature in my house using a browser on a friends machine while I'm a thousand miles away.

The only thing I regret about them is using ethernet to talk to the thermostats, if I were to do-over, I would use an RF link and a concentrator for controlling both of them and displaying their activity.  That's because the network gets crappy from time to time due to the DSL modem I got stuck with from the provider.  But, that's a problem most people don't have.

They've been in place for a couple of years now working fine and saving me hundreds of dollars in power bills.  Sure, there were bugs that I had to work out and changes I made based on how I wanted to use them, but they have been faithful little devices.


The concept of shutting down HVAC when the doors are left open is intriguing!  I hadn't thought of that but it gives me several other ideas

The main reason I wanted to use the display in the same place as the thermostat was to disguise the security camera.  Secondary reasons include continuity (the wife is used to having them there) and the convenient 24VAC to power the device, and the wifi radio that negates the need for an ethernet drop.  I can easily add other controls, too.  Internet, tablet on the wall, whatever I like.

BTW, your network should not be affected in the least by a subpar DSL modem.  Your connection to the internet certainly would be, but internal networking is a separate entity.  Maybe a shiny new switch is in order? :)


You're absolutely right draythomp.  The hardware controllers and the software interface(s) should be completely separate, and a light-weight API helps ensure that.  With the hardware in place, and an API that gives you read/write control to all the functions of the hardware, you can have interfaces wherever and on whatever platform you want. 

On another note, something I just thought about last night while discussing this project with my wife:
One of the ultimate goals that I want to achieve, is that if I decide to move out of my house, one of two results manifests itself: either 1) the system is integrated enough, pretty enough, and user-friendly enough that the next home-owner doesn't have to necessarily be a geek to operate or manage it, nor need to spend a lot of time learning how it works, or 2) it's modular enough that I can swap it out for the original hardware, so I can easily install the modules in my next home.


Go with option two, for liability reasons if nothing else.


Good point.  Unless I make a marketable product, under an LLC or some other type of business model, I wouldn't want to be held responsible for my DIY project if it ended up burning down the house a month after I moved out.  Obviously, that's the worst case scenario, but it's enough to sway my decision to the latter.  On the down-side, that means that I can't do any big time re-wiring.  On the up-side, I don't need to start from ground zero in my new home.


djjoshuad:  I did the same thing with having an interface at the location of the old thermostat, but I don't actually use it much, and it isn't pretty, just functional.  I use a laptop from my easy chair.  Good point about the network device.  I gotta think a bit about that.

bryanschmidty: That worried me a bit too.  I decided, to heck with it.  I'll automate the heck out of the place and should I move (again), I'll just replace the stuff with cheap conventional devices if the new owner wants me to.  I may wind up with a person that wants to tinker with the stuff and wants me to leave it.  Or, it may work so well by then that I want to take it with me.  It's called delayed decision making by me and procrastination by others.

As to liability as wildbill mentioned.  This is a slippery issue, but many states in the US have a 'disclosure' law.  The idea is that you disclose exactly what you did to the new owners and they list it in their home inspection instructions.  Then, when the devices go up in blue smoke, they were lawfully informed and accepted the risks.  But, this varies state by state, so check it out carefully to be sure you don't have to buy them a new thermostat a year down the road.


draythromp: by the way, I have stolen/used_gratefully a few ideas from your site.  I recently bought 10 of those $1 chinese 110VAC->USB 5VDC adapters, and your thermostat project influenced mine well before you ever jumped on this thread ;)

fwiw, I'm designing everything except the alarm panel to be swapped for original/standard hardware should we decide to sell.  I might let it stay with the proper release of liability and price negotiation, but more likely I'll want to take it all with me.  Not selling any time soon though, I'll let "future me" make that decision

Go Up