CENTRO PAULA SOUZA

FATEC OURINHOS
CURSO DE SEGURANÇA DA INFORMAÇÃO

Eder Luiz Alves Pinto

Renan Tavares Vieira

AUTOMAÇÃO RESIDENCIAL UTILIZANDO PROTOCOLO DE

COMUNICAÇÃO ZIGBEE IEEE 802.15.4

OURINHOS (SP)
2018
 EDER LUIZ ALVES PINTO
RENAN TAVARES VIEIRA

AUTOMAÇÃO RESIDENCIAL UTILIZANDO PROTOCOLO DE

COMUNICAÇÃO ZIGBEE IEEE 802.15.4

Projeto de Pesquisa para conclusão do curso

apresentado à Faculdade de Tecnologia de
Ourinhos para a conclusão do Curso de
Segurança da Informação. Orientador: Prof. Me.
Fadir Salmen.

OURINHOS (SP)
2018
 RESUMO
Vive-se em uma era em que a tecnologia e a informação são muito importantes para
o modo de vida, a tecnologia evolui em grande velocidade, com isso, aumenta-se o
volume de informação que devemos processar e, tarefas para se desempenhar
durante o dia. Este cenário, causa problemas que nos afeta, a gestão do tempo,
produtividade no trabalhos e desperdício de recursos. Surge então a necessidade de
otimizar e facilitar as tarefas diárias para que se possa executar todas as tarefas do
dia a dia. A automação de tarefas corriqueiras pode ajudar a melhorar a gestão do
tempo, qualidade de vida, conforto, melhorar a produtividade no ambiente de trabalho
e otimizar do consumo de recursos.
Para o desenvolvimento de soluções de automação residencial, normalmente os
sistemas de automação são compostos por um hardware de controle, responsável
pelo monitoramento de sensores e acionamento de dispositivos, e um software de
gerenciamento do sistema, que dispõe de funcionalidades básicas de cadastramento
de dispositivos, monitoramento de eventos e execução de comandos.
Este trabalho propõe a implementação de um sistema de automação residencial
controlados por um aplicativo móvel, conectado a um ponto wifi, contorlando um
sistema de automação que utiliza o protocolo de comunicação IEEE802.15.4 ZigBee
para comunicação. O projeto é composto de um módulo de controle, um módulo
controlador, gerenciados por meio de um aplicativo móvel Android, utilizando protocolo
IEEE802.15.4 ZigBee para a transmissão de dados.

Palavras chave: Automação; Arduino; ZigBee.

 ABISTRACT
To day we lives in an time in which the technology is very important for our lifestyle,
the technology evolves at a great speed, with that, it increases the volume of data that
can processed, the tasks to be carried out during the day. This scenario causes
problems that affect, time management, work productivity and lack of resources. Then
there is the task of optimizing and facilitating daily tasks so that all day-to-day tasks
are performed. Automating tasks can help improve the management of time, energy
consumption, quality of work and reduce resource consumption.
For the development of residential automation solutions, these systems are usually
composed of a hardware control, responsible for sensor monitoring and triggering of
devices, and system management software, which has basic device registration,
monitoring events and execution of commands.
This work proposes the implementation of a home automation system controlled by a
mobile application, connected to a wifi point, contorting an automation system that
uses the communication protocol IEEE802.15.4 ZigBee for communication.
The project consists to control module, a controller module, managed through an
Android mobile application using IEEE802.15.4 ZigBee protocol for data.

Transmission.Keywords: Automation; Arduino; ZigBee.

Lista de figuras:
Figura 2.1. Ilustração de uma placa Arduino. ............................................................ 10
Figura 2.2. Aspecto construtivo dos módulos XBee e XBee-Pro ............................... 12
Figura 2.3. Ilustração das camadas do Modelo ISO/OSI .......................................... 14
Figura 2.4. Modelo de sistema domótico. .................................................................. 20
Figura 2.5. Esquema de conexão e equipamentos usando protocolo X10. .............. 22
Figura 2.6. Representação gráfica da utilização do protocolo Cbus nas camadas que
trabalha no modelo OSI. ........................................................................................... 23
Figura 2.7. Rede com infra estruturada e rede AdHoc. ............................................. 25
Figura 2.8. Representação dos canais na faixa de frequência 2.4 Ghz. ................... 25
Figura 2.9. Distribuição dos canais na faixa de 5 Ghz. ............................................. 26
Figura 2.10. Estação trabalhando de acordo com a DCF. ......................................... 28
Figura 2.11. Mecanismo RTS/CTS do modo PCF. .................................................... 30
Figura 2.12. Estrutura de um quadro de tranmisão do padrão IEEE 802.15.4. ......... 33
Figura 2.13. Topologias implementadas pelo padrão IEEE802.15.4. ........................ 34
Figura 2.14. Arquitetura da pilha de protocolos ZigBee............................................. 35
Figura 2.15. Modos de transmissão suportado protocolo ZigBee (a) broadcast, (b)
multicast e (c) unicast. ............................................................................................... 37
Figura 3.1. Arquitetura do sistema de automação. .................................................... 39
Figura 3.2.Diagrama de conexão em nível de hardware. .......................................... 40
Figura 3.3. Tela do App Inventor Designer................................................................. 41
Figura 3.4. tela do Blocks Editor................................................................................ 42
Lista de tabelas:

Tabela 2.1. Canais e bandas de frequência do padrão IEEE 802.15.4. .................... 31

Tabela 2.2. Configuração dos canais e bandas do padrão IEEE 802.15.4. ............... 32
Tabela 2.3. Sensibilidade de Recepção e Alcance máximo do padrão IEEE 802.15.4.
.................................................................................................................................. 32
 SUMÁRIO
1. INTRODUÇÃO ................................................................................................. 7
1.1. O Problema. ................................................................................................. 7
1.2. Objetivo Geral............................................................................................... 8
1.3. Objetivo específico. ...................................................................................... 8
1.4. Justificativa do projeto .................................................................................. 8
2. REVISÃO BIBLIOGRÁFICA ............................................................................. 9
2.1. Sistema Operacional Linux Android.............................................................. 9
2.2. Arduino ....................................................................................................... 10
2.2.1. Hardware .................................................................................................... 11
2.2.2. Software ...................................................................................................... 11
2.3. Módulos XBee ............................................................................................ 11
2.3.1. Software XCTU ........................................................................................... 13
2.4. Modelo OSI................................................................................................. 13
2.4.1. Camada física. ............................................................................................ 14
2.4.2. Camada de Enlace...................................................................................... 14
2.4.3. Camada de rede. ........................................................................................ 15
2.4.4. Camada de transporte ................................................................................ 15
2.4.5. Camada de sessão ..................................................................................... 16
2.4.6. Camada de apresentação ........................................................................... 17
2.4.7. Camada de aplicativo.................................................................................. 17
2.5. Domótica. ................................................................................................... 18
2.5.1. Definição de domótica................................................................................. 18
2.5.2. Classificação das funções domótica. .......................................................... 18
2.5.2.1. Função de gestão ....................................................................................... 18
2.5.2.2. Função de controle. .................................................................................... 19
2.5.2.3. Função de comunicação............................................................................. 19
2.5.3. Arquiteturas. ................................................................................................ 19
2.5.4. Redes domóticas e padronização. .............................................................. 20
2.5.5. Principais padrões utilizados em redes domótica ....................................... 21
2.5.5.1. Padrão X-10 ............................................................................................... 21
2.5.5.2. Padrão CEBus ............................................................................................ 22
2.5.5.3. Padrão LONWORKS .................................................................................. 23
2.5.5.4. Padrão BACnet........................................................................................... 23
2.5.5.5. Padrão OSI ................................................................................................. 24
2.5.5.6. Padrão EIB ................................................................................................. 24
2.6. Rede Wi-Fi.................................................................................................. 24
2.6.1. Operações da camada física ...................................................................... 26
2.6.2. Detecção de Portadora ............................................................................... 26
2.6.3. Transmissão................................................................................................ 27
2.6.4. Recepção .................................................................................................... 27
2.6.5. Camada de Enlace...................................................................................... 28
2.7. PROTOCOLO IEEE 802.15.4 ZIGBEE....................................................... 30
2.7.1. O padrão IEEE 802.15.4 ............................................................................. 31
2.7.2. IEEE 802.15.4 Camada Física .................................................................... 31
2.7.3. Modos de Operação e topologias de rede IEEE 802.15.4 .......................... 33
2.7.4. Camada de Enlace (MAC) do padrão IEEE 802.15.4 ................................. 34
2.7.5. Camadas implementadas pelo ZigBee ....................................................... 34
2.8. Funções da camada de rede ZigBee.......................................................... 35
2.8.1. Modo de transmissão broadcast ................................................................. 36
2.8.2. Modo de transmissão unicast ..................................................................... 36
2.8.3. Modo de transmissão multicast ................................................................... 36
3. METODOLOGIA ............................................................................................. 38
3.1. Arquitetura do sistema de automação. ....................................................... 39
3.2. Arquitetura do Hardware ............................................................................ 40
3.3. Arquitetura do Software. ............................................................................. 40
3.3.1. Código fonte do dispositivo móvel............................................................... 41
3.3.2. Código fonte do módulo controlador. .......................................................... 42
3.3.3. Código fonte do módulo de controle. .......................................................... 43
4. CONCLUSÃO. ................................................................................................ 44
REFERÊNCIAS. ........................................................................................................ 45
APÊNDICE A – CÓDIGO FONTE DO MÓDULO CONTROLADOR.......................... 48
APENDICE B – CÓDIOGO FONTE DO MÓDULO DE CONTROLE ........................ 51
 7

