Michel Vinicius de M elo Euzebio

DroidLar - Automacao residencial atraves de um

celular Android

Sao Jose SC
agosto / 2011
 Michel Vinicius de M elo Euzebio

DroidLar - Automacao residencial atraves de um

celular Android

Monografia apresentada a Coordenacao do

Curso Superior de Tecnologia em Sistemas
de Telecomunicacoes do Instituto Federal de
Santa Catarina para a obtencao do diploma de
Tecnologo em Sistemas de Telecomunicacoes.

Orientador:
Prof. Emerson Ribeiro de Melo, Dr.

CURSO SUPERI OR DE T ECNOL OGI A EM SI STEM AS DE T EL ECOM UNI CA COES

I NSTI TUTO FEDERA L DE SA NTA CATA RI NA

Sao Jose SC
agosto / 2011
 Monografia sob o ttulo DroidLar - Automacao residencial atraves de um celular An-
droid , defendida por Michel Vinicius de Melo Euzebio e aprovada em 12 de agosto de 2011,
em Sao Jose, Santa Catarina, pela banca examinadora assim constituda:

Prof. Emerson Ribeiro de Melo, Dr.

Orientador

Prof. Tiago Semprebom, M. Eng.

IFSC

Prof. Marcos Moecke, Dr. Eng.

IFSC
As pessoas raramente reconhecem a oportunidade
porque ela surge disfarcada em trabalho arduo.
H. L. Mencken
 Agradecimentos

Dedico meus sinceros agradecimentos a Deus e a minha famlia que me deram forca para
vencer os obstaculos e chegar ate aqui.

Agradeco tambem ao professor Emerson, que me proporcionou um grande aprendizado me

orientando nas bosas de iniciacao tecnol ogica e tambem nesse trabalho, que me ajudaram a
encontrar a direcao que eu deveria seguir na minha vida profissional. Por fim, agradeco aos
amigos e colegas que convivi nesses anos de curso.
 Resumo

Sistemasdeautomacao residencial permitem queosusuarioscontrolem oseletroeletronicos

de sua residencia atraves de interfaces de controle como paineis afixados em paredes. A
popularizacao dos telefones inteligentes se deu pelo fato de possurem configuracoes de hard-
ware superiores aos telefones convencionais, e tambem sistemas operacionais complexos que
permitem o desenvolvimento de aplicacoes mais sofisticadas. O sistema operacional Android
e um projeto de codigo aberto desenvolvido para dispositivos moveis e por isso esta presente
em diversos telefones inteligentes. O protocolo ZigBee e utilizado em redes sem fio de baixa
taxa de transmissao e possibilita uma economia de energia por parte dos transmissores. As
transmissoes na rede ZigBee nao possuem longo alcance porem, nesse protocolo e possvel
que os transmissores encaminhem as mensagens da rede aumentando a extensao desta. Nesse
trabalho e apresentado o DroidLar, um sistema de automacao residencial completo que utiliza
uma aplicacao rodando em telefones Android como interface de controle. Os controladores de
dispositivos desse sistema se comunicam por uma rede ZigBee.
 Abstract

Home automation systems allow the users to control of electronics of a residence through
control interfaces like fixed panels on the walls. The smart phones become popular because
have superior hardware settings compared to conventional mobile phones and because have
more complex operating systems allowing development of sophisticated applications. The ope-
rating system Android is an open source project developed for mobile devices and is present in
so many smart phones. The ZigBee protocol is used in wireless networks with low transmis-
sion rate and provides energy safe by the transmitters. The transmissions in ZigBee networks
dont have long-range but this protocol allows the transmitters forward messages in network,
increasing the length it. In this paper we presents the DroidLar, a complete home automation
system that uses an application running on Android phones as a control interface. The devices
controller of this system communicate over a ZigBee network.
 Sumario

L ista de Figur as

L ista de Tabelas

1 I ntroducao p. 12

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

1.3 Organizacao do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13

2 Revisao Bibliogr afica p. 15

2.1 Automacao Residencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.1.1 X10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.1.2 Insteon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2.1.3 Z-Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

2.1.4 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.1.5 Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2 Padrao IEEE 802.15.4 e ZigBee . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.2.1 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.3 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

2.4 XBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32

2.5 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32

3 DroidL ar p. 35
 3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35

3.1.1 Controladores de Dispositivos . . . . . . . . . . . . . . . . . . . . . p. 35

3.1.2 SAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37

3.1.3 Cliente Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40

3.2 Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.2.1 Cliente Android SAR . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.2.2 Cliente Android SAR Controladores . . . . . . . . . . . . . . . . p. 46

3.2.3 SAR Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.3 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

4 Conclusoes p. 53

4.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

L ista de Abreviatur as p. 55

Refer encias Bibliogr aficas p. 57

 Lista de Figuras

2.1 Transmissao sincronizada no nvel zero AC (EUROX10, 2011). . . . . . . . . p. 16

2.2 Transmissao nas tres fases (EUROX10, 2011). . . . . . . . . . . . . . . . . . p. 17

2.3 Topologia da rede Insteon (DARBEE, 2005). . . . . . . . . . . . . . . . . . p. 19

2.4 Mensagens do protocolo Insteon. . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.5 Quadro de mensagem(IEEE, 2006). . . . . . . . . . . . . . . . . . . . . . . p. 26

2.6 Pilha do protocolo ZigBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.7 Topologias da rede ZigBee. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

2.8 Elementos de um kit Arduino (HERRADOR, 2009). . . . . . . . . . . . . . p. 30

2.9 Codigo para piscar um LED no Arduino. . . . . . . . . . . . . . . . . . . . . p. 31

2.10 Configuracao de modulos no X-CTU . . . . . . . . . . . . . . . . . . . . . . p. 33

2.11 Arquitetura do Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

2.12 Aplicacao Android utilizando Java e XML. . . . . . . . . . . . . . . . . . . p. 34

3.1 Elementos do DroidLar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3.2 Prototipos do DroidLar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36

3.3 Configuracao dos circuitos nos Kits. . . . . . . . . . . . . . . . . . . . . . . p. 37

3.4 Interface principal e de configuracao do SAR . . . . . . . . . . . . . . . . . p. 40

3.5 Interfaces para configuracao dos dispositivos e perfis . . . . . . . . . . . . . p. 41

3.6 Mensagem de controle padrao. . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.7 Mensagem de controle usada na autenticacao. . . . . . . . . . . . . . . . . . p. 42

3.8 Mensagem de autenticacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43

3.9 Mensagem de requisicao das informacoes de todos os dispositivos. . . . . . . p. 43

3.10 Mensagem de requisicao das informacoes de dispositivos pelo tipo. . . . . . . p. 44

3.11 Mensagem de requisicao do ID da lista de perfis. . . . . . . . . . . . . . . . p. 44

3.12 Mensagem de atualizacao de perfis. . . . . . . . . . . . . . . . . . . . . . . p. 45

3.13 Mensagem de requisicao da lista de perfis. . . . . . . . . . . . . . . . . . . . p. 45

3.14 Mensagem de configuracao dos nomes. . . . . . . . . . . . . . . . . . . . . p. 45

3.15 Mensagem de configuracao da varredura peri odica. . . . . . . . . . . . . . . p. 46

3.16 Mensagem de controle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.17 Mensagem de varredura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.18 Mensagem com as informacoes. . . . . . . . . . . . . . . . . . . . . . . . . p. 48

3.19 Mensagem de atualizacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

3.20 Diagrama de casos de uso da aplicacao. . . . . . . . . . . . . . . . . . . . . p. 49

 Lista de Tabelas

2.1 Comparativo entre os protocolos. . . . . . . . . . . . . . . . . . . . . . . . . p. 25

 12

1 I ntroducao

1.1 M otivacao

Os sistemas de automacao residencial presentes atualmente no mercado oferecem como

interfaces de controle paginas Web que podem ser acessadas de qualquer computador pes-
soal. Com a disseminacao dos telefones celulares em todo mundo, tornou-se possvel que eles
tambem tivessem acesso aessas paginas Web, porem, com umainterfacemais simples por conta
das limitacoes de hardware e software desses telefones.

O surgimento dos telefones inteligentes possibilitou uma melhor utilizacao de dispositivos

moveis como interfaces de controle para sistemas de automacao residencial. Esses telefones
possuem recursos como maior quantidade de memoria e poder de processamento, aliados a
sistemas operacionais mais sofisticados, se comparados ao celulares comuns.

Esse trabalho foi motivado pela possibilidade de utilizar uma aplicacao rodando em celula-
res Android (OPEN HANDSET ALLIANCE, 2008) como interface de controle de um sistema
de automacao residencial, a fim de substituir as limitadas paginas Web utilizadas pelos siste-
mas atuais. A utilizacao de aplicacoes em telefones inteligentes possibilita usufruir de recursos
como manipulacao de arquivos, reproducao de audio e vdeo, al em de construcao de interfaces
graficas avancadas com uma facilidade maior do que em paginas Web.

O protocolo ZigBee(ZIGBEE ALLIANCE, 2005) possibilitaacriacao deredes sem fio que

nao exijam umataxadetransferenciaalta. Por isso, osdispositivosquesecomunicam utilizando
esse protocolo necessitam de pouca energia para operar. Uma das causas dessa economia e o
curto alcance das transmissoes. Porem, o ZigBee previne essa limitacao permitindo que os nos
da rede possam encaminhar as mensagens uns aos outros.

Sistemas de automacao residencial contem dispositivos que sao conectados aos eletroe-
letronicos da residencia e executam efetivamente os comandos do usuario. Esses dispositivos
precisam estar disponveis o tempo todo para receberem as mensagens da rede e executar os
comandos. As caractersticas apresentadas pelo protocolo ZigBee sao ideias para sistemas de
1.2 Objetivos 13

automacao residencial, e por isso ele foi utilizado nesse trabalho.

1.2 Obj etivos

Este trabalho tem o objetivo de apresentar o DroidLar, um sistema de automacao residen-

cial controlado por telefones Android que contem recursos semelhantes aos apresentados pelos
sistemas encontrados no mercado. No desenvolvimento desse trabalho os seguintes objetivos
especficos foram propostos:

Desenvolvimento de um dispositivo capaz de controlar os eletronicos de uma residencia

com a utilizacao de kits Arduino que se comuniquem pela rede ZigBee;

Desenvolvimento de uma aplicacao servidora que encaminhe mensagens provenientes da

aplicacao cliente pela rede IP para os controladores de dispositivos pela rede ZigBee.
Essa aplicacao tambem permite a execucao de comandos agendados pelo usuario;

Desenvolvimento de uma aplicacao cliente que rode em telefones Android e sirva como
interface de controle para os eletronicos da residencia. Essa aplicacao tambem possibilita
o agendamento de comandos no servidor.

1.3 Or ganizacao do texto

O texto esta organizado da seguinte forma: No Captulo 2 sao descritos os principais pro-
tocolos utilizados em sistemas de automacao residencial, como tambem produtos comerciais
que as utilizam. E estudada tambem a plataforma Arduino. Iniciando com suas principais ca-
ractersticas, sua integracao com redes ZigBee atraves do modulo XBee e terminando com um
exemplo de codigo.

Outro assunto abordado nesse captulo e o protocolo ZigBee. E feita uma analise de sua
arquitetura e tambem descrito seu funcionamento, os papeis de cada tipo de dispositivo na rede
e tambem, os motivos pela sua utilizacao nesse trabalho ao inves de outros protocolos de rede
mais populares. Al em desses assuntos, tambem e apresentado o sistema operacional Android,
sua arquitetura e a estrutura basica de uma aplicacao.

No Captulo 3 e apresentado o DroidLar, o sistema de automacao residencial resultante

