OpenHAB on RaspberryPI

RaspberryPi (Courtesy: Wikipedia)
RaspberryPi (Courtesy: Wikipedia)

In my earlier post, Starting off with OpenHABI listed down the steps involved in building a OpenHAB distribution. Since OpenHAB runs on Java, it can run anywhere if built once.  Also in the post, OpenHAB – Working with the GUI, we added a new device to the OpenHAB system, the “Second Floor Corridor Light” and watched it enumerated on the brower GUI. We will treat this device as a LED on RaspberryPi’s GPIO and control it through the OpenHAB GUI.

OpenHAB demo on RaspberryPi

  1. Ensure that Java is installed and JAVA_HOME is setup properly on RaspberryPi (else follow this)
  2. Copy all the 3 distributions of OpenHAB (distribution-1.6.0-SNAPSHOT-runtime.zip, distribution-1.6.0-SNAPSHOT-addons.zip and distribution-1.6.0-SNAPSHOT-demo.zip) from your build machine to Raspberry Pi and unzip them into your local directory as described here. Please note that the sequence of steps is important here.
  3. Now, run start.sh from your $OPENHAB_HOME. Please note that since RaspberryPi is still an under-powered device and it will take a few minutes for OpenHAB to completely initialize. On my device it takes anywhere between 3-4 mins.
  4. Once all the waiting is done, point your browser to the demo URL provided by OpenHAB. If RaspberryPi has an IP address of 192.168.0.104, your new OpenHAB demo URL will be http://192.168.0.104:8080/openhab.app?sitemap=demo#_Home

You should now be seeing the new “Second Floor Corridor Light” device from your RaspberryPi and toggle it on the browser.

Binding OpenHAB device to RaspberryPi GPIO

OpenHAB has a concept of bindings that allow easy addition and control of different types of automation devices. For example, if I need to support NXP light device, I will need to bind it. Technically this translates to, a abstraction code that will allow me to easily add, configure, monitor and generally communicate to this device. For more on binding refer to the OpenHAB website here. I would suggest you read through this link once and then get your hands dirty.

So, for the job at hand, we still need to get to the “Second Floor Corridor Light”. If I need to bind a GPIO present on RaspberryPI to the OpenHAB server running locally, I will need to use a GPIO Binding (for more on this see here). The examples in this link are quite straight forward.

GPIO on RaspberryPI

RaspberryPI provides a series of GPIO pin-outs that can be configured as input as well as outputs (more on RaspberryPI GPIO here) For now, we will choose to use GPIO 17 that can be configured as an output to drive an LED. Please note that

the LEDs already present on the board can be driven too (well with a hack), but they are for special purposes only. We will not be using these. GPIO 17 can be found on physical pin number 11 on the board breakout. Now connect this pin 11 to positive end of an LED on a breadboard with a 1K register in series to ground (physical pin number 25).Your connection should now look like the one in this picture.

GPIO 17 Connection
GPIO 17 Connection

Now to test the LED, we will use the “gpio” kernel device driver that is provided with the Raspberry distribution (more on this here) For a quick LED toggle, follow the following steps,

  1. cd /sys/class/gpio
  2. echo 17 > export
  3. echo out > gpio17/direction
  4. echo 1 > gpio17/value
  5. echo 0 > gpio17/value
  6. echo 17 > unexport

After step 4, you should be able to see the LED glow. Please note that step 6 is an essential step to ensure that any other application can use GPIO 17.

GPIO Binding

In the earlier post, we made changes to the OpenHAB configuration to add a new “Second Floor Corridor Light” device. The changes to the demo.items file looked like this,

Switch Light_SF_Corridor_Ceiling “Corridor” (SF_Corridor, Lights)

Now at the end of the above line, add the device binding to GPIO 17. The change should look like this,

Switch Light_SF_Corridor_Ceiling “Corridor” (SF_Corridor, Lights) { gpio=”pin:17″ }

Now start the OpenHAB server and wait for the URL to come up. Once you are able to view the URL, you will be able to toggle the “Second Floor Corridor Light” as shown in the video.

As you can see, binding makes configuring OpenHAB a lot easier and maintainable. However, this was an example of local binding where the device to be controlled was directly connected. However, in reality, devices in home automation are spread across different places in your home. This necessities binding to work over the access network (like WLAN) as well. The next step in this project is to head towards defining my own binding for my custom device.

 Update:

OpenHAB doesn’t cleanup well in case you exit from the console. Due to this, the exported GPIOs will not be unexported. Hence the next time you start OpenHAB, it will find the GPIO busy. For now, the workaround is to ensure that the GPIOs are unexported before you start OpenHAB. More on this issue in this thread here, GPIO Binding problem.

