PROTÓTIPODESISTEMADEAUTOMAÇÃORESIDENCIALMODULAR...

PROTÓTIPO DE SISTEMA DE AUTOMAÇÃO RESIDENCIAL MODULARDE BAIXO CUSTO COM INTERFACE WEB UTILIZANDO SOFTWARES DE

CÓDIGO ABERTO

Leonardo dos Santos Teixeira de Souza

Projeto de Graduação apresentado ao Cursode Engenharia de Computação e Informaçãoda Escola Politécnica, Universidade Federaldo Rio de Janeiro, como parte dos requisitosnecessários à obtenção do título de Engenheiro.

Orientador: Fernando Gil Vianna ResendeJunior

Rio de JaneiroSetembro de 2017


CÓDIGO ABERTO


PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DOCURSO DE ENGENHARIA DE COMPUTAÇÃO E INFORMAÇÃO DA ESCOLAPOLITÉCNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMOPARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAUDE ENGENHEIRO DE COMPUTAÇÃO E INFORMAÇÃO.

Examinado por:

Prof. Fernando Gil Vianna Resende Junior, Ph.D.

Prof. Carla Amor Divino Moreira Delgado, D.Sc

Prof. Marcos do Couto Bezerra Cavalcanti, D.Sc

RIO DE JANEIRO, RJ – BRASILSETEMBRO DE 2017

Souza, Leonardo dos Santos Teixeira deProtótipo de Sistema de Automação Residencial

Modular de Baixo Custo com Interface Web utilizandosoftwares de código aberto/Leonardo dos Santos Teixeirade Souza. – Rio de Janeiro: UFRJ/ Escola Politécnica,2017.

XIII, 62 p. 29, 7cm.Orientador: Fernando Gil Vianna Resende JuniorProjeto de Graduação – UFRJ/ Escola Politécnica/

Curso de Engenharia de Computação e Informação, 2017.Bibliography: p. 60 – 62.I. Resende Junior, Fernando Gil Vianna. II.

Universidade Federal do Rio de Janeiro, Escola Politécnica,Curso de Engenharia de Computação e Informação. III.Título.

iii

À memória de Octavio Teixeira de Souza, pai e amigo, que me ensinou a valorizaro conhecimento, a perseverança e a hombridade.

Agradecimentos

Em primeiro lugar, agradeço a Deus por estar sempre presente e me dar ascondições necessárias à conclusão deste trabalho.

Agradeço a meus pais que sempre me apoiaram, jamais mediram esforços parame propiciar uma boa formação acadêmica e que me passaram os valores morais eéticos pelos quais norteio minha conduta. A meus amigos e familiares, que sempreestavam dispostos a me ajudar quando eu necessitava e sem os quais eu não teria amotivação necessária para seguir em frente perante as adversidades da vida.

Agradeço a meus professores que dedicaram a vida à esta nobre profissão e semos quais eu não não teria conseguido chegar onde estou.

Por fim, agradeço aos contribuintes brasileiros, que custearam minha formaçãoacadêmica na Universidade Federal do Rio de Janeiro. Com este trabalho, procurodemonstrar que vosso investimento foi bem aproveitado.

“Never let your limitations become your limit.”Unknown Author

v

Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ comoparte dos requisitos necessários para a obtenção do grau de Engenheiro deComputação e Informação.


CÓDIGO ABERTO


Setembro/2017

Orientador: Fernando Gil Vianna Resende Junior

Curso: Engenharia de Computação e Informação

A automação residencial, também conhecida como domótica, é uma área doconhecimento que vem ganhando muita popularidade nos útimos anos. As possibili-dades de aplicação das técnicas e tecnologias desenvolvidas nesta área são inúmerase variam desde simples sistemas para prover conforto e segurança aos usuários atésoluções complexas que podem revolucionar a forma que vivemos.

As maiores empresas de tecnologia do mundo (Google, Amazon, Apple, etc.)têm interesse em desenvolver produtos nesta área e a tendência é que tecnologias deautomação residencial estejam cada vez mais inseridas no quotidiano das pessoas.

O presente projeto implementa uma alternativa de baixo custo e de fácil insta-lação às soluções de automação residencial comerciais mais populares, possibilitandoo monitoramento e o controle de dispositivos e sensores através de uma interface in-tuitiva.

No projeto, foi criado um sistema cliente-servidor para automação residencialcom módulos de switch, sensor e infra-vermelho. A comunicação entre dispositivosse dá através de 433 MHz rádio frequência e a interação com o usuário aconteceexclusivamente através de uma interface web. O servidor foi implementado uti-lizando Node.js rodando em uma Raspberry Pi e todos os módulos clientes foramimplementados com código C executando em microcontroladores Attiny85.

Ao final, foi obtido um sistema de automação residencial capaz de desempenharfuncionalidades semelhantes aos produtos líderes de mercado, mas com um investi-mento aproximadamente 14 vezes menor.

Palavras-chave: Domótica, Automação Residencial, IoT.

vi

Abstract of Undergraduate Project presented to POLI/UFRJ as a partial fulfillmentof the requirements for the degree of Engineer.

PROTOTYPE OF A LOW COST MODULAR HOME AUTOMATION SYSTEMWITH WEB INTERFACE USING OPEN-SOURCE SOFTWARES


September/2017

Advisor: Fernando Gil Vianna Resende Junior

Course: Computer and Information Engineering

Home automation, also known as domotics, is an area of knowledge that has beengaining much popularity in recent years. The possibilities of applying the techniquesand technologies developed in this area are numerous and range from simple systemsto provide comfort and safety to users to complex solutions that can revolutionizethe way we live.

The largest technology companies in the world (Google, Amazon, Apple, etc.) areinterested in developing products in this area and the trend is that home automationtechnologies are increasingly inserted into people’s daily lives.

The present project implements a low cost and easy-to-install alternative to themost popular home automation commercial solutions, allowing the monitoring andcontrol of devices and sensors through an intuitive interface.

In the project, a client-server system was created for residential automationwith switch, sensor and infra-red modules. The communication between devicesoccurs through 433 MHz radio frequency and the interaction with the user happensexclusively through a web interface. The server was implemented using Node.jsrunning on a Raspberry Pi and all client modules were implemented with C coderunning on Attiny85 microcontrollers.

At the end, it was obtained a home automation system capable of performingsimilar functionalities to the leading products in the market, but with an investmentapproximately 14 times smaller.

Keywords: Domotics, Home Automation, IoT.

vii

Contents

List of Figures xi

List of Tables xiii

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 General Objective . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Specific Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Basic Concepts 62.1 Project Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Initial Ideas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Topology and user Interface . . . . . . . . . . . . . . . . . . . 7

2.2 Project Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Client-Server Architecture . . . . . . . . . . . . . . . . . . . . 82.2.2 Concurrency Control . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 JavaScript Language . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Radio Frequency . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.6 Infrared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.7 Attiny85 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.8 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.9 RF Receiver/Emitter . . . . . . . . . . . . . . . . . . . . . . . 142.2.10 LED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.11 LM35 Temperature Sensor . . . . . . . . . . . . . . . . . . . . 152.2.12 TSOP4838 Infrared Receiver . . . . . . . . . . . . . . . . . . . 172.2.13 Infrared Emitter . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.14 IRremote Library . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Linux and distributions . . . . . . . . . . . . . . . . . . . . . . . . . . 18

viii

2.3.1 Linux Operating System . . . . . . . . . . . . . . . . . . . . . 182.3.2 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.3 Raspbian (Linux distribution) . . . . . . . . . . . . . . . . . . 202.3.4 WiringPi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.5 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.6 RCSwitch Library . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 System Development 233.1 Proposed RF Communication Standard . . . . . . . . . . . . . . . . . 233.2 Shared Command Header . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Server Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.2 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3 System Data File . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.4 hhsend - the RF Communication Program . . . . . . . . . . . 303.3.5 Web Interface Dashboard . . . . . . . . . . . . . . . . . . . . . 323.3.6 Example Use Case . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Detecting New Client Modules . . . . . . . . . . . . . . . . . . . . . . 343.5 Switch Client Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5.2 Example Use Case . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6 Sensor Client Module . . . . . . . . . . . . . . . . . . . . . . . . . . 403.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.6.2 Example Use Case . . . . . . . . . . . . . . . . . . . . . . . . 40

3.7 IR Client Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.7.2 First Example Use Case - Configuring a New IR Command . . 453.7.3 Second Example Use Case - Sending an IR Command . . . . . 473.7.4 Third Example Use Case - Deleting a Configured IR Command 49

4 Results 524.1 Transmission and Functionality Testing . . . . . . . . . . . . . . . . . 524.2 Improving Communication . . . . . . . . . . . . . . . . . . . . . . . . 534.3 Comparison with Similar Market Solution . . . . . . . . . . . . . . . 54

4.3.1 General Characteristics . . . . . . . . . . . . . . . . . . . . . . 544.3.2 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.5 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ix

5 Conclusion 585.1 Suggestions for Future Work . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliography 60

x

List of Figures

1.1 Popularity of IoT related searches on Google * Source: Google Trendson 13 May 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 System Block Diagram * Source: Produced by the author . . . . . . . 82.2 Picture of an Attiny85 Microcontroller Chip * Source: br-arduino.org 122.3 Circuit used to program an Attiny85 with an Arduino Uno board *