desse trabalho. Inicialmente e descrita a sua arquitetura e as tecnologias utilizadas em cada
parte do sistema. Posteriormente e estudado o protocolo utilizado na comunicacao do sistema
1.3 Organizacao do texto 14

atraves da analise das possveis sequencias de mensagens trocadas na rede. E finalizando o

captulo, sao apresentadas as possveis acoes que um usuario pode executar enquanto estiver
utilizando o sistema. Por fim, no Captulo 4 serao apresentadas as conclusoes desse trabalho e
tambem os trabalhos futuros que podem ser desenvolvidos a partir deste.
 15

2 Revisao Bibliogr afica

2.1 Automacao Residencial

Sistemas de automacao sao sistemas capazes de executar comandos, obter medidas, regular
parametros e controlar funcoes automaticamente. Esses sistemas comecaram a ser utilizados
na decada de 70 em aplicacoes industriais. Consolidados no setor industrial sua utilizacao
expandiu-se tambem para o comercio com o surgimento dos chamados predios inteligentes ,
originando os sistemas de automacao predial (PINHEIRO, J. M. S., 2004).

A automacao predial consiste em equipar predios, normalmente com funcoes comerciais,

com sistemas automatizados de iluminacao, seguranca, ar condicionado, controle de acessos
e etc. Apenas na decada de 90, com o avanco das tecnologias computacionais e das redes
de comunicacao, os sistemas usados em predios comecaram a ser utilizados tambem em do-
miclios, dando origem a automacao residencial (PINHEIRO, J. M. S., 2004).

A automacao residencial tem como principais objetivos fornecer conforto e comodidade

aos usuarios, porem ela tambem pode ser utilizada para outros objetivos como a economia e
a seguranca. Esses sistemas sao tipicamente formados por um dispositivo de gerenciamento
centralizado e dispositivos micro controlados conectados aos eletroeletronicos da residencia.
O usuario envia os comandos aos dispositivos controladores atraves de interfaces de controle
como, por exemplo, paineis afixados em paredes. Existem diversos protocolos de comunicacao
para sistemas de automacao residencial, eles diferem-se pelo custo, meio fsico que utilizam
para as transmissoes e complexidade. Nas proximas secoes serao apresentados alguns destes
protocolos e tambem, solucoes presentes no mercado de automacao que fazem uso deles.

2.1.1 X10

O X10 (SARASWAT et al., 2008) foi um dos primeiros protocolos a serem utilizados em
automacao residencial. Desenvolvido na decada de 70 pela empresa escocesa Pico Electro-
nics, tem como principal caracterstica a utilizacao da rede el etrica da residencia como meio
2.1 Automacao Residencial 16

de comunicacao, o que oferece economia ao usuario, pois, e utilizada uma infraestrutura j a

instalada. Por possuir um baixo custo e ser de f acil instalacao tornou-se muito popular nos Es-
tados Unidos e na Europa. Em 1997 expirou a patente da Pico Electronics sobre o X10, o que
tornou o protocolo acessvel gratuitamente a qualquer fabricante, motivando ainda mais a sua
popularizacao.

O protocolo X10 pode funcionar de forma descentralizada, ou seja, as interfaces de con-

trole, normalmente paineis afixados em paredes, se comunicam diretamente com os dispositi-
vos controladores. Esse protocolo suporta no maximo 256 enderecos de rede, al em disso, um
mesmo endereco pode ser compartilhado por diferentes dispositivos. Nesse caso, quando uma
mensagem e enviada para um endereco compartilhado por mais de um dispositivo, todos eles
executaram a acao determinada por essa mensagem.

As mensagens sao enviadas em direcao unica, ou seja, as interfaces de controle enviam as

mensagens aos dispositivos e nao recebem nenhuma confirmacao. Isso ocorre porque o X10
nao possui um protocolo de acesso ao meio, o que possibilita colisoes entre mensagens, sendo
isso uma desvantagem, quando comparado a outras tecnologias para automacao residencial.

As mensagens sao transmitidas atraves da rede el etrica da residencia, sendo que os bits de
valor 1 sao enviados na forma de pulsos de 120 Khz a cada cruzamento pelo valor zero de
tensao Corrente Alternada (CA), j a os bits 0 sao caracterizados pela ausencia desses pulsos,
como mostra a Figura 2.1 (CHUNDURU; SUBRAMANIAN, 2006).

Figura 2.1: Transmissao sincronizada no nvel zero AC (EUROX10, 2011).

Os pulsos sao enviados a cada 60 da tensao CA para que o protocolo seja compatvel
com potencias trif asicas e, assim, receber o bit pela fase que estiver em melhor estado naquele
momento (Figura 2.2), resultando numa melhora na relacao sinal/rudo. O protocolo X10 ainda
preve o envio de um segundo bit que e o complemento do original (Figura 2.2) aumentando,
assim, a imunidade a rudos do sistema (DA SILVA, A. A. J. P., 2005).

As mensagens do X10 sao formadas por uma sequencia de 13 bits. Os 4 primeiros bits
2.1 Automacao Residencial 17

Figura 2.2: Transmissao nas tres fases (EUROX10, 2011).

indicam o incio da mensagem, os 4 bits subsequentes indicam o codigo da casa e os outros 5

variam de acordo com o tipo de mensagem. Desses 5 bits vari aveis, o quinto bit mais signifi-
cativo indica se a mensagem e do tipo Address ou do tipo Function. Quando um usuario envia
um comando para determinado dispositivo, primeiramente e enviada uma mensagem do tipo
Address que informa o endereco para o qual sera enviada a proxima mensagem. Em seguida
e enviada uma mensagem do tipo Function que contem o comando que o dispositivo devera
executar.

Quando eenviadaa mensagem Address, os 4 bits vari aveis indicam o codigo do dispositivo.
Esse codigo juntamente com o codigo da casa podem ser usados para o enderecamento dos dis-
positivos, resultando no total de 256 enderecos possveis na rede. No envio de uma mensagem
Function os 4 bits vari aveis sao usados para indicar o tipo de comando. Esses 4 bits limitam a
quantidade de comandos em 16, al em disso, os comandos do X10 sao predefinidos como, por
exemplo, On, Off e Dim que servem para ligar, desligar e diminuir a intensidade de energia
do dispositivo, respectivamente, tornando o X10 menos flexvel comparado a outros protocolos
para automacao (DA SILVA, A. A. J. P., 2005).

No X10 as interfaces de controle e os dispositivos normalmente sao conectados a rede

el etrica por meio de cabos, o que impede a mobilidade no sistema. Isso e um grande problema,
pois, hoje em dia existem varias tecnologias que fazem o transporte dos dados por uma rede
sem fio. Pensando nisso alguns fabricantes de produtos para o X10 utilizam um adaptador que
recebe as mensagens dos paineis de controle por um receptor de Radiofrequencia (RF) e as
envia pela rede el etrica.

Apesar da utilizacao de adaptadores de RF amenizar o problema do X10 quanto a mobili-

dade, outros fatores ainda o tornam invi avel para aplicacoes mais complexas e que requeiram
uma confiabilidade maior do sistema tais como: mensagens em direcao unica, limite de 256
2.1 Automacao Residencial 18

enderecos e comandos predefinidos, como j a explicado nessa secao. Al em disso, a propria

utilizacao da rede el etrica na transmissao das mensagens pode acarretar problemas aos disposi-
tivos devido a quedas de energia e descargas eletromagneticas, por exemplo. Como j a visto o
X10 e compatvel com potencias trif asicas mas para que os dispositivos ligados em diferentes
fases possam se comunicar e necessario a instalacao de um equipamento adicional ou mesmo a
utilizacao de capacitores para interligar essas fases (SENA, 2005).

Siatron

Desenvolvido pela Siatron Automacao1, o Siatron e um sistema de automacao residencial

no qual o usuario pode controlar eletroeletronicos de sua residencia, que estao conectados a
dispositivos X10, por interfaces de controle como paineis, uma pagina Web ou mesmo um
telefone celular, tanto localmente como pela Internet.

A comunicacao entre as interfaces de controle, que utilizam redes Internet Protocol (IP)
para se comunicar, e os dispositivos X10 e feita atraves de um software da mesma empresa que
roda em um computador pessoal e encaminha as mensagens entre essas duas redes distintas.
Esse software ainda permite o agendamento de comandos aos dispositivos para horarios pre-
determinados pelo usuario.

O Siatron e comercializado em forma de modulos tais como o Siatron Biometria, que con-
trola o acesso a residencia atraves de identificacao biometrica e o Siatron Iluminacao, que per-
mite que o usuario acenda ou apague as l ampadas da sua residencia.

2.1.2 I nsteon

O Insteon (DARBEE, 2005) e um protocolo de rede para automacao residencial criado pela
Smarthome Technology - maior distribuidora de dispositivos X10 do mundo - em 2001. Ele e
considerado o sucessor do X10, pois, assim como ele, tambem utiliza a rede el etrica existente
da residencia como meio de comunicacao. Entretanto, diferente do X10, o Insteon tambem
preve a comunicacao de dispositivos utilizando RF, o que so e possvel no X10 com a utilizacao
de adaptadores de terceiros como j a mencionado na Secao 2.1.1.

Os dispositivos da rede podem se comunicar utilizando a instalacao el etrica, atraves de RF

ou por ambos. Isso permite que uma mensagem que foi perdida por rudos na rede el etrica, por
exemplo, seja recebida atraves do receptor de RF. Outra caracterstica que torna a comunicacao
na rede mais segura e a retransmissao de mensagens, ela ocorre quando nao e recebida uma
1http://www.siatron.com.br
2.1 Automacao Residencial 19

confirmacao da mensagem enviada. A Figura 2.3 apresenta um exemplo de uma rede Insteon
com dispositivos atuando tanto na rede el etrica quanto por RF. E possvel ver que podem ser
utilizados dispositivos hbridos, que transmitam tanto por RF quanto pela rede el etrica, como
ponte para a comunicacao de dispositivos conectados a diferentes fases da rede el etrica.

Figura 2.3: Topologia da rede Insteon (DARBEE, 2005).

O Insteon utiliza uma rede do tipo par a par, sendo que todos os modulos podem receber,
enviar ou repetir as mensagens (Figura 2.3). A repeticao de mensagens aumenta ainda mais a
protecao do sistema contra perdas, j a que elas tem varios caminhos possveis para chegar ao
destino. Nao ha configuracoes de rotas na rede, ou seja, todos os modulos repetirao todas as
mensagens que receberem. Para evitar uma repeticao infinita de mensagens na rede, o Insteon
limita em 3 o numero de repeticoes de uma mesma mensagem.

Existem doistiposdemensagensno protocolo Insteon: amensagem Standard (Figura2.4(a))

que contem 10 bytes e a mensagem Extended (Figura 2.4(b)) que contem os mesmos 10 by-
tes da Standard acrescidos de 14 bytes para preenchimento com quaisquer informacoes que
o usuario queira. Esses 10 bytes comuns nas duas mensagens sao divididos em cinco campos:
endereco deorigem; endereco dedestino; flags; comandos1 e2 epor ultimo Cyclic Redundancy
Check (CRC) (DARBEE, 2005).

Os campos endereco de origem e de destino ocupam 3 bytes da mensagem cada, ou seja, na

rede Insteon existem 16.777.216 enderecos unicos possveis. Esses enderecos sao configurados
2.1 Automacao Residencial 20

(a) Mensagem do tipo Standard(DARBEE, 2005).

(b) Mensagem do tipo Extended(DARBEE, 2005).

Figura 2.4: Mensagens do protocolo Insteon.