OpenHAB – Working with the GUI

In the previous post [here] , I noted down on building OpenHAB and getting up and running with its distribution.

Here, I will briefly introduce you to the user interface. We will modify the OpenHAB demo setup, we installed earlier, by adding a new device to control. We will be able to toggle this device eventually.

Adding a new device in OpenHAB

This is quite easy. It is just incredible that anyone using OpenHAB doesn’t need to worry too much about it’s user interface. The files of interest here are,

$OPENHAB_HOME/configurations/sitemaps/demo.sitemap

$OPENHAB_HOME/configurations/items/demo.items

Please note that I use OPENHAB_HOME to refer to any location where you would have installed the OpenHAB distributions that we built here.

Sitemaps

If you look at the defOpenHAB-Demo Homeault demo page of OpenHAB, you will find that devices are segregated into groups. The groups here are given user readable names like “First Floor” or “Ground Floor”. This is hierarchical as you would have seen in the earlier post. We will define a new group as “Second Floor” and add a new Light control for its “Corridor”.

Each of the sections in the home page is a frame which provides a clear distinction between various functionality you might want to provide from your home page. You can define a new frame here just for devices that can be monitored (for example: Outside Temperature device here). This is just a high level logical separation that user might want to work with. No rocket science here.

In the file demo.sitemap, you will find the page layout definition. Here look at the first entry under unnamed frame type which includes groups for all the floors. Go ahead and add another entry for our “Second Floor”. It should now look something like this.

sitemap demo label=”Main Menu”
{
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”
      Group item=gSF label=”Second Floor” icon=”firstfloor” 
}

……….

…..

The highlighted entry defines a new group type (no devices yet) with user label of “Second Floor” and an user defined icon.

Items

Now, under the demo.items declare that “Second Floor” group gSF will be used. Your entry should look like this,

Group All
Group gGF (All)
Group gFF (All)
Group gC (All)
Group gSF (All)

Now under this new group we can add any number of devices or items to control. Since we want to control a light device on the second floor corridor, define a new corridor device like this,

Group SF_Corridor “Corridor” <corridor> (gSF)

Now under section commented as Lights, include the following line,

Switch Light_SF_Corridor_Ceiling “Corridor” (SF_Corridor, Lights)

Now this tells OpenHAB system that SF_Corridor is a switch device type and that it can be controlled in ON or OFF manner like Lights. This is rather an incomplete definition since there is no physical access defined for controlled this device. But OpenHAB is happy to oblige and doesn’t care if there is no physical device present.

Device Control Simulation

Now refresh your browser (preferably by clearing the cache) and you should be able to see the new device additions to OpenHAB GUI.

OpenHAB New Second Floor Group
New Second Floor Group
Second Floor Location List
Second Floor Location List
Second Floor Corridor Device List
Second Floor Corridor Device List

Everytime you toggle the Corridor Light, you will be able to see INFO logs on the OpenHAB console. These message are helpful when debugging,

11:53:39.388 INFO runtime.busevents[:22] – Light_SF_Corridor_Ceiling received command OFF

11:54:00.186 INFO runtime.busevents[:22] – Light_SF_Corridor_Ceiling received command ON

The OpenHAB console also provides for command line access to the devices. You can quickly test your device access instead of using the GUI. You can list out all the devices under Second Floor using pattern matching,

osgi> openhab items *SF*
gSF (Type=GroupItem, Members=1, State=ON)
SF_Corridor (Type=GroupItem, Members=1, State=ON)
Light_SF_Corridor_Ceiling (Type=SwitchItem, State=ON)

This lists all the SF group devices and their state information.

To specifically check status of an item, you can use the status option,

osgi> openhab status Light_SF_Corridor_Ceiling
ON

Control of the item can be done using the update command,

osgi> openhab update Light_SF_Corridor_Ceiling OFF
Update has been sent successfully.

This has been an easy change. But to physically cause state of a device (LED for now) to change using this GUI, we will use a RaspberryPI with OpenHAB running on it. We will also introduce another OpenHAB concept of bindings in the next post.

Starting off with OpenHAB

To start off, I would like to get OpenHAB running on my Linux based laptop. The assumption is that Java will be available on the end system that will eventually host the OpenHAB server.

Cloning OpenHAB

Clone the latest version of OpenHAB source from GitHub. This is fairly simple.

git clone https://github.com/openhab/openhab.git

Installing Build System

OpenHAB is built and managed using Maven build system. It performs automatic resolution of all the dependencies present in your workspace. If you don’t have Maven yet, get it first.

sudo apt-get update

sudo apt-get install maven

mvn -V
Apache Maven 3.0.4
Maven home: /usr/share/maven
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: “linux”, version: “3.2.0-67-generic”, arch: “amd64”, family: “unix”