Source: highlowtech.org . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Picture of an Arduino Uno Board * Source: Sparkfun . . . . . . . . . 142.5 Picture of a simple LED component . . . . . . . . . . . . . . . . . . . 162.6 Picture of a LM35 Temperature Sensor * Source: Texas Instruments . 162.7 Picture of an TSOP4838 infrared receiver * Source: filipeflop.com . . 172.8 Picture of an Infrared Emitter LED * Source: hbahiashop.com.br . . 182.9 Raspberry Pi 2 Model B * Source Raspberry Pi Foundation . . . . . 192.10 Raspberry Pi GPIO pin map * Source: Raspberry Pi Foundation . . 202.11 Example of RCSwitch Telegram * Source: RCSwitch Wiki . . . . . . 22

3.1 24-bit package fields * Source: Produced by the author . . . . . . . . 243.2 Basic Workflows * Source: Produced by the author . . . . . . . . . . 253.3 Server Module Block Diagram * Source: Produced by the author . . . 283.4 Server Module Circuit on a Protoboard * Source: Produced by the

author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Database Organization Level * Source: Produced by the author . . . 303.6 Detailed hhsend Workflow * Source: Produced by the author . . . . . 313.7 User Web Interface Dashboard * Source: Produced by the author . . 323.8 Switch Module Prototype Block Diagram * Source: Produced by the

author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.9 Switch Module Circuit on a Protoboard * Source: Produced by the

author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.10 Sensor Module Prototype Block Diagram * Source: Produced by the

author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

xi

3.11 Sensor Module Circuit on a Protoboard * Source: Produced by theauthor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.12 IR Module Prototype Block Diagram * Source: Produced by the author 443.13 IR Module Circuit on a Protoboard * Source: Produced by the author 44

4.1 Example of a 17 cm antenna used on all system modules * Source:Produced by the author . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Switch Client Module with 17 cm antenna on transmitter and receivercomponents * Source: Produced by the author . . . . . . . . . . . . . 54

xii

List of Tables

2.1 Specifications for the Attiny85 Chip * Source:https://static.efetividade.net/img/1005-87137.jpg * Accessed on: . . 12

2.2 Specifications on RF receivers and transmitters . . . . . . . . . . . . 142.3 LM35 Temperature Sensor Specifications . . . . . . . . . . . . . . . . 162.4 Specifications for the raspberry Pi 2 model B . . . . . . . . . . . . . . 19

3.1 Library Commands Hexadecimal Values . . . . . . . . . . . . . . . . 263.2 MTP Interaction Methods . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Modules Component Prices . . . . . . . . . . . . . . . . . . . . . . . 57

xiii

Chapter 1

Introduction

1.1 Motivation

Household appliances controlled remotely via web interface, self-regulating light

intensity and thermostats, voice-controlled doors and electrical devices, security

systems sending alarms for security personnel over mobile networks. What was

considered only science fiction decades ago is becoming popular with each passing

day.

Domotics is a science field focused on providing comfort and security through

home automation solutions, which provide better quality of life by allowing the user

to control household appliances remotely or by automatically making decisions based

on the value read at its sensors[33]. This kind of systems are used nowadays not only

to provide comfort and convenience for its users, but also to improve energy usage

efficiency [28] [32], help people with special needs or help monitoring the health of

elderly people [29].

The technology for home automation has many possibilities to deeply change

the people’s daily lifes. Big technology companies such as Google[7], Amazon[1]

and Facebook[6] are creating home automation solutions to allow them not only to

become even more present on its clients homes but also to collect a huge amount of

data about their behavior.

From the beginning of the 21st century to the present days, the demand in the

1

market for applications connected and integrated with the Internet and the web is

increasing [26][31]. It is no coincidence that commercial terms like IoT (Internet of

Things) and WoT (Web of Things) became increasingly popular since the beginning

of the decade. Figure 1.1 illustrates the popularity growth of IoT related topics

from January of 2010 to March of 2017 where the horizontal axis shows time and

the vertical axis shows the percentage of the maximum historic popularity. Despite

this scenario, the home automation applications in the market are, in majority, still

expensive or difficult to install.

Figure 1.1: Popularity of IoT related searches on GoogleSource: Google Trends on 13 May 2017

There are 2 (two) types of home automation systems: wireless and hardwired.

The first one is usually cheaper and easier to install when compared to hardwired

systems. They make use of wireless mesh network technologies, like Z-Wave, ZigBee

or Bluetooth, to implement communication between nodes and automate appliances.

Popular options in the market like the Belkin We-Mo Switch cost approximately $40

per network node. The cost of automating all house appliances remain significantly

high. Other business models which use this type of technology, like Control4 charge

approximately $100 monthly of its clients to install a complete home automation

system. There are also special appliances in the market made specially for home

automation, like Philips’ HUE light bulb, with on-line control and integration with

smartphone systems, which cost around $50 a unit and are dependent of a hub de-

2

vice. There are also plenty of options for hobbyists interested in home automation.

Technologies and projects like Arduino made building automation systems relatively

cheap. The downside is that it requires at least some basic knowledge in program-

ming and electronics for developing projects, what makes it a barrier for people not

interested in studying this field.

Hardwired home automation systems, on the other hand, usually range from

$3000 to $15000 to install. They tend to be considerably more expensive because

they are developed to become an integrated part of the house. They also tend

to be more secure once they are less vulnerable to wireless communication inter-

ception.This kind of system, however, needs specialized personnel to install and

configure, preventing customers from acquiring plug-and-play devices and installing

the system themselves.

Looking at this scenario, it it is possible to say that the market has limited

options for a low-cost, easy to install home automation system. This project brings

a functional prototype of a modular home automation system focusing on reduced

operation and component costs, efficiency in processing power needs, compatibility

with most of common household appliances and ease of system set-up.

Because the project has focus on developing a low-cost solution, the hardwired

system option was discarded. For the construction of the project, it was developed

a client-server system with communication through 433 MHz radio frequency. The

server was implemented with Node.js running on a Raspberry Pi exchanging mes-

sages with several client modules implemented with Attiny85 microcontrollers, using

a communication standard developed specifically for this system.

The work originated a solution for residential automation capable of executing

the same functionalities of the market leaders, but with a considerably smaller in-

vestment needed.

3

1.2 Objectives

1.2.1 General Objective

The objective of this work is to build a modular prototype for home automation

using low-cost components and techniques, exposing household appliances and sen-

sors to the user through an intuitive web interface. The prototype also needs to be

implemented using only open-source softwares.

1.2.2 Specific Objectives

• Propose a communication standard for supported devices

• Implement communication between devices through wireless low-cost technol-

ogy

• Design a server device to act as a centralized communication intermediary

between the user and controlled devices

• Design client modules capable of controlling household appliances when re-

quested by the user

• Build an intuitive user web interface

• Allow expansion of system functionalities

1.3 Organization

The present document is organized in the following manner:

1. Chapter 1: Motivation and objectives for the project

2. Chapter 2: Theoretical background and description of components used on

the project

4

3. Chapter 3: Clarifications about decisions made through the development of

the prototype, explanations about the development process, the implemented

algorithms and the overall functionalities of the prototype

4. Chapter 4: Presentation of system test methods, results and comparison with

similar solutions on the market

5. Chapter 5: Conclusion and suggestions for future work

5

Chapter 2

Basic Concepts

2.1 Project Decisions

2.1.1 Initial Ideas

The main idea behind this project is the construction of a low-cost, easy-to-install

residential control system capable of controlling most basic household appliances.

For this, 3 types of basic modules were planned.

The first, and simplest, is the "Switch" module, which is responsible for switching

on or off a power output. This type of module is useful for controlling lamps or

remotely controlled outlets. The development of this module also sets the bases

for the construction of other more complex modules, since its simple functionality

allows to test the protocols of communication and synchrony between devices.

The second is the "Sensor" module. This is one of the most important module

types because it allows the system to obtain information from the environment so

that it can make decisions autonomously. The prototype of this module can be used

as the basis for the creation of more complex devices, connected to some actuator

that will generate a reaction on the environment.

The third, and more complex, is the infrared (IR) module. This type of module

makes it possible to control general household devices such as televisions, air condi-

tioners, sound systems, home theaters, and other remotely controlled devices, which

6

were not designed to respond to a house automation system. The idea is that the

device has sequences of commands programmed into memory to emit them when

requested by the user, thus emulating the original remote control of the devices.

In order for the system to be easy to install, it is necessary to avoid the need

to install new wiring or to carry out structural works in a residence. Therefore,

communication between the user and the devices must be performed wirelessly. The

system communication channel also needs to take into account the possible presence

of obstacles such as walls and furniture. Given these specifications, communication

through radio waves stands out as a strong candidate.

Therefore, it was decided that the communication between devices in the system

would occur through radio frequency, more specifically 433MHz, since this frequency

band is available, in Brazil, for the operation and control of low power equipment

[2].

2.1.2 Topology and user Interface

In order to communicate with the modules that control devices and sensors and

to avoid the constant establishment of new connections to individual devices, the

user must be connected to a device dedicated for this purpose.

Thus, it was decided that a new module would be planned, the "Server", re-

sponsible for receiving user commands and passing them to client modules (switch,

sensor or IR). The server must also store the system state, keeping information

about which modules are present in the network and what their individual states

are. The server is also responsible for providing interaction with the user trough an

intuitive interface.

