International Conference on Advances in Electrical, Electronics, Information, Communication and Bio-Informatics (AEEICB16)
Cost effective digitization of Home Appliances for
Home Automation with low-power WiFi devices
Ashutosh Bhatt
C.S.P.I.T, CHARUSAT University
Changa, Gujarat, India
Email: ashubhatt.ec@gmail.com
AbstractThe notion of a smart home with integrated sensors,
actuators, wireless network and a graphical user interface is very
enticing. This paper presents the design and implementation
of reliable, flexible, secure and economical sensor network for
transforming traditional home into a smart home. The heteroge-
neous sensor and actuator nodes based on wireless networking
technologies are deployed in the home environment. These nodes
communicate to a middleware which runs home automation
server and which operates as broker to facilitate the MQTT
connectivity protocol. The middleware facilitates controlling of
wireless nodes over local as well as remote network. The proposed
system is designed to be low cost and scalable to accommodate
variety of devices to be controlled.
Index TermsHome Automation, WiFi, OpenHAB, IOT, Rasp-
berry Pi, ESP8266
I. I NTRODUCTION
T WENTY First century is an era of digital revolution.
A revolution which introduced human society with ad-
vancement in technologies. With this advent in technology,
cost effective and reliable wireless technologies came into
existence. The improvements offered by the wireless tech-
nologies now significantly reduces the complexity of harness-
ing wired transmission and facilitates the communication for
internet-of-things (IOT). Utilization of such low cost wireless
technologies can be made to introduce digitization in tradi-
tional homes and effectively build a Smart Home System.
A. Home Automation
A Smart Home is usually a freshly constructed home/build-
ing that is furnished with special structured wired or wireless
system that enables inhabitants to operate home appliances
remotely. Smart home incorporates home automation tech-
nologies to provide occupants with information and intelligent
feedback by monitoring various aspects of home.
The concept of IOT is closely integrated with the popu-
larization of home automation. By employing the network
infrastructure of IOT and utilizing standard IOT protocols,
the household appliances can be monitored and controlled
remotely over internet. A home that is equipped with such
a wireless system can be called Smart Home in context of
IOT. The Smart Home concept fundamentally brings several
new features to a regular home like interoperability, remote
access and flexibility of expansion [1].
978-1-4673-6725-2
2016
c IEEE
Jignesh Patoliya
C.S.P.I.T, CHARUSAT University
Changa, Gujarat, India
Email: jigneshpatoliya@charusat.ac.in
Home Automation is the introduction of technology within
the home to enhance the quality of life of its occupants,
through the provision of different services such as telehealth,
multimedia entertainment and energy conservation [2]. In
a Home Automation System, several home appliances are
connected to each other in an existing or dedicated network
and can be controlled, monitored and automated through a
central application.
B. Proposed System
The popular notion that retro-fitting (adding smart home
technologies to an existing property) a house to make it a
smart home is significantly costly, is no more acceptable in
the modern era. The development and innovations in wire-
less technologies has certainly brought reduction in cost of
Wireless Systems. The wireless technologies have evolved and
its progress can be observed in latest technologies being not
only cost-effective but also reliable and power efficient. These
technologies can be deployed in a traditional home environ-
ment and the regular home appliances can be digitized after
which they can be controlled and monitored effectively using
the Smart Home concept. The proposed system essentially
converts traditional homes into smart homes.
Features of Proposed System:
The system can be integrated in traditional homes.
The system has scalable architecture. Any number of
home appliances can be controlled and monitored with
the proposed system.
The system proposes cost-effective home automation
solution.
The system can integrate existing wireless home appli-
ances to effectively present a single interface to the user
to control and monitor almost all home appliances.
The system can efficiently utilize existing wireless net-
work architecture for communication.
The system can be customized to automate only user
picked appliances; in which case rest of the appliances
will work with their inherent functionality.
The system handles and manages all home resources
through a central server, which makes debugging and
reconfiguration of system easy for user.
 II. H OME AUTOMATION S YSTEM A RCHITECTURE
