A journey in Home Automation

A while ago, after dabbling into automating some of my chores and looking into the possibilities, I stumbled into the domain of home automation. It grew on me quickly and soon I found myself sourcing parts in different countries and splicing them together in various ways as means to various ends. And it was fun, too! I then decided to put all my ideas into one place, to document the process and make a sort of work log of it, so I could recover from failure quickly. Remember that setting you just ‘’had to’’ get right in order for your system to work just right, that you looked for online for over two hours? Well, you sure won’t in a couple of months. Better write it down somewhere! Or so the reasoning went.

However, between deciding to do something and actually doing it there is sometimes that period of time that goes by when you have to do other things, not necessarily more important but more urgent. And so my ideas went on hold. I read, I experimented and I failed, then I read again and tried again and in the end I decided I could do more than just a worklog, and actually write some articles about the whole shebang. Sure, I’m no expert, but I believe those who are keep the knowledge to themselves because this business is quite lucrative. I do have some experience with microcontrollers though, and with setting up various control systems, as well as a background in telecommunications and software programming, and this is what I’d be doing if I could do whatever I wanted, so why not take a crack at it? So the idea stuck and I decided to write and post the articles on devtome so people could actually see them.

So without further ado, here is an introduction and an outline of Home Automation for the not-necessarily-technically-inclined. Chapter 2 deals with the technical overview and cloud security issues, as well as an overview of current technology and how it fits into the theoretical schema. Chapter 3 compares a couple of simple, off the shelf light control systems while Chapter 4 takes steps further and designs a simple home automation system from parts.

As day jobs are notorious in gobbling up time, though, and the realm of home automation is but a hobby to the author, the following information will arrive in sets which will be linked below as they are written. Bookmarking this page and checking back often is highly recommended!

Table of contents:

Chapter 1 - Overview, state of things and possibilities

Chapter 2 - Basic theory, cloud security and examples

Chapter 3 - A (theoretical) home automation system

Chapter 4 - A simple home automation system

Chapter 5 - A practical example using Tasker

You Are Here:

Chapter 6 - A complex solution

In the last few chapters, we talked about home automation as a principle, and some ways to implement it using a Windows™ PC, some hardware and the supporting software for an easy example. However, aside from the cool factor, the system wasn’t really all that useful. It could control some outlets from a PC or smartphone, and that was about it. Cool, for sure, but not really that exciting, and not much in the way of, you know, actual ``automation``.

For actual, bona-fide, decision-making automation, we need a few more things. First, a central control system, preferably running on some low powered, always-on machine. Sure, the Windows™ PC works well, but it’s way too much of a powerhouse. Electricity is not usually cheap unless you’re running your own solar plant, and there are much better ways to automate your home than keep a computer powered on all the time. Some people use HTPCs, in which case an added script or two and some Eventghost rules (for Windows) or cron jobs (for Linux) are all they would need in order to use the home automation setup we detailed in the last few chapters. The computer could, for example, dim or turn off the lights in the room when XBMC (now Kodi) starts playing something, and turn them back again on Pause / Exit. Simple, useful, and the processing power is already there, so it’s a win-win.

However, the advent of cheap but powerful development boards has brought forward a new era. Now, computers that are small enough to fit on a credit card, but powerful enough to be able to run actual operating systems are getting more and more affordable, with the latest offering from the Raspberry PI foundation being a trivial $5 (with no accessories). Make no mistake, it still needs a power source, at least one USB adaptor and could use a case, but it is a fully working computer on a chip smaller than a $5 bill. Thus beings the era of affordable home automation – not with bespoke systems from the likes of Google and Apple, but with affordable, small computers and open source software.

