1
Abstract —This paper describes a low cost and flexible home automation system that can be programmed and controlled remotely. Even though for the devices integration we have used the Modbus protocol, the system is flexible enough to easily include new devices with other interfaces such as the popular X10. The central control system is developed using the robotic programming environment RIDE that allows defining, monitoring and debugging tasks modeled as Petri nets. The variety of devices that are needed to include in mobile robot projects comes handy to use RIDE tools in the domotic domain in order to build an open system to integrate different kinds of devices.
While running, the execution of tasks can be easily monitored watching the evolution of the different Petri nets. Besides monitoring, the system can be instrumented to log state changes at different levels of detail.
Index Terms —Home automation system,
Modbus, Petri nets, remote control system.
I. I NTRODUCTION
H OME automation, also known as
Building Automation systems (BAS) can be many different things and it can be
applied at different levels [1]. It might range
from a simple control remote to turn on/off different switches such as lights to complex sequences of actions that might define different environments in the living room of our house.
Joaqu´ın L´opez and Enrique Paz are with the University of Vigo.
E-mail: joaquin@uvigo.es, epaz@uvigo.es
Diego P´erez Losada is with AIMEN Technology
Centre.
E-mail: diego.perez@aimen.es
Imagine a remote control with a set of buttons to change the look of your living room. If you want to enjoy the latest movie with your family or friends you press the theatre button and the living room turns into a theatre : main lights come off while the
LED lighting around the room comes on and the blinders lower down; a screen rolls down, the thermostat sets the temperature to the perfect environment while the projector at the back of the room starts the movie.
Imagine at the end of the movie you want to have dinner with your family or friends in the other side of the living room, so you press the dinner button to turn the living room into a dinner room: the lights on top of the dinner table come on while the LED lights come off, the screen rolls up, etc.
This is just one example of the hundreds of systems that can be installed, programmed and managed. However, different users would like different configurations for a theatre environment and therefore the system needs to be very flexible and easy to reconfigure, in order to be adapted for each
user demands. Fig. 1 shows a few examples
of features that can be included in the home automation system such as:
• Lighting.
Lighting systems can be programmed to switch off in certain lighting conditions (natural light is adequate), reducing lighting costs. Alternatively, lights can be set to switch on automatically when one person enters a room, making the home safer and

2
•
•
• also reducing power consumption. In addition, lighting can be set to create different environments as mentioned before.
Intelligent Climate Control.
Heating and air conditioning can be set to certain levels based on different parameters, such as expected and actual occupancy, the weather forecast, the inside temperature or, if a window or exterior door is left open. These systems can also be controlled remotely. This is a great savings mechanism, reducing the amount of electricity wasted on unnecessary cooling or heating, ensures at the same time that the house is at the right temperature at all times.
Security Systems.
Security systems can also be automated and integrated with other house devices. Systems respond to voice and biometric data, and locks can be upgraded to keypads that are opened with codes or swipe cards. These systems can also be turned on or off remotely. Besides, while we are on vacation we can see images of the cameras, receive messages from our house and activate alarms if necessary.
Home Entertainment.
Automated home entertainment systems allow the users to pre-set favourite settings, remove the need for multiple remotes and listen to music, news, or podcasts anywhere in the house.
Most systems can be tailored by a custom electronics professional to provide all the benefits desired by the users. However, there are some key features that will make the programmer’s job easier and the interaction with the home automation system more enjoyable.
The main features are:
•
Interoperability.
All the diverse electronic devices must be integrated and centralized, so they can perform as one unified system. In order to be able to connect all the different devices, the central control system has to be
•
•
•
•
• open and able to communicate with all the sensors and actuators. Even though some standards have been adopted, special care has to be taken when buying new devices in order to be able to interact with the home automation system.
Remote access.
Being able to communicate remotely with the home automation system is one of the most celebrated features. Remote access capabilities allow the home owner to monitor the home’s environment and also alter the settings of the lights, thermostats and other gear if necessary all, from a laptop, personal computer, cellphone or any mobile device.
Scalability.
Technology will continue to evolve, introducing new generations of products to the marketplace.
Flexibility.
Automation is only beneficial and practical if it fits the home owner’s lifestyle. Since everyone’s lifestyle is different, the manufacturer should provide its installers with the tools to customize the system to user’s specific needs. This goes both for the installer and the manufacturer.
The manufacturer should provide flexible programming tools for the installer to design and adapt each automation system to the user’s needs.
Robustness.
The system should be able to deal with the most common problems such as when the power on the house goes down. For this case, the automation system should have the appropriate back-up protection.
Power Saving.
Automation systems can help save energy by turning off elec-
tronics devices automatically [2].
A recent example of the interest in this field is the purchase of Nest Labs by Google.
There are numerous tendencies to integrate various kinds of embedded devices and con-
sumer appliances into software systems [3].
Most of them are functional only for subproducts within the brand that sells the system as a whole, but some are compatible