A universal type of communication, which works on any device regardless of the

operating system or manufacturer, is the web interface. It is possible for the user

to connect to the server module and control the system through a local network or

even from another continent. In this way, it was decided that the system should be

controlled by the user through a web interface and that every command of the user

7

should be read, interpreted and passed on to client modules by the server, which

acts as a communication bridge between user and devices.

Figure 2.1 shows a block diagram representing the home automation system.

The User uses a Web Accessing Device (smartphone, tablet, personal computer,

etc.) connected to the same Network Access Point the Server Module is connected.

By doing this, the User is able to send commands directly to the Server Module

using its web interface. Then, the Server Module uses its RF Transmitter to resend

the command to the Client Module, which receives the message from the server with

its RF Receiver. The Client Module tries to execute the command with its actuator

(a sensor or LED for example) and communicates the outcome to the Server Module,

which resends the message to the User.

Figure 2.1: System Block DiagramSource: Produced by the author

2.2 Project Components

2.2.1 Client-Server Architecture

Client-Server architecture is a kind of structure for distributed systems. In this

model, the tasks are divided between the service providers, called servers, and service

8

consumers, called clients. In a normal operation, the servers wait for a connection

or request from the clients, which must initiate the communication [24].

This kind of topology is common in many distributed systems such as e-mail ser-

vices, databases and the World Wide Web. The home automation system prototype

was developed using this kind topology.

2.2.2 Concurrency Control

Concurrency control is a technique for ensuring the correct operation of different

tasks running simultaneously while sharing the same limited resource. For correct

execution, each task depends on a set of consistency rules. Consistency of a given

task might be corrupted by another task if these rules are not respected [22].

One way of ensuring task consistency is to use semaphores to control access to a

shared resource. Semaphores can be used to guarantee mutual exclusion, preventing

that more than a given number of tasks try to access the same shared at the same

time [27]

Semaphores are used by the prototype Server Module to prevent more than one

request made by the user to access the radio frequency transmission components

at the same time. Ignoring the need for mutual exclusion could result in corrupted

messages and incorrect server behavior.

2.2.3 JavaScript Language

JavaScript is a programming language developed in 1995 by Netscape Commu-

nications Corporation to allow introducing logic and creating small programs in

web pages. Originally called Livescript, JavaScript received its name after Netscape

formed a partnership with Sun Microsystems, creator of the Java programming

language. Despite its name, JavaScript is not directly related to Java [12].

Although it was developed for implementing client-side functionality on Web

pages, nowadays JavaScript can also used for different ends, like robotics [13] and

server-side utilities [15].

9

In the prototype, JavaScript was used to implement the main functionalities of

the Server Module web interface.

2.2.4 JSON

JavaScript Object Notation (JSON) is a file styling format for data exchange. It

was created to be easily understood by both humans and machines. This type of file

has ".json" extension and is nothing more than a text file with some standardized

notations. Despite the name, the JSON files can be interpreted by several other

programming languages besides JavaScript. It was used in the prototype as mean

to store relevant data about system topology and state in non-volatile memory.

2.2.5 Radio Frequency

Radio frequency (RF) is every form of wireless communication that uses electro-

magnetic waves with frequency between 3kHz and 300 GHz. By transmitting data

through radio waves, this communication is more robust to obstacles that may be

between the sender and the receiver, such as walls or furniture, when compared to

other types of electromagnetic waves, such as visible light or infrared.

For the prototype, 433MHz RF was used for communication between system

modules. This frequency was chosen because the Brazilian National Agency of

Telecommunications (ANATEL) made it available for the operation and control of

low power equipment [2]

Other wireless protocols like Bluetooth, ZigBee and Z-Wave, which follow the

standards defined by IEEE (Institute of Electrical and Electronics Engineers) for

wireless personal area networks [25], were also candidates for implementing commu-

nication between modules. Their transceiver components, however, were consider-

ably more expensive than the 433 MHz transmitter/receiver pair. For this reason,

these commercial protocols were excluded from the candidates list.

10

2.2.6 Infrared

Infrared Radiation (IR) is a kind of electromagnetic radiation between 300 GHz

and 430 THz, the red colored bottom limit of the the visible light spectrum, hence

its name. Nowadays, infrared communication is used primarily for short-range com-

munications between devices [9].

Examples of the use of infrared communications are the remote controllers for

televisions, air conditioners, home theaters and other household appliances. There

are also devices that use this type of communication to transfer data and files.

Infrared communication was used in the IR Module of the prototype, which

emulates household devices remote controllers. This way, the prototype is able to

control generic appliances such as a television or a home theater device.

2.2.7 Attiny85

The Attiny85 is a low cost microcontroller produced by Atmel. It is compatible

with Arduino code, provided the source code is ported to work with its limited

memory, processing power and number of I/O pins.

In the prototype, the Attiny85 chip is the microcontroller used in all client mod-

ules. Figure 2.2 shows a picture of an Attiny85 chip.The specifications for the

Microcontroller chip can be found on Table 2.1 [23].

11

Table 2.1: Specifications for the Attiny85 ChipSource: https://static.efetividade.net/img/1005-87137.jpg

Accessed on:

Flash 8 kB

Pin Count 8

Maximum Operating Frequency 20 MHz

CPU 8-bit AVR

Maximum I/O Pins 6

EEPROM Size 512 x 8 Bytes

RAM Size 512 x 8 Bytes

Voltage 2.7 V ∼ 5.5 V

To write compiled code on the Attiny85, it was used an Arduino Uno board con-

figured as an external programmer. The circuit used to program the microcontrollers

can be seen on Figure 2.3

Figure 2.2: Picture of an Attiny85 Microcontroller ChipSource: br-arduino.org

2.2.8 Arduino

Arduino, by itself, is not a microcontroller, but an open-source, single-board plat-

form for the development and prototyping of electronic systems. The Arduino boards

were designed using microcontrollers produced by Atmel and can programmed using

C or C++ [3].

The Arduino board comes in various versions such as Uno, Leonardo, Mega,

Nano and others. Each one of them has different price and computational power.

12

Figure 2.3: Circuit used to program an Attiny85 with an Arduino Uno boardSource: highlowtech.org

However, as the project is open-source, there are many independent clones of the

Arduino boards on the market presenting a wide range of capabilities, features and

prices.

The Arduino project was created to provide enthusiasts a relatively cheap and

simple to program platform to help them develop electronic projects. Figure 2.4

shows an Arduino Uno Board.

The Arduino platform was not directly used to build the prototype, but its

compilers were important to program the Attiny85 microcontrollers.

13

Figure 2.4: Picture of an Arduino Uno BoardSource: Sparkfun

2.2.9 RF Receiver/Emitter

The FS1000A transmitter and the C218D001C radio frequency receiver are low-

cost components for performing wireless communication between devices. Generally,

these systems are coupled (receiver and transmitter) for the approximate price of $2.

This component is used by all modules in the prototype for communicating through

433MHz radio frequency.

Depending on the voltage with which the component is powered, its range can

reach up to 200m in optimal conditions. Table 2.2 shows the technical specifications

of the components.

Table 2.2: Specifications on RF receivers and transmitters

Transmitter Receiver

Operation Voltage 3.5 ∼ 12V DC Operation Voltage 5V DC

Operation Range 20 - 200 m (varies with voltage) Operation Current 4 mA

Frequency 433 MHz Frequency 433 MHz

Operation Mode AM Sensibility -105 dB

Transfer Rate 4 KB/s

For the receiver/transmitter pair to work effectively, it is recommended that

antennas are installed on the components. For this reason, 17 cm antennas were

14

installed on each of the transmitters and receivers of the prototype. To calculate the

minimum antenna size, it is necessary first to calculate the transmission wavelength,

which is given by the formula:

λ =c

f

Where λ is the wave length of the transmitted wave, c is the speed of light on

vacuum and f is the frequency of the transmitted wave. Approximating the speed

of light as c = 3.0 × 108 m/s substituting the value for the frequency as f = 433

MHz:

λ =3.0× 108

433× 106≈ 0.6928m

The antenna length may be of approximately 14of the wavelength. This way, the

length found for the antennas in the components is:

length =λ

4=

0.6928

4≈ 0.1732m

According to the calculations, it is concluded that the antennas must be at least

17 cm in size for the 433 MHz frequency.

2.2.10 LED

The Light Emiting Diode (LED) is the simplest of the components present on

the prototype. Its only purpose is to indicate the the logic level of port in a module.

On the prototype it was used to simulate a light bulb. Figure 2.5 shows a typical

LED component.

2.2.11 LM35 Temperature Sensor

The LM35 is a low cost temperature resistive sensor (approximately $ 2.00 per

unit). The component resistance varies according to ambient temperature. The

15

Figure 2.5: Picture of a simple LED component

sensor is calibrated so that the variation of the output voltage of the component is

linearly proportional to the temperature variation in Ceusius. The sensor offers an

accuracy of ±0.25oC at room temperature and ±0.75oC when operating in the range

of −55 to +150oC. In the prototype, this component is used as the main sensor

for the Sensor Module. Table 2.3 shows LM35 sensor specifications [34]. Figure 2.6

shows a LM35 sensor.

Table 2.3: LM35 Temperature Sensor Specifications

Calibration Celsius

Linear Scale Factor 10.0 mV/ºC

Accuracy 0.5ºC at 25ºC