Building OpenHAB

Please note that Maven requires that Java home to be setup properly. I use OpenJDK 7 on a 64 bit, and hence my JAVA_HOME is setup as,

JAVA_HOME = /usr/lib/jvm/java-7-openjdk-amd64/

If JAVA_HOME is incorrectly set, Maven will not be able to build anything.

Go to the newly cloned OpenHAB repository and perform a clean build,

cd openhab

mvn clean install

Please remember that Maven will take a lot of time for the first build since it downloads all the libraries. This will happen if you perform a clean everytime. To avoid this and to enforce Maven to use the locally cached libraries and dependencies, use the -o option

mvn install -o

If the build is successful, you will have the OpenHAB distribution zipped under ./distribution/target/. You should be expecting to see these packages,

cd distribution/target/

ls -l

distribution-1.6.0-SNAPSHOT-addons.zip
distribution-1.6.0-SNAPSHOT-demo.zip
distribution-1.6.0-SNAPSHOT-designer-linux64bit.zip
distribution-1.6.0-SNAPSHOT-designer-linux.zip
distribution-1.6.0-SNAPSHOT-designer-macosx64.zip
distribution-1.6.0-SNAPSHOT-designer-win.zip
distribution-1.6.0-SNAPSHOT-greent.zip
distribution-1.6.0-SNAPSHOT-runtime.zip
openhab-runtime-1.6.0-SNAPSHOT.deb

Of interest are the following distributions,

distribution-1.6.0-SNAPSHOT-runtime.zip : Contains the core OpenHAB modules

distribution-1.6.0-SNAPSHOT-addons.zip: Contains support for bundles that provide support for various types of devices.

distribution-1.6.0-SNAPSHOT-demo.zip: Provides demo configurations and sitemaps.

Starting OpenHAB

For a quick check, copy the above 3 distributions into a separate location and follow the below 4 steps,

1. Unzip the runtime distribution first.

unzip distribution-1.6.0-SNAPSHOT-runtime.zip

2. Unzip the demo distribution and say yes to any overwrite prompt.

unzip distribution-1.6.0-SNAPSHOT-demo.zip

3. Move the addons distribution into the addons directory and unzip it there. Say yes to any overwrite prompt.

mv distribution-1.6.0-SNAPSHOT-addons.zip addons/

cd addons/

unzip distribution-1.6.0-SNAPSHOT-addons.zip

4. Go back to the parent directory and then to configuration directory. Make a copy of OpenHAB default configuration as a running configuration. This is good enough to run in the demo mode.

cd ../

cd configurations/

cp openhab_default.cfg openhab.cfg

Now OpenHAB is ready to run in demo mode. Go back to the parent folder and you will find couple of start shell scripts. Run the start.sh and wait for a few seconds. Now go to the demo URL [ http://localhost:8080/openhab.app?sitemap=demo ] offered by OpenHAB server on your localhost, and have the first look at the GUI in the demo mode. You will be able to play around and change the state of some devices.

OpenHAB Demo Home
OpenHAB Demo Home
OpenHAB Demo - First Floor View
OpenHAB Demo – First Floor View
OpenHAB Demo - Bath View
OpenHAB Demo – Bath View

Now I cannot wait to toggle an LED with this web interface on my RaspberryPI.

Decision time!

In this post, I highlighted the expectations from a home automation prototype.

As a hobbyist, for someone who is trying to balance  work and life, time and cost of development is pretty high the list. As such I tried to search options for systems that are already existing (preferably open). Google is everyone’s friend and rarely disappoints. One look here at the popular options documented in Wiki reveals that home automation is not really open. For systems where complete integrated solution is available for a smart home, there is a cost.

Some more googling took me to another list of open source options

So to start off, the idea is simple, “choose a good enough open source platform, adapt it for custom hardware, scale it layer”.

OpenHAB (Open Home Automation Bus)

OpenHAB is a popular open source home automation platform or rather just a big piece of software that allows you to play around with any type of automation hardware. I choose OpenHAB mainly due to,

1) Written in JavaJava Beans (Courtesy Jeff Eaton)

This means I can run it anywhere (laptop/pad/mobile/RaspberryPi?). I understand that Java has its own performance issues on smaller systems, but its a different problem all together. For now, this is good enough.

2) Integrates with any known/custom automation hardware

Be it an Insteon, Zigbee, NXP or any known automation device in market, OpenHAB can work with it. Basically, the developers have a done a great job of reverse engineering these devices and their closed protocols.

Of course, I can add support my custom hardware to!

3) Provides advanced features like rules