3
Fig. 1. A few examples of features that can be included in the home automation system.
might connect to the cloud (some corporate server on the web). The benefit of IOT devices in the home is that they allow you to control and monitor your home system from anywhere through your iPhone or any other mobile device or computer connected to the internet.
The rest of this paper is organized as follows: the next section introduces the system. Section III shows the architecture and describes the main elements of the BAS.
Section IV describes the executive layer for task definition and monitoring. Tools for debugging the home automation system are shown in section V. Finally, section VI presents the results and concludes the paper.
with other existing standard technologies like
X10, KNX, Insteon, Z-wave, etc.
There are many solutions similar to the one presented here. One of the most similar
solutions is presented in [2] that consists of a
house network (sensors and appliance actuators to respectively get information from and control the house environment). As a central controller, they used an Arduino microcontroller that communicates with an Android application. In our case we pretend to use more internet based connections.
One of the most popular computer opensource software for general Home Automation applications is MisterHouse, which is customizable, very flexible and compatible
with most technologies [4]. However, it is
very geeky and some programming knowledge is needed to manage it and it has to be written in Perl. On the other side, tools
like Node-RED
1
allow for wiring together hardware devices, APIs and online services in new and interesting ways. In its simplest form, Node-Red is an open source visual editor for wiring the internet of things produced by IBM. The wiring can be programmed with a flowchart in a very simple way. However, the flowchart is a data-flow oriented instead of a event sequence oriented like the one we propose here.
The popular Internet of Things or IOT can be seen as a way of saying that devices in the home are connected via the Internet. Most of these devices connect directly to each other or through the router. However, other devices
1 http://nodered.org/
II. O VERVIEW
The connections between different ele-
ments in the BAS are shown in Fig. 2.
Sensors and actuators positioned throughout the building are connected to the central unit that controls and monitors the edifice state.
The classic BAS is connected to a computer
(Central server) that registers all the events produced by the different sensors. In our case, all these devices are connected via
Modbus using the building’s local network
(Ethernet).
The central server is a computer running the main control programs. We are currently using the operating system GNU Linux on the central computer, but all the programs were programmed in Java and can be executed in other operating systems. So far they have been already executed on GNU Linux and Windows.
All the devices exchange information with the central server using the building wired
Ethernet network. For the remote devices with difficult access, a WIFI connection might be used. The user GUIs can connect to the Central server and monitor the state of devices and tasks, or change the state of devices, start tasks, stop tasks and change parameters, such as scheduler’s times.