Measurement Range -55 ∼ +150 ºC

Operational Voltage 4 ∼ 30 V

Operational Current >60 µA

Figure 2.6: Picture of a LM35 Temperature SensorSource: Texas Instruments

16

2.2.12 TSOP4838 Infrared Receiver

The TSOP4838 is a small component used as an infrared (IR) signal receiver.

The signal received is demodulated and can be read directly by the microcontroller.

In the system, this component is used for reading IR signals sent for a specific

module. This component is used by the IR Module to be able to read new IR

commands.

Details on the use of the signals received by this component can be found on

section 3.7. Figure 2.7 shows a TSOP4838 IR receiver.

Figure 2.7: Picture of an TSOP4838 infrared receiverSource: filipeflop.com

2.2.13 Infrared Emitter

For emitting infrared signals, it is used a special kind of LED. Instead of visible

light spectrum electromagnetic waves, it emits infrared radiation. The functionali-

ties and behavior are exactly the same as its visible spectrum emitter counterpart.

On the prototype, it is used to send infrared signals to household devices emulating

their factory default remote controllers. Figure 2.8 shows an infrared LED.

2.2.14 IRremote Library

IRremote [10] is a library, compatible with the Arduino platform, to enable

sending and receiving IR signals. It includes several IR communication protocols,

making it compatible with a wide selection of remotely controlled devices. The

17

Figure 2.8: Picture of an Infrared Emitter LEDSource: hbahiashop.com.br

large number of preprogrammed protocols, however, makes the library heavy and

memory-demanding. To circumvent this, it is necessary to disable protocols that

will not be used during system operation [11].

In the prototype, this library is responsible for sending and receiving all IR

commands. Details about its application can be seen on section 3.7

2.3 Linux and distributions

2.3.1 Linux Operating System

Created on 1991 by Linus Torvalds, Linux [14] is an open-source Operating

System (OS) based on an older OS called UNIX. The system, released under GNU

GPL license, has gained popularity and is now one of the most used OS’s in the

world, being used not only on personal computer but also mobile devices, satellites,

supercomputers, television devices, web servers and many others.

As the system is free and open-source, there are many different distributions

developed by independent organizations or companies. One of the most consolidated

distributions is Debian, produced by the Debian Project [4], which is the base for

many other distributions such as Ubuntu and Mint.

Other notable Linux-based Operating Systems include Android (for mobile de-

vices), Fedora, Redhat Linux, Suse and others. The Server Module runs a Linux-

Based Operating System called Raspbian.

18

2.3.2 Raspberry Pi

Raspberry Pi is a low-cost computer produced by the Raspberry Pi Foundation

[20] at the United Kingdom aiming to promote the teaching of Computer Science

on schools. It comes in different versions with prices ranging from $5 to $35. The

Raspberry Pi is the main hardware component of the Server Module.

Because of its small size, low cost and decent computational power, Raspberry

Pi became popular among enthusiasts and businesses alike for building home au-

tomation projects or smart devices. Figure 2.9 shows a Raspberry Pi 2 Model B.

Figure 2.9: Raspberry Pi 2 Model BSource Raspberry Pi Foundation

For building the prototype, it was used the Raspberry Pi 2 model B. This model

costs approcimatelly $35 but it is compatible with cheaper models like the Raspberry

Pi Zero of about $5. Direct communication with other devices is done using its 40

available General Purpose I/O (GPIO) pins. Table 2.4 shows hardware specifications

for the model used on the project [19]. Figure 2.10 shows a map for the GPIO pins

Table 2.4: Specifications for the raspberry Pi 2 model B

Processor Broadcom BCM2836

GPIO pins 40

CPU Clock 900 MHz

RAM 1 GB

Hard Drive depends on the size of the inserted Micro SD card

19

Figure 2.10: Raspberry Pi GPIO pin mapSource: Raspberry Pi Foundation

2.3.3 Raspbian (Linux distribution)

Raspbian [16] is a Linux distribution, based on Debian, produced by the Rasp-

berry Pi Foundation. The system includes several optimizations to work efficiently

with Raspberry Pi hardware. Because it is a common Linux system, Raspbian is

also capable of supporting written programs regardless of the language used. It is

also capable of running complex applications such as web servers, games, simulations

and others.

This operating system is distributed free of charge by the Raspberry Pi Founda-

tion itself. To install it, the developer only needs to write the system image into a

micro SD card, insert it into Raspberry Pi and use it to boot the system, applying

the desired configurations. This is the Operating System which runs in the Server

Module.

20

2.3.4 WiringPi

WiringPi [21] is the name of the default open-source library for controlling the

Raspberry Pi General Purpose I/O (GPIO) pins. It is written using the C program-

ming language and released under the GNU LGPLv3 license. On the prototype, it

is used by the RCSwitch library, on Raspberry Pi only, to control the GPIO pins in

order to send messages to other modules in the system.

2.3.5 Node.js

Developed by Ryan Dahl from the Chrome V8 JavaScript engine, Node.js [15]

is a platform for building network applications using JavaScript. Node.js uses a

non-blocking event-based I/O model. This makes it work efficiently when dealing

with intense data exchange in distributed systems.

Currently, Node.js is widely used in the market, being employed by famous web

services like Netflix, Uber, LinkedIn, PayPal and others.

In the prototype, Node.js is used to answer commands sent by the user through

the web interface and pass them on to the devices. A more detailed explanation on

the use of this tool can be found on section 3.3.

2.3.6 RCSwitch Library

RCSwitch [17] a multi-platform open-source library written in C++ made for

interacting with Radio Frequency transmitters and receivers. It was originally made

to be compatible with the Arduino platform but was ported to also run on Raspbian,

a Linux distribution made specially to run on a Raspberry Pi device. The library is

used to control an output pin on the sending side and to read from an input pin on

the receiving side. The library is used by all modules in the system to implement

the ability to communicate with other modules through 433 MHz radio frequency.

The library comes, by standard, with 6 predefined communication protocols to

allow compatibility with many RF transmitting devices. The library also allows the

21

definition of new protocols but, as the FS1000A is compatible with protocol 1, it

was not necessary to create a new one.

In protocol 1, every message is sent in small p̈ackagesc̈alled Telegrams, which

are divided in two parts, synchronization and message. The first part is composed

of 32 synchronization pulses, being one HIGH pulse at the the beginning followed

by 31 LOW pulses. The second part contains the message bits, represented by 96

pulses. Each bit is represented by four pulses totalizing 24 bits in each telegram.

Bit 0 is transmitted using 1 pulse HIGH followed by 3 pulses LOW and bit 1 is

transmitted using 1 pulse LOW followed by 3 pulses HIGH. Each pulse has length

of about 350 microseconds. When sending a message, the library sends at least 3

copies for every telegram to minimize the chances of a message loss. Figure 2.11 [18]

shows an example of a generic telegram, showing the pulse levels for synchronization

and bit transmitting.

Figure 2.11: Example of RCSwitch TelegramSource: RCSwitch Wiki

22

Chapter 3

System Development

3.1 Proposed RF Communication Standard

All devices in the system need a standard message template to understand each

other. For this reason, it was proposed a shared standard to be used in all of the

devices composing the system. When a device needs to send a message to another, all

necessary information is condensed in a 24-bit package called Message Transmission

Package (MTP). Figure 3.1 shows details about the package.

The MTP package is divided in the following fields:

• Message Type (1 bit): A simple 1 bit field representing the direction of the

message. This field equals to 0 if the message is from server to client and 1 if

the message follows the opposite direction.

• Client ID (7 bits): An identification number for each client. The server is

the only device in the system which does not have an identification. Client ID

number 0x0 is reserved for devices for which the server has not yet assigned

an identification number and Client ID number 0x7F (all 7 bits set in 1) is

reserved for broadcast messages, directed to all client devices.

• Command Code (4 bits): An identification number for the action to be

executed on the client. ACK and NACK codes are also sent in this field.

23

Figure 3.1: 24-bit package fieldsSource: Produced by the author

• Data (8 bits): Used to send additional information when needed. Can be used

to carry many kinds of information like a new Client ID number, readings from

a sensor or an error code.

• Message Count (2 bits): Used to prevent the execution of the same command

more than once. If the received Message Count number is equal to the the

one in the last message received, the client device ignores the command. ACK

and NACK messages always have the Message Count field set to 0.

• Parity (2 bits): Parity bits are used to detect errors in the message received

by the device. If the parity number of a message is incorrect, the receiving

device ignores it.

The basic behavior for client and the server modules can be seen on Figure 3.2.

More detailed use cases for the MTP will be presented later in this chapter.

3.2 Shared Command Header

To allow different devices do understand each other, it was also needed to define

standard bit sequences which would represent useful information or commands to

24

(a) Basic Client Workflow (b) Basic Server Workflow

Figure 3.2: Basic WorkflowsSource: Produced by the author

be executed. Because of this, it was written a C header file, shared between all

modules in the system, to define the hexadecimal values representing supported

module commands. The library also includes methods to allow extracting or writing

specific fields in a given integer. Table 3.1 shows the defined values and methods

included in the header file. All modules in the system include the same header

file but access to command IDs is restricted depending of the module type. Server

module has access to all codes in the library. Other types of modules have access only

to the shared and the module specific codes. Table 3.2 shows the public methods

defined in the library. All modules have access to the methods.

25