durante a fabricacao dos dispositivos e, por isso, nao podem ser alterados. O campo flags
ocupa 1 byte e contem informacoes como o tipo de mensagem que e enviada, j a o campo
comandos ocupa 2 bytes, um para cada comando, e contem os comandos predeterminados que
o dispositivo devera executar. O ultimo byte contem o valor de CRC utilizado para deteccao de
erros.

Os sinais que carregam as mensagens na rede el etrica tem frequencia de 131,65 Khz e, as-
sim como no X10, sao sincronizados no nvel zero de tensao CA. Esses sinais sao modulados
utilizando-se a modulacao Binary Phase Shift Keying (BPSK) o que garante uma boa perfor-
mance do sistema na presenca de rudos. Ja os sinais enviados por radiofrequencia utilizam a
faixa de 902 a 924 Mhz dentro da banda Industrial, Scientific and Medical (ISM) e sao trans-
mitidos a uma taxa de 38,4 Kbps.

O protocolo X10 e compatvel com o protocolo Insteon, ou seja, os dois sistemas podem
operar na instalacao el etrica da mesma residencia sem causar interferencias entre si. Porem, as
mensagens do Insteon e do X10 nao sao compatveis, por isso, os fabricantes foram autorizados
a desenvolver dispositivos hbridos - que operem nas duas redes - o que permite a integracao de
uma nova rede Insteon com uma rede X10 j a instalada.

O Insteon resolveu varios dos problemas existentes no X10, porem, por utilizar a rede
el etrica para a transmissao de comandos os problemas decorridos dessa utilizacao tambem
encontram-se nele. Mesmo com a utilizacao de dois meios de transmissao evitando a perda
das mensagens devido a atenuacoes ou rudos na rede, nem todos os dispositivos presentes no
mercado tem a capacidade de utilizar os dois meios.
2.1 Automacao Residencial 21

iHome

Desenvolvido pela IHC Technologies2, o iHome e uma solucao para automacao residen-
cial composta pelo iHomeClub e por hardwares, que controlarao os eletroeletronicos, tambem
desenvolvidos pela IHC. O iHomeClub e o aplicativo utilizado como interface de controle e
foi desenvolvido para dispositivos moveis que rodem o sistema operacional iOS3 como iPhone,
iPod Touch e iPad.

No iHome o usuario pode controlar diferentes setores da sua residencia. Na parte de

iluminacao e possvel acender e apagar l ampadas, agendar o horario de funcionamento delas
e a dimerizacao da intensidade das luzes. Tambem e possvel o controle dos aparelhos de som,
televisores e Home Theaters da residencia. Al em disso, ele permite o controle de sistemas
adicionais como: ar condicionado; lareiras; persianas entre outros.

Al em do protocolo Insteon, o iHome suporta outros protocolos para automacao residen-

cial como Global Cache, Lutron, AMX, Creston e outros. Os dispositivos que controlarao os
equipamentos da residencia sao vendidos separadamente em representantes comerciais da IHC
Technologies, j a o aplicativo iHomeClub pode ser baixado gratuitamente no site iTunes.com.

2.1.3 Z-Wave

A transmissao deinformacoespelainstalacao el etricadaresidenciaforneceum metodo sim-

ples e barato para a infraestrutura de uma rede de comunicacao. Entretanto, com a exposicao
dos dados da rede aos problemas inerentes a rede el etrica buscou-se criar uma infra-estrutura
propria, separada da fiacao eletrica, para serem utilizados em sistemas de automacao. Com esse
intuito foi criado o Z-Wave(Z-WAVE ALLIANCE, 2004), um protocolo proprietario desenvol-
vido pela empresa Zensys que utiliza comunicacao sem fio para a troca de mensagens entre os
dispositivos da rede.

No Z-Wave os dados sao transmitidos a uma taxa de 40 Kbps - 9,6 Kbps nos dispositivos
antigos - utilizando a banda ISM de 902 a 928 Mhz. Na comunicacao entre os dispositivos da
rede, o raio de alcance das mensagens pode chegar a 30 metros. Para evitar colisoes no meio
onde as mensagens sao transmitidas, o Z-Wave utiliza uma solucao bastante simples, quando
um dispositivos quer enviar uma mensagem pela rede ele primeira escuta o meio e caso ele
esteja ocupado espera um tempo aleatorio para tentar mandar a mensagem novamente, se o
meio estiver ocioso entao a envia.
2
http://www.ihclub.com.br
3http://www.apple.com/ios
2.1 Automacao Residencial 22

Numa rede Z-Wave podem haver 232 dispositivos ativos na rede, o que pode ser pouco
dependendo daresidenciaedacomplexidadedo sistemaem queforem instalados. Paradiminuir
essa limitacao foi includo no protocolo uma funcionalidade bem interessante que sao os nos
virtuais. Um dispositivo Z-Wave com a funcionalidade de controle pode servir como ponte
para varios outros dispositivos. O interessante disso e que esses dispositivos podem pertencer a
outrostiposderedecomo TCP/IPeX10, eparao restantedaredeserao vistoscomo dispositivos
Z-Wave. Essa funcionalidade permite um numero acima de 125 nos virtuais na rede Z-Wave e
possibilita a integracao do protocolo com sistemas pre-instalados numa residencia.

Os dispositivos na rede Z-Wave podem rotear mensagens formando uma rede em malha
o que resulta num aumento do alcance de suas transmissoes. As mensagens enviadas podem
carregar no maximo 64 bytes de informacao, al em disso, quando um dispositivo recebe uma
mensagem ele envia para a origem uma mensagem do tipo acknowledge para confirmar o rece-
bimento com sucesso. Para a protecao contra rudos ou interferencias no meio, as mensagens
enviadas contem um campo que guarda um valor de checksum para que o dispositivo de destino
possa verificar a integridade das informacoes recebidas. Quando uma mensagem e enviada e
nao e recebida uma confirmacao de recebimento ou quando e identificado um erro durante a
verificacao do valor de checksum, e feita uma retransmissao dessa mensagem.

NumaredeZ-Waveexistem variostipos dedispositivosdependendo dafuncao queexercem

na rede. Toda rede Z-Wave tera um unico dispositivo do tipo Controlador Primario, que sera
responsavel por iniciar a rede e por funcoes como a inclusao e exclusao de dispositivos da rede.
Os dispositivos podem ser do tipo Controlador, que tem a funcao de gerenciar a rede, porem
so executa acoes de modo indireto, ou seja, mediante comandos do Controlador Primario. Os
dispositivos podem tambem ser do tipo Escravo, sao eles quem enviam, recebem e encaminham
as mensagens na rede. Os dispositivos do tipo Controlador podem ainda ser classificados como
Portateis ou Estaticos. Os Controladores Portateis tem a capacidade se movimentar na rede,
pois, podem modificar a tabela de roteamento atualizando suas posicoes nela automaticamente.
Os Controladores Estaticos exercem a funcao de ponte para nos virtuais e para isso devem ter
pouca mobilidade na rede, pois para atualizar suas posicoes na tabela de rotas deve haver um
evento externo, como um aperto de botao por exemplo.

M odest Solution

A empresa Modest Solution4 dispoe de uma solucao para automacao residencial onde e
possvel controlar cameras, iluminacao, climatizacao, sonorizacao e eletroeletronicos como te-
4http://www.modestsolution.com.br
2.1 Automacao Residencial 23

levisores e home theaters. Para a comunicacao das interfaces de controle e dos dispositivos que
controlarao os eletros da casa e utilizado o protocolo Z-Wave para residencias j a construdas e
cabeamento estruturado para residencias ainda em fase de projeto.

O sistema de automacao da Modest Solution funciona de forma descentralizada, ou seja,

nao existe qualquer equipamento mediando a comunicacao entre os controles e os dispositivos
terminais. Isso cria uma certa limitacao no sistema, j a que nao havendo um servidor ativo o
tempo todo na rede se perde funcionalidades como o agendamento de tarefas aos dispositivos.

Nesse sistema tambem ha a opcao da criacao de cenarios. Esses cenarios permitem que
diferentes tipos de dispositivos tais como, l ampadas, televisores e persianas, sejam controlados
na mesma tela da interface de controle. Um exemplo dessa funcionalidade seria a criacao de
cenarios especficos para cada comodo da residencia.

2.1.4 ZigBee

Um grupo de varias empresas entre elas Philips, Texas Instruments, Intel, Cisco e AT& T
formam a ZigBee Alliance5. Esse grupo desenvolveu o ZigBee (ZIGBEE ALLIANCE, 2005),
um protocolo criado para sistemas sem fio especficos, que nao necessitem de altas taxas de
transmissao tais como sistemas de controle e automacao. O ZigBee foi construdo sobre o
padrao IEEE 802.15.4 (IEEE, 2006) que define as redes pessoais sem fio com baixa taxa de
transmissao, e por isso produtos de diferentes fabricantes sao mais compatveis entre si do que
em outros protocolos.

O ZigBee utiliza as bandas ISM de 868 e 915 Mhz al em da banda de 2,4 Ghz, para a
transmissao dos dados que pode chegar a taxa de 250 Kbps. O alcance dessas transmissoes
atinge em media 50 metros dependendo do ambiente onde e realizada e dos dispositivos utiliza-
dos. Porem, e possvel estender esse alcance configurando os nos da rede ZigBee para atuarem
como roteadores. Nessa configuracao as mensagens podem ser encaminhadas por diversos nos
ate chegarem ao destino.

Para a transmissao das mensagens e feito uso do protocolo Carrier Sense Multiple Ac-
cess With Collision Avoidance (CSMA/CA), que escuta o meio antes de enviar a mensagem,
e caso ele esteja ocupado, toma medidas para evitar colisoes na rede. Outra medida tomada
e a utilizacao da tecnica Direct Sequence Spread Spectrum (DSSS) para alargar o espectro de
frequencias do sinal e, consequentemente, aumentar a imunidade dele a rudos.

O protocolo ZigBee suporta no maximo 65.536 redes coabitando a mesma area. Ele ainda
5http://www.zigbee.org
2.1 Automacao Residencial 24

preve dois tamanhos para enderecos, os mais curtos de 16 bits - para reduzir o tamanho do
pacote - que possibilitam a quantidade de 65.536 enderecos unicos na rede, e os de 64 bits que
possibilitam mais de 18x1018 de enderecos. Os enderecos dos modulos ZigBee vem gravados
desde a sua fabricacao e nao podem ser alterados.

No ZigBee e possvel garantir a seguranca na transferencia das mensagens utilizando crip-

tografia. Ja a confiabilidade dessa troca de informacoes e conseguida utilizado-se um esquema
de deteccao de erros para verificar a integridade dos dados recebidos, caso seja identificado
um erro, entao sera realizada uma retransmissao da mensagem. Al em disso, para toda mensa-
gem enviada - exceto as de broadcast - deve ser recebida uma mensagem de confirmacao de
recebimento com sucesso do destino, caso contrario, tambem ocorrera a retransmissao dessa
mensagem.

Control4

A empresa americana Control46, especializada em solucoes na area de automacao, desen-

volveu um sistema de automacao residencial completo onde e possvel controlar desde equi-
pamentos mais simples como luminarias, ate equipamentos eletronicos mais complexos como
televisores, equipamentos de ar-condicionado, aparelhos de som e home theaters.

O usuario pode utilizar como interface de controle paineis com telas sensveis ao toque,
controles remotos convencionais e ainda pode utilizar aplicativos disponveis para dispositivos
moveis rodando iOS e tambem para computadores pessoais e laptops. Os dispositivos que con-
trolam os eletros utilizam a rede ZigBee no envio dos comandos, j a as interfaces de controle
utilizam a rede Wi-Fi, com excecao dos controles remotos convencionais que tambem utili-
zam ZigBee. Para a comunicacao entre as interfaces de controle e os dispositivos, a Control4
desenvolveu um equipamento denominado Controller que integra os dois tipos de rede.