4
Fig. 2.
Overview of the home automation system.
III. C ONTROL A RCHITECTURE
Fig. 3 shows the different processes and
their connections. Those programs are executed in the central server with the exception of the users GUIs that might be executed in mobile devices such as a smart phone or any type of computer.
The yellow background boxes together with JCentral represent the programs required to be running all the time to control the system. Blue background boxes represent different graphical user interfaces, to configure the application (Task editor and Param editor), monitor the execution or interact with the system.
Fig. 3. Software control architecture. Each module is a different program. Blue background modules are GUIs and yellow blocks are Control Programs.
Each program on the RIDE architec-
ture Fig. 3 exchanges information with
other modules using JIPC [5] [6]. Devel-
oped for multirobot applications, JIPC provides, among others features, a publicationsubscription model. A JIPC-based system consists of an application independent JCentral server and a number of applicationspecific processes. Each process connects with JCentral and specifies what types of messages it publishes and what types it listens for. Any message that is passed to
JCentral is immediately copied to all other processes subscribed to it. The framework implemented here uses JIPC in centralizedrouted mode. For this mode, JIPC provides:
•
•
JCentral server.
JIPC uses an application-independent central server module to maintain system-wide information and to route and log message traffic. Before starting any module, a program named JCentral must first be started. The most basic service provided by JCentral is the message passing. A message sent from any module connected to the server will be forwarded by the server to the modules containing handlers for the message.
JIPC interface class. This class includes functions to connect to JCentral, subscribe to messages and register message handlers. These functions take care of opening sockets, registering messages, and sending and receiving messages.
The JIPC library contains functions to serialize and de-serialize data, invoke user-defined handlers when a message is received, and invoke user-defined callbacks at set intervals.
Among the advantages of using this framework, we can include some of the features mentioned above:
• Platform-independent: All the modules are fully developed in Java. Therefore they can be executed in a wide set of devices (Windows, GNU Linux, Android, iOS). On the other side, the Web User
Interface is, for most of the applications, a Java applet in a web page that

5
•
•
• can be started from any web browser.
This facilitates the remote access, expandability and flexibility features described in the introduction.
Modular: The simple publish/subscribe
JIPC mechanism allows the integration of any kind of module that can be connected and disconnected at will. For example, a new kind of camera can be connected using the same kind of messages.
Access control: According to Fig. 2,
any user can try to monitor and send commands to the home automation system. However, for this kind of application this cannot be allowed. When the Web user interface starts, the user needs to be identified. Afterwards, all the commands he sends are checked by the JCentral referee for privileges. In a similar way, subscription to different resources (view camera, robot position, etc) must be approved by the JCentral referee.
Polling mechanism: In order to use the user interfaces behind NAT mechanisms and to solve the private/public connectivity problem.
A. Central Server
The central server is in charge of the coordination of the Modbus modules for the execution of different tasks. Any kind of device with an Operating System (linux, windows, android, ...) that supports JAVA can be used, such as a PC, raspberry PI,
... There are three modules running on the central server:
•
•
JParams.
This module loads the project parameters from an XML file. The parameters to be defined might include a
CAD map of the building, used by the
GUI to present in a more intuitive way the position of the different devices.
JDispatch.
The tasks are executed by this program that loads the Petri nets from the XML definition file. Then
• it interprets the Petri net, executing the commands according to the current marking and subscribes to events that might evolve the loaded Petri nets.
BuildingInterface.
The communications with all the building devices are managed by this module.
Fig. 4.
Software control architecture used for simulation.
The home automation system can de designed and programmed while the building is under construction, thanks to some simulation tools and utilities. The framework in
this case is shown in Fig. 4 where most of
the modules are the same as in the control
framework (Fig. 3). The module
BuildingInterface is changed for the BuildingInterface simulator and a new module ( EventSim ) is added.
BuildingInterface simulator publishes and subscribes to the same messages as the
BuildingInterface module, so all the other modules should not realize the different between the simulation and the real system.
The EventSim module loads a simulation parameter file that includes the times of some events to occur and the duration of the actions to be simulated.
B. Device Integration
On this first approach we use the Modbus protocol over ethernet to communicate the central server with all the satellite modules
(arduino, ...). In order to build a low cost system, we use an Arduino with Ethernet as