There are a lot of options out there, including various development boards, like the Raspberry Pi clones (Banana PI, Orange Pi etc), or specialized media center / development board hybrids like the iCube, or even hackable WI-FI routers that have custom firmware like DD-WRT installed and have plenty of power to run additional scripts. However, the Raspberry PI 2 remains a great little board, with more than enough power to run the software that we’ll need, and a small enough power requirement that it can be left running around the clock. Consuming just 1-2 Watts per hour means it won’t have much of an impact on the power bill and this makes it a great choice for an always-on central control unit. The community support is very good, as is the aftermarket accessory segment, which means we’ll find plenty of support for when, invariably, something goes wrong and the application just doesn’t work the way it’s supposed to.


While some people will choose to deploy their own solution, if not for any other reason than to learn how to build one, others will be more keen on installing a ready-made application and just configuring it to their liking. However, in the world of home automation, it also means taking care that the operating system works with the chosen application as well as the hardware it controls, via the drivers that might or might not be easily available. A home automation system, especially one that should be always on should also be efficient, and that has meant using Linux, or embedded operating systems, not all of which can be easily configured for the task at hand. Driver availability might be lacking, and fully developed solutions are usually just playthings for the enthusiasts – great if you’re good at coding, but less so if you’re looking for an easily maintainable, fire-and-forget type of application.

Lately though, as the concept has begun getting more and more traction and the open source world becomes more and more powerful, actually ``good`` options have started to appear. We consider to be good enough any application that is open source, can interact with the home automation equipment on hand, and has a bit of community behind it for the support we’ll invariably need. User friendliness is a boon, but as it stands right now just usability without having to write shell scripts is all that is required.

For a long time I’ve used the Tellstick with the Raspberry Pi using either python scripts (that didn’t do that much) or a home automation application called Automagically, written in Django, when I stumbled into it online. For reference, and because it made such a big difference in my projects, I’ve included the link here. It has a lot of options, including setting timers, reacting to external commands and a REST API that makes interacting with it from another app easy. This has made for interesting and useful home automation rules, some of which will be explained below.

It also had some limitations. It uses Django on top of Mysql and Apache, which is not the most efficient way to use a Raspberry Pi’s limited processing power. On the Raspberry Pi 1 B it was noticeably laggy, especially on the first command after being idle for a while. On the Raspberry Pi 2 with its improved CPU it worked a lot better, and the lag was almost gone.

Another limitation was that, while it had a way to set a variable and then later take an action based on the value of said variable, it didn’t have much flexibility in this department. It could do the old “turn lights on when I get home” or the “turn lights on after sunset” bit just fine, but there was no easy way to add another check to that rule. It couldn’t do logic inside the app - understandably, since it would add a whole other layer of complexity to what was basically just a one man project – but that meant that there was no IF, no AND, and no OR. So “turn lights on when I get home AND it’s dark” was out. All in all, this app did get a lot of things right. It had a REST API which made the lack of logic tolerable, since it could be handled in an external script or Tasker rule and a command could be fired through the API with the end result; it had a way to easily add and delete devices and group devices, and could do events, going as far as to understand and calculate the sunset/sunrise times automatically based on latitude and longitude and act on them. It is a lot better than a bunch of scripts and some cron jobs, and would have worked well for a long time.

However, in 2015 there is something better, and it’s called OpenHAB. As a collaborative open source project on which a lot of people work, hardware-agnostic as it is implemented in Java, modular, with a full logic engine, it is the state of the art in home automation software for the masses.

It has bindings which are modules that can be loaded as needed, meaning it is not linked to one system like Automagically was (worked only with Tellstick). It is running Java and has a REST API, and a built-in web server that provides a graphical interface. It has rules files that work with the XTEND language, meaning that complex rules can be written. Things like turn the lights on if it’s raining, it’s winter and it’s a Saturday are easy to do. It has Android and Iphone apps to control the system, and the interface can be customized for administrators and guests. It can control an XBMC app through the XBMC binding, making turn lights on if movie is paused, but only if it’s dark outside feasible. It has an astro binding which calculates various parameters based on latitude and longitude, making it easy to make decisions based on season, sunrise/sunset, moonrise or set, and sun position in the sky among other things (think “lower blinds if sun is above a certain height in the sky”). It is extendable, since it is open source and anybody can write bindings and share them with the world.