Essa solucao tambem disponibiliza o Composer Home Edition, um software para compu-
tadores pessoais que permite, entre outras coisas, a criacao de cenarios personalizados para o
controle dos dispositivos e tambem o agendamento de eventos como acendimento de l ampadas
e a mudanca de temperatura dos equipamentos de ar-condicionado, em horarios especficos.

Nasolucao paraautomacao residencial daControl4 os dispositivosquecontrolam os eletros

eo Controller podem ser adquiridosseparadamentedeacordo com anecessidadedo usuario. Os
aplicativos para dispositivos moveis e computadores podem ser baixados gratuitamente, porem,
o usuario tera que adquirir uma licenca de funcionamento para cada dispositivo usado como
6http://www.control4.com
2.2 Padr ao IEEE 802.15.4 e ZigBee 25

interface de controle.

2.1.5 Compar ativo

Na Secao 2.1 foram apresentados importantes protocolos da automacao residencial seja

pelo aspecto historico ou seja pela grande utilizacao no mercado. Al em disso, foram apre-
sentados exemplos de produtos de automacao residencial presentes no mercado que utilizam
esses protocolos. Foram descritas caractersticas desses protocolos como o meio e a taxa de
transmissao que utilizam, e outras como topologias de rede e funcionalidades de seguranca que
possuem. Na Tabela 2.1 essas caractersticas sao postas lado a lado.

X10 Insteon Z-Wave ZigBee

Meio Fsico Rede El etrica Rede El etrica e RF Radiofrequencia Radiofrequencia
Bandas de RF 902 MHz 902 MHz 868, 915 MHz e 2,4 GHz
Taxa M axima 60 bps 38,4 Kbps 40 Kbps 250 Kbps
Topologias Estrela Malha Malha Estrela, Malha, Arvore
Qtd. de Info. 4 bits 2 bytes 64 bytes Vari avel
Seguranca Baseada na AES 128 bits AES 128 bits
Caracterstica Instal. simples Hbrido Roteamento Baixo consumo

Tabela 2.1: Comparativo entre os protocolos.

E possvel perceber queo X10, mesmo tendo acaractersticade ser utilizado diretamentena
rede el etricada residencia, e bastante simples e nao possibilita aformacao de topologias derede
mais complexas ou mesmo possui recursos de seguranca. Em contrapartida, o ZigBee se mostra
o protocolo mais completo, dos apresentados na tabela, possibilitando diversas topologias e
bandas para transmissao, al em de possuir funcionalidades sofisticadas de seguranca e economia
de energia.

2.2 Padr ao I EEE 802.15.4 e ZigBee

Com a popularizacao das redes sem fio em ambientes comerciais e residenciais, onde um
longo alcance e uma alta taxade transferencia de dados sao caractersticas desej aveis, tornou-se
necessario o desenvolvimento de uma tecnologia voltada para redes especficas, como as in-
dustriais e de automacao. Essas redes nao necessitam de grandes taxas de transmissao, porem,
elas requerem dispositivos que tenham um baixo consumo de energia. Por essa razao foi de-
senvolvido o padrao IEEE 802.15.4. Esse padrao define a Low-Rate Wireless Personal Area
Network (LR-WPAN) e pode ser aplicado em sistemas de automacao industrial e residencial,
militares, de monitoramento sem fio, entre outros.
2.2 Padr ao IEEE 802.15.4 e ZigBee 26

No 802.15.4 sao utilizadas as bandas ISM de 868 Mhz (Europa somente), 902 Mhz e 2,4
Ghz para as transmissoes de dados. Na Banda de 868 Mhz e utilizado apenas um canal de
transmissao e consegue-se taxas de no maximo 40 Kbps, na banda de 902 Mhz sao utilizados
ate 8 canais que possibilitam taxas de ate 40 Kbps, j a na banda de 2,4 Ghz sao dispostos 16
canais e a taxa maxima salta para 250 Kbps. Quando se utiliza bandas com varios canais, os
dispositivos que controlam a rede podem ser configurados para escolher automaticamente o
canal que estiver ocioso, isso permite que possam coexistir varias redes sem fio numa mesma
area.

Numa rede 802.15.4 existem dois tipos de dispositivos: os Full Function Devices (FFD)
e os Reduced Function Devices (RFD). Os FFDs sao dispositivos que podem se comunicar
com qualquer outro tipo de dispositivo, ou seja, FFDs e RFDs. Esses dispositivos podem ainda
exercer funcoes de controle e gerenciamento da rede. Em contrapartida, os RFDs podem se
comunicar apenas com os FFDs e nao exercem quaisquer funcoes extras na rede.

As mensagens do 802.15.4 sao transmitidas em forma de pacote. Como mostra a Fi-

gura 2.5, o pacote e dividido em tres partes: o Medium Access Control Header (MHR), a
informacao enviada (Medium Access Control Payload (MAC Payload)), e um Medium Access
Control Footer (MFR). No MHR estao contidos o campo delimitador de quadro (Frame Con-
trol), indicando o incio do pacote, um campo com o numero de sequencia do pacote, e os
campos de enderecamento. O campo MAC Payload tem o comprimento vari avel e seu tamanho
maximo varia de fabricante pra fabricante. No MFR esta contido o valor do Frame Checksum
Sequence (FCS). Esse valor serve para verificar a integridade das informacoes recebidas, ecaso
seja encontrado algum erro, entao sera requisitada uma retransmissao do pacote ao dispositivo
de origem.

Figura 2.5: Quadro de mensagem(IEEE, 2006).

Para o envio das mensagens e possvel utilizar enderecos de 16 ou 64 bits. O endereco

de 16 bits e atribudo ao dispositivo quando este se conecta a rede, j a o de 64 bits e fixo e
exclusivo para cada dispositivo ZigBee fabricado. Para a troca de mensagens na rede e utilizado
o endereco de 16 bits, porem, como ele e facilmente mutavel, na montagem dos pacotes deve
ser utilizado o endereco de 64 bits. Durante o envio da mensagem, a rede ZigBee utilizara
2.2 Padr ao IEEE 802.15.4 e ZigBee 27

esse endereco de 64 bits para descobrir o endereco mais curto atual do dispositivo de destino e,
assim, evitar perdas de pacotes.

2.2.1 ZigBee

O padrao IEEE 802.15.4 define as camadas Physical Layer (PHY) e Medium Access Con-
trol Layer (MAC Layer) para as LR-WPANs, entretanto, as camadas superiores precisam ser
definidas pelas especificacoes que utilizarem essa base. O ZigBee e uma delas, ele utiliza a
base definida pelo 802.15.4 e adiciona outras duas camadas, as camadas de rede e de aplicacao
a qual pertence a sub-camada de suporte a aplicacao, como visto na Figura 2.6.

Figura 2.6: Pilha do protocolo ZigBee.

A camadaderede eresponsavel por funcoescomo o gerenciamento deinclusao/exclusao de

dispositivos e a descoberta e manutencao de rotas na rede. Ja a camada de aplicacao fornece as
instrucoes necessarias para o desenvolvimento dos servicos. Nessacamadaaindaestao contidos
servicos como os de seguranca, os da fabricante do dispositivo e tambem servicos do usuario.

Numa rede ZigBee um dispositivos pode ter a funcao de roteador, coordenador ou pontos
finais. Os roteadores sao dispositivos montados sobre a arquitetura FFD do 802.15.4, eles po-
dem enviar, receber e encaminhar mensagens na rede. Em uma rede ZigBee sempre deve haver
um unico roteador com funcao de coordenador, e ele quem inicia e gerencia a rede. Ja os pon-
tos finais sao projetados sobre a arquitetura RFD, eles sao as terminacoes da rede, por isso, so
enviam e recebem mensagens.

Os pontos finais nao necessitam estar o tempo todo funcionando, eles podem entrar em
modo de hibernacao, fazendo-os ficar parcialmente desligados, e de tempos em tempos acordar
para se comunicar na rede. Operando nesse modo, eles consomem pouca energia podendo ser
alimentados, inclusive, por baterias durante meses e ate anos. Esse baixo consumo de energia
2.2 Padr ao IEEE 802.15.4 e ZigBee 28

torna o ZigBee mais apropriado para sistemas de automacao se comparado a outras tecnologias
mais populares de rede sem fio como o Wi-Fi (IEEE, 2007).

No ZigBee as redes podem ser implantadas utilizando-se as topologias em forma de estrela,

em arvore ou em malha, como mostra a Figura 2.7. A topologia em estrela e formada por um
roteador - atuando como coordenador - e varios pontos finais, sendo que todas as mensagens da
rede passarao por esse roteador para chegarem ao seu destino. A topologia em arvore funciona
como uma arranjo de varias topologias em estrela. Ja na topologia em malha, o nucleo da rede
e formado por roteadores e podem haver pontos finais nas bordas. Nesse caso, as mensagens
podem passar por quantos dispositivos forem necessarios para chegar ao destino. Essa capa-
cidade de encaminhamento das mensagens do ZigBee permite a transmissao de mensagens a
distancias maiores que outras tecnologias de rede sem fio que tambem possibilitam baixo con-
sumo energetico como, por exemplo, o Bluetooth (BLUETOOTH, 1998) onde nao e possvel
topologias em malha.

Figura 2.7: Topologias da rede ZigBee.

2.2 Padr ao IEEE 802.15.4 e ZigBee 29

Segur anca

A segurancanasredesZigBee eumadascaractersticasquemaiso destacam em comparacao

a seus concorrentes. Para garantir a seguranca na troca de mensagens, estao presentes nele
funcionalidades como o controle de acesso, integridade das mensagens, confidencialidade das
mensagens, e protecao contra ataques de repeticao. Essas funcionalidades sao implementadas
naMAC Layer esao manipuladas pelos servicosdacamadadeaplicacao (SASTRY; WAGNER,
2004).

O controledeacesso previnequedispositivosintrusossecomuniquem numaredeprivada, j a

a integridade das mensagens, garante que as mesmas nao sejam alteradas no meio do percurso
de transmissao. Para garantir essas funcionalidades, e includo em cada pacote um Message
Authentication Code (MAC). O MAC funciona como um codigo de checksum criptografado.
Ele e gerado na origem utilizando-se uma chave secreta, e quando recebe o pacote, o destino
recalcula o MAC utilizando essa mesma chave secreta. Se o MAC recebido no pacote e o MAC
calculado no destino forem diferentes, significa que o pacotenao foi enviado por um dispositivo
pertencente a rede, ou que ele foi alterado (SASTRY; WAGNER, 2004).

Para garantir a confidencialidade das informacoes contidas nos pacotes, o ZigBee utiliza
criptografia. Essa confidencialidade, al em de garantir que um intruso nao tenha acesso a essas
informacoes, tem que garantir tambem que ele nao consiga acessar nenhuma parte delas. A
criptografia das mensagens no ZigBee e feita de modo simetrico, ou seja, os dispositivos de
origem e destino utilizam a mesma chave para criptografar e descriptografar as mensagens.
Para isso e utilizado o padrao AES (DAEMEN; RIJMEN, 2002) com chaves de 128 bits. Uma
unica chave pode ser compartilhada por todos os nos da rede, ou ainda, pode utilizar-se uma
chave distinta para cada par de nos que se comunicam.