System Architecture provides a conceptual idea about the
implementation of Home Automation System. The architecture
that was planned for the proposed system is described next.
The system architecture is comprised of three main parts:
1) Wireless Nodes: A node is an electronic module that
is capable of processing some information, gathering sensory
information and communicating with other connected nodes
and middleware in the network. Nodes can be attached with
either sensors or actuators or a combination of both. Nodes
are analogous to switchboards in a regular home.
2) Middleware: A middleware behaves as a central server,
which facilitates communication between all the connected
nodes in the network and hosts the automation software.
Further it provides user the facility to access home appliances
over local or remote network.
3) User Interface: An intuitive and customizable graphical
interface which can be accessed either through smartphone
application or through browser interface. The application in-
terface can support major platforms like Android, iOS and
Windows.
Consider the architecture diagram as shown in the Fig. 1.
The architecture is comprised of several wireless nodes, a
middleware and user interface. All the wireless nodes com- Fig. 1: System Architecture
municate over a dedicated or existing network with the mid-
dleware. This communication is based on Message Queue
Telemetry Transport (MQTT) connectivity protocol which is A. Hardware Part
designed for internet-of-things [3]. The MQTT protocol uses In a home automation system, the monitoring subsystem
Publish/Subscribe based messaging on the top of TCP/IP requires input readings acquired from several sensors like
Protocol. light, temperature, pressure, humidity, motion, fire alarm, dust
In the MQTT mechanism, a client needing data (known as air sensors, etc. And based on the input from UI, or based
subscriber) registers its interests with a server (also known on the automation script, the controlling subsystem needs
as broker). The client producing data (known as publisher) to operate several actuators like door locks, linear actuators,
sends the data to a server and this server forwards the fresh motors, etc. These sensors and actuators are attached with the
data to the subscriber. In that context, the nodes subscribe and WiFi module.
publish messages on a specific topic.The Middleware makes
1) Raspberry Pi: Raspberry Pi is a series of small, rela-
the provision to relay messages between nodes and works as
tively cheap, single-board computers. It is about the size of a
MQTT Broker with which all nodes are connected. The nodes
credit card, has a 32-bit ARM processor and uses a Debian
attached to sensors generally use the publish mechanism,
distribution of Linux for its default Operating System (OS).
whereas the nodes attached to actuators generally use the
It can be programmed with python or any other language that
subscribe mechanism. If a wireless node is connected to
will compile for ARMv7. The experimental system utilizes
both actuators and sensors, it will use publish as well as
Raspberry Pi 2 Model B loaded with Raspbian Jessie image.
subscribe mechanism. Apart from hosting a MQTT Broker, the
It is essentially a system-on-chip (SoC) with connection ports
Middleware runs a home automation server based on HTTP,
like USB, Ethernet, etc. The Raspberry Pi can be connected to
from which the User Interface (UI) can be accessed.
the network by either a USB WiFi Modem or by an Ethernet
User can use either a Smartphone Application or a Web
Cable.
Browser to access the UI of Home Automation. The user is
presented with a graphical menu containing all the actuators Raspberry Pi is the heart of the system. It operates as a
available in the system. For example, for a particular room, the Middleware, as mentioned in the System Architecture. The
menu shows the switches for Ceiling Light, Fan, Plugs. When automation software OpenHAB along with the MQTT broker
user touches a switch the corresponding item will turn On/Off. is installed in the Raspbian OS. For the Home Automation
system to remain functional, it is necessary that Raspberry Pi
III. S YSTEM I MPLEMENTATION must be powered on and connected to network all the time.
The system was developed using Raspberry Pi and ESP8266 However, it is possible that Raspberry Pi might loose power
as the hardware part and the OpenHAB platform and because of intermediate power outages which will stop the
Mosquitto Broker as the software part. automation server. To make automation system robust, once