Table 3.1: Library Commands Hexadecimal Values

Code Name Hexadecimal Value

Shared Codes

Set New Client ID 0xF

ACK Message 0xE

NACK Message 0xD

Switch Module Codes

Turn On 0xC

Turn Off 0x3

Sensor Module Codes

Request Sensor Reading 0x9

IR Module Codes

Register New IR Command 0xA

Delete Registered IR Command 0x5

Send IR Command 0x1

26

Table 3.2: MTP Interaction Methods

Method Name Method Parameters

getMessageType uint32_t message

setMessageType uint32_t value, uint32_t * message

getClientId uint32_t message

setClientId uint32_t value, uint32_t * message

getCommandId uint32_t message

setCommandId uint32_t value, uint32_t * message

getCommandData uint32_t message

setCommandData uint32_t value, uint32_t * message

getCommandCount uint32_t message

setCommandCount uint32_t value, uint32_t * message

getParity uint32_t message

setParity uint32_t value, uint32_t * message

computeParity uint32_t message

3.3 Server Module

3.3.1 Overview

The server module acts as a central hub and concentrates all the "intelligent"

part of the system. The server is the only module able to initiate communication

with other modules and is responsible for storing the system state. It is also the

only module that receives direct instructions from the user through a web interface,

transmitting the given commands to target devices. The user is not allowed to

communicate directly to any other module.

For the prototype, it was used a Raspberry Pi 2 Model B device, with Raspbian

Linux distribution, connected to a network access point through Ethernet or Wi-Fi.

The RCSwitch library needs to be installed in the device for it to be able to use the

27

Figure 3.3: Server Module Block DiagramSource: Produced by the author

RF communication devices through its GPIO pins. The library also depends on the

WiringPi Library for it to be able to control the GPIO pins. The Raspberry Pi 2

model B could be substituted by cheaper alternatives, like the Omega2 or Raspbery

Pi Zero W, by porting RCSwitch to use other library to control the GPIO pins.

Figure 3.3 shows the block diagram of the Server Module Prototype.

The Server Module physical electronic circuit mounted on a protoboard can be

seen on Figure 3.4. On the left is the Raspberry Pi 2 Model B, in the center is

the RF Receiver and in the right is the RF Transmitter. Red wires represent 5V

tension and black wires are for 0V tension. Green and blue wires represent input

and output data respectively.

3.3.2 Node.js

Node.js is the main software component in the Server Module. It is responsible

for providing the web interface, interpreting user commands, maintaining system

state and instancing other processes to execute specific actions. The server is initi-

ated at Operating System start and listens for requests at port 80.

28

Figure 3.4: Server Module Circuit on a ProtoboardSource: Produced by the author

3.3.3 System Data File

The Server Module needs to be able to persistently store information about the

rest of the system. For this reason, all information about system logical topology

is stored within the database.json file. The file is organized in a tree structure, the

root node being a representation of the system as a whole.

The second level includes all "rooms" of the system. Each room acts as a di-

rectory that stores a certain group of devices. Despite the name, there are no

impediments to a single "room" in the system include devices present in more than

one physical room of the house.

The third level includes three fixed groups: Switches, Sensors and IRModules.

These groups address all devices present in the system, storing information such

as Client ID, default state and other useful configurations for each specific client

module type.

The information contained in the JSON file is read and stored in memory every

time the server is started. When some configuration in the system is changed (device

added or removed, change of Client ID, new command added, among others), the

29

Figure 3.5: Database Organization LevelSource: Produced by the author

database file is modified to store these changes. When the system restarts, the

system default state is restored according to the information in this file. Figure 3.5

shows the organization levels of the JSON file.

3.3.4 hhsend - the RF Communication Program

When Node.js server receives a request from the user, it usually needs to send a

message to a client module, for what it calls a binary program called hhsend. This

executable is written in C++, using the RCSwitch and the WiringPi libraries, and

is responsible for controlling the GPIO pins of the Raspberry Pi in order to send

a message using the RF interface. This binary is also responsible for receiving the

response from the clients and return useful data to be treated by Node.js.

To send a message, the program needs three inputs: The Client ID of the target

module, the Command Code to be sent to the client and the Data to be written on

the correspondent field on the MTP. The program uses this information to assemble

a valid MTP and send it in broadcast, waiting for a response immediately after.

Figure 3.6 shows a detailed workflow for hhsend.

30

Figure 3.6: Detailed hhsend WorkflowSource: Produced by the author

31

(a) Home page of the Dashboard showing all configured rooms

(b) Menu opened when a room is selected

Figure 3.7: User Web Interface DashboardSource: Produced by the author

3.3.5 Web Interface Dashboard

The Dashboard is the main interface for the user to interact with the system.

Accessed via the web, the dashboard is a dynamic page that allows the user to

configure, send commands and monitor the system.

When the user accesses the web address of the server, it sends the user a basic

web page. Subsequently, the sent page requests the sending of the file database.json

to set up the organization of the page in "rooms" and "devices". The Dashboard

also prompt the Server Module for the current state of the devices controlled by the

system so that it can be presented on the page.

Figure 3.7 shows screenshots of the Dashboard interface.

32

3.3.6 Example Use Case

For the example use case, we suppose the user wants to command the Switch

Client Module to turn the device it controls on. This example focus only on the

inner workings of the Server Module. A detailed use case showing the work done

at the Switch Client Module for the same command to be executed is presented on

section 3.5. For this example, it is assumed the user wants to turn ON the Switch

Client Module of Client ID equal to 0x2.

1. First, the user tells the Server Module, through the web interface (Dashboard),

he wishes a specific switch client module, originally on OFF state, to turn ON

its controlled device.

2. The web page detects a press on the button representing device 0x2 and in-

forms the Server Module. As it is a Switch Module, no additional data is sent

to the server.

3. Node.js captures the message sent by the web page and treats the data. By the

target Client ID received, the server is able to check its type (Switch Module)

and current state (OFF). As the target is a Switch on OFF state, the only

possible command to be sent is a "Turn On", of hexadecimal code equal to

0xC. Node.js then call hhsend with inputs Client Id = 2, Command Code =

12 (0xC) and Data = 0.

4. The program hhsend is started and executes the following steps in order:

• Store input values in internal variables

• Write a MTP to be sent to the Switch Client. Details about the MTP

contents can be seen on section 3.5.

• hhsend waits for the RF semaphore to be available. This is done to

eliminate the risk of two different instances of this program to try to

send a message at the same time.

33

• After semaphore access is granted, hhsend creates two other threads: one

to send the message and another to listen for any responses.

• The "send" thread sends the message containing the MTP using the

RCSwitch library. It sends a burst

• The "receive" thread waits for the correct response from the target client.

If timeout is expired, maximum number of tries is reached or a NACK

message from the target client is received, this thread writes an error

code on the "return" variable. If no error occur and an ACK is received

from target client, this thread writes the response "Data" value on the

"return" variable. After any of these scenarios, the "receive" thread tells

the "send" thread to terminate.

• After both threads terminate, hhsend returns whatever value is written

on the "return" variable.

5. Node.js updates the system state accordingly with the response returned by

hhsend.

6. Server stays on Standby waiting for another request from the user.

3.4 Detecting New Client Modules

As seen on Table 3.1, some commands are common to all devices in the system.

The most important common use case for the devices in the system is the setting of

a new Client ID for a client module. As the server does not have an ID number in

the system, the Client ID Set use case only applies to client modules.

1. First, the user tells the Server Module, through the web interface, he wishes

to detect a new device. Currently, this algorithm only works if there is only

one device to be detected. The system behavior when more than one module

is waiting to be detected is not determined.

34

2. The server detects it has received a "Detect Devices" request. As new devices

do not have a declared Client ID, it is the same as sending a "Set New Client

ID" command to the module with Client ID equal to 0x0, so the server sends

a MTP with the following values on its fields:

• Message Type = 0x0 (1 bit): As the message is from server to client, this

field receives value 0.

• Client ID = 0x0 (7 bits): The Client ID is still null, so it must be equal

to 0.

• Command Code = 0xF (4 bits): The server writes the "Set New Client

ID" command hexadecimal value in this field.

• Data = 0x2 (8 bits): The Data field contains the Client ID value the new

Client module will assume. In this use case, it is assumed the ID 0x2 is

the next free address, so the server writes this value on the Data field.

This is the only use case in which the server will expect a response from

a Client ID equal to the value written on the Data field.

• Message Count = 0x0 (2 bits): This field is equal to the last Message

Count value sent to the target device plus 1. This is the first message

ever to the new device, this field is set to zero.

• Parity = 0x1 (2 bits): The parity is a 2 bit sum of the amount of ’1’ bits

in the message, excluding the Parity field. In this example, it would be

equal to 0x1

The resulting MTP has value 0x21 in hexadecimal, which equals to 33 in

decimal base. The server sends this value in broadcast using its radio frequency

transmitter

3. The target client receives the message and initiates the default correctness

check procedures presented in Figure 3.2a. If all values are correct and no

errors occurred during transmission, the client writes the new attributed Client

ID value on its EEPROM memory and sends an ACK message:

35

• Message Type = 0x1 (1 bit): The message is from client to server, so this


• Client ID = 0x2 (7 bits): The Client ID field receives the client’s new ID

value.

• Command Code = 0xE (4 bits): Client writes the ACK code in this field