1. INTRODUÇÃO
Vive-se em uma era em que a tecnologia e a informação são muito importantes
para o modo de vida, a tecnologia evolui numa velocidade exponencial, com isso,
aumenta-se o volume de informação que devemos processar e, tarefas para se
desempenhar durante o dia. Este cenário, causa problemas que nos afeta, a gestão
do tempo, produtividade no trabalho e desperdício de recursos. Surge então a
necessidade de otimizar e facilitar as tarefas diárias para que se possa acompanhar
o frenético e caótico dia a dia. A automação de tarefas corriqueiras pode ajudar a
melhorar a gestão do tempo, qualidade de vida, conforto, melhorar a produtividade no
ambiente de trabalho e otimizar do consumo de recursos (SILVA 3, 2017).
Acompanhando as tendências das casas inteligentes, a automação pode ser
encontrada em diversas residências, escritórios e apartamentos modernos pelo
mundo, tanto pela comunicação remota, quanto para medidas de segurança e lazer.
Os maiores atrativos estão relacionados ao laser, porque depois que a rede de
equipamentos estiver toda conectada, não será necessidade de se utilizar vários
controles remotos. Com a automação residencial é possível, por exemplo, definir
horários em que a cafeteira, o sistema climático e de iluminação serão acionados, bem
como identificar quem as acionou, também acionar portas e portões eletrônicos e
gerenciar sensores e alarmes do ambiente pode ser possível (BOTELHO, 2005).
Outro ponto importante na automação é o custo. O custo de uma automação
variará de acordo com a escolha realizada pelo consumidor. Normalmente essa
questão é avaliada da seguinte forma: o que é possível instalar na residência e o que
se procura em termos de integração. Regularmente em uma primeira análise
recomenda-se passar um valor entre 3 e 8% dos investimentos que a casa possui,
envolvendo luzes, cortinas, áudio, vídeo e alguma opção de segurança (MOURA,
2011).

1.1. O Problema.
É possível melhorar as condições de um ambiente residencial, com domótica?
 8

1.2. Objetivo Geral.

Desenvolver um projeto de automação, baseado no protocole ZigBee,
utilizando um aplicativo desenvolvido para dispositivos móvel, juntamente com
microcontroladores Arduino e módulos XBee.

1.3. Objetivo específico.

• Desenvolver um aplicativo para smartphone que será utilizado para

controlar o sistema de automação.
• Construir o sistema de automação usando micro controlador Arduino,
módulos XBee, módulo relê e Shields necessárias para a interconexão dos
hardwares mencionados.
• Estabelecer uma conexão entre o aplicativo instalado no smartphone, e o
sistema de automação para acionar e desligar interruptores, onde estão
conectados alguns dispositivos eletroeletrônicos.

1.4. Justificativa do projeto

Tendo em vista os grandes avanços na área tecnológica e a falta de tempo que
se enfrenta no cotidiano, este trabalho visa demonstrar que um sistema de automação
pode fornecer maior conforto ao usuário, melhorando a gestão do tempo gasto nas
tarefas corriqueiras, aumentando a eficiência na utilização dos recursos disponíveis.
 9

2. REVISÃO BIBLIOGRÁFICA
Este capítulo tem como objetivo expor todas as ferramentas e tecnologias
usadas no trabalho visando uma compreensão e embasamento para o
desenvolvimento do projeto utilizando o protocole IEEE802.15.4 ZigBee.

2.1. Sistema Operacional Linux Android

O Android é uma plataforma desenvolvida para smartphones, baseada em um
kernel UNIX, com uma vasta disponibilidade de bibliotecas e interface gráfica, também
disponibiliza ferramentas para a criação de aplicativos (LECHETA, 2009 apud
HUBSCH, 2012).
O sistema foi desenvolvido inicialmente para ser utilizado em máquinas digitais
avançadas pela empresa Android Inc., que foi incorporada pela Google, hoje chamada
de Alphabet Inc. O grande atrativo para a Alphabet e possuir uma plataforma aberta
aos fabricantes dos smartphones, assim tornando-o customizável, flexível e
atualizável. O Android possui uma arquitetura dividida em Kernel, runtime, bibliotecas,
framework e aplicativos. O Kernel é responsável por fazer a intercomunicação entre o
hardware e o software, gerenciando os recursos existentes no sistema e permitindo a
execução dos aplicativos. O Kernel também garante o uso otimizado da memória RAM
sem riscos de falhas. Runtime são bibliotecas que atuam em backgroud para
automatizar tarefas comuns realizadas em linguagens diferentes de programas e
sistemas operacionais. Runtime, também são utilizados para melhorar a eficiência do
sistema, por redução do número instruções necessárias para executar e reduzir os
recursos necessários utilizados pelos programas, tais como o espaço de disco,
quantidade de memória utilizado e uso do CPU (DEVELOPERS, 2017).
As bibliotecas são usadas para atividades como abertura de arquivos,
realização de cálculos aritméticos, exibição de imagens, vídeos e outros. O framework
de aplicativo, fornece componentes que auxiliam na implementação dos programas,
permitindo a criação de listas, grades, caixas de texto e botões. Aplicativos são
programas desenvolvidos que trabalham em conjunto do sistema operacional para
realizar diversas tarefas diferentes (HUBSCH, 2012).
 10

2.2. Arduino
O Arduino é uma plataforma de placa única projetada com um microcontrolador
com suporte a entrada/saída embutido, uma linguagem de programação padrão que
essencialmente é C/C++. A plataforma tem como objetivo criar ferramentas
acessíveis, de baixo custo, flexíveis e fáceis de usar (ARDUINO, 2017).
O Arduino pode ser usado utilizado no desenvolvimento de objetos interativos,
ou ainda para ser conectado a um computador hospedeiro. A placa Arduino é
composta por um controlador, algumas linhas de entrada/saída digital e analógica,
além de uma interface serial/USB, para interligar-se ao hospedeiro, que é usado para
sua programação e interação em tempo real. A placa Arduino não possui qualquer
recurso de rede, porém é comum a utilização de extensões apropriadas chamadas de
shields. A interface para a programação é simples, é pode ser escrita em diversas
linguagens. A mais popular é a Processing, mas outras que podem comunicar-se com
a conexão serial são: Max/MSP, Pure Data, SuperCollider, ActionScript e Java
(ARDUINO, 2017). A figura 2.1 mostra a Ilustração de uma placa Arduino.

Figura 2.1. Ilustração de uma placa Arduino.

Fonte: https://voidsetuploop.files.wordpress.com/2011/04/Arduino .png

 11

Hardware
Sua placa tem como ponto central um micro controlador Atmel AVR de 8 bits,
com componentes complementares que facilitar a programação e agregação de novos
circuitos. Um ponto importante a se notar é a forma padrão que os conectores são
expostos, isso permite ao CPU ser interligado a outros módulos shields. Os Arduinos
originais utilizam a série de chips MegaAVR, especialmente os ATmega8, ATmega168,
ATmega328 e a ATmega1280; porém existem muito clones que usam um variado tipo
de processadores (KASUO; AMARANTE; LINS, 2010).
A grande maioria de placas inclui um regulador linear de 5 volts e um oscilador
de cristal de 16 MHz (podendo haver variantes com um ressonador cerâmico), embora
alguns esquemas como o LilyPad usem até 8 MHz e dispensem um regulador de
tensão embutido, por ter uma forma específica de restrições de fator. Além de ser
micro controlador, o componente também é pré-programado com um bootloader, o
que simplifica o carregamento de programas para o chip de memória flash embutido,
em comparação com outros aparelhos que geralmente demandam um chip
programador externo (KASUO; AMARANTE; LINS, 2010).

Software
O Arduino IDE é uma aplicação multiplataforma escrita em Java. Esta IDE é
responsável por gravar a programação realizada no dispositivo Arduino. Em suas
funcionalidades temos um editor de código com recursos de realce de sintaxe,
identação automática e parênteses correspondentes, sendo capaz de compilar e
carregar programas para o módulo facilmente. Com isso não há a necessidade de
editar Makefiles ou rodar programas em ambientes de linha de comando (ARDUINO,
2017). Tendo uma biblioteca chamada "Wiring", ele possui a capacidade de programar
em C/C++. Isto permite criar com facilidade muitas operações de entrada e saída de
dados. (KASUO; AMARANTE; LINS, 2010).

2.3. Módulos XBee

Fabricados pela empresa Maxstream, operam na banda de 2.4Ghz, para
integração em sistemas que transmitem informação por rádio frequência. Suportam o
protocolo ZigBee e diferentes topologias, os módulos tem como característica
ausência de configuração externa, sendo possível realizar as operações através de
 12

comandos AT e de redes específicas de controle. Assim, atuam com

microcontroladores, através de uma Serial Peripheral Interface (SPI), encarregando-
se da transmissão/recepção dos dados (SILVA 1, 2017).

Apresentam dimensões muito reduzidas, inferiores a 3cm x 3 cm, e são em 2

versões distintas (XBee / XBee Pro), cuja diferença está na potência de transmissão.
Ao XBee está associado uma potência de 1mW e um alcance de 100m em área aberta
ou 30m em ambientes fechados, enquanto o XBee Pro, opera com uma potência de
60mW, o que lhe permite alcançar um raio de transmissão até 1,6km em área aberta
ou 100m em ambientes fechados. Em termos de consumo, são dispositivos que
apresenta um consumo muito reduzido, inferior a 10µA quando em estado sleep,
aumentando, no entanto, a necessidade de alimentação quando da
recepção/transmissão. No âmbito deste parâmetro, e como se torna evidente, é o
XBee quem apresenta menor consumo energético. Consome corrente de
aproximadamente 50mA quando em plena operação e uma tensão de alimentação de
3,3V (XBee Manual, 2017). A figura 2-2 mostra o aspecto construtivo dos módulos
XBee e XBee-Pro.

Figura 2.2. Aspecto construtivo dos módulos XBee e XBee-Pro

Fonte: (XBee Manual, 2017)

 13

Software XCTU
XCTU é uma aplicação multiplataforma gratuita que permite aos
desenvolvedores gerenciar módulos de frequência de rádio XBee (RF) através de uma
interface gráfica simples de usar. O aplicativo inclui ferramentas incorporadas que
facilitam a configuração, a configuração e o teste de módulos de XBee RF. Este
software é compatível com os sistemas operacionais mais utilizados.
Independentemente do tamanho da rede onde o dispositivo está inserido, o XCTU
pode simplificar as tarefas de gerenciamento de dispositivos (DIGI. 2017).

2.4. Modelo OSI