It does have a bit of a learning curve, and unfortunately there still is some coding involved as the interface and rules are designed by editing some files. OpenHAB 2 is in the works, and will provide a graphical way to implement rules and design the user interface (or at least that’s the intention right now) for added user friendliness, but until then writing code is still required. However, there is plenty of documentation available online, and the community behind this project is pretty active so it shouldn’t be too difficult.

The actual project

To recap the previous chapters, for a useful home automation system we will need:

  • A central monitoring and control system, that will have to conform to some specifications:
    • Always on
    • Cheap to buy
    • Cheap to run
    • Powerful enough to run the apps with little or no lag
  • An automation system (sensors and actuators) to actually do stuff
    • We’ll use the Telldus stick since it’s relatively inexpensive and versatile as it runs on Windows and Linux. It pairs with 433.92 MHz sockets and dimmers, but no sensors.
    • If the sensors are really needed, there is another, more expensive version of the telldus device, called Tellstick Duo, which also receives information.
  • A software solution that can use the hardware. This also would benefit from:
    • Ease of use (graphical versus command line)
    • Ease of installation and configuration
    • REST API (so it integrates easily in other apps)
    • Mobile presence (Android and iPhone apps are a boon)

Trying to hit all of these checkmarks would have been tricky a year ago, but nowadays there is a solution: Raspberry Pi version 2 for the central processing platform, Telldus Tellstick with 433 MHz sockets and OpenHAB for software. The bill of materials is below, as is the configuration how-to.

Raspberry PI

Going with the Raspberry Pi is good for many reasons, one of which is the ease of configuration. Just grab an image off the internet, write it to a microSD card and boot the Pi. There are a lot of guides out there that cover installation and initial configuration and are beyond the scope of this article.

Once the Pi is online we can connect to it using SSH. Putty works well on Windows, and if you’re running Linux, just use SSH. (Hint: default user is “pi”, default password is “raspberry”. Do change that.) OpenHAB comes next. There are some good guides out there, and I’ll point you in the direction of the one I’ve been using. Again, installing it is all about following directions and running a series of commands and shouldn’t be problematic. What’s more interesting is how OpenHAB works and how it can be tailored to our needs.


OpenHAB works by combining bindings to a graphical user interface (a sitemap) that can be configured with rules. The bindings are similar to drivers, they are modular and each runs one piece of equipment, whether it is an actual piece of hardware like the Tellstick, or some software that does something. It can also persist the information, which is another way of saying it can save the switches’ states, and can transform the information, meaning it can lookup values in a dictionary and show the result to the user.


Bindings are .jar files that can be downloaded from the project site or installed (on the Pi) via apt-get if the repository is configured as in the guide above. Most bindings need to be configured by the user, and that is done in the openhab.cfg file - and most of them have default values already written in the config file OpenHAB comes with. There are a lot of bindings available to OpenHAB that deal with interacting with the actual equipment, like the Tellstick, or by getting information from the web, like weather info from forecast providers, and more. For example, the astro binding is a piece of software that calculates various astronomical times based on latitude and longitude. The user supplies the GPS coordinates of one place, and the astro binding makes available various information, like sunrise and sunset times at that location among other things. Here is the part of openhab.cfg that deals with the configuration:

################################# Astro Binding #######################################
# The latitude

# The longitude

# Refresh interval for azimuth and elevation calculation in seconds
# (optional, defaults to disabled)