Fig. 2: ESP8266 with USB-UART
the Power returns, the automation system should restart itself
without any user intervention. This can be done by preparing
a script for automation server initialization, which then can be
added in .bashrc file located in Raspbian Home Directory.
2) ESP8266: The ESP8266 WiFi Module is a self con-
tained SoC with integrated TCP/IP protocol stack [4]. The
ESP8266 is capable of either hosting an application or
offloading all WiFi networking functions from another proces-
sor. It is an extremely cost effective module that has on-board
processing and storage capability. It can be directly integrated
with actuators and other application specific devices through
its programmable GPIOs. The module can operate on a low
voltage range of 1.8V to 3.6V and supports three different low
power modes as described in [5].
The Espressif system which manufactures the ESP8266
modules provides a Software Development Kit (SDK) along
with a list of Application Programming Interfaces (APIs) to
program the ESP8266 module [6], [7]. Using these APIs the
MQTT protocol can be implemented for ESP8266 modules.
The authors have utilized an existing MQTT Client library for
ESP8266 which is ported from Contiki by TuanPM [8]. Apart
from the protocol, in-order to interface the WiFi modules with
various sensors and actuators, GPIOs needs to be configured
separately by the APIs. Such a subsystem consisting of WiFi
module along with sensors and/or actuators is termed as a
Wireless Node in the Architecture.
As per the system architecture, there can be multiple nodes
attached with the Middleware. Each of these wireless nodes
needs configuration for proper accessibility. ESP8266 module
has 8 digital GPIOs, excluding the Serial pins, which can be
attached to relays or actuators for controlling purpose. It also
has a single analog GPIO which can be utilized to read input
from analog sensors. The pin diagram of ESP8266 is shown in
Fig. 2. Although the ESP8266 module does not contain a USB
port through which it can be programmed, it accommodates
two GPIOs which can function as Rx-Tx pins for serial
connection. By interfacing these GPIOs with a USB-Serial
converter as shown in Fig. 2, the module can be programmed
serially using the Eclipse IDE and Espressifs SDK.
To make GPIOs accessible over WiFi through MQTT pro-
Fig. 3: Node Interaction Diagram
tocol, the ESP8266 module is programmed to accept MQTT
requests on a separate dedicated topic for every GPIO and in-
turn send an acknowledgement response to the Broker. The
Middleware then publishes data in the topic corresponding to
the GPIO number for the corresponding node depending on
the user input. For instance, consider the interaction diagram
shown in Fig. 3. The Middleware sends the data in topic
node#/gpio#, where # represents the node or gpio number.
Similarly the wireless node responds back to Middleware in
topic node#/state/gpio# corresponding to its node number #.
In this way, the nodes can be easily classified by the Middle-
ware and the GPIOs corresponding to different nodes can be
accessed methodically. The response mechanism from wireless
node serves two purpose: 1) To detect GPIO failure and 2)
To verify that present state of GPIO is in sync with the User
Interface. When the GPIO state is received by the middleware,
it can cross-check this state with the local state copy and can
determine above mentioned conditions.
B. Software Part
1) MQTT Broker: In the experimental setup an Open
Source implementation of MQTT broker called Mosquitto
is utilized and is integrated with the Middleware. Mosquitto
provides both online and offline implementation of Broker. In
the offline implementation, a software package is available
for all major platforms, which must be installed for the
corresponding OS. There is a separate repository available
for Raspberry Pi which supports the installation of Mosquitto.
Once the Mosquitto is installed in the Raspberry Pi, all the
wireless nodes can communicate over a local network to
Middleware and to each other.
2) OpenHAB: OpenHAB is an acronym of Open Home Au-
tomation Bus. It is a Java based home automation system that
allows user to control multiple technologies all from a single
location. It is fully open source and can run on any device
that is capable of running a Java Virtual Machine (JVM) [9].
The software supports several home automation technologies
such as Plugwise, RFXCOM, Tellstick, EnOcean, etc. It also
provides integration with various notification systems includ-
ing Email, XMPP (Jabber / Google Talk), NotifyMyAndroid
and can also be integrated with Google Calendar.
The openHAB project is split into two parts:
openHAB Runtime: It is the main package which runs as
home automation server on Raspberry Pi.