O Modelo OSI (Open System Interconnection) é um modelo de rede de
computador referência da ISO dividido em camadas de funções, criado em 1971 e
formalizado em 1983, com objetivo de ser um padrão, para protocolos de
comunicação entre os mais diversos sistemas em uma rede local (Ethernet),
garantindo a comunicação entre dois sistemas computacionais (end-to-end). Possui
em sua composição sete camadas. Hierarquicamente iniciando pela camada inferior
temos, a camada física no primeiro nível, no próximo nível temos a camada Enlace,
de Rede, de Transporte, de Sessão, de Apresentação, e de aplicativo (Suporte da
Microsoft, 2017). Na próxima página, a figura 2.3 mostra as camadas do modelo
ISO/OSI.
 14

Figura 2.3. Ilustração das camadas do Modelo ISO/OSI

Fonte: (CARDOZO; MAGALHÃES, p.8 2002)

Camada física.
Esta camada é responsável pela geração de sinais, elétricos, óticos ou
eletromagnéticos que serão transmitidos pelo meio físico. Protocolos nesta camada
especificam qual a duração e intensidade do sinal, utilizando técnica de multiplexação,
pinagem e outros (CARDOZO; MAGALHÃES, 2002).

Camada de Enlace.
A camada de enlace utiliza a camada física para a transmissão de quadros de
dados denominado dataframe. Estes dataframe são compostos de algumas centenas
de bytes e, são delimitados por sequência determinada de bytes. A camada de enlace
transmite dataframe, aguardando o respectivo dataframe de reconhecimento de
recepção. A transmissão de dataframe, mesmo com reconhecimento de recepção, não
é confiável. Os dataframe podem ser duplicados ou chegar fora de ordem. A
duplicação ocorre quando o dataframe de reconhecimento chega deformado, não
 15

sendo compreendido pelo receptor, nesse caso, o quadro de dados correspondente é

novamente enviado por falta de reconhecimento, gerando assim a sua duplicação. A
camada de enlace também controla o fluxo de quadros, evitando que um host envie
dataframes em uma tacha superior à que o receptor é capaz de processar
(CARDOZO; MAGALHÃES, 2002).

Camada de rede.
A camada de rede controla a operação da sub-rede, decidindo que caminho
físico os dados devem seguir com base nas condições da rede, na prioridade do
serviço e em outros fatores. Ela fornece os seguintes recursos (TORRES, 2017):
• Roteamento: roteia dataframes entre redes.
• Controle do tráfego da sub-rede: roteadores (sistemas intermediários da
camada de rede) podem instruir uma estação de envio a "desacelerar"
sua transmissão de quadros quando o buffer do roteador fica cheio.
• Fragmentação de dataframes: se ela determinar que o tamanho da
unidade máxima de transmissão (MTU) do roteador downstream é
menor que o tamanho do quadro, um roteador poderá fragmentar um
quadro para transmissão e remontagem na estação de destino.
• Contabilidade de uso da sub-rede: tem funções de contabilidade para
manter o controle dos quadros encaminhados por sistemas
intermediários da sub-rede, para produzir informações de cobrança.

Camada de transporte
A camada de transporte garante que as mensagens sejam entregues sem
erros, em sequência e sem perdas ou duplicações. Ela elimina para os protocolos de
camadas superiores qualquer preocupação a respeito da transferência de dados entre
eles e seus pares. O tamanho e a complexidade de um protocolo de transporte
dependerão do tipo de serviço que ele pode obter da camada de rede. Para uma
camada de rede confiável com capacidade de circuito virtual, uma camada de
transporte mínima é necessária. Se a camada de rede não for confiável e/ou apenas
tiver suporte para datagramas, o protocolo de transporte deverá incluir procedimentos
externos de detecção e recuperação de erros. A camada de transporte fornece os
seguintes recursos (Suporte da Microsoft ,2017):
 16

• Segmentação de mensagens: aceita uma mensagem da camada acima

dela (sessão), divide a mensagem em unidades menores (se ela ainda
não for suficientemente pequena) e transmite as unidades menores até
a camada de rede. A camada de transporte na estação de destino
remonta a mensagem.
• Confirmação de mensagem: fornece uma entrega completa e confiável
de mensagens com confirmações.
• Controle de tráfego de mensagens: instrui a estação de transmissão a
se "retirar" quando não houver buffers de mensagens disponíveis.
• Multiplexação de sessão: multiplexa vários fluxos de mensagem ou
sessões em um vínculo lógico e controla quais mensagens pertencem a
quais sessões (consulte camada de sessão).
Normalmente, a camada de transporte pode aceitar mensagens relativamente
grandes, mas existem limites rigorosos de tamanho de mensagens impostos pela
camada de rede (ou inferior). Consequentemente, a camada de transporte deve dividir
as mensagens em unidades menores, ou dataframes, acrescentando um cabeçalho
ao início de cada dataframe (Suporte da Microsoft, 2017).
As informações de cabeçalho da camada de transporte devem então incluir
informações de controle, como sinalizadores de início e fim de mensagem, para
permitir que a camada de transporte na outra extremidade reconheça os limites da
mensagem. Além disso, se as camadas inferiores não mantiverem a sequência, o
cabeçalho de transporte deverá conter informações de sequência para permitir que a
camada de transporte na extremidade receptora junte as partes na ordem certa antes
de entregar a mensagem recebida para a camada acima (Suporte da Microsoft, 2017).

Camada de sessão
A camada de sessão permite o estabelecimento da sessão entre processos em
execução em estações diferentes. Ela fornece os seguintes recursos (ALENCAR,
2017):
• Estabelecimento, manutenção e término de sessões: permite que dois
processos de aplicativo em máquinas diferentes estabeleçam, usem e
terminem uma conexão, conhecida como sessão.
 17

• Suporte a sessões: realiza as funções que permitem que esses

processos se comuniquem pela rede, realizando tarefas de segurança,
reconhecimento de nomes, registro em log e assim por diante.

Camada de apresentação
A camada de apresentação formata os dados a serem apresentados na
camada de aplicativo. Ela pode ser considerada o tradutor da rede. Essa camada pode
converter dados de um formato usado pela camada de aplicativo em um formato
comum na estação de envio e, em seguida, converter esse formato comum em um
formato conhecido pela camada de aplicativo na estação de recepção.
A camada de apresentação fornece (Suporte da Microsoft, 2017):
• Conversão de códigos de caractere: por exemplo, ASCII para EBCDIC.
• Conversão de dados: ordem de bits, ponto de CR-CR/LF, flutuante inteiro
e assim por diante.
• Compactação de dados: reduz o número de bits que precisam ser
transmitidos na rede.
• Criptografia de dados: criptografa dados para fins de segurança.

Camada de aplicativo
A camada de aplicativo serve como a janela onde os processos de aplicativos
e usuários podem acessar serviços de rede. Essa camada contém uma variedade de
funções normalmente necessárias (ALENCAR, 2017):
• Redirecionamento de dispositivo e o compartilhamento de recursos
• Acesso remoto a arquivos
• Acesso de impressora remota
• Comunicação entre processos
• Gerenciamento de rede
• Serviços de diretório
• Mensagens eletrônicas (como email)
• Terminais de rede virtuais
 18

2.5. Domótica.
De acordo com (BOTELHO, 2005), o termo domótica é derivado da fusão da
palavra latina domus (casa) e robótica (automação), tendo como sinônimos as
expressões “intelligent building” e “smart building”. Domótica tem como objetivo a
redução do trabalho doméstico, aumento do bem-estar, segurança dos habitantes do
edifício e redução do consumo de energia, promovendo assim uma melhoria da
qualidade de vida.

Definição de domótica.
Uma definição atual do termo, pode ser descrita como a utilização simultânea
da tecnologia da informação, eletrônica e eletricidade no ambiente residencial,
possibilitando a gestão do ambiente, seja no local ou remotamente. Domótica também
pode oferecer uma vasta gama de aplicações nas áreas da segurança, comunicações,
gestão de energia e conforto (LINS; MOURA, 2010).
Pode se identificar vários graus de automação em uma residência, seja uma
casa ou em um apartamento. A domótica é uma solução para estudar e aplicar
soluções tecnológicas para automatizar operações específicas ou também
sequências de ações que podem ser executados em um ambiente doméstico
(SCHNEIDER.ELECTRIC, 2016).

Classificação das funções domótica.

Na década de 80 surgiram novos requisitos de segurança, conforto, áreas de
trabalho dinâmica, com serviços de telecomunicação e processamento de informação
mais robustos. Com isso, definiu-se três grandes classes de funções as quais
possuem subfunções elementares, que pode ser analisado abaixo (GOMAZAKO,
2007).

2.5.2.1. Função de gestão

Essa função tem por objetivo automatizar certas atividades sistemáticas

principalmente voltadas ao conforto. Essas automações podem ser feitas por meio de
programação, controle de consumo de recursos e manutenção preventiva. As ações
sistêmicas dessa função estão principalmente relacionadas com o conforto e podem
ser classificadas como:
 19

• Gestão da iluminação;
• Gestão da calefação, ventilação e ar-condicionado;
• Gestão da qualidade do ar;
• Gestão de funcionalidades dos espaços.

2.5.2.2. Função de controle.

A função de controle fornece ao usuário informações sobre o estado de

funcionamento dos equipamentos e das instalações que os integram. Também cria
um registro dos diversos parâmetros e infere comandos corretivos. Para isso, ele
possui controles instantâneos e memorizados. Essa função atua sobre os dispositivos
de regulagem das instalações, garantindo que as tarefas programadas sejam
respeitadas. (GOMAZAKO, 2007).
As funções de controle, quando associadas a um algoritmo ou a uma unidade
de tratamento da informação, conduzirão às funções de comando. Essas funções de
comando podem ser classificadas em funções de controle técnico, segurança e
teletransmissão.

2.5.2.3. Função de comunicação

As capacidades de telecomando e de programação se aliam às potencialidades

técnicas da interatividade. Entre elas se encontram o controle, espaçamento de
informações e serviços. A interatividade designa, por um lado, uma característica da
comunicação que é uma mesma condição da domótica, e por outro lado, está
indicando que o espaço do ambiente não será somente interativo, mas também de
convivência (GOMAZAKO, 2007).