to tell the server command has completed successfully.

• Data = 0x0 (8 bits): The client does not need to send any data back to

the server, so this field is set to a null value.

• Message Count = 0x0 (2 bits): The server ignores this field when waiting

for a response, so it is set to a null value.

• Parity = 0x0 (2 bits): The parity calculated for this message.

4. The server receives the client response, updates the system database. It also

includes a new entry on memory, setting the value of the new device’s Com-

mand Count to 0x0

3.5 Switch Client Module

3.5.1 Overview

This is the most basic module type in the system. Its only function is to turn on

or off the device linked to it. Although simple, this kind of module is the core for

many home automation functionalities like controlling light bulbs, locks, alarms, and

others. The module prototype was set to control a LED (Light Emitting Diode),

turning it on or off, depending on the command received. Figure 3.8 shows the

schematic of a Switch Module Prototype. The physical electronic circuit can be

seen on Figure 3.9. It is worth to note that a LED was was used on the prototype

only for practical testing purposes. On a real system, this module would probably

be connected do a relay module instead of an indication LED.

36

Figure 3.8: Switch Module Prototype Block DiagramSource: Produced by the author

Figure 3.9: Switch Module Circuit on a ProtoboardSource: Produced by the author

37


For the example use case, we suppose the user wants to command the Switch

Client Module to turn the device it controls on. On the prototype, the device is

represented by a LED. This process is analogous to the case where the user wants

to turn the device on. In this example it is assumed the Switch Client Module

is correctly configured by the server, responds to Client ID 0x2, the last Message

Count sent to it was equal to 0x2 and its device is currently turned OFF. From the

issuing of the command by the user to the turning ON of a specific device by the

Switch Client Module, the system executes the following steps:

1. First, the user tells the Server Module, through the web interface, he wishes a

specific switch client module, originally on OFF state, to turn ON its controlled

device.

2. The server detects it has received a "turn ON" request for the client with ID

equal to 0x2. The server, then, checks the last Command Count sent to this

device and assembles the MTP with the following values:



• Client ID = 0x2 (7 bits): The Client ID is equal to the ID of the target

device of the request.

• Command Code = 0xC (4 bits): The server writes the "Turn ON" com-

mand hexadecimal value in this field. If it had received a "Turn OFF"

request from the user, the server would then write a 0x3 value in this

field.

• Data = 0x0 (8 bits): The "Turn ON" command does not need any data

to be sent. For this reason, this field receives a null value.


Count value sent to the target device plus 1. As the last value sent was

38

2, the server writes value 3 in this field.



equal to 0x1

The resulting MTP has value 0x2C00D in hexadecimal, which equals to 180237

in decimal base. The server sends this value in broadcast using its radio

frequency transmitter

3. The target Switch Client Module receives the message and initiates the check

procedures presented in Figure 3.2a. If all values are correct and no errors

occurred during transmission, the client turns the attached device ON and

prepares an ACK MTP to tell the server the command has been executed.

The response package would have the following values:



• Client ID = 0x2 (7 bits): The Client ID field receives the client’s ID value.


to tell the server command has completed successfully. If the command

received from server was not recognized, the client would write a 0xD

value instead, which is the code for the NACK response.

• Data = 0x0 (8 bits): The client does not need to send any data back to

the server, so this field is set to a null value.



• Parity = 0x0 (2 bits): The parity calculated for this message.

4. The server receives the clients response, updates the state of the client module

from OFF to ON and updates the value of the last Message Count to the

device with Client ID equal to 2 from 0x2 to 0x3.

39

Figure 3.10: Sensor Module Prototype Block DiagramSource: Produced by the author

3.6 Sensor Client Module

3.6.1 Overview

Sensors are important components in any home automation systems. They are

useful for monitoring environments and can act as triggers for the system to perform

certain kinds of actions autonomously. It is important that the sensors are able

to send data to the server and, for this reason, this is the module that uses the

Data field in the MTP the most. For building the prototype, it was used the

LM35, a temperature sensor. Figure 3.10 shows the schematic for the Sensor Module

Prototype. The physical electronic circuit can be seen on Figure 3.11


For this example use case, it is supposed the user wants to fetch the tempera-

ture reading value from a correctly configured Sensor Client Module attached to a

temperature sensor. It is assumed the Sensor Module responds to Client ID 0x1,

the last Message Count sent to it was equal to 0x3 and that the sensor will read a

40

Figure 3.11: Sensor Module Circuit on a ProtoboardSource: Produced by the author

temperature value of 27°C. In this example, the system executes the following steps:


to read the value of a specific sensor. This process can be configured to repeat

automatically after a set period of time.

2. The server detects the "Request Sensor Reading" request for the client with

ID equal to 0x1. The server, then, checks the last Command Count sent to

this device and assembles the MTP with the following values:





• Command Code = 0x9 (4 bits): The server writes the "Request Sensor

Reading" command hexadecimal value in this field which was presented

41

on Table 3.1.

• Data = 0x0 (8 bits): The "Request Sensor Reading" command does not

need any data to be sent. For this reason, this field receives a null value.



3, the value of this field would be 4 but, as it has only 2 bits, the value

in this field becomes 0x0. For the client to accept the command, this

value only needs to be different from the previous one it received, but not

necessarily greater.



equal to 0x3

The resulting MTP has value 0x32003 in hexadecimal, which equals to 204803


frequency transmitter

3. The target Sensor Client Module receives the message and initiates the check


occurred during transmission, the client reads the sensor for 8 times in a row

and calculates a mean value for the readings. This is done to reduce the

uncertainty of the response value. The client then sends an ACK MTP with

the following values:








42

• Data = 0x1B (8 bits): The client writes the mean of 8 sensor readings

in this field. For its size limitations, the sensor would only be able to

transmit temperatures ranging from -128°C to 127°C correctly. The mean

value is rounded to the nearest 8-bit integer value. In this example, it is

assumed the sensor is reading a 27°C temperature.



• Parity = 0x1 (2 bits): The parity value calculated for this message.

4. The server receives the clients response, updates the state of the sensor client

module to the new reading value of 27°C. The value of the last Message Count

to the device with Client ID equal to 1 from 0x3 to 0x0.

3.7 IR Client Module

3.7.1 Overview

A good feature for a home automation system is for it to be able to control devices

which were not designed for understanding its communication standards, such as

a standard television, air conditioning system or a stereo radio. For controlling

devices such as these, the module needs to have means to control the target devices

by simulating its standard input forms, like remote controllers or keyboards.

To build a prototype for this kind of module, it was used an IR Receiver sensor

and an IR emitter LED. Both were used to control a remote controlled Stereo Radio

system by simulating its default remote controller. Figure 3.12 shows the block dia-

gram representing the IR Client Module Prototype. The physical electronic circuit

can be seen on Figure 3.12 shows the schematic for the IR Module Prototype. The

physical electronic circuit can be seen on Figure 3.13

43

Figure 3.12: IR Module Prototype Block DiagramSource: Produced by the author

Figure 3.13: IR Module Circuit on a ProtoboardSource: Produced by the author

44

3.7.2 First Example Use Case - Configuring a New IR Com-

mand

In this example, the user wants configure a new IR command in the IR Client

Module emulating the device remote control. It is assumed the IR Module responds

to Client ID 0x3, the last Message Count sent to it was equal to 0x3 and that the

last IR command configured in the IR module has ID 0x13. For this example, the

system executes the following steps:


configure a new command at the IR Client Module.

2. The server detects the "Register New IR Command" request for the client

with ID equal to 0x3. The server, then, retrieves the last Command Count

sent to this device and assembles the MTP with the following values:





• Command Code = 0xA (4 bits): The server writes the "Register New IR

Command" command hexadecimal value in this field which was presented

on Table 3.1.

• Data = 0x0 (8 bits): This command does not need any data to be sent.



3, the value of this field would be 4 but, as it has only 2 bits, the value

in this field becomes 0x0. For the client to accept the command, this

value only needs to be different from the previous one it received, but not

necessarily greater.

45



equal to 0x0

The server then sends this MTP value in broadcast using its radio frequency

transmitter

3. The target IR Client Module receives the message and initiates the check pro-

cedures presented in Figure 3.2a. If all values are correct and no errors occurred

during transmission, the client starts blinking an indicator LED, demonstrat-

ing it is waiting for an IR message to be received. The user now needs to

provide an example of IR message for the client to store as a new config-

ured command. Usually this is done by pressing a button on the household

appliance remote control while directing it to the IR Client Module.

After the user provides the IR command he wishes to configure, the IR Client

Module sends an ACK MTP with the following values:








• Data = 0x14 (8 bits): This field tells the server the 8-bit value to be sent

for the IR Client Module to execute the recently configured command.

On a NACK message, this value would be null.




46

4. The server receives the clients response and updates the IR Client Module

table of IR commands. The value of the last Message Count to the device

with Client ID equal to 3 from 0x3 to 0x0.

3.7.3 Second Example Use Case - Sending an IR Command

In this example, it is supposed the user wants transmit an IR command to

a specific device controlled by an IR Client Module emulating the device remote

control. It is assumed the IR Module responds to Client ID 0x3, the last Message

Count sent to it was equal to 0x0 and that the IR command issued by the user is

already configured in the client module under ID 0x14. For this, the system executes

the following steps:


transmit an IR command to a specific device.

2. The server detects the "Send IR Command" request for the client with ID