Ataques de repeticao sao feitos repetindo-se mensagensdeum no valido narede sem altera-
las. Um exemplo seria a captura de uma mensagem de pagamento de uma pessoa destinada a
uma instituicao financeira. Quem capturou essa mensagem poderia enviar ela repetidas vezes,
e entao seriam efetuados diversos pagamentos. Para evitar isso, os pacotes da rede ZigBee
tem um campo onde e inserido um numero de sequencia, como visto na Figura 2.5, e caso um
dispositivo receba um pacote com o mesmo numero de sequencia de uma mensagem recebida
anteriormente, esse pacote sera descartado.
2.3 Arduino 30

2.3 Ar duino

A plataforma Arduino7 foi desenvolvida em 2005 no Interaction Design Institute Ivrea na

Italia com o intuito de ser utilizada como uma ferramenta simples e f acil de usar mesmo para
leigos em programacao e eletronica. Essas caractersticas tornaram ela uma plataforma muito
utilizada para o desenvolvimento de prototipos. Por se tratar de uma plataforma aberta de hard-
ware e software, qualquer fabricante pode montar e vender kits Arduino baseados no original
sem precisar pagar por isso.

O kit padrao do Arduino e composto por uma placa de silcio na qual e soldado um micro-
controlador da famlia Atmega8, que contem o codigo a ser executado, alem de conectores para
as portas do microcontrolador e para conexoes externas (p. ex. USB). Esse microcontrolador
contem portas de entrada e sada digitais, portas para comunicacao serial, portas de entrada
anal ogicas e de sada PWM (Power Wave Modulation), onde e possvel controlar o nvel de
tensao da sada, entre outras, como mostra a Figura 2.8. Nessas portas de entrada e sada e
possvel conectar botoes, sensores, LEDs ou quaisquer outros dispositivos el etricos, tornando
inumeras as possibilidades de uso para o kit.

Figura 2.8: Elementos de um kit Arduino (HERRADOR, 2009).

A expansao das funcionalidades do kit Arduino pode ser feita com a utilizacao de shields,
os quais, consistem de placas que devem ser acopladas aos kits e podem conter, entre outros
dispositivos, interfaces Ethernet ou Wi-Fi para se comunicarem pela rede IP, ou mesmo trans-
missores ZigBee o que tornaria esses kits nos dessa rede.

Para permitir que kits Arduino se comuniquem numa rede ZigBee podem ser utilizados os
7http://www.arduino.cc
8http://www.atmel.com
2.3 Arduino 31

modulos XBee (DIGI INTERNATIONAL INC., 2009). Esses modulos devem ser acoplados
a um XBee Shield9 e sao configuraveis para exercerem funcionalidades j a mencionadas na
Secao 2.2.

Para a programacao dos microcontroladores, o Arduino utiliza uma linguagem, baseada no

Wiring10, que e implementada em C/C++. Por esse motivo, a linguagem do Arduino encapsula
diversos aspectos de baixo-nvel da programacao do microcontrolador como, por exemplo, a
manipulacao de registradores. Isso torna a programacao do Arduino mais amigavel se compa-
rada a outras plataformas(WADDINGTON; TAYLOR, 2007).

Para o desenvolvimento de projetos no Arduino foi criada uma Integrated Development

Environment (IDE) onde o usuario pode escrever e compilar seus codigos. Al em disso, ela
possui uma ferramenta chamada Serial Monitor onde e possvel enviar dados pela porta serial
do Arduino e visualizar os dados recebidos. Na IDE tambem estao disponveis codigos com
exemplos de utilizacao dos mais variados dispositivos el etricos.

A Figura 2.9 mostra um dos exemplos de codigo disponveis na IDE. Apos ser compilado
e instalado no microcontrolador, ele faz com que o mesmo acende e apague um LED, que
deve estar conectado na porta digital. Todos os programas escritos para a plataforma Arduino
deverao conter as funcoes setup() e loop(). A funcao setup() e sempre chamada no incio da
execucao, antes de qualquer outra e pode ser utilizada para inicializar vari aveis e configurar
as portas do microcontrolador. A funcao loop() e chamada em seguida, ela e repetida infinitas
vezes, portanto, e nela que devera ficar toda a l ogica do programa. Outras funcoes podem ser
criadas, porem, elas so poderao ser chamadas de dentro das funcoes setup() ou loop().

1 void setup() {
2

3 // inicializando a porta digital como saida

4 // A porta 13 tem um LED conectado a ela na maioria dos kits Arduino:
5 pinMode(13, OUTPUT);
6 }
7

8 void loop() {
9
10 digitalWrite(13, HIGH); // acende o LED
11 delay(1000); // espera por um segundo
12 digitalWrite(13, LOW); // apaga o LED
13 delay(1000); // espera por um segundo
14 }

Figura 2.9: Codigo para piscar um LED no Arduino.

9http://www.libelium.com
10http://wiring.org.co
2.4 XBee 32

2.4 XBee

Os modulos XBee foram desenvolvidos pela Digi International 11 - membro da ZigBee Al-
liance - com o intuito de permitir que dispositivos eletronicos de todos os tipos se comuniquem
pela rede ZigBee. Esses modulos consistem em pequenas placas onde estao presentes transmis-
soresquesecomunicam em redesZigBeeutilizando radiofrequencia. Asinformacoesrecebidas
pelo radio podem, inclusive, ser passadas para o dispositivo que faz uso do modulo atraves da
comunicacao serial existente entre eles.

Existem duas versoes de modulos XBee, denominadas Series 1 e 2, sendo a principal

diferenca entre as duas a capacidade de roteamento de mensagens, presente apenas na Series
2. Existe ainda uma versao PRO de cada Serie, que basicamente tem a potencia de transmissao
maior do que as versoes comuns, porem, resultando num consumo maior de energia.

Os modulos XBee podem operar tanto no modo AT quando no modo Application Program-
ming Interface (API). No modo AT a comunicacao com os outros modulos e feita de forma
transparente, ou seja, os dados sao enviados como se os dois modulos - transmissor e receptor
- estivessem conectados por uma interface serial. Ja no modo API os dados sao enviados em
forma de pacote que, al em dos dados, carregam informacoes como endereco de origem e de
destino.

Para a configuracao dos modulos XBee pode ser feito uso do aplicativo X-CTU12, tambem
desenvolvido pela Digi. Inicialmente e necessario escolher as configuracoes da comunicacao
serial como aportaem queo modulo estaconectado eataxadecomunicacao, quedeveser igual
a utilizada pelo modulo (Figura 2.10(a)). Concluindo as configuracoes iniciais j a e possvel
configurar o modulo no menu, mostrado na Figura 2.10(b), com as caractersticas desejadas,
tais como o identificador da rede, seu endereco, o canal utilizado na comunicacao, opcoes de
criptografia, entre outras.

2.5 Android

Os telefones inteligentes se tornaram populares, contudo, seus sistemas operacionais pro-

prietarios dificultam o desenvolvimento de uma mesma aplicacao para diferentes dispositivos
moveis. Por essarazao, um grupo deempresaslideradaspelo Googleformaram aOpen Handset
Alliance. Essa alianca tem como objetivo o desenvolvimento do Android (OPEN HANDSET
11http://www.digi.com
12http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125
2.5 Android 33

(a) Configurar comunicacao serial do X-CTU (b) Gravar configuracoes no modulo

Figura 2.10: Configuracao de modulos no X-CTU

ALLIANCE, 2008), um sistema operacional de codigo aberto, e por isso, pode ser utilizado por
qualquer fabricante de dispositivos moveis.

Como mostra a Figura 2.11, na base da arquitetura do Android encontra-se um Kernel Li-
nux. Sobre ele estao as bibliotecas C/C++ de varios componentes do sistema como a biblioteca
de mdia, a do banco de dados SQLite13, a de gerenciamento da tela, entre outras. Sobre o Ker-
nel tambem roda a Dalvik, uma maquina virtual Java otimizada para dispositivos moveis que
possui recursos para economia de memoria e implementa a compilacao JIT (Just In Time) para
economia de processamento. Rodando sobre a maquina virtual e fazendo uso das bibliotecas
estao as aplicacoes do sistema e as aplicacoes do usuario.

Para o desenvolvimento das aplicacoes para Android o Google disponibilizou um Software

Development Kit (SDK). Esse kit contem, entre outras ferramentas, um emulador de telefone
celular - onde e possvel testar as aplicacoes, codigos com diversos exemplos de aplicacoes
e ferramentas de depuracao. Para a escrita dos codigos e recomendado a utilizacao da IDE
Eclipse14, onde, al em de escrever, e possvel compilar e instalar aplicacoes no emulador de
maneira simples gracas a um plugin disponibilizado pela propria Google para a integracao da
SDK com o Eclipse.

Para a programacao de software e utilizada a linguagem Java, entretanto, para a criacao

13www.sqlite.org
14www.eclipse.org
2.5 Android 34

Figura 2.11: Arquitetura do Android.

das interfaces graficas pode ser utilizada tambem a linguagem Extensible Markup Language
(XML), deixando o codigo Java apenas com a l ogica de programacao. Quando se utiliza XML
na criacao da interface grafica, e necessario atribuir aos objetos nesses arquivos um valor de
identificacao para que eles possam ser convertidos para objetos Java, como e mostrado na Fi-
gura 2.12.

Figura 2.12: Aplicacao Android utilizando Java e XML.

 35

3 DroidLar

Os sistemas de automacao residencial apresentados na Secao 2.1 oferecem muitas opcoes

de configuracao, al em disso, os mais sofisticados possibilitam a utilizacao de aplicativos em
telefones inteligentes. Em contrapartida, as suas infraestruturas proprietarias limitam as opcoes
do usuario na hora de substituir um dispositivo, ou mesmo, ampliar a automacao na residencia.
O DroidLar consiste num sistema de automacao residencial completo, onde e possvel controlar
eletroeletronicos de uma residencia utilizando como interface de controle celulares Android.

3.1 Arquitetur a

A arquiteturado DroidLar foi construdadeformacentralizada, ou seja, um servidor central

gerencia toda a rede. Este e capaz de se comunicar tanto com as interfaces de controle quanto
com os dispositivos controladores. Como e possvel ver na Figura 3.1, o DroidLar e dividido
em tres partes: cliente Android, Servidor de Automacao Residencial (SAR), e kits Arduino.
O cliente Android atua como uma interface de controle no sistema e se comunica pela rede
IP, os kits Arduino funcionam como controladores de dispositivos e utilizam ZigBee para a
comunicacao, j a o SAR e o servidor central, ele se comunica tanto pela rede IP quanto por
ZigBee e tem como principal funcao transferir as mensagens entre essas duas redes.

3.1.1 Controladores de Dispositivos

Os controladores de dispositivos, na automacao residencial, tem a funcao de executar os

comandos enviados pelas interfaces de controle nos eletroeletronicos da residencia tais como
acender l ampadas, fechar cortinasealterar a temperaturadeaparelhos dear-condicionado. Nor-
malmente, esses dispositivossao constitudos demicrocontroladores erealizam acoes deacordo
com o comando recebido.

Nesse trabalho foram utilizados kits Arduino para a prototipagem dos controladores de
dispositivos, devido as suas caractersticas apresentadas na Secao 2.3. A Figura 3.2 e uma
3.1 Arquitetura 36

Figura 3.1: Elementos do DroidLar.

fotografia desses kits, nela e possvel ver que em cada matriz de contato estao dispostos tres
LEDs e tres botoes, al em defios conectados as portas do microcontrolador presente no Arduino.
Os LEDs fazem o papel das l ampadas controladas de uma residencia. Estes estao conectados
nas sadas Pulse Width Modulation (PWM) do microcontrolador. Os botoes estao conectados
nas entradas digitais e fazem a funcao de interruptores das l ampadas (Figura 3.3).

Figura 3.2: Prototipos do DroidLar.