Arquiteturas.
A domótica está dividida em dois tipos de arquiteturas: a arquitetura ABA
(Arquitetura Baseada em Automação), conhecida como domótica estática, esta
domótica que utiliza arquitetura trata da automação a partir de dispositivos de controle,
como controles remoto, sensores de movimento, biométricos etc. (LINS; MOURA,
2010).
A domótica que utiliza arquitetura ABC, pode ser denominado como um tipo de
automação que possui algum mecanismo de tomada de decisão baseada em
 20

inteligência artificial. Conhecida como domótica inteligente, baseada em

comportamento, ou seja, pelo uso de mecanismo de aprendizado possibilitando ajuste
das regras de automação ao comportamento das pessoas que habitam uma casa ou
prédio inteligente. Esse ajuste se dá de forma automática e sem intervenção do
indivíduo, nenhuma configuração manual é necessária (LINS; MOURA, 2010). A
Figura 2.4 mostra um exemplo de um modelo de sistema domótica.

Figura 2.4. Modelo de sistema domótico.

Fonte: http://www.sentidodigital.pt/wp-
content/uploads/2015/12/banner_domotica_01.png

Redes domóticas e padronização.

A rede domótica é o principal elemento de um sistema domótico. Um sistema
de interconexão, sendo cabeado ou wireless, permite realizar a comunicação entre os
dispositivos conectados à rede, que é essencial para a domótica. As redes projetadas
para edifícios inteligentes se baseiam em aplicações, onde existem redes
independentes destinadas para cada aplicação no edifício. De modo que estas
edificações inteligentes possuem redes destinadas à segurança, à detecção de
incêndios, ao controle de acessos, à climatização e à informática. As redes domótica
são, em termos gerais, redes polivalentes que permitem realizar diferentes funções a
fim de simplificar a complexidade da instalação da rede. A mesma rede domótica
assegura, por exemplo, as funções de segurança, conforto e gestão técnica. A rede
 21

pode estar constituída de um ou vários suportes de comunicação de acordo com as

funções que esse sistema domótico realiza (LINS; MOURA, 2010).
A elaboração e adoção de padrões para utilização em sistemas domótico
representam um desafio contínuo para pesquisadores e projetista. As características
da rede e os protocolos de comunicação têm definido os padrões existentes. Por
permitir a comunicação entre os diferentes equipamentos conectados a ela, a rede
domótica é o principal componente de todo o sistema. Por sua vez, os protocolos de
comunicação, por estarem em desenvolvimento e constante evolução, competem
entre si por um lugar de destaque, seja pela sua eficiência ou pelo domínio do
mercado, (GOMAZAKO, 2007).

Principais padrões utilizados em redes domótica

Os padrões desenvolvidos para aplicação em outras áreas tecnológicas, tais
como a Automação Industrial, podem ser aplicados à domótica, por exemplo o
Modbus, CAN, DeviceNet, FieldBus e Profibus. Os padrões mais utilizados são:

2.5.5.1. Padrão X-10

Provavelmente é o primeiro padrão para automação residencial desenvolvido.

Introduzido há mais de vinte anos no mercado, utiliza a própria fiação elétrica para
comunicações entre transmissores e receptores X10, a modulação é feita pela
frequência e tensão da rede elétrica, que serve como portadora. Em decorrência da
qualidade de fiação, este padrão se limitado a pequenas e médias distâncias, sendo
que para instalações com área maior a 185 metros quadrados é necessária a
implementação de amplificadores de sinal. Os atuadores e sensores são
unidirecionais, não possuindo inteligência. É o padrão mais utilizado nos EUA neste
seguimento, a Figura 2.5 ilustra o esquema de conexão e equipamentos usando
protocolo X10 (ABREU; VALIM, 2011).
 22

Figura 2.5. Esquema de conexão e equipamentos usando protocolo X10.

Fonte: http://www.bwired.nl/images/how/schema_Xanura.gif

2.5.5.2. Padrão CEBus

Esse protocolo para automação residencial, fornece controle com taxa de

transferência de até 10 Kbps. Implementa as camadas 1, 2, 3 e 7 do Modelo OSI,
sendo um padrão versátil que permite a utilização de vários meios de transmissão e
linhas portadoras de energia. Como exemplos de meio de transmissão, o par
trançado, a rádio frequência, infravermelhos, cabo coaxial e fibra óptica. A forma de
acesso ao meio físico se dá por Carrier Sense Multiple Access / Collision Detection
(CSMA/CD), O chip IT800 produzido pela empresa Intellon Corporation em Ocala, na
Flórida, é responsável pelo funcionamento do hardware de comunicação e do
protocolo que só é produzido pela empresa, (GOMAZAKO, 2007) (CEBUS, 2017).
Figura 2.6 mostra representação gráfica da utilização do protocolo Cbus nas camadas
que trabalha no modelo OSI.
 23

Figura 2.6. Representação gráfica da utilização do protocolo Cbus nas camadas que
trabalha no modelo OSI.

Fonte: http://www.cricte2004.eletrica.ufpr.br/edu/anterior/cd00/trab/cebus/

2.5.5.3. Padrão LONWORKS

É uma topologia de rede para automação predial e industrial criada pela

empresa Echelon. É considerado um dos padrões mais completos em termos de
recursos e utilização. O esquema de acesso ao meio físico se faz por Carrier Sense
Multiple Access / Collision Avoidance (CSMA/CA), este acesso é ativado por eventos
(SILVA1, 2017).
Assim como o CBus, o hardware de comunicação e o protocolo de rede (lon
Talk) é controlado por um chip denominado NEURON (SILVA1, 2017).

2.5.5.4. Padrão BACnet

Building Automation and Control NETworkse (BACnet), esse padrão de controle

para automação predial mantido pela American Society of Heating, Refrigerating and
Air-Conditioning Engineers (ASHRAE). Suporta múltiplos protocolos: Ethernet,
ARCnet, MS/TP, PTP, LonTalk, IP. Todos os protocolos standard da indústria. Cada
um com implementação específica e exigências de meios de comunicação, define
 24

protocolos para uso em quatro camadas do modelo de referência OSI (Shineider

Eletric, 2017).

2.5.5.5. Padrão OSI

Aplicação, rede, enlace de dados e física. Sua utilização é mais difundida no

controle de bioclimático (HVAC), mas esta não é uma restrição, (GOMAZAKO, 2007).

2.5.5.6. Padrão EIB

O definido pela EIBA, implementa um sistema descentralizado com inteligência

distribuída, com acesso ao meio físico por CSMA/CA. A instalação do barramento de
dados é feita paralelamente ao fornecimento de energia, permitindo 64 dispositivos
por linha, 12 por linha principal e 15 por linhas principais por Backbone. A utilização
de um padrão não é exclusiva em um sistema domótico. Mais de um padrão pode ser
adotado e coexistir com outro numa aplicação de automação residencial ou predial
(GOMAZAKO, 2007).

2.6. Rede Wi-Fi

Wi-Fi é uma marca estabelecida pela empresa Wi-Fi Alliance sendo utilizada
em dispositivos de rede local sem fios (WLAN) baseados no padrão EEE 802.11
(SILVA2, 2017). O padrão IEEE 802.11 estabelece os critérios para padronização das
camadas físicas e de enlace para a implementação de uma rede local sem fio (WLAN).
O padrão permite duas possíveis arquiteturas: infra estruturada e AdHoc. Na
arquitetura infra estruturada os dispositivos estão conectados a pontos de acesso que
são responsáveis pela organização e controle da rede. Na arquitetura AdHoc os
dispositivos que compõem a rede podem trabalhar como pontos de acesso,
estabelecendo comunicação entre os dispositivos (SILVA3, 2017). A Figura 2.7 ilustra
as redes com infraestrutura e rede AdHoc.
 25

Figura 2.7. Rede com infra estruturada e rede AdHoc.

Fonte: http://s3.amazonaws.com/magoo/ABAAAgZe8AE-18.jpg
A camada física do padrão IEEE 802.11 é responsável pela transmissão dos
bits por um do canal de comunicação. Esse padrão define as especificações elétricas
e mecânicas do sistema. Sua principal função é a modulação, preparando a
informação para ser transmitida no meio de transmissão em forma de onda
eletromagnética, ou seja, esta camada é responsável pela transmissão dos dados de
forma bruta, por meio de um canal de comunicação utilizando-se de parâmetros como
a modulação do sinal e a frequência da banda utilizada. O Wi-Fi usa duas bandas de
frequência. A primeira banda é chamada de ISM (Industrial Scientific Medical),
abrange a faixa entre 2,4 e 2,5 Ghz, possuindo 14 canais neste intervalo de
frequência. Esta faixa de frequência é aberta, podendo sofrer interferências devido a
utilização por outros padrões de redes e eletrodomésticos. A figura 2.8 ilustra os
canais subdivididos dentro da faixa de frequência de 2.4 Ghz (SILVA3, 2017).

Figura 2.8. Representação dos canais na faixa de frequência 2.4 Ghz.

Fonte: http://gutocarvalho.net/dokuwiki/lib/exe/fetch.php/canais_Wireless.png?cache
=&w=900&h=209&tok=008f7e
 26

A segunda banda abrange a faixa de frequência entre 5,17 a 5,85 Ghz,

suportando até 25 canais, possuindo 3 subdivisões: 5,12 até 5,25 (indoor), 5,25 até
5,35 (indoor/outdoor), e 5,725 até 5,825 (outdoor pont-to-pont) (SILVA3, 2017). A
Figura 2.9 ilustra a distribuição dos canais na faixa de 5 Ghz.

Figura 2.9. Distribuição dos canais na faixa de 5 Ghz.

Fonte: https://cdn-images-1.medium.com/max/800/1*2E-imIpMAqoX5dn_fvY1tQ.png

Operações da camada física

As operações da camada física são similares, independente da técnica de
modulação utilizada. O padrão definiu três estados possíveis, conforme descritos
abaixo:
1. Detecção de Portadora: estado que permite a subcamada MAC (Media Access
Control) “escutar” o meio;
2. Transmissão: modo de transmissão dos dados;
3. Recepção: modo de recebimento dos dados (SIRUFO, 2005).

Detecção de Portadora
Sirufo (2005) afirma que a camada física executa a detecção de portadora
consultando a subcamada PMD (Physical Medium Dependent) periodicamente para
 27