6
Modbus interface (Fig. 5). The core is based
on a low cost Arduino board with an ATmega328 microcontroller, Ethernet communications and 14 configurable inputs and outputs (4 of them provide PWM output). Those cores are intended to communicate with the
BuildingInterface module using the ModBus protocol over Ethernet, so the software in the upper layers could be used with other industrial solutions without any change, or it even could be used with Arduino core modules and industrial solutions together.
In order to connect the devices to the home automation system, the most basic approach is to use a direct connection of the devices
to the microcontroller, like in [7].
Fig. 6.
Hardware interface.
the current in the maximum allowed value.
The hardware interface also contains a 5-24V
DC-DC power source that could be used to feed the control board, with a standard USB output up to 10W.
Any new device connected to the home automation system can be directly included in the tasks according to the framework defined in the next section.
Fig. 5.
Arduino with Ethernet used as Modbus interface.
The Arduino board is built in 5V DC TTL technology and most of domotic commercial devices have a 24V DC power bus. To adapt the electrical levels between the signals core board and the domotic devices, a hardware interface was designed. This interface is designed to be mounted in DIN rail and contains 12 inputs and 4 outputs, providing electrical isolation between the control architecture and the sensors or actuators.
The Fig. 6 shows the signals interface. The
inputs are type 2 in IEC61131-2 and the outputs could be used for fast switching, as they are transistor outputs with a current up to
150mA and shortcut protection. The shortcut protection avoids the output transistors to be overloaded, decreasing the voltage to keep
IV. D EFINING , E XECUTING AND
M ONITORING T ASKS
Petri nets have been widely used to model, design, execute and evaluate tasks in dy-
namic manufacturing systems [8]. In this
work we use hierarchical binary interpreted
Petri nets to model the desired behavior of our house. With Petri nets it is possible to define any sequence of actions included in a task.
As a simple example, the Fig. 7 shows
the Petri net that can be used for the simulate people home task. There is only one initial mark in the place labeled P0, while there is no final place. In general, a task ends when only the final places are marked or when there are no marks on the Petri net, if no final places have been defined. In this

7 case, the task runs continuously until it is cancelled by the user.
First transition ( wake-up schedule ) is fired according to the times of the wake up schedule. In this case two places become marked: the lights sequence is another petri net that turns the lights on following a similar sequence as a person wakes up, goes to the bathroom, etc. The roll-up blinds starts another Petri net that rolls up some blinds in a predefined sequence. Both actions will run at the same time. The condition associated to transition T1 is that the light sequence petri net would finish. In a similar way, the condition associate to T2 is that the rollup blinds Petri net would finish. When both finish, it will wait for the sleep time schedule.
When the sleep time schedule becomes active, another couple of parallel actions start.
This time the actions aim to simulate the actions carried out for a person when goes to bed. In this simple example the parallel sequences aims to roll down the blinds and turn off the lights. Similar sequences can be defined for every home automation task such as programming the garden irrigation system, changing environments on the living room, programming the heating system.
Even though they are not included in
Fig. 7, different Petri net mechanisms, such
as timers, can be added to deal with some common problems.
In editor mode, the user can create new tasks using a simple and intuitive Petri net
graphical editor. Fig.8 shows the GUI while
editing the task on Fig. 7. The Petri net
structure is created by selecting, dragging and dropping the different elements: places, transitions, arcs and marks. Then the actions
(associated to places and transitions) and conditions (associated to transitions) must be defined.
Actions can be commands implemented in any module in the control architecture
represented in Fig. 2. These commands can
be selected from a menu list, automatically generated by the GUI. Each command is a message and the user must define the
Fig. 7.
Petri net that simulates the presence of people at home.
command parameters that will automatically appear in a new window when that command is selected in the editor. The basic commands are messages that can be sent to the building interface module to activate or deactivate the home devices.
When dispatch executes the Petri net, the messages assigned to places and transitions will be published as the net progresses. Also available are some special commands, such as start and stop another task (Petri net) or start a timer.
Conditions can be events produced by any
module represented in Fig. 2. These events
are selected from the menu list generated automatically by the GUI. An event can be the simple arrival of a message, a condition on some message parameter or any logical expression on several parameters over the same or different messages. RoboGraph GUI allows any logical expression to be defined over the message fields. However, complex conditions over message fields are sometimes more naturally expressed using other