Para a comunicacao com o SAR pelo protocolo ZigBee (ZIGBEE ALLIANCE, 2005) fo-
ram acoplados aos kits Arduino modulos XBee1 utilizando shields. Esses modulos recebem as
mensagens pela rede sem fio e as transferem para o microcontrolador utilizando uma conexao
serial. Os modulos XBee foram configurados em modo API (DIGI INTERNATIONAL INC.,
2009) e, por isso, recebem as mensagens em forma de pacote. No microcontrolador e feito
o mapeamento desses pacotes para tornar as suas informacoes legveis e entao, executar um
1http://www.digi.com
3.1 Arquitetura 37

determinado procedimento.

Figura 3.3: Configuracao dos circuitos nos Kits.

Os kits Arduino possuem apenas duas funcoes: (1) executar efetivamente os comandos
recebidosno eletroeletronico conectado aumadesuasportas; (2) enviar ao SAR umamensagem
contendo o estado dos dispositivos que controla, por exemplo, a quantidade de dispositivos, o
tipo de dispositivo e se estao ligados ou nao. A primeira e executada toda vez que e recebida
uma mensagem do SAR com a requisicao do comando, j a a segunda, e executada sempre que o
dispositivo controlador e ligado e, tambem, quando e recebida uma mensagem de varredura do
SAR.

Na escrita do codigo do Arduino, foi utilizada uma API, implementada em C/C++, para
facilitar a manipulacao das mensagens ZigBee 2. Ela simplifica o processo de montagem dos
pacotes enviados e o mapeamento dos pacotes recebidos. Al em disso, nessa API estao contidas
instrucoes que possibilitam facilmente a obtencao de campos importantes dos pacotes como a
informacao recebida e o endereco de origem.

Para a configuracao dos modulos XBee foi utilizado o aplicativo X-CTU3. Foi escolhido
54 Mbytes para o tamanho maximo do conteudo dos pacotes. A criptografia foi desabilitada e,
por isso, nao sera utilizado espaco extra dos pacotes. A comunicacao serial entre o modulo e o
microcontrolador, foi configurada com a taxa de 9,6 Kbps e o sinal de radiofrequencia para ser
transmitido com aproximadamente 3 dBm de potencia.

3.1.2 SAR

O SAR e o servidor central do DroidLar. Ele e capaz decomunicar-se tanto pelas redesZig-
Beequanto pelasredesIP. Isso sedeveao fato deter sido utilizado redesZigBeenacomunicacao
2http://code.google.com/p/xbee-arduino
3http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=125
3.1 Arquitetura 38

dos controladores de dispositivos, por causa das caractersticas j a descritas na Secao 2.2, e os
telefones inteligentes presentes no mercado nao poderem se comunicar nessas redes, sendo ca-
pazes de se comunicar apenas nas redes IP. Por essa razao, cabe ao SAR a transferencia das
mensagens entre essas duas redes.

O servidor deautomacao residencial devepermanecer operando constantemente, pois, al em

de gerenciar as mensagens trocadas entre os membros da rede, ele e responsavel tambem por
executar tarefas agendadas pelo usuario como acender ou apagar as luzes de determinadas
l ampadas em determinadas datas.

O SAR foi implementado em formadeum softwarerodando num computador pessoal. Para

essa aplicacao se comunicar com o cliente no Android e necessario que esse computador esteja
conectado em alguma rede IP, j a para a comunicacao com os kits Arduino, e necessario que
haja um modulo XBee, assim como nos Arduinos, conectado em uma das portas USB desse
computador (Figura 3.2). Esse modulo XBee tem que estar configurado como coordenador da
rede ZigBee e, assim, ser o responsavel pelas configuracoes dessa rede.

Umaalternativaparaacomunicacao naredeIPpor partedaaplicacao servidora, eautilizacao

desockets Transmission Control Protocol (TCP) diretamente. Sockets sao interfaces, acessveis
na camada de aplicacao, que permitem criar conexoes na rede IP utilizando um endereco dessa
rede e uma porta TCP. A utilizacao deles e bastante simples e, por isso, sistemas que tenham
uma grande quantidade de conexoes simultaneas terao que implementar uma l ogica adicional
para suportar essa demanda.

Aplicacoes servidoras de grande porte e que necessitem que tarefas complexas sejam exe-
cutadas em segundo plano, podem ser implementadas fazendo uso de aplicacoes Web. Essas
aplicacoes funcionam como extensoes de servidores Web e, por isso, procedimentos como o
controle de acessos, manutencao de sessoes das conexoes e manipulacao de mensagens de pro-
tocolos da camada de aplicacao, sao transparentes ao desenvolvedor durante a escrita destas
aplicacoes.

Uma das tecnologias para aplicacoes Web testadas nesse trabalho foram os Servicos Web.
Eles tem como principal caracterstica a comunicacao multiplataforma, ou seja, servicos ope-
rando em sistemas distintos podem comunicar-se diretamente. Essa transparencia e conseguida
pelo fato dos dados, de ambos os lados, serem enviados por meio de XML. A utilizacao de
XML implica num numero maior de bytes na troca de mensagens se comparada a transmissao
de mensagens contendo informacao pura. Outra caracterstica dos Servicos Web e que eles nao
guardam o estado das vari aveis do seu codigo, sendo necessaria a utilizacao de servicos adi-
cionais, como banco de dados, para isso, o que pode ser um incomodo na fase inicial de um
3.1 Arquitetura 39

projeto.

Para a implementacao do SAR foi utilizado um Servlet. Os Servlets sao programas escritos
em Java utilizados em aplicacoes Web. Eles tem o acesso direto as requisicoes HTTP recebidas
pelo servidor Web, portanto, podem interagir com qualquer aplicacao clientequetambem utilize
HTTP para se comunicar. Diferentemente dos servicos Web, eles consistem em classes Java
instanciadas uma unica vez - quando o servidor Web e iniciado - o que os permite memorizar as
vari aveis dos seus codigos e mante-las durante todo o tempo de execucao.

A aplicacao Web na qual consiste o SAR deve rodar sobre um servidor Web que suporte
esse tipo de tecnologia e, consequentemente, atue como uma interface de acesso a rede externa
para esta. No projeto DroidLar foi utilizado o servidor de aplicacao GlassFish4 porem, outros
servidores de aplicacao que tambem oferecem esse tipo de suporte poderiam ser utilizados,
como por exemplo o Apache Tomcat5.

Para a escrita da l ogica para a comunicacao com os kits Arduino pela rede ZigBee, foi
utilizada uma API 6 em Java. Essa API, assim como a utilizada para a programacao dos Ar-
duinos, possibilita de maneira simples acessar os dados dos pacotes recebidos tais como seu
endereco de origem, a funcao desse dispositivo na rede ZigBee (se e roteador ou end-device)
e as informacoes, propriamente ditas. Al em disso, ele possibilita o envio de comandos AT
ao modulo conectado ao SAR, o que possibilita o acesso por codigo das configuracoes desse
modulo.

O SAR possui a funcionalidade de executar varreduras na rede ZigBee. Essa acao e tomada
toda vez em que ele recebe uma requisicao do cliente Android. O SAR entao envia uma men-
sagem para todos os dispositivos da rede ZigBee e os que estiverem ativos respondem com suas
informacoes e, assim, e possvel atualizar as listas com os dados conhecidos pelo servidor.

O SAR pode, ainda, receber tanto mensagens de controle quanto mensagens de gerencia-
mento. As mensagens de controle sao enderecadas aos controladores de dispositivos para to-
marem acoes como a de acender parcialmente determinada l ampada, tendo o SAR a funcao de
recebe-las da rede IP e transferi-las para a rede ZigBee e vice-versa. Ja as mensagens de geren-
ciamento sao trocadas apenas entre o SAR e os clientes Android e podem ser para autenticacao
ou edicao de perfis.
4http://glassfish.java.net
5http://tomcat.apache.org
6http://code.google.com/p/xbee-api
3.1 Arquitetura 40

3.1.3 Cliente Android

Com a popularizacao dos telefones inteligentes foi possvel a criacao de interfaces de con-
trole para sistemas de automacao residencial mais sofisticadas e com uma usabilidade maior
para o usuario. Por isso, no DroidLar foi utilizado como interface de controle uma aplicacao
disponvel para telefone inteligentes que rodem Android.

Essa aplicacao atua como um cliente enviando requisicoes ao servidor, para executar suas
funcoes. Ela utiliza as conexoes de rede disponveis em telefones Android como 3G e Wi-Fi,
paraseconectar aumaredeIP. Quando estaconectado aumaredeIP, aaplicacao podeenviar as
mensagens com os comandos ao SAR utilizando o protocolo HTTP, como visto na Secao 3.1.2.
A aplicacao cliente nao necessita estar o tempo todo conectada ao SAR, mas somente quando
for enviar algum comando.

Quando o usuario acessa a aplicacao e exibida a ele a tela mostrada na Figura 3.4(a). Nela
estao presentestodas as funcoes queo usuario podeexecutar no sistema. Paraexecutar qualquer
funcionalidade no sistema, o usuario precisa estar autenticado no servidor. Por isso, na primeira
vez que o usuario acessa o aplicativo, a tela mostrada e a de configuracoes (Figura 3.4(b)).
Nessa tela o usuario deve inserir seus dados de identificacao e senha, al em do endereco IP e
porta utilizados pelo SAR. Caso queira fazer alteracoes nesses dados, o usuario pode clicar no
botao com um cone de engrenagem na tela inicial.

(a) Tela inicial (b) Informacoes sobre o servidor

Figura 3.4: Interface principal e de configuracao do SAR

3.1 Arquitetura 41

A Figura 3.5(a) demonstra uma tela para o controle de l ampadas. Nela o usuario pode
acender ou apagar quaisquer l ampadas da lista apenas clicando no seu cone, ou pode confi-
gura-las com um nvel intermedi ario de luminosidade arrastando o dedo na barra horizontal
correspondente a essa l ampada.

O controledel ampadas ebaseado no envio devaloresnumericos, correspondentesao estado

em que se queira configurar a l ampada, aos controladores de dispositivos. Em valores percen-
tuais seriam 0% para apagar totalmente uma l ampada e 100% para acende-la. Dessa forma, e
possvel utilizar esse sistema de valores para controlar diversos itens da residencia como persi-
anas e portoes eletronicos. A unica diferenca esta no equipamento acoplado as sadas do con-
trolador, que no caso das l ampadas, tem apenas que reduzir ou aumentar a tensao proveniente
da rede el etrica da residencia.

Outra funcionalidade presente no cliente Android e o gerenciamento de perfis. Ele pode

ser iniciado clicando-se no botao com um cone de rel ogio na tela principal, encaminhando o
usuario para a tela mostrada na Figura 3.5(b). Nela, o usuario pode criar, editar e excluir perfis.
Esses perfis sao grupos dedispositivos queserao acionadosna mesma data. Os dispositivos per-
tencentes a algum perfil possuem um horario inicial para serem configurados com determinado
valor e um horario final para configurar outro valor. Mesmo sendo executados na mesma data,
dispositivos pertencentes a um mesmo perfil podem ser executados em horarios diferentes.

(a) Controle dos dispositivos (b) Configuracao dos perfis

Figura 3.5: Interfaces para configuracao dos dispositivos e perfis

3.2 Protocolo 42

3.2 Protocolo

Para a comunicacao entre as tres partes do DroidLar, foi necessaria a criacao de um pro-
tocolo na camada de aplicacao. As mensagens desse protocolo podem ter destinos diferentes
dependendo do seu tipo. Como visto anteriormente, elas sao transmitidas pelo clienteAndroid e
recebidas pelo SAR utilizando o protocolo HTTP, por isso, os dados sao passados como strings.
As mensagens entre o SAR e os controladores, que trafegam pela rede ZigBee, sao enviadas em
forma de valores do tipo inteiro. Para evitar erros, os campos das mensagens que passarem
pelas duas redes foram padronizados com valores numericos.