equal to 0x3. The server, then, checks the last Command Count sent to this

device and assembles the MTP with the following values:





• Command Code = 0x1 (4 bits): The server writes the "Send IR Com-

mand" command hexadecimal value in this field which was presented on

Table 3.1.

• Data = 0x14 (8 bits): The "Send IR Command" needs a data value to

be written on the MTP. This is how the IR Client Module will identify

which command it needs to send to its household appliance. This field

cannot have a null value.

47


Count value sent to the target device plus 1.



equal to 0x2

The resulting MTP has value 0x6229 in hexadecimal, which equals to 25129 in

decimal base. The server sends this value in broadcast using its radio frequency

transmitter.

3. The target IR Client Module receives the message and initiates the check


occurred during transmission, the client sends the anteriorly configured IR

command through its IR emitter. It does not have a way to check if the

command was accepted by the receiving device. The client then sends an

ACK MTP with the following values:








• Data = 0x0 (8 bits): This message is only to tell the server that the client

has emitted the IR signal. No data needs to be written in this field.




48

4. The server receives the IR Client Module response and updates the value of

the last Message Count to the client with Client ID equal to 1 from 0x0 to

0x1.

3.7.4 Third Example Use Case - Deleting a Configured IR

Command

This example shows the steps the system takes to delete a configured IR com-

mand from a specific IR Client Module. It is assumed the IR Module responds to

Client ID 0x3, the last Message Count sent to it was equal to 0x1 and that the IR

command the user wants to delete is already configured under ID 0x14. The system

would execute the following steps:


delete an IR command of a specific device.

2. The server detects the "Delete Registered IR Command" request for the client

with ID equal to 0x3. The server, then, retrieves the last Command Count

value sent to this client and assembles the MTP with the following values:





• Command Code = 0x5 (4 bits): The server writes the "Delete Registered

IR Command" hexadecimal value, which was presented on Table 3.1, in

this field .

• Data = 0x14 (8 bits): The "Delete Registered IR Command" needs to

tell the IR Client Module what is the ID of the IR command that should

be deleted.

49


Count value sent to the target device plus 1.



equal to 0x3

The resulting MTP has value 0x3514B in hexadecimal, which equals to 217419


frequency transmitter.

3. The target IR Client Module receives the message. If all values are correct

and no errors occurred during transmission, the client and deletes the entry

for command under ID 0x14. The next command, however, will not be written

in this position, but in the next one available. The 0x14 Id will only be reused

again if there are no more available IDs and the IR client needs to reuse

previously freed positions.

After deletion, the client then sends an ACK MTP with the following values:








• Data = 0x0 (8 bits): This message is only to tell the server that the client

has emitted the IR signal. No data needs to be written in this field.




50

4. The server receives the IR Client Module response and updates the value of

the last Message Count value sent to the client with Client ID equal to 3 from

0x1 to 0x2.

51

Chapter 4

Results

4.1 Transmission and Functionality Testing

The first module to be tested was the server. Its main functionality is the logic

in the hhsend program, which is what will be used to control the entire system. All

other features are secondary, as they only support user interaction through the web

interface. It was necessary to know if hhsend was properly formatting the messages.

Automatic tests were performed to verify correctness of message formatting. As

a basis for verification, the test cases described in sessions 3.4, 3.5, 3.6 and 3.7 were

used. After confirming the correct operation of sending server messages, it was time

to test the client modules. In each of them the "DEBUG" macro of the customer

codes was defined. This flag included lines of code that enabled writing by serial

communication, which was used to verify each important step of the execution of

the code in client modules and compare the obtained result with the expected value.

Once the correct functioning of server and client modules was achieved, it was

possible to test the functionalities of the web interface, simulating a normal use of the

system using all the features that the user could use. Again, the same test cases listed

on previous sections were used but, this time, they were triggered by interaction with

the web interface and not with command lines. All tests were considered successful

once client servers presented expected operation given the correct input through web

interface.

52

4.2 Improving Communication

When the correctness of the system overall operating logic was verified, it was

necessary to improve the range of the communication. The range of experimental

communication between modules was still approximately 2m, much lower than the

expected for a residential automation system.

In order to increase the reach of the server module, antennas were placed in

all modules. Antennas can be made by using a rigid copper wire suitable for the

wavelength used.

Since the frequency used for communication was 433 MHz, copper wires of ap-

proximately 17 cm were used. The wire size was calculated using the equation

presented in session 2.2.9. Figure 4.1 shows the copper wire used to make the an-

tennas along a RF transmitter and a RF receiver component. Figure 4.2 shows a

Switch Client Module with the antennas installed.

Figure 4.1: Example of a 17 cm antenna used on all system modulesSource: Produced by the author

After the addition of the antennas in both the server module and the client

modules, the new range changed from 35 to 40m, which represents an increase of up

to 2000% in the communication range.

53

Figure 4.2: Switch Client Module with 17 cm antenna on transmitter and receivercomponents

Source: Produced by the author

4.3 Comparison with Similar Market Solution

In order to compare the functionalities and the cost of the system with a similar

consolidated product in the market, the solution of iHouse [8], a leading company in

residential automation in Brazil, will be used as a basis. All comparisons have taken

into account the Home Controller HC220 (equivalent to the Server Module used on

this project) and its optional modules, commercialized by the same company.

4.3.1 General Characteristics

As both systems have a modular topology, the HC220 Home Controller [30]

and Sensor Module play similar roles. However, the devices have some functional

differences. The main one is that the Server Module connections are exclusively

wireless. The Home Controller, on the other hand, offers wireless communication

with all but the infrared (IR) modules.

In the latter, there is a maximum limit of 4 (four) IR module connections, es-

tablished by the number of plugs where the module can be fitted. Because the

Server Module connection to IR devices is wireless, the limit of connected devices is

54

given only by the number of bits reserved for Client ID in the Message Transmission

Package (MTP), which currently uses 7 bits, enabling the connection of 126 discrete

modules, discounting reserved addresses.

Information on how many client modules Home Controller can address wirelessly

was not found in the documentation provided by the vendor.

Another basic difference is that the Home Controller uses ZigBee, a wireless

communication standard with mesh network, in which each module repeats the

signal to the next one, to communicate wirelessly with its client devices, while the

Server Module uses 433 MHz radio frequency. This provides greater reliability for

the Home Controller HC220 but at an increased price.

4.3.2 Functionalities

As both systems are modular, the functionalities they provide depend only on

the client modules compatible with them. As the basic modules (lighting control,

sensor and IR) are present on both systems and the developed system is compatible

with the implementation of new functionalities, it is possible to say both systems

are able to compete on the same level in the market.

4.3.3 Operation

With Home Controller each client device can be allocated to one of 16 "Zones"

(equivalent to Server Module’s "rooms"), which can be customized by the user.

When a new client module is detected on the network, it is able to detect automat-

ically in which of the Zones it is in.

With Server Module, the number of different rooms is limited by the size of

the array clients, which means it depends on the free RAM amount on the server.

However, as it does not make sense to have a room with no client modules, the

maximum number of rooms can be considered to be equal to the maximum number

of clients, which is currently equal to 126.

55

4.3.4 User Interface

The user interface of Home Controller is provided by a mobile device app while

the Server Module’s provides user interface through a web page. A mobile app is

usually more intuitive and better accepted by the user. However, a web interface

was preferred for the system prototype because it is compatible with any device

capable of accessing the web. The development of a mobile app for interacting with

the Server Module is left as future work.

4.3.5 Cost

The exact cost of a home automation system depends a lot on where it will be

installed. However, according to iHouse, their complete automation kit cost starts

from R$4.590.00 [8], or about $1450.00 at the exchange rate of August 2017. The

complete living room automation automation system considered by iHouse includes

the Home Controller, 1 (one) Dimmer Module with 4 (four) channels for controlling

lights, 4 (four) IR modules and 1 (one) Sensor Module with 4 sensors for controlling

curtains, air conditioners and others. The kit provided by them would be roughly

equivalent to a Server Module, 4 (four) Switch Modules, 4 (four) sensor modules and

4 (four) IR Modules. The cost of the components for the modules in the system is

on Table 4.1. All prices were taken from DigiKey Electronics Website [5] on August

2017.

The total cost for the system to implement similar functionalities when compared

to iHouse’s system is the price of the Server Module plus four times the sum of the

other modules prices. Hence, the full cost of the components in the system would be

44.50+4× (2.95+4.80+3.15) = 88.10 US dollars. It is necessary to note, however,

that other costs such as logistics, marketing, transportation and profit were not

considered in this simulation.

56

Table 4.1: Modules Component Prices

Server ModuleComponent Price (US Dollars)Raspberry Pi 2 Model B (could be replaced by cheaper models) 35.00MicroSD card (16 GB) 8.00RF transmitter/receiver 1.50Server Total 44.50Switch ModuleAttiny85 1.25RF transmitter/receiver 1.50Resistor 0.20Switch Module Total 2.95Sensor ModuleAttiny85 1.25RF transmitter/receiver 1.50Sensor (Varies, but LM35 was used as reference value) 2.05IR Module Total 4.80IR ModuleAttiny85 1.25RF transmitter/receiver 1.50IR emitter LED 0.20IR receiver 0.20IR Module Total 3.15

57

Chapter 5

Conclusion

The present work presented a prototype for an alternative to market-leading