(a) Sitemap (b) Items
Fig. 4: User Interface of Demo Configuration
openHAB Designer: It is a configuration tool for openHAB
runtime. It comes with a user friendly editor which can be used
to define UIs and set automation rules.
For the experimental setup, openHAB runtime package is
installed in the Raspberry Pi. This openHAB runtime package
contains two main subfolders:
1. addons: Add-ons contains several optional features of
openHAB, each of which can be installed independently.
Inorder to keep core runtime package size minimum, these
addon bundles are provided separately on the openhab website
[10], for the user to select the features that are of interest.
The system required MQTT support along with remote
access of UI for which the addons that were utilized are: http-
binding, mqtt-binding and tcp-binding. Once the addons are
added in this directory, the openhab.cfg file needs to be edited
to enable the MQTT binding support in UI.
mqtt : pibroker . u r l = tcp : / / l o c a l h o s t :1883
mqtt : pibroker . c l i e n t I d =openHAB
mqtt : pibroker . u s e r=<u s e r >
mqtt : pibroker . p a s s w o r d=<p a s s w o r d>
Here pibroker is the name of the MQTT binding which
is configured to use openHAB as clientId. In the Setup,
Raspberry Pi itself is hosting the MQTT broker hence lo-
calhost is used for broker url. Apart from these settings, the
Authentication settings for MQTT can also be configured in
the same file.
2. configurations: It is used to define the Graphical UIs and
automation rules. It further contains subdirectories for different
topics:
Sitemap is concerned with the user interface and it contains
the graphical & hierarchical information in the format of Tree
Structure.
Items is an inventory of every control device, sensor or
information element present in the system.
While adding a control device such as a Switch, the control
device needs to be programmed to send and receive MQTT
commands over the wireless connection. The programming
can be done as demonstrated in the listed code, where Switch
represents a switch item having name gpio0 n1 and label
Celing. Once the state of the Switch is modified by user,
middleware will send a MQTT command over topic node1/0
to wireless node Node1. Node1 receives the command and
toggles the switch attached to its GPIO0 and in response
sends the updated status of switch over node1/state/0 to the
middleware.
/ ESP8266 m q t t i t e m f o r node1 /
S w i t c h g p i o 0 n 1 C e i l i n g ( node1 , l i g h t s )
{ m q t t =>[ p i b r o k e r : node1 / 0 : command :ON: d e f a u l t ] , >[
p i b r o k e r : node1 / 0 : command : OFF : d e f a u l t ] , <[ p i b r o k e r
: node1 / s t a t e / 0 : s t a t e : d e f a u l t ] }
Rules is where the home automation aspect comes into
play, where user can define schedules or conditions for an
action to happen. Events which can be configured could be as
simple as turning on the room lights at 10pm to a blue color;
or more complex logic such as turning on a room heater if the
temperature is less than 0 and someone is present in that room.
Even more complex level of programmable logic is supported
in the scripts directory.
Persistence is used to keep a record of data. By default,
openHAB stores only the present state of any item; if user
wants to track the value over time such as measurement of in-
ternal room temperature over a month, persistence definitions
needs to be setup for that data source.
Transform contains mapping of data values to labels.
For instance, the temperature.scale file defines a range of
temperature index values and how they should be shown in
English: 29-38 is Very Hot.
The sitemap and items files are essential for OpenHAB to run;
the rest are optional. OpenHAB provides a demo configuration
package as presented in Fig. 4, which can be utilized as
reference for programming.
Apart from graphics and automation, an important feature
required by any home automation system is Security, to pro-
tect the system from unapproved external access. OpenHAB
supports two security mechanisms: HTTPS & Authentication.
The HTTPS communication is supported by default, but to
enable Authentication support, the user needs to configure
login credentials in the users.cfg file. Once the credentials are
configured, openHAB will ask for username and password to
login into UI and any anonymous access will be blocked.
The final setup with complete implementation diagram is
demonstrated in Fig. 5, which involves one Raspberry Pi oper-
ating as a Middleware and multiple wireless nodes operating as
Sensor or Actuator Nodes. The communication between them
is supported by an existing home router, thereby utilizing the
existing network infrastructure. The Raspberry Pi is directly
connected to Router to access the network and hosts the Home
Automation Server which can provide users access to UI. The
Raspberry Pi needs to be configured to have a static IP address
for the wireless nodes to communicate to it and for the UI
applications to track the openHAB server. The Wireless Nodes
are attached to appropriate sensors and/or actuators (not shown
in diagram) to complete the automation functionality of the
system.
C. User Interface
OpenHAB server provides two different methods to access
the Graphical User Interface (GUI). These methods involve a