3.2.1 Cliente Android SAR

As mensagens trocadas entre o cliente Android e o SAR servem para configurar as funci-
onalidades extras do DroidLar. Funcoes de seguranca, agendamento de perfis e configuracoes
dos dispositivos, agregam recursos ao sistema e aumentam as possibilidades de uso do mesmo,
al em do simples acender e apagar de l ampadas. Com excecao das mensagens de autenticacao,
essas mensagens sao divididas nos seguintes campos: Tipo, Endereco, Conteudo, e Opcional
(Figura 3.6). Porem, para as mensagens a seguir (exceto a de autenticacao) serao utilizados
apenas os campos Tipo e Conteudo.

Figura 3.6: Mensagem de controle padrao.

Autenticacao

A mensagem de autenticacao e indicada pela constante MSG AUTENTICACAO. Para o

envio dos dados de usuario e senha sao utilizados os campos de Endereco e Conteudo presentes
nas demais mensagens, como e mostrado na Figura 3.7.

Figura 3.7: Mensagem de controle usada na autenticacao.

Quando o aplicativo cliente deseja se conectar no sistema, ele simplesmente envia uma
mensagem MSG AUTENTICACAO contendo seus dados. Ao receber essamensagem o SAR ira
verificar se esses dados pertencem a algum usuario j a cadastrado no sistema. Se ele encontrar,
o usuario recebera uma mensagem de confirmacao, apenas com o campo Tipo preenchido com
3.2 Protocolo 43

a constante MSG SUCESSO, indicando que esta apto a operar as funcoes do sistema, caso
contrario, recebera uma mensagem de erro, contendo apenas a constante MSG ERRO como
tipo (Figura 3.8).

Figura 3.8: Mensagem de autenticacao.

Requisicao de Dispositivos

Para montar a lista de dispositivos que serao controlados ou mesmo adicionados em algum
perfil, o cliente Android utiliza informacoes contidas no SAR, ou seja, elas nao ficam armaze-
nadas no dispositivo movel, sempre que for necessario o cliente fara uma requisicao ao SAR
dessa lista contendo as informacoes dos dispositivos.

O clienteAndroid pode requisitar alista completadedispositivos contidano SAR, paraisso

e enviada uma mensagem com o tipo definido pela constante REQUEST DISP. Em seguida o
servidor envia a lista com as informacoes de todos os dos dispositivos ativos (Figura 3.9). Em
determinados momentos a aplicacao necessita apenas das informacoes de determinados tipos
de dispositivos, para isso, e enviada uma mensagem do tipo REQUEST TIPO (Figura 3.10).

Figura 3.9: Mensagem de requisicao das informacoes de todos os dispositivos.

3.2 Protocolo 44

Figura 3.10: Mensagem de requisicao das informacoes de dispositivos pelo tipo.

Alter acao de Per fis

A sequenciadaFigura 3.11 eexecutada sempre que o usuario acessa ateladeconfiguracoes

deperfisno clienteAndroid. Primeiramenteumamensagem do tipo REQUEST PERFIL UUID
e enviada solicitando o valor de identificacao da atual versao de perfis configurados no SAR. Se
esse valor for diferente do valor contido na aplicacao cliente significa que as configuracoes de
perfis presentes nesse cliente nao sao as mais recentes. Quando isso acontecer, sera requisitado
ao usuario sobrescrever assuasconfiguracoeslocaiscom asdo servidor, ou o processo contrario,
sobrescrever as configuracoes do servidor com as suas.

Figura 3.11: Mensagem de requisicao do ID da lista de perfis.

Quando quiser enviar suas configuracoes de perfis ao SAR o usuario deve enviar uma men-
sagem do tipo MSG PERFIL inserindo no campo Conteudo uma string formatada contendo
essas configuracoes (Figura 3.12).

Se o usuario optar em receber os perfis configurados no servidor, entao, a aplicacao enviara

umamensagem do tipo REQUEST PERFIL. Como respostaserarecebidaumastring formatada
com as configuracoes de perfis atuais do SAR (Figura 3.13).

Configur ar Nomes

A configuracao dos nomes pode ser efetuada apenas por usuarios que contenham permissao
de superusuario. Para alterar os nomes dos dispositivos configurados na aplicacao Android
no SAR, e enviada a ele uma mensagem do tipo MSG SET NOME com o campo Conteudo
3.2 Protocolo 45

Figura 3.12: Mensagem de atualizacao de perfis.

Figura 3.13: Mensagem de requisicao da lista de perfis.

preenchido com uma string contendo os novos nomes dos dispositivos. Em caso de sucesso,
sera recebida uma mensagem de confirmacao do tipo MSG SUCESSO, caso contrario, se o
usuario autenticado nao possuir privil egios de superusuario, entao, sera recebida a mensagem
do tipo MSG ERRO (Figura 3.14).

Figura 3.14: Mensagem de configuracao dos nomes.

Configur ar Var redur a Per i odica

Outra funcionalidade configurada apenas por superusuarios e a varredura peri odica. Para
isso, eenviadaumamensagem do tipo SET VARREDURA inserindo no campo Conteudo um va-
3.2 Protocolo 46

lor correspondente ao intervalo de tempo entre as varreduras. Como resposta sera recebida uma
mensagem do tipo MSG SUCESSO, se o usuario possuir privil egios de superusuario, senao,
sera recebida uma mensagem do tipo MSG ERRO (Figura 3.15).

Figura 3.15: Mensagem de configuracao da varredura peri odica.

3.2.2 Cliente Android SAR Controladores

Controle

A principal funcionalidade do cliente Android e a possibilidade de controle dos eletro-

eletronicosdaresidencia. Atravesdo envio demensagensdo tipo MSG CONTROLE erealizado
esse controle. No campo Endereco e inserido o endereco de 64 bits da rede ZigBee do contro-
lador que devera executar esse comando. O campo Conteudo e preenchido com o valor que o
dispositivo controlado devera assumir, sendo 0 para totalmente desligado e 255 para totalmente
ligado. Ja o campo Opcional nao tem funcao especfica. Nesse trabalho os kits Arduino foram
configurados para controlar ate tres dispositivos, por isso, o campo Opcional foi utilizado para
indicar a qual desses tres eletros controlados se destinava ocomando (Figura 3.16).

Var redur a

A mensagem de varredura tem como objetivo recolher informacoes dos controladores ati-
vos no sistema de forma automatica. Para isso, e necessario o envio de uma mensagem do tipo
MSG VARREDURA. Quando essa mensagem e recebida pelo SAR, o mesmo envia uma men-
sagem, do tipo REQUEST INFO, em broadcast pela rede ZigBee requisitando as informacoes
dos dispositivos. Os controladores que estiverem ativos na rede responderao ao SAR enviando
mensagens do tipo RESPONSE INFO. O servidor utilizara essas mensagens para atualizar suas
listascom asinformacoesdoscontroladores. Ao invesdessasinformacoes, o clienteAndroid re-
3.2 Protocolo 47

Figura 3.16: Mensagem de controle.

cebera como resposta do SAR apenas uma mensagem de confirmacao, j a que essas informacoes
recebidas serao requisitadas posteriormente (Figura 3.17).

Figura 3.17: Mensagem de varredura.

3.2.3 SAR Controladores

I nfor macoes I niciais

Sempre que um controlador de dispositivos e ligado ele tenta se conectar na rede ZigBee e
enviar suas configuracoes ao SAR tais como seu endereco, quantos e que tipo de dispositivos
elecontrola. Paraisso, o controlador enviauma mensagem do tipo RESPONSE INFO, amesma
que ele envia durante a varredura, para o endereco zero, correspondente ao coordenador da rede
ZigBee, utilizado pelo modulo XBee do SAR (Figura 3.18).

Atualizacao de Estado

Quando o usuario altera o estado de um dispositivo sem utilizar a aplicacao do Android,

como por exemplo acender a luz utilizando um interruptor, e enviado ao SAR uma mensagem
3.3 Casos de Uso 48

Figura 3.18: Mensagem com as informacoes.

contendo esse novo estado do eletroeletronico. Essa mensagem e do tipo UPDATE ESTADO
e serve para manter as interfaces de controles sempre atualizadas, mesmo quando ocorrerem
alteracoes externas (Figura 3.19).

Figura 3.19: Mensagem de atualizacao.

3.3 Casos de Uso

A Figura 3.20 contem o diagrama com as possibilidades de uso da aplicacao, ou seja, as

acoes que um usuario pode executar enquanto estiver utilizando o cliente Android. E possvel
perceber que um pre-requisito para todos os casos e a autenticacao do usuario no sistema, inclu-
sive como superusuario, nos casos Alterar os nomes das l ampadas e Configurar a varredura
peri odica .

Autenticar no sistema

Na primeira vez em que abrir a aplicacao ou selecionando a opcao configuracoes, no menu

inicial daaplicacao, o usuario sera encaminhado paraainterfacede configuracoes do aplicativo.
Nela, o usuario deve inserir seus dados de usuario e senha, al em do endereco IP e porta do
servidor. Depois de inserir as informacoes, o usuario deve clicar no botao Salvar para o
aplicativo memoriza-las.

Acender e apagar l ampadas

O usuario abre a aplicacao e seleciona a opcao de controlar as l ampadas, entao, e exibida

a ele a interface com uma lista de l ampadas carregadas do servidor, para serem controladas.
Quando ele clica num dos cones de l ampadas, a mesma inverte seu estado, ou seja, se estava
apagada acende e vice-versa.
3.3 Casos de Uso 49

Controlar a intensidade das l ampadas

O usuario abre a aplicacao e seleciona a opcao de controlar as l ampadas, entao, e exibida

a ele a interface com uma lista de l ampadas carregadas do servidor, para serem controladas.
Quando ele arrasta uma das barras de controle a intensidade de luz se altera, indo de totalmente
acesa a completamente apagada.

Figura 3.20: Diagrama de casos de uso da aplicacao.

Sincronizar per fis

O usuario abre a aplicacao e seleciona a opcao de perfis, entao, e exibida a ele a interface
para o gerenciamento de perfis. Quando a interface e exibida a aplicacao envia, automatica-
mente, ao servidor uma mensagem para verificar se o mesmo contem uma lista de perfis mais
atual. Caso exista, sera requisitado ao usuario escolher entre sobrescrever os seus perfis com os
do servidor, ou sobrescrever os do servidor com os seus. Depois de feita a verificacao, e exibida
3.3 Casos de Uso 50

ao usuario a lista de perfis.

Adicionar per fis

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis
com o servidor. Ele abre o menu de opcoes da aplicacao e seleciona a opcao Criar Perfil . E
exibida a ele uma interface onde deve ser inserido um nome para o perfil e, tambem, deve ser
selecionado os dias da semana ou do mes que esse perfil deve ser executado. Por fim, ele deve
confirmar a criacao do perfil clicando no botao Criar . Em seguida ele voltara para a interface
de configuracao de perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir
o menu de opcoes e selecionar a opcao Salvar Perfis .

Remover per fis

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis
com o servidor. Ele abre o menu de contexto de um determinado perfil da lista e seleciona
a opcao Remover Perfil . Entao, quando ele for requisitado se deseja confirmar a exclusao
do perfil deve responder que sim. Em seguida ele voltara para a interface de configuracao de
perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes e
selecionar a opcao Salvar Perfis .

Alter ar per fis