residential automation systems for a cost lower than $100.00, which represents an

investment approximately 14 times lower when compared with the leading solution

on the Brazilian market.

The project consists of a client-server system with communication at 433 MHz

radio frequency. The server was implemented with Node.js running on a Raspberry

Pi and clients with Attiny85 microcontrollers running C code. For developing the

prototype, it was needed knowledge in digital and analog electronics, software engi-

neering techniques, programming at high and low level, construction of frontend and

backend systems, as well as technical knowledge about the operation of operating

systems, web servers and communication protocols.

All decisions in the project were made considering cost, efficiency and ease of

installation and operation for the final user. In addition, the system was restricted to

using only free software to implement its features. The performance of the system at

the tests can be considered satisfactory, and is a viable solution for providing house

control over web. However, refinements are still necessary and new functionalities

need to be implemented in order for the system to be able to be commercialized.

Although wireless communication between system modules occurs through 433

MHz radio frequency, it is relatively easy to switch to a more secure and energy-

efficient communication standard such as Bluetooth or ZigBee by simply replacing

58

the library for Radio frequency communication (RCSwitch) and transmission and

reception components by others capable of operating with these standards.

5.1 Suggestions for Future Work

• Implement user authentication for web interface access

• Use more complex, secure and energy-efficient wireless communication stan-

dards such as ZigBee or Bluetooth to implement communication between sys-

tem modules

• Encrypt communication between modules for considerable increase in security

level

• Develop new client modules for implementing other functionalities like door

lock control or energy and water consumption monitoring

• Implement user interaction with the Server Module through mobile app inter-

face

• Develop a business model and better price estimation for making the product

available in the market

• Implementation of autonomous decisions based on sensor reading values

• Provide a scripting environment for the user to implement customized func-

tionalities

• Add speech recognition as additional interface for the user to issue commands

to the system

• Collection of usage data for artificial intelligence training

59

Bibliography

[1] “Amazon Alexa”. Disponível em: <https://developer.amazon.com/alexa>.

[2] 2008. “ANATEL, Resolution number 506, from 1st of July of 2008”. Disponívelem: <http://www.anatel.gov.br/legislacao/resolucoes/2008/104-resolucao-506>.

[3] “Arduino Official Website”. Disponível em: <https://www.arduino.cc/>.

[4] 2017. “Debian - The universal Operating System”. Disponível em: <https://www.debian.org/>.

[5] 2017. “DigiKey Electronics - Electronic Components Distributor”. Disponívelem: <https://www.digikey.com/>.

[6] “Zuckerberg’s Jarvis Project”. Disponível em: <https://www.facebook.com/notes/mark-zuckerberg/building-jarvis/10154361492931634/>.

[7] “Google Home”. Disponível em: <https://madeby.google.com/home/>.

[8] 2017. “iHouse - Automação Residencial”. Disponível em: <http://www.ihouse.com.br/>.

[9] “Infrared: A Historical Perspective”. Disponível em: <https://www.omega.com/literature/transactions/volume1/historical1.html>.

[10] . “IRremote Library”. . Disponível em: <https://github.com/z3t0/Arduino-IRremote>.

[11] . “IRremote Library Documentation”. . Disponível em: <https://github.com/z3t0/Arduino-IRremote/wiki>.

[12] 1995. “Netscape and Sun announce JavaScript”. Disponível em:<https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html>.

[13] “Johnny-Five: JavaScript Robotics and IoT Platform”. Disponível em: <http://johnny-five.io/>.

60

https://developer.amazon.com/alexa

http://www.anatel.gov.br/legislacao/resolucoes/2008/104-resolucao-506

http://www.anatel.gov.br/legislacao/resolucoes/2008/104-resolucao-506

https://www.arduino.cc/

https://www.debian.org/

https://www.debian.org/

https://www.digikey.com/

https://www.facebook.com/notes/mark-zuckerberg/building-jarvis/10154361492931634/

https://www.facebook.com/notes/mark-zuckerberg/building-jarvis/10154361492931634/

https://madeby.google.com/home/

http://www.ihouse.com.br/

http://www.ihouse.com.br/

https://www.omega.com/literature/transactions/volume1/historical1.html

https://www.omega.com/literature/transactions/volume1/historical1.html

https://github.com/z3t0/Arduino-IRremote

https://github.com/z3t0/Arduino-IRremote

https://github.com/z3t0/Arduino-IRremote/wiki

https://github.com/z3t0/Arduino-IRremote/wiki

https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html

https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html

http://johnny-five.io/

http://johnny-five.io/

[14] 2017. “Linux Foundation”. Disponível em: <https://www.linuxfoundation.org/>.

[15] “Node.js: Asynchronous Event Driven JavaScript Runtime”. Disponível em:<https://nodejs.org/>.

[16] 2017. “Raspbian”. Disponível em: <https://www.raspbian.org/>.

[17] . “RCSwitch Library”. . Disponível em: <https://github.com/sui77/rc-switch>.

[18] . “RCSwitch Library Documentation”. . Disponível em: <https://github.com/sui77/rc-switch/wiki/KnowHow_LineCoding>.

[19] 2017. “Specifications for the Raspberry Pi 2 Model B”. .Disponível em: <https://www.raspberrypi.org/products/raspberry-pi-2-model-b/>.

[20] 2017. “Raspberry Pi Foundation”. . Disponível em: <https://www.raspberrypi.org/>.

[21] “WiringPi Library”. Disponível em: <http://wiringpi.com/>.

[22] ANDREW S. TANENBAUM, A. S. W., 2006, Operating Systems Design andImplementation, 3rd Edition. Prentice Hall. ISBN: 0-13-142938-8.

[23] 2013, Attiny25/45/85 DATASHEET. Atmel Corporation, 8. Rev.2586Q–AVR–08/2013.

[24] BENATALLAH, B., CASATI, F., TOUMANI, F., 2004, “Web service con-versation modeling: a cornerstone for e-business automation”, IEEE In-ternet Computing, v. 8, n. 1 (Jan), pp. 46–54. ISSN: 1089-7801. doi:10.1109/MIC.2004.1260703.

[25] CALLAWAY, E., GORDAY, P., HESTER, L., et al., 2002, “Home networkingwith IEEE 802.15.4: a developing standard for low-rate wireless personalarea networks”, IEEE Communications Magazine, v. 40, n. 8 (Aug),pp. 70–77. ISSN: 0163-6804. doi: 10.1109/MCOM.2002.1024418.

[26] D., E., 2011. “The Internet of Things: How the Next Evolution of the InternetIs Changing Everything”. Disponível em: <https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf>.

[27] DOWNEY, A. B., 2016, The Little Book of Semaphores, 2nd Edition.

61

https://www.linuxfoundation.org/

https://www.linuxfoundation.org/

https://nodejs.org/

https://www.raspbian.org/

https://github.com/sui77/rc-switch

https://github.com/sui77/rc-switch

https://github.com/sui77/rc-switch/wiki/KnowHow_LineCoding

https://github.com/sui77/rc-switch/wiki/KnowHow_LineCoding

https://www.raspberrypi.org/products/raspberry-pi-2-model-b/

https://www.raspberrypi.org/products/raspberry-pi-2-model-b/

https://www.raspberrypi.org/

https://www.raspberrypi.org/

http://wiringpi.com/

https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

[28] EROL-KANTARCI, M., MOUFTAH, H. T., 2011, “Wireless Sensor Networksfor Cost-Efficient Residential Energy Management in the Smart Grid”,IEEE Transactions on Smart Grid, v. 2, n. 2 (June), pp. 314–325. ISSN:1949-3053. doi: 10.1109/TSG.2011.2114678.

[29] HAGHI M, THUROW K, S. R., 2017, “Wearable Devices in Medical In-ternet of Things: Scientific Research and Commercially Available De-vices”, Healthcare Informatics Research, v. 1, n. 23, pp. 4–15. doi:10.4258/hir.2017.23.1.4.

[30] 2012, HC220 User Manual. iHouse, 1.

[31] LEHONG H, V. A., 2014, “Hype cycle for the Internet of Things”,Disponível em: <https://www.gartner.com/doc/2804217/hype-cycle-internet-things->.

[32] PEDRASA, M. A. A., SPOONER, T. D., MACGILL, I. F., 2010, “Coordi-nated Scheduling of Residential Distributed Energy Resources to Opti-mize Smart Home Energy Services”, IEEE Transactions on Smart Grid,v. 1, n. 2 (Sept), pp. 134–143. ISSN: 1949-3053. doi: 10.1109/TSG.2010.2053053.

[33] PHILIPOSE, M., FISHKIN, K. P., PERKOWITZ, M., et al., 2004, “Inferringactivities from interactions with objects”, IEEE Pervasive Computing,v. 3, n. 4 (Oct), pp. 50–57. ISSN: 1536-1268. doi: 10.1109/MPRV.2004.7.

[34] 1999, LM35 DATASHEET. Texas Instruments, 8. REVISED AUGUST 2016.

62

https://www.gartner.com/doc/2804217/hype-cycle-internet-things-

https://www.gartner.com/doc/2804217/hype-cycle-internet-things-

PROTÓTIPODESISTEMADEAUTOMAÇÃORESIDENCIALMODULAR...

Documents

Transcript of PROTÓTIPODESISTEMADEAUTOMAÇÃORESIDENCIALMODULAR...