saber se o meio está ocioso ou não. A subcamada PLCP (Physical Layer Convergence
Procedure) implementa, no caso de nenhuma transmissão ou recepção, as seguintes
operações:
• Detecção de sinais de entrada: a PLCP verifica periodicamente o meio para
detectar a chegada de alguma mensagem. Se algum quadro MPDU (MAC
Protocol Data Unit) é detectado, seu cabeçalho é lido de modo a identificar o
destino da informação;
• Determinação de canal ocioso: verifica periodicamente se o canal está ocioso
ou não.

Transmissão
A PLCP envia uma mensagem para a PMD (Physical Medium Dependent)
alterar seu estado de detecção de portadora para o estado de transmissão logo que
recebe uma requisição de transmissão da subcamada MAC. A PMD responde à
solicitação garantindo que o serviço está disponível e envia um preâmbulo (relatório
de pré transmissão). O cabeçalho da mensagem será posteriormente adicionado ao
preâmbulo, completando as informações do início do quadro que será transmitido.
Após o envio do cabeçalho e do preâmbulo, a PLCP então termina o envio do pacote.
Após a conclusão do envido do pacote, o transmissor é desligado e o modo de
operação da PMD é alterado para modo de detecção de portadora (SIRUFO, 2005).

Recepção
O modo recepção inicia sempre que a PMD está em modo de detecção de
portadora e um pacote é detectado. O sinal do pacote para ser detectado deverá
possuir um sinal com intensidade mínima de 85dBm e seu preâmbulo ser considerado
válido, para então o processo de verificação de cabeçalho ser iniciado. Caso a
intensidade do sinal satisfaça ao requisito mínimo e o cabeçalho não contenha erro,
ele será anexado a uma premissa que é enviada à subcamada MAC pela PLCP para
indicar a chegada de um pacote. A PLCP também é responsável por detectar o fim do
pacote e informar à camada MAC quando isso ocorrer. Assim a PLCP pode notificar a
subcamada MAC do fim do pacote, e o processo de recebimento está concluído. Então
a PLCP envia uma ordem para PMD voltar ao modo de detecção de portadora
(SIRUFO, 2005).
 28

Camada de Enlace
A camada de enlace tem a função de detectar erros que possam ocorrer na
camada física. O controle de acesso é feito por meio de dois modos de operação que
trabalham em conjunto.
O mecanismo fundamental de acesso ao meio é chamado de DCF (Distributed
Coordination Function). Este mecanismo e baseado em um método de transmissão
com prevenção de colisão denominado de CSMA/CA (Carrier Sense Multiple Access
with Collision Avoidance). Sempre que uma estação tem algum pacote para transmitir,
esta monitora a atividade do canal. Se o canal estiver ocioso por um período maior
que o tempo entre quadros distribuídos, denominado de DIFS, a estação transmite o
pacote, senão, o canal é analisado até que este esteja ocioso por um período de
tempo igual a DIFS e então inicia um contador de duração aleatória denominado
backoff antes de iniciar sua transmissão, tentando diminuir a probabilidade de uma
nova colisão. Como a estação não tem como detectar se houve uma colisão ou não,
um aviso de recepção ACK (Acknowledgement) é transmitido pela estação de destino
logo após um curto período, chamado de SIFS. Se após o intervalo de ACK a estação
não receber confirmação, esta saberá que ouve uma colisão ou uma perda, então,
reagendará a transmissão de acordo com o backoff (HARGREAVES, 2017). A figura
2.10 ilustra este comportamento.

Figura 2.10. Estação trabalhando de acordo com a DCF.

Fonte: (HARGREAVES, 2017)

Para que o protocolo seja mais eficiente, a DCF usa um modelo de tempo
segmentado de modo que uma estação transmitirá no início de cada segmento. O
 29

intervalo de cada segmento deve ser suficiente para que todas as estações detectem
a transmissão de outra estação (HARGREAVES, 2017).
O mecanismo DCF adota um esquema de backoff aleatório. A cada início de
transmissão, é inicializado um timer com um valor aleatório uniformemente distribuído
entre (0, ω –1), onde ω é o tamanho da janela de contenção cujo valor dependerá do
número de tentativas malsucedidas de transmissão. Na primeira tentativa, ω tem o
menor tamanho possível de uma janela de contenção. A cada vez que ocorre uma
colisão o tamanho da janela de contenção dobra até o valor máximo. Este aumento
da janela da contenção seria uma forma de fazer com que as estações
compreendessem o padrão de funcionamento da rede, se a rede estiver permanente
ocupada, volta a tentar mais tarde, se ela estiver muito ociosa, transmite no momento.
Este contador sofre decréscimo sempre que canal está desocupado. Quando uma
outra transmissão inicia, o contador é “congelado” e só é reativado quando o canal
fica inativo por um período igual a DIFS (HARGREAVES, 2017).
Como já mencionado, o controle de acesso é feito por meio de dois modos de
operação que trabalham em conjunto. O modo supra descrito é chamado de modo
básico, o segundo modo de operação é chamado PCF (Point Coordination Function).
O PCF se baseia em polling, ou seja, verifica periodicamente o canal. Assim, quando
se identifica que uma estação possui dados para transmitir, esta estação ganha
acesso exclusivo ao meio. Ele é construído acima do DCF (Distributed Coordination
Functio) na subcamada MAC (SILVA4, 2016). Neste modo pós, cada estação detecta
o canal livre por um tempo igual a DIFS, ao invés de transmitir seus dados úteis envia
um quadro de reserva, denominado de RTS (Reservation Request), contendo a
duração do pacote de dados endereçado à estação de destino. Se a estação de
destino recebe este RTS corretamente, ela espera um tempo igual a SIFS (Interframe
Space) e envia um quadro chamado STS (clear-to-send) indicando que a estação que
fez o pedido pode enviar os dados. Após um tempo igual a Short SIFS, a estação que
recebeu o CTS (Clear to Send) inicia a sua transmissão (HARGREAVES,2017). O
comportamento do modo de reserva está descrito na figura 2.11.
 30

Figura 2.11. Mecanismo RTS/CTS do modo PCF.

Fonte: (HARGREAVES, 2017).

Nos quadros de RTS/CTS vem especificado o tamanho do payload que a

estação que fez a requisição do canal deseja transmitir. Como o canal é de difusão,
as estações que receberem o RTS/CTS podem usar esta informação para atualizar
seu vetor de alocação da rede, denominado network NAV (allocation vector). Desta
forma, as estações que não participam do processo de comunicação não precisam
escutar o meio durante todo o tempo, só quando o contador de tamanho igual a NAV
estourar (HARGREAVES, 2017).

2.7. PROTOCOLO IEEE 802.15.4 ZIGBEE.

ZigBee, também conhecido como IEEE 802.15.4, é uma tecnologia
homologada em maio de 2003 pelo consórcio denominado ZigBee Alliance. Esse
padrão foi desenvolvido para tornar simples a comunicação em redes sem fio, além
de tornar a aquisição, instalação e manutenção dos equipamentos, menos custosos.
 31

Apesar de sua recente incorporação no grupo de aplicações sem fio, esta tecnologia
já está bem estruturada, podendo ser aplicada nos segmentos de automação
industrial, residencial, controle de periféricos para computadores e controle remoto de
produtos eletrônicos.

O padrão IEEE 802.15.4

O padrão IEEE 802.15.4 é uma tecnologia de comunicação Wi-Fi de curto
alcance, tem como propósito atender a aplicações que não necessitem de uma alta
taxa se transmissão de dados e baixa latência. Os dispositivos que utilizam essa
tecnologia operam numa faixa que não necessitam de licenciamento para operação.
De acordo com Pinheiro (2016), as faixas de operação dos dispositivos são 2,4GHz –
Global, 915Mhz – América, e 868Mhz – Europa. Com taxa de transferência de dados
250Kbps, 40Kbps e 20Kbps respectivamente. As características principais desta
tecnologia são: baixa complexidade da topologia, baixo custo de implementação e
manutenção, baixo consumo de energia. Estas características favorecem sua
utilização para redes de sensores sem fio e automação (BURATTI, 2011).

IEEE 802.15.4 Camada Física

A camada física opera em três diferentes faixas de frequência não-licenciadas
dependendo da localização geográfica. O padrão específica 27 canais half-duplex
para as três bandas, conforme pode ser visualizado na Tabela 2.1 (BURATTI, 2011).

Tabela 2.1. Canais e bandas de frequência do padrão IEEE 802.15.4.

Banda Frequência (MHz) Local de Largura de Quantidade

utilização banda de canais
2.400 MHz (ISM) 2.400 – 2.483,5 GLOBAL 250 Kbps 16
915 MHz (ISM) 902 - 928 EUA 40 Kbps 10
868 MHz 868 – 868,6 EUROPA 20 Kbps 1

A modulação, o método de propagação e a distância entre os canais, variarão

com o tipo de banda utilizada. As bandas de 868 e 915 MHz utilizam modulação Binary
Phase Shift Keying (BPSK) e o método de propagação Diret Sequence Spread
Spectrum (DSSS) (BURATTI, 2011). Já a banda de 2,4 GHz utiliza modulação Offset
 32

Quadrature Phase Shift Keying OQSKY. A Tabela 2.2 resume estas informações para
cada uma das bandas.

Tabela 2.2. Configuração dos canais e bandas do padrão IEEE 802.15.4.

Distância entre Tipo de

Banda Método de propagação
canais modulação
2.400 MHz (ISM) 5 MHz Q-QPSK 16-Array orthogonal
915 MHz (ISM) 2 MHz BPSK DSSS binário
868 MHz - BPSK DSSS binário

A Tabela 2.3, demonstra a potência mínima para recepção e o alcance máximo

em cada uma das bandas. O alcance máximo é obtido considerando que os cálculos
levam com base, condições ideais de transmissão, ou seja, desconsiderando perdas
por efeitos de reflexão, difração e espalhamento (BURATTI, 2011) (SILVA4, 2016).

Tabela 2.3. Sensibilidade de Recepção e Alcance máximo do padrão IEEE 802.15.4.

Sensibilidade Máximo
Banda
de recepção alcance
2.400 MHz (ISM) -85 dBm 200 m
915 MHz (ISM) -92 dBm 1 Km
868 MHz -92 dBm 1 Km