O usuario estanainterfacedegerenciamento deperfis, aposter sincronizado seusperfiscom

o servidor. Ele abre o menu de contexto de um determinado perfil da lista e seleciona a opcao
Editar Perfil . Sera exibida uma interface com o nome e os dias de execucao configurados
nesse perfil. O usuario tem apenas que alterar os dados que quiser e confirmar o salvamento das
informacoesclicando no botao Salvar . Em seguidaelevoltaraparaainterfacedeconfiguracao
de perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes
e selecionar a opcao Salvar Perfis .

Adicionar dispositivos

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis
com o servidor. Ele abre o menu de contexto de um determinado perfil da lista e seleciona
a opcao Adicionar Dispositivo . Sera exibida a ele uma interface onde e possvel escolher o
tipo de dispositivo que sera adicionado, a lista de dispositivos disponveis do tipo escolhido
anteriormente, os horario iniciais e finais para a execucao desse dispositivo no perfil ao qual
pertence, juntamente com os valores inicial e final para o estado desse dispositivo. Depois de
configurar essas informacoes o usuario deve confirmar o salvamento delas clicando no botao
Salvar . Em seguida ele voltara para a interface de configuracao de perfis. Para salvar as
3.3 Casos de Uso 51

alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes e selecionar a opcao
Salvar Perfis .

Remover dispositivos

O usuario estanainterfacedegerenciamento deperfis, aposter sincronizado seusperfiscom

o servidor. Ele abre o menu de contexto de um determinado dispositivo da lista e seleciona a
opcao Remover Dispositivo . Entao, quando ele for requisitado se deseja confirmar a exclusao
do dispositivo deve responder que sim. Em seguida ele voltara para a interface de configuracao
de perfis. Para salvar as alteracoes dos perfis no servidor, o usuario deve abrir o menu de opcoes
e selecionar a opcao Salvar Perfis .

Alter ar dispositivos

O usuario esta na interface de gerenciamento de perfis, apos ter sincronizado seus perfis
com o servidor. Ele abre o menu de contexto de um determinado dispositivo da lista e seleciona
a opcao Editar Dispositivo. Sera exibida uma interface com o tipo, os horarios e os valores
iniciais e finais configurados nesse dispositivo. O usuario tem apenas que alterar os dados
que quiser e confirmar o salvamento das informacoes clicando no botao Salvar . Em seguida
ele voltara para a interface de configuracao de perfis. Para salvar as alteracoes dos perfis no
servidor, o usuario deve abrir o menu de opcoes e selecionar a opcao Salvar Perfis .

Executar var redur a

O usuario deve abrir o menu de opcoes na interface inicial da aplicacao eselecionar a opcao
Fazer Varredura . O aplicativo mandara a mensagem de varredura ao servidor que respondera
com uma mensagem de confirmacao do recebimento da mesma, sendo esta confirmacao visvel
ao usuario em forma de um aviso na tela.

Alter ar os nomes das l ampadas

O usuario abre a aplicacao e seleciona a opcao de controlar as l ampadas, entao, e exibida

a ele a interface com uma lista de l ampadas carregadas do servidor, para serem controladas.
Quando o usuario abre um menu de contexto contido nos nomes das l ampadas, e apresentada
a ele uma segunda interface contendo o nome atual da l ampada. Depois de edita-lo o usuario
confirmar as alteracoes clicando no botao OK , fazendo-o voltar para a interface de controle
das l ampadas. Para salvar as alteracoes nos nomes das l ampadas no servidor, o usuario deve
abrir o menu de opcoes e selecionar a opcao Salvar Nomes .

Configur ar a var redur a per i odica

O usuario deve abrir o menu de opcoes na interface inicial da aplicacao eselecionar a opcao
3.3 Casos de Uso 52

Varredura Peri odica . Em seguida, sera exibida uma interface onde o usuario pode escolher o
tempo de intervalo entre as varreduras. O usuario pode ativar ou desativar a varredura peri odica
no servidor clicando nos botoes Ativar ou Desativar .
 53

4 Conclusoes

Os sistemas de automacao residencial atuais oferecem como interfaces de controle paineis

afixados em paredes, controles remotos, paginas Web ou aplicacoes para celulares. O sistema
operacional Android (OPEN HANDSET ALLIANCE, 2008) e um projeto aberto e por isso,
e utilizado em uma grande quantidade de telefones inteligentes. Ele possibilita a criacao de
aplicacoes tao complexas quanto as utilizadas em computadores pessoais.

Nesse trabalho foi apresentado o sistema de automacao residencial DroidLar. Ele permite
queum aplicativo rodando em celularesAndroid controleoseletroeletronicosdeumaresidencia
e possibilita tambem, o agendamento de comandos com a utilizacao de perfis. Esse sistema e
aberto, e seu codigo pode ser obtido em http://goo.gl/VZUYF.

Os controladores de dispositivos sao os elementos do sistema que executam os comandos

nos eletroeletronicos da residencia. Eles devem consumir pouca energia pois podem ser posi-
cionados em qualquer local da residencia podendo, inclusive, operar sem estarem conectados a
rede el etrica.

O protocolo ZigBee (ZIGBEE ALLIANCE, 2005) e tipicamente utilizado em redes de

baixa taxa de transmissao e com transmissores de baixa potencia. Por isso, ele se torna ener-
geticamente economico possibilitando que os dispositivos transmissores sejam alimentados por
baterias. Para aumentar a extensao da rede o ZigBee permite que dispositivos atuem como
roteadores e encaminhem as mensagens, formando uma topologia em forma de malha.

Essas caractersticas do ZigBee foram decisivas na sua escolha como a tecnologia para
a comunicacao dos controladores de dispositivos. Para a prototipagem desses controladores
foram utilizados kits Arduino1. Esses kits fazem parte de uma plataforma aberta de hardware
que visa o desenvolvimento de uma ferramenta de f acil utilizacao ate mesmo para leigos. Para
esses kits se comunicarem na rede ZigBee foram acoplados a eles modulos XBee2.

Como telefones inteligentes possibilitam a comunicacao em diversos tipos de rede sem

1http://www.arduino.cc
2http://www.digi.com
4.1 Trabalhos Futuros 54

fio como Wi-Fi (IEEE, 2007) e 3G, mas nao se comunicam em redes ZigBee, foi necessario o
desenvolvimento de um servidor centralizado na rede. O SAR tem como principal funcao trans-
ferir as mensagens vindas do cliente Android pela rede IP para os controladores de dispositivos
na rede ZigBee.

4.1 Tr abalhos Futuros

Esse trabalho tem o objetivo de ser o ponto de partida para a criacao de um sistema de
automacao residencial tao sofisticado quanto os presentes no mercado. Por se tratar de um
projeto de codigo aberto e que utiliza tecnologias abertas, sao inumeras as possibilidades de
adaptacoes, modificacoes e insercao de novos recursos.

Como trabalho futuro pode ser embarcado o SAR em um dispositivo micro controlado,
tornando o sistemamaiseconomico, pois, evitariaautilizacao deum computador pessoal ligado
constantemente. Al em disso, autilizacao deum dispositivo menor trariamobilidadeao servidor.

Outro trabalho futuro seria a expansao dos tipos de dispositivos que podem ser controlados
atraves da aplicacao Android, pois, atualmente apenas l ampadas sao suportadas. Esse processo
envolveria, al em da modificacao do codigo do cliente Android, a criacao de hardware extra
conectado aos controladores de dispositivos.
 55

Lista de Abreviaturas

PWM Pulse Width Modulation

API Application Programming Interface

I P Internet Protocol

TCP Transmission Control Protocol

CA Corrente Alternada

RF Radiofrequencia

CRC Cyclic Redundancy Check

BPSK Binary Phase Shift Keying

I SM Industrial, Scientific and Medical

CSM A/CA Carrier Sense Multiple Access With Collision Avoidance

DSSS Direct Sequence Spread Spectrum

FFD Full Function Devices

RFD Reduced Function Devices

FCS Frame Checksum Sequence

M AC Message Authentication Code

I DE Integrated Development Environment

SDK Software Development Kit

XM L Extensible Markup Language

M HR Medium Access Control Header

M FR Medium Access Control Footer

 56

L R-WPAN Low-Rate Wireless Personal Area Network

M AC L ayer Medium Access Control Layer

PHY Physical Layer

M AC Payload Medium Access Control Payload

 57

Refer encias Bibliogr aficas

BLUETOOTH, S. Bluetooth specification. 1998.

CHUNDURU, V.; SUBRAMANIAN, N. Effects of power lines on performance of home
control system. In: IEEE. Power Electronics, Drives and Energy Systems, 2006. PEDES06.
International Conference on. [S.l.], 2006. p. 16.
DA SILVA, A. A. J. P. Visaoweb - vigil ancia e controlo remoto. In: . 2005. Disponvel
em: < http://repositorio-aberto.up.pt/bitstream/10216/11540/2/Texto%
20integral.pdf> . Acesso em: 16 mai. 2011.
DAEMEN, J.; RIJMEN, V. The design of Rijndael: AESthe advanced encryption standard.
[S.l.]: Springer Verlag, 2002.
DARBEE, P. Insteon: The details. Smarthome Technology, p. 164, 2005.
DIGI INTERNATIONAL INC. Product manual v1.xex 802.15.4 protocol. pdf. ieee
802.15. 4 oem rf modules. 2009. Disponvel em: < http://ftp1.digi.com/support/
documentation/90000982_B.pdf> .
EUROX10. Teoria da transmissao de sinais x-10. In: . 2011. Disponvel em:
< http://www.eurox10.com/Content/X10SignalTheory.htm> . Acesso em: 26 jul. 2011.
HERRADOR, R. E. Gua de usuario de arduino. 2009. Disponvel em: < http:
//www.uco.es/aulasoftwarelibre/wp-content/uploads/2010/05/Arduino_user_
manual_es.pdf> . Acesso em: 26 mai. 2011.
IEEE. Part 15.4: Wireless Medium AccessControl (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless PersonalArea Networks (WPANs). [S.l.], jun. 2006.
Disponvel em: < http://www.http://standards.ieee.org/getieee802/download/
802.15.4-2006.pdf> .
IEEE. Wireless lan medium access control (mac) and physical layer (phy) specifications. IEEE
Std 802.11-2007 (Revision of IEEE Std 802.11-1999), p. C11184, 12 2007.
OPEN HANDSET ALLIANCE. Android operating system. 2008. Disponvel em:
< http://www.android.com> .
PINHEIRO, J. M. S. Sistemas de automacao. In: . 2004. Disponvel em: < http:
//www.projetoderedes.com.br/artigos/artigo_sistemas_automacao.php> . Acesso
em: 8 mai. 2011.
SARASWAT, V. et al. The X10 language specification. [S.l.], 2008.
SASTRY, N.; WAGNER, D. Security considerations for ieee 802.15. 4 networks. In: ACM.
Proceedings of the 3rd ACM workshop on Wireless security. [S.l.], 2004. p. 3242.
Refer encias Bibliogr aficas 58

SENA, D. Automacao residencial. 2005. Disponvel em: < http://www2.ele.ufes.br/

~projgrad/documentos/PG2005_2/dianecristinasouzasena.pdf> .
WADDINGTON, N.; TAYLOR, R. Arduino & Open Source De-
sign. 2007. Disponvel em: < http://web.media.mit.edu/~mellis/
arduino-chi2007-mellis-banzi-cuartielles-igoe.pdf> .

Z-WAVE ALLIANCE. Z-wave technology. 2004. Disponvel em: < http://www.z-wave.

com> .

ZIGBEE ALLIANCE. Zigbee specification. ZigBee Document 053474r06, Version, v. 1, 2005.