And here is the information that the astro binding makes available to rules and sitemaps in OpenHAB:

  • planet sun
  • type rise, set, noon, night, morningNight, astroDawn, nauticDawn, civilDawn, astroDusk, nauticDusk, civilDusk, eveningNight, daylight (Order of these types)
    • property start, end (DateTime), duration (Number)
  • type position
    • property azimuth, elevation (Number)
  • type zodiac
    • property start, end (DateTime), sign (String)
  • type season
    • property: spring, summer, autumn, winter (DateTime), name (String)
  • type eclipse
    • property: total, partial, ring (DateTime)
  • planet moon
  • type rise, set
    • property start, end (DateTime), duration (Number), Note: start and end is always equal, duration always 0.
  • type phase
    • property: firstQuarter, thirdQuarter, full, new (DateTime), age, illumination (Number), name (String)
  • type eclipse
    • property: total, partial (DateTime)
  • type distance
    • property: date (DateTime), kilometer, miles (Number)
  • type perigee
    • property: date (DateTime), kilometer, miles (Number)
  • type apogee
    • property: date (DateTime), kilometer, miles (Number)
  • type zodiac
    • property sign (String)
  • type position
    • property azimuth, elevation (Number)

As you can see, the amount of information available is quite impressive. Rules can be made to depend on season, or on the sun’s position (elevation), or on time of day (before or after sunset); a sprinkler system can start only after sunset, on summer, and blinds can be drawn if sun is over the neighbor’s house, for example. The binding even has information about the zodiac sign and distance to the moon, which might not make it into many rules but still allows for interesting and creative applications.

Bindings are used to tell OpenHAB how to connect to or control something. There is a binding for Yahoo Weather, there is another binding for Telldus control, and yet another for Zwave and the like. It’s all a matter of downloading the needed one and configuring it in the openhab.cfg file.


Sitemaps are configuration files that define the layout of the interface. Here’s the demo version below. The best part about OpenHAB is that it already has an iPhone and Android app ready, and it is user configurable. You just need to define the layout ‘’once’’ and it’s the same whether used via the website or the mobile app, as it is generated “on the fly”. The basic sitemap just has a name, and a label. The following is a part of the ‘’’demo’’’ sitemap that shows just four items, in a nice frame. [insert image]

sitemap demo label="Demo House"