A camada PHY também e responsável pela gestão de consumo de energia. Os

dispositivos que implementam o padrão IEEE 802.15.4 permanecem no estado inativo
na maior parte do tempo. O padrão IEEE 802.15.4 possibilita que dispositivos fiquem
no estado de sleep por até 99% do tempo (BURATTI, 2011). A transmissão é
organizada em quadros (frames) que se diferenciam de acordo com o propósito. A
estrutura de um quadro geral é demonstrada na figura 4-9. Existem quatro tipos de
quadros que compõem o Physical Protocol Data Unit PPDU: o quadro de beacon, o
quadro de dados, o quadro de ACK e o quadro de comando MAC. Todos os quadros
são estruturados com um Synchonization Header (SHR), um Physical Header (PHR),
uma Physical Service Data Unit (PSDU). O PSDU é composto por uma Payload Data
Unit (MPDU), que por sua vez é construído com um MAC Header (MHR), um MAC
Footer (MFR) e um MAC Service Data Unit (MSDU). Para assegurar que uma
mensagem foi recebida corretamente é utilizado Cyclic Redundancy Check (CRC). O
 33

campo MSDU é preenchido de acordo com o tipo do quadro, exceto no quadro de

ACK, onde este campo é ausente. A figura 2.12 mostra a Estrutura de um quadro de
tranmisão do padrão IEEE 802.15.4 (BURATTI, 2011) (SILVA4, 2016).

Figura 2.12. Estrutura de um quadro de tranmisão do padrão IEEE 802.15.4.

Fonte: (BURATTI, 2011).

Modos de Operação e topologias de rede IEEE 802.15.4

O padrão IEEE 802.15.4 implementa os dispositivos Full Function Device (FFD)
dispositivos de função completa que possuem o conjunto completo dos serviços MAC
e pode operar como o coordenador de uma rede, ou como um simples dispositivo da
rede, e Reduced Function Device (RDF) dispositivos de função reduzida que possuem
uma parte dos serviços MAC e operam apenas como um dispositivo da rede. Nos
dispositivos FFD é possível operar com tipos de topologias suportadas no padrão
IEEE 802.15.4, que no presente trabalho, não será completamente descrita, pois a
definição das camadas mais altas, rede e transporte, não abrangem o escopo do IEEE
802.15.4. As topologias suportadas são: estrela e peer-to-peer. Na topologia estrela,
o nó coordenador, um FFD que inicia a rede, se comunica diretamente com os demais
nós e estes apenas podem ter comunicação com o coordenador. Na topologia peer-
to-peer, todos os nós podem se comunicar entre si, mesmo o nó não sento
coordenador. Para o uso das topologias aconselha se o uso da topologia estrela para
pequenas áreas de cobertura e necessite baixa latência. A topologia peer-to-peer
permite a formação de redes mais complexas, com transmissões multi-saltos, sendo
 34

mais adequadas para cobrir grandes áreas, a figura 2.13 ilustra as topologias
implementadas pelo padrão IEEE802.15.4 (SILVA4, 2016).

Figura 2.13. Topologias implementadas pelo padrão IEEE802.15.4.

Fonte: (SILVA4, p.81 2016).

Camada de Enlace (MAC) do padrão IEEE 802.15.4

No padrão IEEE 802.15.4, as funções executadas pela camada de enlace são:
associação e desassociação, controle de segurança, gerenciamento de time slot para
transmissão, geração de ACKs, e suporte à aplicação para as duas topologias
suportadas. Esta camada usa protocolo baseado no algoritmo CSMA/CA, o qual
requer que se escute o canal antes de transmitir para que se diminua a probabilidade
de colisões durante a transmissão (HARGREAVES,2017) (BURATTI, 2011). Existem
dois modos de operação, que correspondem a dois mecanismos diferentes de acesso
ao meio: o modo “non beacon-enable” e o modo “beacon-enabled”. No modo non
beacon-enable o nó procura um canal para realizar a transmissão, enquanto no modo
beacon-enabled, existe uma estrutura chamada superframe que realiza uma espécie
de sincronização para evitar colisões na transmissão. Uma descrição detalhada do
acesso ao meio em IEEE 802.15.4-2003, incluindo fluxogramas dos algoritmos
CSMA/CA, já os mecanismos beacon-enabled e non beacon-enable encontra-se
disponível em (BURATTI, 2011).

Camadas implementadas pelo ZigBee

O ZigBee, desenvolvido pela ZigBee Alliance, é um padrão que implementa
camadas sobre o IEEE 802.15.4. A figura 2.14 ilustra a arquitetura da pilha de
protocolos ZigBee.
 35

Figura 2.14. Arquitetura da pilha de protocolos ZigBee.

Fonte: (GISLASON. 2008).

O padrão ZigBee, trabalha com três tipos de dispositivos:

• Coordenador: nó responsável por iniciar a Wi-Fi Personal Area Network
(WPAN). Pode dar assistência ao roteamento de dados por aceitar
pedidos de associação a rede. Somente pode existir um coordenador
para cada WPAN.
• Roteador: este nó deve se associar a uma WPAN existente e permitir,
por meio dele, que outros dispositivos se associem à rede, enviando e
recebendo pacotes.
• Dispositivos finais: Permanecem na maior parte do tempo em estado
sleep. Não possuem a capacidade de associar dispositivos nem efetuar
roteamento (GISLASON, 2008).
O padrão ZigBee tem como serviços de segurança a criptografia de dados,
autenticação de dispositivos e de dados e proteção contra quadros repetidos
(FARAHANI, 2008).

2.8. Funções da camada de rede ZigBee

A camada de rede ZigBee tem como função oferecer mecanismos para que um
dispositivo ingresse ou saia da rede; proporcionar segurança do quadro; descoberta
de rodas e de dispositivos vizinhos diretos; roteamento e armazenamento de
 36

informações dos dispositivos vizinhos. Semelhante ao endereçamento IP das redes

de computadores, a camada de rede ZigBee atribui um endereço de 16 bits para os
dispositivos conectados à rede. A forma de transmissão pode ser por meio de
broadcast, multicast e unicast. A seguir será discutida as formas de transmissão da
camada de rede ZigBee (FARAHANI, 2008).

Modo de transmissão broadcast

Neste tipo de transmissão a mensagem é transmitida para todos os nós

conectados à rede. Toda vez que um dispositivo recebe um pacote, o dispositivo
verificará o endereço de destino fornecido no pacote para verificar se o dispositivo é
o destinatário do pacote. Para transmitir nas redes IEEE 802.15.4, o modo de
endereçamento curto é usado e o endereço de destino é definido como “0xffff”. Este
endereço será aceito por todos os dispositivos que recebem o pacote como seu
próprio endereço. O identificador PAN (Personal Area Network) também pode ser
definido como “0xffff”. O dispositivo receptor aceita o endereço como um identificador
PAN válido. O endereço MAC do dispositivo com endereço 0xffff é conhecido como o
endereço de transmissão. O identificador PAN do dispositivo 0xffff é chamado de
identificador PAN de transmissão. Embora o IEEE 802.15.4 possui suporte ao uso de
um identificador PAN de transmissão, ou seja, 0xffff para transmitir uma mensagem
em várias redes, o padrão ZigBee não permite a transmissão em várias redes, e o
identificador PAN é sempre configurado para o identificador PAN de rede ZigBee em
vez de 0xffff. A subcamada APS de qualquer dispositivo dentro de uma rede pode
iniciar uma transmissão usando o serviço de dados da camada NWK (FARAHANI,
2008).

Modo de transmissão unicast

As transmissões unicast são aquelas em que existe apenas um nó transmitindo
para um nó destino. No ZigBee esta transmissão utiliza sempre o endereço de rede
de 16 bits do nó destino. Cada nó também possui um endereço de 64 bits permanente,
o qual é um número de série do módulo e não pode ser modificado. Este endereço de
64 bits pode ser utilizado para descobrir o endereço de rede do destino.

Modo de transmissão multicast

No multicast, a mensagem é entregue a um grupo de dispositivos dentro da
mesma rede em vez de toda a rede. Embora seja possível realizar o mesmo resultado
com transmissões unicast consecutivas, um único multicast é uma maneira mais
 37

eficiente de entregar a mesma mensagem para um grupo de dispositivos. Cada grupo

é identificado por um ID de grupo multicast de 16 bits. Os dispositivos do mesmo grupo
são conhecidos como membros do grupo. Um dispositivo pode ser um membro de
mais de um grupo multicast. Cada dispositivo mantém a lista de membros do grupo
multicast em uma tabela chamada a tabela multicast. Um dispositivo não precisa ser
um membro de um grupo multicast para poder usar o multicast para alcançar os
membros. Existem dois modos de operação no multicast: modo membro e modo não-
memorial. No modo membro, um multicast é iniciado por um dispositivo membro e
enviado aos membros de seu grupo multicast. No modo não-memorial, um dispositivo
que não é um membro de um grupo multicast encaminha a mensagem para um
membro do grupo multicast, a partir do qual a mensagem será enviada para os
membros do grupo. A figura 2.15 ilustra os modos de transmissão suportado protocolo
ZigBee.

Figura 2.15. Modos de transmissão suportado protocolo ZigBee (a) broadcast, (b)
multicast e (c) unicast.

Fonte: (FARAHANI, 2008 p. 81).

 38