8
Fig. 8.
RoboGraph GUI editing a Petri net that simulates the presence of people at home.
When starting, dispatch subscribes to the task execution or cancellation requests. The execution of a new task starts loading the interpreted Petri net from a PNML file (Petri net markup language). Then the dispatch subscribes to all the messages referenced in the events. Finally the initial marking is set and the actions associated to the marked places are executed. The Petri net can only progress with the arrival of messages or the end of a timer.
Each time a change in the status of a Petri net (start, stop, evolve) or in the waiting queues (new requests added or removed) is produced, a new message reporting that change is issued for monitoring and stored in the log file for off-line debugging.
programming languages. For these cases, a
Java-like editor is also integrated in the Petri net editor to program conditions and actions associated to places and transitions.
Timers are a tool widely used in automation that comes in very handy here. In addition, in our applications, we have also used them as an error detection mechanism in order to time some actions of different modules. Actions can start a timer while conditions can test the value of a timer.
Schedulers allow for the definition of time points or intervals where we want to do some specific actions. Most schedulers are associated to transitions that will be fired when the scheduler enters one of its points or intervals.
Global variables are used to get starting data and store information to share conditions and events in different places and/or transitions.
Fig. 9.
Petri net debugger main window.
V. D EBUGGING AND M ONITORING
The dispatch module schedules the different home device actions and executive actions (other Petri nets), as well as the synchronization with the produced events.
The interaction with other control units in the architecture is performed by publishing and subscribing to JIPC messages. This way, local problems in a control unit, such as a deadlock, do not block dispatch .
The RoboGraph Editor module in monitor mode subscribes to different dispatch messages that show the status of the different running or waiting Petri nets. Every running
Petri net is shown in a different tab with the
current marking as in Fig. 9. When
dispatch evolves a Petri net marking, a new message is issued and the debugger will update the monitor tabs. Therefore, using the monitor we can see the status of the system in a snapshot, since the marking of the running
Petri nets represents its status. This is a very helpful tool when debugging an application.
An information window with the queued tasks (Petri nets) and messages can also be

9
displayed on the left tabbed panel of Fig. 9.
Petri nets, together with the messages received and published to the different control units, can be logged at different levels of detail. The system administrator can then run the RoboGraph Editor module in the playlogger mode, open the log file and play it at the same pace as in the real execution.
Different tabs with the running Petri nets will be shown as in monitor mode. Besides the regular play option, the user can monitor the log file step by step. It can also jump to a defined place in execution as do many commercial programming development environments (C, Java, C++, etc.). Finally, the user can see different details about the JIPC messages.
VI. R ESULTS AND C ONCLUSIONS
The main contribution of this paper is to present a Home automation system using tools based on the Robotics Integrated Development Environment (RIDE), emphasizing the advantages of using it in the design, implementation and maintenance. RIDE has been used to develop different applications
based in mobile robots [9] [10], sharing some
characteristics and features with the home automation problem.
First, it is an open system since different kind of devices can be easily integrated.
Technology will continue to evolve, introducing new generations of products to the marketplace and it is very difficult to predict the interface for the future devices. However, the trend is that most of the new devices will provide some kind of connection to internet
(Internet Of Things) or at least the device can be connected through an internet adapter.
In this paper a Modbus interface was used but IOT devices could be connected directly and there are gateways from most of other networks to internet.
Second, a flexible task programming based on Petri Nets tool named RoboGraph is proposed. RoboGraph is a general tool that has also been applied in mobile robots task
programming and debugging [11]. Besides
task programming, RoboGraph can be used for model checking to gain insight into the behavior and properties of the modeled system and monitoring. Monitoring the system using Petri nets is very helpful since it is possible to see the status of the system in a snapshot because the marking of the running Petri nets represents its status. Another feature of RoboGraph is the capability of analyze the data logged during execution.
A visual interface is used to present the evolution of the Petri nets.
The system has been tested on a prototype model with several sensors and actuators
(Fig. 10). For the prototype, a few Modbus
modules (Schneider OTB 1E0DM9LP) with an analogic input module (TWD AMI2LT)
as the one shown in Fig. 10 were installed.
Each Modbus module includes several inputs connected to buttons and a temperature sensor and outputs connected to LEDs and a
Peltier cell through a relay. We have used a set of eight modules connected to the central building automation system and created tasks to control the temperature of the Peltier cells and the LED lights according to the state of buttons, emulating some sensors on the building.
Fig. 10.
One Modbus module used to test the transactions between building devices and the central control system.
We have also developed our own Modbus
interfaces with the popular Arduino. Fig. 5 and Fig. 6 show the hardware module with
Ethernet used to build the Modbus modules and the I/O interfaces connected to the Arduino.
The user interfaces manage the interac-