Fig. 5: System Implementation Diagram
Smartphone Application and the Browser based Web Client.
The Smartphone Application is available for major plat-
forms such as iOS, Windows and Android. The experimental
setup mainly focused on Android application called HAB-
Droid. The HABDroid uses multicast DNS service discovery
to find the openHAB runtime server in local network. At the
startup, the application tries to locate the openHAB on the
local network. If not found, it tries to locate the server on the
remote URL. The application needs to be configured first by
providing it the URL of the Raspberry Pi hosting the openHAB
server. Once the server is found, the application presents user
with a menu of sitemap as shown in Fig. 4a, through which
the user can access the regular home appliances.
Another access method is to use the Web Client interface,
accessible through any (webkit-based) web browser. To access
the GUI from browser, the user needs to enter the URL of
server:
/ F o r Remote A c c e s s /
h t t p :// < Middleware E x t e r n a l IP Address >:8080/
o p e n h a b . app ? s i t e m a p=<S i t e m a p Name>
/ F o r L o c a l Network A c c e s s /
h t t p :// < Middleware I n t e r n a l IP Address >:8080/
o p e n h a b . app ? s i t e m a p=<S i t e m a p Name>
/ F o r t h e s i t e m a p named d e f a u l t /
h t t p : / / < M i d d l e w a r e I P A d d r e s s > : 8 0 8 0 / o p e n h a b . app
/ Example : A c c e s s t h r o u g h i n t e r n e t /
h t t p : / / 1 8 2 . 2 1 1 . 1 0 2 . 4 3 : 8 0 8 0 / o p e n h a b . app ? s i t e m a p =
myHome
D. Node Availability Detection
It is crucially important for an automation system to keep
synchronization between Hardware and Software part. Con-
sider a scenario when user presses a Switch in GUI but the
corresponding node has collapsed due to some fault and thus
(a) All Nodes Available (b) Node 2 Unavailable
Fig. 6: Node Availability Detection
the appliance cannot be controlled. To tackle such conditions,
the system needs to detect the availability of WiFi Nodes and
perform corresponding changes in GUI depending on the node
detection.
The collapsed node must be detected within few seconds
(depending on the application) to keep the User Interface
updated. Under the detection of a faulty node, the GUI
should provide relevant warning message to the user. Although
OpenHAB provides various functionality, Node detection over
MQTT protocol is not yet included in it.
The Node detection can be achieved by utilizing the Last
Will & Testament (LWT) feature available in MQTT protocol.
The LWT feature of MQTT is used to notify other clients about
the unexpectedly disconnected client. The ESP8266 nodes
must be configured to send an OFF (offline) message in the
LWT packet on a predefined lwt topic. This message will get
stored in the Broker until the client disconnects unexpectedly.
Upon disconnection the Broker then sends the LWT message
to the subscribers. Apart from this, the nodes should send an
ON (online) message over the lwt topic upon startup. In this
way, every node itself will let the Automation Server know
about its availability.
The openHAB provides a feature called Visibility, which
can be used to make the Items conditionally visible in the
GUI. Utilizing this feature, the Switch Controls can be shown
only during the availability of nodes. Upon detection of node
failure, these controls can be made invisible and a warning
message can be made visible as shown in the Fig. 6.
/ SiteMap /
Frame l a b e l = ESP8266 a t Node #1 {
Group i t e m = node1 l a b e l =Room 1 i c o n = bedroom
v i s i b i l i t y = [ n 1 S w i t c h ==ON]
S w i t c h i t e m = n 1 L i g h t s m a p p i n g s = [OFF= A l l O f f ]
v i s i b i l i t y = [ n 1 S w i t c h ==ON]
T e x t i t e m = n 1 S w i t c h i c o n = w a r n i n g v i s i b i l i t y = [
n 1 S w i t c h ==OFF ]
}
/ Items /
S w i t c h n 1 S w i t c h Node 1 F a i l u r e { m q t t =<[ p i b r o k e r :
node1 / l w t : s t a t e : d e f a u l t ] }
The Node Detection functionality comes with a disadvan-
tage. The functionality utilizes the LWT packets of MQTT.

