Just as I did with our previous projects I’m going to elaborate on the ‘Engineering Experience’ project we’ve done this semester. We opted to build a home automation (Domotica) system from scratch. We, a team of 4 (clicky & clicky) electronics students at Group T University College, spent the last five months or so developing and building a system that, in theory, could be used to control and sense stuff in your house. Here’s some explanation on both hardware/electronics and software.
Hardware
The essential hardware (excluding sensors such as temperature sensors, light sensors, switches, …):
We made a ‘sandwich’ of the Uno, Ethernet and XBee shields which acts as the core, the central coordinator or access point. From here all data is received from and sent to modules around the house. Thanks to the Ethernet connection, a MySQL database is hooked up and a webinterface is able to check and control the entire system. Unfortunately the Uno only has one serial IO channel, which caused some problems in the end due to both shields being connected to that one line. We fixed most of them by software filtering but looking back it would’ve been easier if we had for example an Arduino Mega, which has 3 serial channels.
As you can see on the left, the end device “module” is something we designed ourselves. An XBee is used to send over sampling data to the Access Point and to receive commands (set a digital pin to logical 1 or 0).
You can easily attach sensors to any of the 8 available XBee pins (which can be set either to DIO or ADC).
The programming of the XBee devices is done with a tool developed by Digi called X-CTU. We started out with a serial terminal to program the XBees but quickly switched to a more user-friendly application.
This program can be used to quickly change some parameters in the XBee’s firmware. The firmware can also be easily upgraded, which is a great thing since Digi seems to release a newer version every couple of months that introduces more features for the device.
Software
XBees can either be used in transparent or API mode. For more complex actions one quickly leaves the simple transparent mode behind and uses the somewhat more complex API mode. This mode uses packets (frames) of data to send over information.
This was quite the challenge to be able to read the data, making sense of it and being able to use it to interpret voltages and status information. That’s why I developed a simple packet parser program in C# that quickly transforms any received data packet into human readable form. And so XBeeP was born!
We transfer data to and from the database by letting the Arduino do PHP GET requests. Packet data is assembled and parsed on the webserver which translates it into usable information that can be shown on an interface. For ease of use we developed both a regular website and a mobile version with jQuery mobile.
With these bits of software, the possibilities are nearly endless, you can create cron jobs or do a check every time the Arduino fetches a page to automate things like turning on the lights when it gets dark. We’ve added a scheduler where you can set actions to be performed at a certain time. These can also be set to be repeated daily or weekly.
Some other features the webinterface has:
- User rights management (see screenshot above)
- Easy overview of your switches and the option to turn them on or off
- Temperature/humidity graph
- Motion Detection notifications
Conclusion
This was always just a proof of concept project but it turned out to be pretty usable. Of course, for a commercial project a lot more security would be added as well as the usage of “confirmation” packets a module would send to the access point to notify it has correctly received a command. Some more checksum calculations should be added as well to make sure there is no corruption of information along the way.
To conclude, if you look at Twine, which is somewhat similar I think this project is a beautiful example of home automation systems that allow a lot more interactivity between the system and its users. A funfact here is that if our project would be an actual commercial product on the market it would be cheaper than a Twine with something like $30 to $50 per module and $100-150 for the central access point.
Update: more photos of the finished product can be found at http://ee5.crombeen.be/