10 tions with the users, allowing them to monitor the house devices. The main window of
a user GUI is shown in the Fig. 11.
Our next future work is aimed to create new behaviours and to increment the number of devices our system is able to talk to. For example, integrating interfaces to talk to X10 deices (CM11 and CM17 interfaces)
Fig. 11.
GUI with nodes that represent device positions.
R EFERENCES
[1] C. Gomez and J. Paradells, “Wireless home automation networks: A survey of architectures and technologies,” Communications Magazine, IEEE , vol. 48, pp. 92–101, June 2010.
[2] K. Baraka, M. Ghobril, S. Malek, R. Kanj, and A. Kayssi, “Low cost arduino/android-based energy-efficient home automation system with smart task scheduling,” in Computational Intelligence, Communication Systems and Networks
(CICSyN), 2013 Fifth International Conference on , pp. 296–301, June 2013.
[3] P. Rigole, Y. Berbers, and T. Holvoet, “A upnp software gateway towards eib home automation,” in IASTED International Conference on Computer
Science and Technology , pp. 253–258, 2003.
[4] “Misterhouse it knows http://misterhouse.sourceforge.net/.
kung-fu.”
[5] J. L´opez, D. P´erez, and E. Zalama, “A framework for building mobile single and multi-robot applications,” Robotics and Autonomous Systems , vol. 59, pp. 151 – 162, March 2011.
[6] “Robotics integrated development environment
(ride).” http:/webs.uvigo.es/vigobot.
[7] A. ElShafee and K. A. Hamed, “Design and implementation of a wifi based home automation system,” vol. 6, no. 8, pp. 1856 – 1862, 2012.
[8] “Petri net world web page.
petri nets tools database.” http://www.informatik.unihamburg.de/TGI/PetriNets/tools/quick.html.
[9] J. Fernandez, D. Losada, and R. Sanz, “Enhancing building security systems with autonomous robots,” in Technologies for Practical Robot Applications, 2008. TePRA 2008. IEEE International
Conference on , pp. 19–24, Nov 2008.
[10] J. L´opez, D. P´erez, E. Zalama, and J. Garc´ıa-
Bermejo, “Bellbot - a hotel assistant system using mobile robots,” International Journal of Advanced
Robotic Systems , vol. 10, 2012.
[11] J. Fernandez, R. Sanz, E. Paz, and C. Alonso,
“Using hierarchical binary petri nets to build robust mobile robot applications: Robograph,” in
Robotics and Automation, 2008. ICRA 2008. IEEE
International Conference on , pp. 1372–1377, May
2008.