OpenHAB comes with a rich set of features like rules which makes the software job easier. I can add rules like “If LIGHT_SENSOR = ON then CURTAIN=OPEN” .

4) Open Source

OpenHAB is completely reusable and can be modified for our use. Whats more, i can contribute to it.

5) Scalable

OpenHAB Android Screen
OpenHAB Android Screen

OpenHAB can be run anywhere. It could be installed as a single controlling entity at home while also running on a node like a switch controller. Whats more, it can be installed on cloud as well using services like Xively. Basically it can work with any number of devices and any number of instances because of its event bus architecture. There basically doesnt seem to be any practical limit on the number of devices that can be controlled or monitored by OpenHAB.

6) Security

OpenHAB allows for a layer of security when communicating with devices. More here.

7) User Access

OpenHAB comes with very usable user interfaces. While the server instance of OpenHAB can be accessed using a web-browser (for ex: http://192.168.0.105:8080/openhab.app?sitemap=demo), an Andriod or IOS version provides the exact same interface. The Andriod interface is quite neat and uses network discovery to find the OpenHAB server instance. The user access system is complete on its own and seems easy to tweak around.

So with the decision to stick with OpenHAB, my next job is to find a linux based platform (like RaspberryPI?) to run it.

Home Automation Prototype – Expectations

Lets try and chalk down the expectations from a typical home automation system. The system in consideration is a prototype that should be able to work seamlessly in a local home environment. Connectivity to/from the outside world or cloud would be the next logical step to this type of system.

Scale & Architecture

One ring to rule them allIt is a lot easier to have a local server-client architecture which can allow for centralized control, access and monitoring. A typical home automation network would consist of multiple control nodes, devices and one server to rule them all. However, the devices that control our very lives have been proliferating and hence the architecture of the system should be a able to scale easily.

Minimal Invasion

Most of the houses in developing nations aren’t home automation enabled. Lets face it, the switch boards are designed only in one way, the locks are supposed to lock manually, the kitchen has electrical sockets all over the place. The job of automating now becomes “retrofitting”. The new system has to seamlessly work with the old one. All this with minimum physical damage to the existing house. Retrofitting should thus, be minimal invasive to the home. The type of technology chosen and its architecture play a key role in deciding this.

Security

No one wants this to happen to their homes.

When there are systems available to ease our lives, they should not come at a cost of security and privacy. This is more of the technology related problem. Security should be inherent and privacy should be well understood when the underlying technology is chosen. Please note that more of security doesn’t mean less of usability.

User Access

The system should be accessible through any well accepted user interfaces like mobile or laptop. The interface should also be able to address each device at home and control them.

The new interface shouldn’t completely do away with traditional controls. The latter still might be needed as a default go to way of controlling devices.

System Stability and Safety

Devices should be able to behave the way they are designed for. When operating vital devices like Gas Sensors and Alarms,, there is no scope for a software bug. Also, the system should be able to checks its own health to figure out an error device or node.

Pneumatic_sirenA unique problem with developing countries is the amount of power fluctuations. While the rest of the world thinks of power that is always available, in developing world frequent power cuts pose a design challenge to the automation system. The system just cannot assume that somehow backup power will be available. This has to be taken into consideration during design. For example, if one of the resource challenged nodes driving your lights uses Linux, then you might as well get up turn on the light yourself then wait for Linux to boot after every power loss. One cannot ignore and design a system which is slow to react to such changes.

Cost

coinsWhile a commercial home automation systems can cost more than $2500 for a small apartment, a project like this aims to bring down the cost and make it cheap. Adoption of open source projects is one of the key motivations here. This project, however, doesn’t aim to inter-operate with any existing home automation devices.

Energy Monitoring

Wouldn’t it be great to find a detailed report of each of your devices so that you can take a better decision about your energy usage?  This is like reading your assorted credit card bill. A chart of on/off times of a each device in your home will an interesting tale onto itself.

 

 

 

 

Home Automation

Its established that home automation is a luxury one would desire to have. Whether you own a condo, an apartment or a farm house far into the country side, home automation always adds a certain level of ease and comfort into your lives.

A visit to developed countries like US and Europe, makes it apparent that automation of daily (though sometimes not so menial) tasks is no more stuff of the futurelego pieces. The same is not the case in developing countries like India. Home Automation falls far behind the acceptance compared to other luxuries associated with home. For example, one might own a million dollar villa with a Olympic sized swimming pool for his Golden Retriever to bathe in, but still have a lowly paid security performing all the monitoring of the property. May be economics of the developing world plays a part here, but home automation does open up a unlimited number possibilities that can enrich your lives. Enough said, the engineer in me would definitely like to own an automated home.

Starting now, this blog will be a running account of how to economically (I really mean cheap here) turn your existing home into an automated one.