The Broker will release the LWT message only when an
acknowledgement message from the client is not received in
the predetermined time. This predetermined time is called
Keep Alive Time. The Broker pings the node after Keep Alive
Time interval is finished. If Broker receives acknowledgement
it refreshes the Timer else it considers the node Collapsed.
As it can be seen, the node detection functionality works
mainly on the Keep Alive Time which is provided by node
upon initial connection. To make the detection instantaneous,
the node must be pinged at relatively small time intervals
which increases the Overhead Packets corresponding to Ping
Acknowledgment. This will increase network traffic, occupy
additional computational resources and increase power con-
sumption in WiFi nodes. Thus the Time Interval for node
detection must be carefully calculated to keep a balance
between the power efficiency of WiFi nodes and the node
failure detection time.
E. Remote Access
The final part of the Home Automation System (HAS) is to
make the system accessible over Internet. Most connections to
the internet are through a dynamic external IP address which
changes quite often (mostly daily). This makes it difficult for
the UI applications to track the HAS server. To resolve the
issue, the system needs static external IP address configuration.
But for the experimental setup, an alternative access method is
implemented. To avoid the need for static external IP address,
the dynamic DNS service is utilized. In this method, a public
DNS service provider such as Duck DNS provides user a
subdomain and a script. The subdomain points directly to the
IP address of the HAS. The provided script needs to installed
in the Raspbian OS which periodically updates the subdomain
IP address with the external IP of the HAS. This makes the
system accessible over internet with the URL of subdomain.
In case the IP address of HAS is changed, within few minutes
the subdomain link will autoupdate, thereby making the system
re-accessible.
Apart from the static IP address, the local gateway router
needs to be configured to allow external access to the HAS
server. OpenHAB server works on 8080 port, hence the router
must be configured to enable port forwarding on 8080 for the
internal IP address of the Raspberry Pi.
IV. C ONCLUSION AND F UTURE W ORK
This paper described architecture and implementation of
home automation system. The proposed idea is to utilize
nodes as an alternative to regular Switch boards in traditional
home, thereby effectively converting it into Smart Home.
The implemented system uses basic electronic development
boards to minimize the system development cost. The cost-
effectiveness of the system can be justified by cost estimation
as shown in the Table I; for the sake of comparision, costing
of battery and relays are neglected. Although the total costing
will vary depending on the number of nodes (n), the basic
costing of the developed system is less than $60. The overall
Developed System Alternative System
Components Cost Components Cost
Raspberry Pi 2 $35 Beaglebone Black $55
8GB SD Card $3 Xbee Breakout Board $2*n
ESP8266 $4*n Xbee Modules $15*n
Total Cost $38+$4*n Total Cost $57+$17*n
TABLE I: Comparison of Home Automation Systems
costing can be further reduced by using low-cost alternatives
of Raspberry Pi such as Orange Pi.
Apart from the low cost, the smartness of the automation
system can be justified with the automation scripts that can
be customized by the user, even at runtime. Also, introduction
of additional wireless node in the system can be easily done
with a little change in the UI configuration, making the whole
system flexible as well as scalable. The complete system
efficiently utilizes the existing network infrastructure with
the help of MQTT protocol. The test results shows that the
overall delay between request and response time from UI to
Node is less than 600 milliseconds in the local network (with
two intermediate routers), making the system interaction time
acceptably low.
The ESP8266 WiFi module only provides a single analog
input, which creates difficulty in interfacing multiple analog
sensors. The issue can be resolved by integrating a separate
Analog IO Expander circuit with the WiFi module. Presently
the wireless nodes can only communicate with Raspberry Pi
using an intermediate router. Further research is required to
make an adhoc network of wireless nodes and remove the
dependency of the router. Additional research will be needed
to relay the MQTT packets over that adhoc network.
ACKNOWLEDGMENT
The authors would like to thank Tuan PM for providing the
MQTT Client library for ESP8266 SoC, which helped authors
to implement MQTT protocol in ESP8266 nodes.
R EFERENCES
[1] S. Folea, D. Bordencea, C. Hotea And H. Valean, Smart home automa-
tion system using Wi-Fi low power devices, Automation Quality and
Testing Robotics (AQTR), 2012 IEEE International Conference, Issue
Date: 24-27 May 2012
[2] D. Culler, D. Estrin, And M. Srivastava, Overview Of Sensor Networks,
IEEE Computer Magaziner, Pp. 4149, 2004.
[3] V. Karagiannis, P. Chatzimisios, F. Vzquez-Gallego, J. Alonso-Zarate,
A Survey on Application Layer Protocols for the Internet of Things, a
Transaction on IoT and Cloud Computing, Vol. 1, 2015.
[4] http://espressif.com/en/products/esp8266/
[5] Kelly, ESP8266 Power Consumption, 2015. [Online] Available:
http://bbs.espressif.com/viewtopic.php?t=133
[6] ESPRESSIF Team, ESPRESSIF ESP8266 SDK Release Web Page,
2015. [Online] Available: http://espressif.com/new-sdk-release
[7] N. Kolban, Kolbans Book on ESP8266, an introductory book on
ESP8266, 2015.
[8] Tuan PM, Native MQTT client library for ESP8266, 2015. [Online]
Available: http://tuanpm.net/native-mqtt-client-library-for-esp8266/
[9] K. Kreuzer, Wiki page for OpenHAB, 2015. [Online] Available:
https://github.com/openhab/openhab/wiki
[10] OpenHAB Developers, OpenHAB packages available for
Download, 2015. [Online] Available: http://www.openhab.org/getting-
started/downloads.html