3. METODOLOGIA
Para a realização desse projeto, foram realizados vários estudos referentes as
áreas de domótica, automação residencial e industrial, além de redes Wireless. Este
trabalho teve como base de pesquisa livros, tutoriais, artigos acadêmicos e científicos.
Após a pesquisa, foi definido como o sistema de automação funcionará e que este
sistema irá controlar o acionamento remoto de interruptores usando tecnologia ZigBee
e um aplicativo instalado em um smartphone. Diante disso foram definidos quais
componentes seriam necessários para a elaboração do projeto.
O projeto de automação foi dividido em três partes. A primeira parte, foi
desenvolvido o aplicativo para o smartphone responsável pela comunicação com o
Arduino.
A segunda parte, foi efetuada a configuração dos microcontroladores Arduino
utilizando uma IDE, cuja linguagem e basicamente C/C++, para a programação do
microcontrolador e mais tarde sendo compilado para microcontrolador Arduino.
A terceira parte foi feita a configuração dos módulos XBee. Os módulos foram
configurados de modo a se comunicarem. Um dos módulos foi configurado como
coordinator, ou seja, este irá comandar o dispositivo configurado como router
responsáveis pela comunicação entre o dispositivo que será acionado e o Arduino.
Esta configuração é realizada utilizando um software denominado X-CTU responsável
por configurar os módulos XBee de modo a definir qual será o dispositivo coordinator
o dispositivo router e a configuração da rede ZigBee para a comunicação dos módulos.
Usou-se a norma NBR-14724 (ABNT, 2017), juntamente com Manual para
Elaboração de Trabalhos de Graduação da Fatec Ourinhos, para a adequação de toda
a documentação elaborada para o projeto.
Mostrar-se-á os componentes usados no presente trabalho e, como ocorre a
integração destes componentes.
O projeto foi desenvolvido em 3 partes definidas do seguinte modo:
• Descrição do funcionamento dos circuitos que constituem o sistema de
automação.
• Relatar o funcionamento do aplicativo desenvolvido na plataforma
Android que será utilizado como controle para o sistema de automação.
• Relatar os softwares de configuração do módulo controlador e router.
 39

3.1. Arquitetura do sistema de automação.

O sistema de automação foi desenvolvido em função do protocolo de
comunicação IEEE802.15.4. A seguir, é realizada uma breve explicação de sua
arquitetura.
A figura 3.1 ilustra a arquitetura do sistema de automação usada neste trabalho
e os principais componentes usados na construção do sistema. O sistema de
automação funcionará de forma que o usuário acessa o aplicativo instalado em um
dispositivo móvel para controlar o acionamento de dos interruptores. Ao pressionar o
botão no aplicativo, o comando é envidado ao módulo controlador via Wi-Fi onde o
módulo XBee coordenador está conectado. O controlador Arduino interpreta o
comando enviado pelo dispositivo móvel, então através do módulo XBee coordenado
é enviado o comando ao XBee router usando o protocolo IEEE802.15.4 ZigBee que
repassa o comando ao módulo controle para que possa ativar ou desativar os
interruptores, através de um módulo relê conectado ao módulo controle.

Figura 3.1. Arquitetura do sistema de automação.

Fonte: Elaborado pelos autores.

 40

3.2. Arquitetura do Hardware

Antes de detalhar os circuitos separadamente, é demonstrado como ocorre
fisicamente a conexão dos componentes que compõem o sistema de automação. A
figura 3.2 mostra o diagrama de conexão em nível de hardware onde pode se ver
todas as conexões dos componentes do sistema de automação.
O dispositivo móvel se comunica com o módulo coordenador via Wi-Fi, o
módulo coordenador é constituído do microcontrolador Arduino, uma sheild ethernet
conectado diretamente aos pinos de entrada e saída do Arduino, e o módulo XBee em
modo coordenador também conectado diretamente aos pinos de entrada e saída do
Arduino.
A comunicação dos rádios XBee ocorre usando o protocolo de comunicação
IEEE802.15.4 ZigBee. No Circuito de acionamento dos interruptores, O XBee Router
é conectado aos pinos de entrada e saído do Arduino do módulo de controle que por
sua vez está conectado a um módulo relê através de suas portas digitais.

Figura 3.2.Diagrama de conexão em nível de hardware.

Fonte: Elaborado pelos autores.

3.3. Arquitetura do Software.

A arquitetura do software possui três diferentes etapas:
 41

• Desenvolvimento do aplicativo destinado a instalação no dispositivo móvel

usado para o controle do sistema
• Desenvolvimento código fonte para o módulo controlador que receberá os
comandos do dispositivo móvel.
• Desenvolvimento código fonte para o módulo de controle que receberá os
comandos do módulo controlador e acionará ou desligará os interruptores.

Código fonte do dispositivo móvel.

O software desenvolvido para plataforma Android, instalado no dispositivo
móvel, tem por objetivo enviar os comandos de acionamento ou desligamento dos
interruptores do sistema de automação.
Para elaboração do software foi utilizada a ferramenta App Inventor.
Desenvolvida inicial mente pela Google e hoje mantida pelo Massachusetts Institute
of Technology (MIT), permite desenvolver aplicativos sem a necessidade de escrita de
códigos. A Ferramenta usa uma interface gráfica que permite o usuário manipular
objetos visuais, criando aplicativos que podem ser executados em dispositivos
Android. A figura 3.3 mostra o a tela inicial do projeto, onde foi desenvolvido o
aplicativo.

Figura 3.3. Tela do App Inventor Designer.

Fonte: Elaborado pelos autores.

 42

A figura 3.4 mostra a tela Blocks Editor onde pode-se ver uma parte da
programação. Com o Blocks Editor, associar ações para cada item do seu programa
anteriormente desenvolvido na tela Designer. Usando uma interface simples e
intuitiva, a construção do aplicativo parece muito com montar um quebra-cabeça.

Figura 3.4. tela do Blocks Editor

Fonte: Elaborado pelos autores

Para concluir o projeto é compilado o aplicativo gerando um arquivo com

extensão “.apk” que pode ser instalado em dispositivo móvel

Código fonte do módulo controlador.

O módulo controlador é o componente principal do sistema de automação pois
nesse módulo é configurado o servidor web que recebe os comandos do aplicativo do
dispositivo móvel, fornece uma resposta ao aplicativo do dispositivo móvel informando
e estado dos interruptores, se estão ligados ou desligados e, envia o comando de
acionamento ou desligamento dos interruptores no módulo de controle.
A conexão do módulo controlador e o dispositivo móvel que é feito por uma rede
LAN. A comunicação entre o aplicativo móvel, o módulo controlador e módulo controle
é feito por meio de comunicação serial, onde foram pré-definidos caracteres
 43

específicos a serem enviados do aplicativo móvel para o módulo controlador. O

módulo controlador por sua vez armazena o caractere em uma variável e transmite a
variável para o módulo controle, onde este último verifica a informação e aciona ou
desligar o interruptor específico. No apêndice B pode-se verificar o código fonte
completo escrito em linguagem c/c++.

Código fonte do módulo de controle.

O programa foi escrito para executar o acionamento ou desligamento dos
interruptores de acordo com os comandos enviados pelo módulo controlador. Foram
definidas variáveis de comando para os interruptores com a condição imposta de
acordo com a informação recebida pelo módulo controlador. O programa irá verificar
a variável recebida elo módulo controlador, então de acordo com as condições pré-
determinadas, o programa irá acionar ou desligar um interruptor específico. No
apêndice C pode-se verificar o código fonte completo escrito em linguagem c/c++.
 44

4. CONCLUSÃO.
Este trabalho implementou um sistema de automação residencial controlados
por um aplicativo móvel, utilizando o protocolo de comunicação IEEE802.15.4 ZigBee.
Desde o princípio decidiu-se por um sistema baseado em redes sem fio para oferecer
maior flexibilidade ao usuário e torna o projeto menos custoso por não necessitar de
cabeamentos.
A dificuldade encontrada no decorrer do trabalho foi referente à aquisição dos
componentes eletrônicos, em especial dos módulos XBee e dos adaptadores USB.
Devido à pouca oferta no mercado brasileiro, estes itens precisaram ser
encomendados de lojas especializadas ou importados, tornando o custo dos
componentes um pouco elevado e o tempo para a entrega um pouco longo.
O sistema desenvolvido para este trabalho está aberto a melhorias e ampliação
das funcionalidades, uma vez que a automação residencial oferece muitas outras
possibilidades além da abordada neste trabalho. Um exemplo de melhoria seria
incorporando sensores de temperatura para controle de um sistema de climatização,
ou talvez um sistema de acionamento de portas ou portões eletrônicos. Também pode-
se programar eletrodomésticos para ser acionados na hora desejada.
Conclui-se então que apesar dos contratempos iniciais, o projeto alcançou os
objetivos propostos, verificando-se que é possível melhorar as condições de um
ambiente residencial, otimizando o tempo gasto nas tarefas cotidianas, aumentando
a eficiência na utilização dos recursos disponíveis e melhorar o conforto usando um
sistema de automação utilizando o protocolo de comunicação IEEE802.15.4 ZigBee.
 45

REFERÊNCIAS.
ABNT. Associação Brasileira de Normas Tecnicas, Disponível em:<http://www.
abntcatalogo.com.br/norma.aspx?ID=86662#>. Acesso em: ago. de 2017.

ABREU, Eduardo Rodrigues de; VALIM Paulo Roberto Oliveira. Domótica: Controle
de Automação Residencial Utilizando Celulares com Bluetooth. Disponível em:
<http://www.aedb.br/seget/arquivos/artigos11/16014124.pdf> Acesso em: fev. 2017.

ALENCAR, Márcio Aurélio dos Santos. Fundamentos de Redes de Computadores.

Disponivel em < http://proedu.ifce.edu.br/bitstream/handle/123456789/288/
Fundamentos_Redes_Computadores_COR_capa_20100624_ISBN.pdf.pdf?sequenc
e=1&isAllowed=y> Acesso em: jan. de 2018.

ARDUINO. Notas de lançamento. Disponível em:<https://www.Arduino. cc/en/Main/

ReleaseNotes> Acesso em: set. 2017.

ARKIN, H. & PACIUK, M. Service system Integration in Intelligent Buildings,

Proceedings of IB/IC Intelligent Building Congress, Tel-Aviv, 1995;

BOTELHO, Wagner. T. Um sistema de identificação e adaptação pervasivo para a

casa inteligente utilizando sistemas multiagentes. Dissertação Instituto Militar de
Engenharia. Rio de Janeiro: 2005. (2005-wagner_botenho.pdf). Disponível em: <
https://www.unip.br/ensino/pos_graduacao/strictosensu/eng_producao/download/eng
_wagnercostabotelho.pdf >. Acesso em: out de 2016.

BURATTI, Chiara et al. Sensor Networks with IEEE 802.15.4: Systems Distributed
Processing, MAC, and Connectivity. Springer, 2011 269 p.

CARDOZO Eleri; MAGALHÃES Mauricio F. REDES DE COMPUTADORES:

MODELO OSI Disponivel em: <ftp://ftp.dca.fee.unicamp.brpub/docs/eleri/
apostilas/osi.pdf> Acesso em 10 de abril de 2018.

CEBUS, Engenharia Elétrica – UFPR. Disponível em <http://www.cricte2004

.eletrica.ufpr.br/edu/anterior/cd00/trab/cebus/> Acesso em: 11 fevereiro de 2017 de
2017.

DEVELOPERS. The developer’s guide. Disponível em: <http://developer.

android.com/guide/index.html>. Acesso em: maio 2017.

DIGI. XCTU Guia do Usuário. Disponível em: <https://www.digi.com/resources/

documentation/digidocs/90001458-13/default.htm>. Acesso em: set. de 2017.

FARAHANI, Shahin et al. ZigBee Wi-Fi Networks and Tranceiver. London: Newnes,
2008. 364 p.

GISLASON, Drew et al. ZigBee Fi-Fi Networking. London: Newnes, 2008. 427 p.

GOMAZAKO, Marcone Susumu. Conservação de Energia em Edifícios Comerciais

através da Implementação de Dispositivos de Automação – UNICAMP, 2007.
 46

Disponivel em < http://bdtd.ibict.br/vufind/Record/AMP_62732ac6bbd173

dbb44182896 d650 6dd > Acesso em out. de 2017

HARGREAVES, E. O protocolo CSMA-CA e o padrão IEEE 802.1. Disponível em:

<http://www.garf.coppe.ufrj.br/PDFs/csma_ca_eduardo.pdf> Acesso em: Abr. de
2017.

HUBSCH, Eduardo. Uma Abordagem Comparativa do desenvolvimento de aplicações

para dispositivo Móveis. Faculdade de Tecnologia de São Paulo, 2012, São Paulo.
Disponível em: < www.fatecsp.br_dti_tcc_tcc00065>. Acesso em: set. de 2017

KASUO D., AMARANTE F., LINS R. M. S. Projetos com Arduino Universidade

Federal do Pará – UFPa. Disponível em: <http://www3.ufpa.br/marcelo/
Home%20Page/Docs-APSH/Sem_APSH_1-2010/Projetos_com_Arduino .pdf>
Acesso em: dez. de 2016.

LINS Vitor; MOURA Waldson. DOMÓTICA: AUTOMAÇÃO RESIDENCIAL. Disponível

em: <http://www.unibratec.edu.br/tecnologus/wp-content/uploads/2010/
12/lins_moura.pdf> Acesso em: 11 fevereiro 2017

MOURA Rosangela de. Projeto "Fi-Fi" parte da escolha do roteador Folha de São
Paulo. 28 de maio 2011. Disponível em: <http://www.aureside.org.br/imprensa/
default.asp?file=folha_2805.HTM>. Acesso em: 17 de janeiro de 2017

PINHEIRO, José Maurício Santos. As Redes com ZIGBEE. Disponível em:

<http://www.projetoderedes.com.br/artigos/artigo_ZigBee.php> Acesso ago. 2016.

Shineider eletric. Redes de Comunicação Industrial Disponível em <https://www.

schneider-electric.pt/documents/product-services/training/doctecnico_redes.pdf>
Acesso em: 8 de maio de 2017

SHNEIDER.ELETRIC, Disponível em: <http://www.schneider-electric.com.br/

sites/brasil/pt/produtos-servico> Acesso em: 14 de fevereiro de 2016

SILVA1, A. V. da. LONWORKS – VISÃO DO PROTOCOLO DE COMUNICAÇÃO.

Disponível em: <https://semanaacademica.org.br/system/files/artigos/lonworks_-
_protocolo.pdf>. Acesso em: 14 de fevereiro de 2017

SILVA2, André Teixeira da. Módulos de Comunicação Fi-Fi para Sensores. Monografia
Universidade do Porto 2007. Disponível em: < https://web.fe.up.pt/
~ee02055/RelatorioTEC15.pdf >. Acesso em: jun. de 2017.

SILVA3, Bruna Roberta Seewald. Sistemas de automação residencial de baixo custo

para redes sem fio. Monografia Universidade Federal do Rio Grande do Sul 2014.
Disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/101188/000931903
.pdf> Acesso em: 3 de março de 2017.

SILVA4, L. H. de S. Desenvolvimento de uma Rede de Sensores Sem Fio Utilizando

ZigBee para Aplicações Diversas. Monografia Universidade de Pernambuco 2011.
 47

Disponível em <http://tcc.ecomp.poli.br/20111/monografia-Leandro_Honorato_Versao
Final.pdf>. Acesso em: 27 de agosto de 2016.

SIRUFO, Sergio Henrique, Análise de desempenho de redes IEEE 802.11b utilizando

mecanismos de segurança. Disponível em: <www.maxwell.vrac.puc-rio.br/
7589/7589_3.PDF> Acesso em: 26 abril de 2017

Suporte da Microsoft. Definição das sete camadas do modelo OSI e explicação de

suas funções. Disponivel em:<https://support.microsoft.com/pt-br/help/103884/the-
osi-model-s-seven-layers-defined-and-functions-explained>. Acesso em: 22 de
outubro de 2017.

TEIXEIRA, L. M. Desenvolvimento de uma aplicação com o protocolo ZigBee aplicado

em Instrumentação de Ensaio em Vôo. 2006. 163 f. Instituto Tecnológico de
Aeronáutica, São José dos Campos. Disponível em: <http://docplayer.com.br/
15749370-Faculdade-de-tecnologia-e-ciencias-sociais-aplicadas-fatecs.html>.
Acesso em: 20 outubro de 2016.

TORRES, Gabriel. O Modelo de Referência OSI para Protocolos de Rede. Disponivel

em: <http://www.clubedohardware.com.br/artigos/redes/o-modelo-de-
refer%C3%AAncia-osi-para-protocolos-de-rede-r34766/>. Acesso em: 22 de outubro

XBee manual. Product Manual v1.xAx - 802.15.4 Protocol. Disponível em: <
https://www.sparkfun.com/datasheets/Fi-Fi/ZigBee/XBee-Manual.pdf>. Acesso em: 16
de setembro de 2017.
 48

APÊNDICE A – CÓDIGO FONTE DO MÓDULO CONTROLADOR

#include <SPI.h>
#include <Ethernet.h>
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192, 168, 0, 200 };
byte gateway[] = { 192, 168, 0, 1 };
byte subnet[] = { 255, 255, 255, 0 };
EthernetServer server(88);
byte sampledata = 50;
int swt1 = 5;
int swt2 = 6;
int swt3 = 7;
String readString = String(30);
String statswt;
void setup () {
Ethernet.begin(mac, ip);
Serial.begin(9600);
pinMode(swt1, OUTPUT);
pinMode(swt2, OUTPUT);
pinMode(swt3, OUTPUT);
}
void loop () {
EthernetClient client = server.available();
if (client) {
boolean newLine = true;
String line = "";
while (client.connected() && client. available()) {
char var = client.read();
if (readString.length() < 30) {
readString += (var);
}
if (var == '\n' && newLine) {
if (readString.indexOf("swt1") >= 0) {
digitalWrite(swt1, !digitalRead(swt1));
}
if (readString.indexOf("swt2") >= 0) {
digitalWrite(swt2, !digitalRead(swt2));
}
if (readString.indexOf("swt3") >= 0) {
digitalWrite(swt3, !digitalRead(swt3));
}
 49

client.println("HTTP/1.1 200 OK");

client.println("Content-Type: text/html");
client.println();
client.println("<!doctype html>");
client.println("<html>");
client.println("<head>");
client.println("<title>Smart Home</title>");
client.println("</title>");
client.println("<meta name=\"viewport\" content=\"width=320\">");
client.println("<meta name=\"viewport\" content=\"width=device-width\">");
client.println("<meta charset=\"utf-8\">");
client.println("<meta name=\"viewport\" content=\"initial-scale=1.0, user-
scalable=no\">");
client.println("</head>");
client.println("<body>");
client.println("<center>");
client.println("<font size=\"5\" face=\"verdana\" color=\"green\">Smart</font>");
client.println("<font size=\"3\" face=\"verdana\" color=\"red\"> droid </font>");
client.println("<font size=\"5\" face=\"verdana\" color=\"blue\">Home</font><br
/>");
if (digitalRead(swt1)) {
statswt = "0n";
Serial.println(1);
}
else {
statswt = "0ff";
Serial.println(2);
}
client.println("<form action=\"swt1\" method=\"get\">");
client.println("<button type=submit style=\"width:150px;\">switch 1 => " +
statswt + " </button>");
client.println("</form> <br />");
if (digitalRead(swt2)) {
statswt = "0n";
Serial.println(3);
}
else {
statswt = "0ff";
Serial.println(4);
}
client.println("<form action=\"swt2\" method=\"get\">");
 50

client.println("<button type=submit style=\"width:150px;\">switch 2 => " +

statswt + " </button>");
client.println("</form> <br />");
if (digitalRead(swt3)) {
statswt = "0n";
Serial.println(5);
}
else {
statswt = "0ff";
Serial.println(6);
}
client.println("<form action=\"swt3\" method=\"get\">");
client.println("<button type=submit style=\"width:150px;\">switch 3 => " +
statswt + " </button>");
client.println("</form> <br />");
client.println("</center>");
client.println("</body>");
client.println("</html>");
readString = "";
client.stop();
}
}
}
}
 51

APENDICE B – CÓDIOGO FONTE DO MÓDULO DE CONTROLE

int value = -1;

String estado;
int swt1 = 5;
int swt2 = 6;
int swt3 = 7;
void setup() {
pinMode(swt1, OUTPUT);
pinMode(swt2, OUTPUT);
pinMode(swt3, OUTPUT);
Serial.begin(9600);
}
void loop() {
if (Serial.available() > 0) {
value = Serial.read();
if(value == '1'){
digitalWrite(swt1, HIGH);
} else if(value == '2'){
digitalWrite(swt1, LOW);
}
if(value == '3'){
digitalWrite(swt2, HIGH);
} else if(value == '4'){
digitalWrite(swt2, LOW);
}
if(value == '5'){
digitalWrite(swt3, HIGH);
} else if(value == '6'){
digitalWrite(swt3, LOW);
}
}
}