Frame {

Group item=gFF label="First Floor" icon="firstfloor"

Group item=gGF label="Ground Floor" icon="groundfloor"

Group item=gC label="Cellar" icon="cellar" 

Group item=Outdoor icon="garden" 


All the items are defined in the ‘’’items’’’ file. What the sitemap does is tell the system which way to represent the various items you have defined. The best part of all this is that once the sitemap is defined, the system automatically serves the right output based on the client equipment: if you view the site on a web browser it will serve HTML, and if you open the Android or iPhone app, it’ll serve just the data the apps need to represent your items. This enables us to deal with the actual problem at hand, which is implementing the house control solution we need, and not worry about the presentation of the control panel for said solution.

The items file

The items file is a file which defines the kind of items we need to show meaningful information in our sitemap. Usually an item will consist of a name, a type, a dynamic human readable description, and a way to get information. As per the example below:

 Number   Temperature      "Temperature [%.2f °C]"       {weather="locationId=home, type=temperature, property=current"} 

This is a ‘’’number’’’ item, named ‘’’temperature’’’, with a dynamic description (the %.2f means a two decimal float, and is a placeholder for the actual temperature), and a binding with various parameters, which in this case tell the system where to get that particular temperature from.

Wherever it will appear in the sitemap file, the system will know to show the item description to the user.

For further exemplification, the demo sitemap uses some of the following item definitions:

Number Temperature_GF_Corridor "Temperature [%.1f °C]" <temperature> (Temperature, GF_Corridor)

Number Temperature_GF_Toilet "Temperature [%.1f °C]" <temperature> (Temperature, GF_Toilet)

Number Temperature_GF_Living "Temperature [%.1f °C]" <temperature> (Temperature, GF_Living)

Number Temperature_GF_Kitchen "Temperature [%.1f °C]" <temperature> (Temperature, GF_Kitchen)

Number Temperature_FF_Bath "Temperature [%.1f °C]" <temperature> (Temperature, FF_Bath)

Number Temperature_FF_Office "Temperature [%.1f °C]" <temperature> (Temperature, FF_Office)

Number Temperature_FF_Child "Temperature [%.1f °C]" <temperature> (Temperature, FF_Child)

Number Temperature_FF_Bed "Temperature [%.1f °C]" <temperature> (Temperature, FF_Bed)

The astute reader will observe that two more item definition parameters appear: ‘’’<temperature>’’’ and ‘’’(Temperature, GF_*)’’’. The first means the “temperature” icon is to be used (it’s a thermometer) and the second is a group declaration, meaning that the item belongs to those two groups. This makes it easy to display a group of items – in the sitemap just enter a group name, and the system will display the group label. On clicking that group label a new page is displayed, with all the items in that group. [insert image]

The actual project

Let’s build a simple system, one that turns the lights on and off in the living room and bedroom, and that also shows the current date and outside temperature. We’ll throw in a master switch as well, so it’s easy to turn it all off at night.

We only need two files for this simple project, an items file and a sitemap file. Let’s deal with the sitemap first. We’ll name the sitemap “ha” for home automation.

First, we’ll define the items. Open your editor of choice, and start copy pasting:

Group Living
Group Bedroom
Group:Switch:OR(ON, OFF) Lights "All Lights [(%d)]"

Switch Light_Living_Main "Living Light" (Lights, Living) 
Switch Light_Bedroom_Main "Bedroom Light" (Lights, Bedroom) 

Number Temperature "Temperature [%.1f °C]" <temperature

/* NTP binding demo item */

DateTime Date "Date [%1$tA, %1$td.%1$tm.%1$tY]" <calendar> { ntp="Europe/Berlin:de_DE" }

Now save this file with the filename ‘’’ha.items’’’ in the items folder of your OpenHAB installation. What the file does: - Define two groups:Living,Bedroom. As we’ll see, an item can be assigned to none, one or more groups which makes for easier rule-making. We don’t really need the groups right now, but if we want to, we can add lights and just assign them to the groups later. - Define a group switch – the master switch. This switches all lights assigned to the “Lights” group. If we decide to add more lights, we just need to add them to this group and they will be controlled by the master switch. - Define two switch items. These are the actual lights. They have an internal name (Light_Living_Main), a user-friendly description (“Living Light”) and a group assignation. As we see, this light is in the “living” group and the “lights” master switch group. - Define a temperature item – the weather binding will fill in the value periodically. - Define a datetime item – the NTP binding will fill in this value periodically.

Next, open up another file – save this one as ha.sitemap in the sitemap folder.

sitemap ha label="House"


Frame {

Group item=Living label="Living"

Group item=Bedroom label="Bedroom"
Switch item=Lights mappings=[OFF="All Off"]


Frame label = “Weather” {
Text item=Temperature  valuecolor=[>25="orange",>15="green",>5="orange",<=5="blue"]
Frame label="Date" {

Text item=Date


What this file does is instruct the system to build a simple, three frame interface. First it defines two clickable groups. This means that all the lights that belong to each group will be neatly shown in their respective group’s window – not really that important since we only have one light for each room. However, just adding the light definition and group assignation in the ‘’’items’’’ file makes the system add that light to the interface. Magic! Next, it defines a “weather” frame where it shows the temperature as Text. The valuecolor option is so that the text color changes based on temperature value. Next, the Date item is defined. Easy!

So far so good. Point your browser to the IP of the raspberry pi, and the following address: http://<IP_address>:8080/openhab.app?sitemap=ha and see how it looks. So far, the light items don’t do anything because they lack a binding, but we’ll get to that soon. To be continued: bindings.

Home | Technology | How To

QR Code
QR Code home_automation_chapter_6 (generated for current page)