MINISTÉRIO DA DEFESAEXÉRCITO BRASILEIRO

DEPARTAMENTO DE CIÊNCIA E TECNOLOGIAINSTITUTO MILITAR DE ENGENHARIA

CURSO DE GRADUAÇÃO EM ENGENHARIA ELÉTRICA

1 Ten FELIPE MEDEIROS PESSOA DA SILVA

IMPLEMENTAÇÃO DE INTERNET DAS COISAS COM ACOMUNICAÇÃO DE OBJETOS VIA NUVEM

Rio de Janeiro2018

INSTITUTO MILITAR DE ENGENHARIA

1 Ten FELIPE MEDEIROS PESSOA DA SILVA

IMPLEMENTAÇÃO DE INTERNET DAS COISAS COM ACOMUNICAÇÃO DE OBJETOS VIA NUVEM

Projeto de Fim de Curso apresentado ao Curso de Graduação emEngenharia de Elétrica do Instituto Militar de Engenharia, comorequisito parcial para a obtenção do título de Engenheiro Eletri-cista.

Orientador: Prof. Andre Rotava - M.Sc.Co-Orientador: Prof. Amarildo Teodoro da Costa - D.Sc.

Rio de Janeiro2018

c2018

INSTITUTO MILITAR DE ENGENHARIAPraça General Tibúrcio, 80 - Praia VermelhaRio de Janeiro - RJ CEP 22290-270

Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-loem base de dados, armazenar em computador, microfilmar ou adotar qualquer forma dearquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecasdeste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou venha aser fixado, para pesquisa acadêmica, comentários e citações, desde que sem finalidadecomercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es) e do(s)orientador(es).

621.3 da Silva, Felipe Medeiros PessoaS586i Implementação de Internet das Coisas com a comuni-

cação de objetos via Nuvem / Felipe Medeiros Pessoada Silva, orientado por Andre Rotava e Amarildo Te-odoro da Costa - Rio de Janeiro: Instituto Militar deEngenharia, 2018.

112p.: il.

Projeto de Fim de Curso (graduação) - InstitutoMilitar de Engenharia, Rio de Janeiro, 2018.

1. Curso de Graduação em Engenharia Elétrica -projeto de fim de curso. 1. Internet das Coisas. 2.MQTT. 3. Nuvem. I. Rotava, Andre . II. da Costa,Amarildo Teodoro . III. Título. IV. Instituto Militar deEngenharia.

1

À minha família, a quem dedico todo meu caminho.

3

AGRADECIMENTOS

Agradeço a todos os apoiadores de minha trajetória profissional e acadêmica. Em

especial, aos meus professores e orientadores André Rotava, Amarildo e Major Sandro

pelo suporte dado durante todo o curso profissional.

4

“A pessimist sees the difficulty in every opportunity; an optimist

sees the opportunity in every difficulty. ”

WINSTON CHURCHILL

5

SUMÁRIO

LISTA DE ILUSTRAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

LISTA DE SIGLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

LISTA DE ABREVIATURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3 Estrutura da Monografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 CONCEITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Arquitetura dos Objetos Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Modelo Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Protocolos e padrões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.2 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 SISTEMA DE REDE DE TOMADAS INTELIGENTES . . . . . . . . . . 26

3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.2 Broker Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.3 Broker na Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Interação com a Tomada Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 IMPLEMENTAÇÃO E TESTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.1 ESP8266 e NodeMCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.2 Relé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.3 Conversor de nível lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.4 Sensor de Corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.5 Fonte de Alimentação DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.6 Montagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6

4.2.1 Instalação e Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.2 Código: NodeMCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.2.1Wi-Fi pré-configurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.3 Wi-Fi pós-configurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.3.1Conexão com o Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2.4 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.1 Instalação e Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.2 Código: App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.3 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.4 Testes e Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6 REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7 APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.1 APÊNDICE 1: Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.1.1 Código Arduino: em C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.1.2 Código Android Studio: em Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.1.3 Código Android Studio: em XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7

LISTA DE ILUSTRAÇÕES

FIG.1.1 Pesquisas sobre os termos WSN e Internet of Things, no Google

(SANTOS, 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

FIG.2.1 2008 - 2009 o ’nascimento’ da Internet das Coisas (EVANS, 2011) . . . . . 20

FIG.2.2 Modelo de arquitetura para Objetos Inteligentes (SANTOS, 2016) . . . . . 21

FIG.2.3 Arquitetura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

FIG.2.4 Modelo de Referência do TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

FIG.2.5 Esquema representando o modelo MQTT (BUGINGA, 2017) . . . . . . . . . . 24

FIG.2.6 Tipos de distribuição de mensagem suportados pelo protocolo

MQTT (B. B. TORRES, 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

FIG.3.1 Diagrama de blocos da Arquitetura base . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

FIG.3.2 Gráfico da carga de trabalho progressiva (B. B. TORRES, 2016) . . . . . . . 28

FIG.3.3 Gráfico de uso da cpu, em % (B. B. TORRES, 2016) . . . . . . . . . . . . . . . . . 29

FIG.3.4 Gráfico de consumo de memória, em MB (B. B. TORRES, 2016) . . . . . . 29

FIG.3.5 Gráfico de pacotes/min (B. B. TORRES, 2016) . . . . . . . . . . . . . . . . . . . . . 30

FIG.3.6 Esquema de Arquitetura com Broker Local . . . . . . . . . . . . . . . . . . . . . . . . . 31

FIG.3.7 Terminal recebendo mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

FIG.3.8 Terminal publicando mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

FIG.3.9 Terminal tentando publicar sem as credencias corretas . . . . . . . . . . . . . . . 33

FIG.3.10 Terminal com as credencias corretas recebendo mensagens . . . . . . . . . . . . 34

FIG.3.11 Arquitetura com Broker global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

FIG.3.12 Criando uma nova instância no CloudMQTT . . . . . . . . . . . . . . . . . . . . . . . 36

FIG.3.13 Detalhes da nova instância criada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

FIG.3.14 CloudMQTT publicando uma mensagem . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

FIG.3.15 Celular recebendo uma mensagem da Nuvem . . . . . . . . . . . . . . . . . . . . . . . 37

FIG.3.16 Modelo de Tomada Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

FIG.3.17 Diagrama de blocos da tomada inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . 39

FIG.4.1 NodeMCU com o ESP8266 incorporado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

FIG.4.2 Pinagem do NodeMCU. Fonte: www.arduining.com . . . . . . . . . . . . . . . . . 43

FIG.4.3 Módulo Relé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

FIG.4.4 Conversor de nível lógico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

FIG.4.5 Sensor de Corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8

FIG.4.6 Divisor de tensão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

FIG.4.7 Fonte de Alimentação DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

FIG.4.8 Circuito da Tomada Inteligente: Alimentação . . . . . . . . . . . . . . . . . . . . . . . 48

FIG.4.9 Circuito da Tomada Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

FIG.4.10 Esquemático das ligações dos componentes . . . . . . . . . . . . . . . . . . . . . . . . . 50

FIG.4.11 Download do Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

FIG.4.12 Arduino Preferências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

FIG.4.13 Gerenciamento de Placas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

FIG.4.14 Arduino Placas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

FIG.4.15 Instalação da Placa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

FIG.4.16 Rede WiFi do NodeMCU disponível para conexão . . . . . . . . . . . . . . . . . . . 58

FIG.4.17 Modo de configuração da rede WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

FIG.4.18 Download do Android Studio IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

FIG.4.19 Configurando um celular virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

FIG.4.20 Começando com o design do app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

FIG.4.21 Localizando o MainActivity.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

FIG.4.22 Mensagem exibida ao clicar no botão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

FIG.4.23 Modelo final do App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

FIG.4.24 Conectando à Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

FIG.4.25 Ligando a tomada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

FIG.4.26 Tomada acionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

FIG.4.27 Desligando a tomada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

FIG.4.28 Começando com o design do app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

FIG.4.29 Fluxo de mensagens durante ON/OFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

FIG.4.30 Temporizador de 1 minuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

FIG.4.31 Fluxo de mensagens durante a temporização . . . . . . . . . . . . . . . . . . . . . . . . 80

FIG.4.32 Consumo do ferro de passar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

FIG.4.33 Nome da tomada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

FIG.4.34 Resetar WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

FIG.4.35 Resetando o WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

FIG.4.36 Reconfigurando a rede WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

FIG.4.37 Conectando o WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9

LISTA DE SIGLAS

IoT Internet of Things

RFID Radio Frequency IDentification

TCP Transmission Control Protocol

IP Internet Protocol

MQTT Message Queue Telemetry Transport

WAMP Web Application Messaging Protocol

10

LISTA DE ABREVIATURAS

ABREVIATURAS

WiFi - Wireless Fidelity

CoAP - Constrained Application Protocol

M2M - Machine to Machine

11

RESUMO

O assunto da Internet das Coisas se tornou bastante difundido pela sociedade.

O termo se popularizou com o crescimento exponencial do número de aplicações e

dispositivos que estão em uso pelo mundo, indo desde automação residencial até controle

de pacientes com doenças sensíveis. A responsabilidade que a IoT assume no cenário

mundial é alta e só tende a crescer.

Dentro disto, este projeto se dividiu em três partes. Na primeira, se dedicou a

entender o conceito daquilo que permeia o caminho entro o usuário e o dispositivo (neste

projeto, uma tomada inteligente) e procurar quais seriam as melhores soluções pra

encurtar essa distância. Foi feita uma analise profunda do que seria a Internet das Coisas

e do que motivou a sua idealização. Fez-se necessário, também o entendimento de termos

inerentes ao projeto, tais quais o modelo de objeto inteligente e a definição do que é e

do que composto o MQTT. Na segunda parte, foi realizada uma breve discussão para a

escolha dos hardwares participantes do projeto da tomada inteligente. A terceira parte

se dedicou a implementação das ferramentas escolhidas, de forma que pudesse oferecer

ao usuário do serviço a melhor experiência possível e apresentar o resultado destas. A

interação entre o usuário e a tomada foi realizada via aplicativo, desenvolvido em Java,

com auxílio da da IDE do Android Studio e a implementação da tomada, na IDE do

Arduino.

Palavras-chaves: Internet das Coisas, Nuvem, MQTT, NodeMCU.

12

ABSTRACT

The topic Internet of Things has become quite widespread by society. The term has

become popular with the exponential rise in the number of applications and devices are

being used around the world, going through since house automation and reaching things

highly sensitives, such as patient monitoring with critical diseases. The responsibility

that IoT has taken in the world is high and prone to grow more.

Grounded on this, the project was divided in three parts. In the first, the main

goal was understand the concept about everything that surround the path between

user and device (in this project, a smart power plug) and look for the best solution

to minimize this distance. A deep analysis was made in the term Internet of Things

and what had motivated its idealization. Necessary to the understand of this part,

essentials terms like MQTT and the definition of smart objects were studied. In the

second part, the focus was chose the hardware will integrate the project of smart socket.

The third part is dedicated to improve the tools are choose and offer to the user the

best experience possible and present the results of them. The interaction between

user and power plug was made through app, developed in Java, in the Android Stu-

dio IDE platform and the implementation of the power plug, in the Arduino IDE platform.

Keywords: Internet of Things, Cloud, MQTT, NodeMCU.

13

1 INTRODUÇÃO

A ideia de interligar os mais diversos equipamentos e conectá-los do mundo virtual ao

real não é algo exclusivo dos tempos mais modernos. Na verdade, o conceito embrionário

teve o início do seu desenvolvimento ainda no começo dos anos 1990, com o artigo "The

Computer for the 21st Century", publicado por Mark Weiser. Mais tarde, em 1999, o

termo Internet of Things (IoT) foi criado e, então, o mundo passou a orquestrar uma

revolução na maneira como nós nos relacionamos com as coisas (ou objetos) ao nosso en-

torno. O conceito e definição de Internet das Coisas será tratado de forma mais detalhada

e abrangente mais adiante.

Paralelamente ao conceito de IoT, foi surgindo o da comunicação via Nuvem, que

nada mais era do que uma forma dinâmica de acesso, pelo usuário, aos dados gerados no

monitoramento das coisas.

O protótipo de um mundo interconectado que a IoT propunha chamou à atenção de

diversas empresas no ramo da Engenharia Elétrica, da Eletrônica e da Computação que

começaram a direcionar seus esforços ao barateamento, à redução de consumo de energia

e à diminuição dos componentes microeletrônicos. O mundo caminhava para a era dos

objetos inteligentes. Os sonhos futuristas da humanidade de se ter casas, fábricas e carros

inteligentes não parecia mais tão impossível.

Não obstante, assim como acontecera com os computadores e seus periféricos no século

passado, um problema de compatibilidade nesse modelo acabou surgindo entre objetos.

Sucintamente, o mercado ainda não desenvolveu um modelo padrão de comunicação entre

as coisas e o usuário, o que dificulta a integração de componentes de diferentes marcas ao

que o IoT propõe: a integração de todas as coisas à Internet.

1.1 MOTIVAÇÃO

O progressivo aperfeiçoamento de funcionalidades direcionadas ao objeto contribui para

a afirmação da IoT no cenário mundial. É bem verdade que a concepção de Internet

das Coisas não é atual. Entretanto, o interesse pelo tema começou a se tornar mais

notório no início desta década. O sustentáculo do impulsionamento desse interesse são

as Redes de Sensores Sem Fio (RSSF), ou em inglês, Wireless Sensor Network (WSN),

que apresenta uma relação intrínseca com a IoT, visto que trazem upgrades sustanciais na

14

esfera da automação industrial e residencial. O amadurecimento das WSN, em adição a

um aumento das expectativas acerca da IoT gerou o terreno fértil que causou a explosão

de buscas sobre o tema (SANTOS, 2016), conforme a Figura 1.1 mostra:

FIG. 1.1: Pesquisas sobre os termos WSN e Internet of Things, no Google (SANTOS,2016)

O espectro de utilização da IoT varre uma vasta gama de empregos desta tecnologia

no nosso cotidiano. Dentre as possíveis aplicações, pode-se citar:

• Controle da produtividade agrícola: através da IoT, a agricultura pode ser benefi-

ciada com a irrigação de forma mais racional, plantio e colheita conforme condições

meteorológicas locais e gerenciamento de propriedades, por exemplo (SENAR, 2017).

• Monitoramento de tempo de semáforos: Baseando seus cálculos no horário e fluxo

de automóveis, semáforos inteligentes se adequam a diversos tráfegos de veículos a

fim de minimizar congestionamentos.

• Monitoramento remoto de pacientes: A medicina moderna se adequou bem às re-

voluções da Internet das Coisas. Já é possível pacientes serem monitorados por

sensores em prol da melhoria do serviço de saúde prestado. Já existem dispositivos

com sensores que medem sinais vitais e outros dados biométricos e repassam essas

informações para a analise a fim de previnir complicações.

Uma das aplicações que ganhou notoriedade é a utilização de Internet das Coisas para

aplicações residenciais. São as chamadas casas inteligentes que, através da tecnologia da

IoT, oferecem ao usuário a possibilidade de desfrutar o máximo possível de suas aplicações,

15

seja para obter mais segurança, através de monitoramento remoto ou alertas de invasão, ou

mesmo para aumentar seu conforto, como por controle de luminosidade, monitoramento

de consumo, controle de temperatura automático, entre outros.

Caminhando para o futuro, os sistemas de automação residencial poderão ter uma

funcionalidade semelhante ao que acontece com o USB nos computadores. Ao se conectar

um dispositivo via USB no computador, automaticamente, no monitor é exibido o ícone do

que foi conectado, como um celular, um pendrive ou uma memória externa, por exemplo.

Trazendo isso para as casas inteligentes, a ideia seria que ao se adicionar algum dispositivo

novo na casa, como uma televisão ou uma câmera, por exemplo, o sistema da casa o

reconhecesse e, a partir daí, o usuário pudesse utilizar todas as funções desenvolvidas para

aquela aplicação adicionada. Dentro desse escopo, porém mais simples, seria desenvolver

essa concepção para uma rede de tomadas inteligentes, onde, ao se conectar algo nela, o

sistema reconhecesse que tipo de dispositivo foi conectado e então passasse a permitir ao

usuário interagir com ele.

1.2 OBJETIVO

Com base nas motivações apresentadas, o presente trabalho tem por objetivo:

Projetar um sistema de casa inteligente genérico, baseado em tecnologias vol-

tadas para a Internet das Coisas, com emprego de rede WiFi e comunicação

via Nuvem e desenvolver um aplicativo de interface amigável para interação

do usuário com a tecnologia desenvolvida.

1.3 ESTRUTURA DA MONOGRAFIA

A estruturação desta monografia está dividida nos seguintes capítulos:

• Conceitos: Neste capítulo, foram explorados tópicos essenciais para o entendimento

do que viria a se tornar a tomada inteligente. Uma profunda análise do que é a

IoT foi feita. Após isso, explorou-se o modelo de Objeto Inteligente, que é formado

pelas 4 unidades: processamento, memória, comunicação e sensores/atuadores. Uma

breve explicação do que seria TCP/IP e o modelo cliente-servidor também ocorreu

neste capítulo. Além disso, foi debatido também os protocolos que são utilizados

atualmente para comunicação na Internet, tais quais HTTP e o MQTT, que tem a

capacidade de desacoplar no tempo e espaço o emissor do receptor

16

• Sistema de Rede de Tomadas Inteligentes: Este capítulo começou com o sequencia-

mento da arquitetura que seria adotada como sendo a deste projeto. Foram avaliados

e escolhidos individualmente cada componente da arquitetura, desde o usuário até a

tomada. Definição do MQTT como protocolo de comunicação, visto suas vantagens

sobre o HTTP, do WiFi como rede de comunicação, a escolha do Mosquitto como o

Broker do projeto e a escolha entre o modelo de servidor local ou na Nuvem foram

alguns dos pontos mais importantes abordados neste capítulo.

• Implementação e Teste: O capítulo 4 começou com a definição dos principais com-

ponentes eletrônicos usados no protótipo. Módulo WiFI NodeMCU, Módulo Relé,

Sensor de Corrente, Conversor de Nível Lógico e uma Fonte de Alimentação DC

foram os escolhidos para serem a estrutura da tomada inteligente. Além do mais,

um esquemático com as ligações também foi fornecido neste capítulo. Outro ponto

abordado aqui foi a implementação do código, em C, através da plataforma Arduino

IDE, para o Módulo WiFi com algumas tomadas de decisão importantes, como a

utilização de uma Web página onde o usuário poderia acessá-la e configurar sua rede

WiFI sem a necessidade de gravar os dados previamente no código do NodeMCU.

Também foi fornecido um tutorial de como instalar a IDE do Arduino, interagir

com ela e realizar modificações importantes no código. Ao final, foi adicionado um

troubleshooting para que futuros desenvolvedores evitem de cair em alguns erros

comuns. Na parte do aplicativo, um tutorial semelhante foi realizado para a plata-

forma Android Studio, em Java e XML. Ao final, um troubleshooting também foi

fornecido. E, finalmente, no final do capítulo, os resultados foram apresentados.

17

2 CONCEITOS

2.1 INTERNET DAS COISAS

Como visto anteriormente, o termo Internet das Coisas não é exclusivo dos tempos

mais atuais. Seguindo uma linha do tempo, o ponto de partida da Internet das Coisas é a

tecnologia do RFID, que surgiu em 1940, em meio a um mundo tenso por conta da Segunda

Guerra Mundial. Os aviões que sobrevoavam os céus durante a guerra dispunham de um

equipamento chamado de transponder. Os transponders enviam uma identificação única

por radiofrequência, identificando os aviões no seu entorno. Isso evitava que a aeronave

entrasse em rotas colisivas e era um fator determinante na execução de manobras e ataques

(DE OLIVEIRA, 2017). Hoje, o RFID é largamente utilizado em veículos, em crachás de

identificação e até mesmo na detecção de incêndios.

Mais tarde, nos anos 1990, o cientista norte americano Mark Weiser, no seu artigo

"The Computer for the 21st Century", publicado em 1991, criou o termo Ubiquitous Com-

puting (em português, Computação Ubíqua), que seria usado pra descrever a onipresença

da informática no cotidiano das pessoas. Numa de suas passagens de seu artigo, Mark

proferiu a seguinte frase:

"The most profound technologies are those that disappear. They weave themselves

into the fabric of everyday life until they are indistinguishable from it(WEISER, 1991)."

Weiser, quando diz que as tecnologias mais profundas são aquelas que são pouco

notadas, cria um cenário de integração hipotético, que mais tarde ia se mostrar uma

realidade, onde a facilidade de uso dessas tecnologias tornaria sua utilização uma atividade

natural do dia-a-dia.

O conceito abordado por Mark Weiser ganharia um nome, anos mais tarde. Em

1999, Kevin Ashton, um pioneiro da tecnologia britânica, usou pela primeira vez o termo

Internet of Things numa apresentação para executivos da Procter & Gamble. Em uma

entrevista, Ashton disse que a terminologia IoT surgiu para nomear uma necessidade de se

etiquetar eletronicamente, via RFID, produtos de uma empresa para facilitar a logística

de cadeia de produção (FINEP, 2015). Em um artigo, em 1999, Kevin Ashton escreveu:

"If we had computers that knew everything there was to know about things—using data

they gathered without any help from us – we would be able to track and count everything,

18

and greatly reduce waste, loss and cost. We would know when things needed replacing,

repairing or recalling, and whether they were fresh or past their best. We need to empower

computers with their own means of gathering information, so they can see, hear and

smell the world for themselves, in all its random glory. RFID and sensor technology

enable computers to observe, identify and understand the world—without the limitations

of human-entered data (ASHTON, 1999)."

Portanto, a Internet das Coisas deve ser enxergada muito além de apenas acender

lâmpadas com smartphones, ela deve ser vista como uma maneira dos seres inanimados

(objetos, coisas) se relacionar entre eles mesmos e com nós, os seres humanos, exercendo,

então, a concepção de estar em rede. Basicamente, seria tornar essas coisas à objetos

inteligentes. Para que um ser inanimado seja considerado um objeto inteligente, ele deve

ter as qualidades citadas abaixo (RUIZ, 2004; LOUREIRO; FIGUEIREDO, 2003):

• Unidade(s) de processamento;

• Unidade(s) de memória;

• Unidade(s) de comunicação;

• Unidade(s) de sensor(es) ou atuador(es).

O que Ashton estava propondo era algo que ainda não podia condizer com a realidade

da época. Interligar bilhões de dispositivos demandaria um tráfego de dados gigantesco.

Era necessário ainda mudanças e melhorias substanciais na tecnologia.

Com o passar dos anos, os crescentes interesses nas área da microeletrônica, nas

tecnologias de comunicação e redes de computadores, em conjunto com o aumento do

interesse na IoT, impulsionaram o mercado da Internet das Coisas à atingir um patamar

completamente novo. A inserção de microeletrônica de baixo custo e consumo em adição

à flexibilidade de acesso aos dados (popularização dos smartphones e de tecnologias de

comunicação, WiFi e 3G/4G, por exemplo) garantiram um terreno fértil para a difusão

da Internet das Coisas (DE OLIVEIRA, 2017). A Figura 2.1 mostra o quão agressivo é o

crescimento da IoT e quão grande ela será em 2020.

19

FIG. 2.1: 2008 - 2009 o ’nascimento’ da Internet das Coisas (EVANS, 2011)

2.2 ARQUITETURA DOS OBJETOS INTELIGENTES

Como citado no item 2.1, os objetos inteligentes são compostos por unidades de

processamento, memória, comunicação e sensores/atuadores. Sua arquitetura básica segue

exatamente essa composição e leva também em consideração a adição da sua alimentação.

A Figura 2.2 ilustra esse modelo que pode ser subdividido em (SANTOS, 2016):

• Unidade(s) de processamento/memória: a unidade de processamento inclui um mi-

crocontrolador que orquestra as ações dos sinais recebidos pelos sensores, enquanto

a unidade de memória tem capacidade de armazenar programas e dados;

• Unidade(s) de comunicação: responsável por criar um canal de comunicação entre

o dispositivo e o usuário, representada aqui pela comunicação via rádio;

• Fonte de energia: alimenta o dispositivo com sua devida tensão. No universo da

internet das coisas, essa alimentação, geralmente, é feita em DC, portanto, normal-

mente, essas fontes tem um conversor AC-DC; e

• Unidade(s) de sensor(es) ou atuador(es): são responsáveis por interagir o objeto

com o ambiente. Os sensores monitoram o ambiente e medem grandezas físicas,

tais quais umidade e temperatura, ao passo que os atuadores realizam alguma ação

sobre o ambiente.

20

FIG. 2.2: Modelo de arquitetura para Objetos Inteligentes (SANTOS, 2016)

2.3 MODELO CLIENTE-SERVIDOR

O modelo cliente-servidor é um modelo request-response que é a base de comunicação que

a internet emprega. O sistema se sustenta na premissa de que os clientes requisitam o

servidor da rede para que este forneça as informações solicitadas. É importante frisar

que neste padrão, a iniciação de comunicação é unidirecional, sendo iniciada sempre pelo

cliente. Podemos definir estes dois itens da seguinte maneira (DE OLIVEIRA, 2017):

• Servidor: é o software responsável por responder às solicitações de informações

dos clientes. Geralmente, os servidores mantém sua porta de comunicação aberta

o tempo todo, permitindo, assim, que muitos clientes possam acessar seu serviço.

Para que os clientes acessem o servidor, faz-se necessário conhecer sua localização.

Normalmente, servidores são rodados por computadores de alto desempenho, visto

que a demanda ocasionada por multi acessos de clientes pode afetar a qualidade do

serviço;

• Cliente: clientes também são softwares de processo ativo, sendo eles responsáveis por

iniciar, diretamente ou automaticamente, uma conexão com o servidor. Os clientes

são, normalmente, dedicados ao usuário, por isso, é interessante que tenham uma

interface gráfica amigável e intuitiva. É interessante destacar que, dentro do universo

da IoT, não necessariamente o acesso aos servidores, pelos clientes, será feito por um

21

usuário animado. Objetos inteligentes também podem exercer o papel de clientes,

para consultar ou atualizar dados acerca de seu próprio funcionamento.

A Figura 2.3 ilustra uma aplicação diária na utilização da arquitetura cliente-servidor.

FIG. 2.3: Arquitetura cliente-servidor

2.4 PROTOCOLOS E PADRÕES

2.4.1 TCP/IP

Sumariamente, protocolos são um conjunto de regras que regem a semântica, sintaxe e

informação entre dois sistemas computacionais, sendo assim, então, a linguagem, ou idi-

oma, entre duas máquinas. O TCP/IP, criado pelo Departamento de Defesa dos Estados

Unidos, é um dos protocolos de comunicação mais usados atualmente. Na verdade, ele é

uma pilha (conjunto) de protocolos. Devido à Internet das Coisas ter como seu alicerce

a Internet, o modelo TCP/IP é capaz de descrever bem as camadas empregadas nela.

Esse conjunto de protocolos é estratificado em quatro camadas, como visto na Figura

2.4, sendo que cada uma delas é responsável por exercer um ofício diferente de forma a

garantir a segurança e integridade dos dados que circulam na rede (MARTINS, 2012).

• Camada de Aplicação: é a camada onde os dados são gerados, ou recebidos de

outros programas via rede. Está nessa camada, por exemplo, o famoso protocolo

22

FIG. 2.4: Modelo de Referência do TCP/IP

HTTP, que é o mais usado na navegação web. Entretanto, esse modelo tem alto

grau de complexidade computacional e elevado gasto de energia em dispositivos IoT.

Mais adiante, será visto um protocolo chamado MQTT que atende muito bem as

especificações impostas pelos dispositivos de baixo custo empregados na Internet

das Coisas.

• Camada de Transporte: é a responsável por receber e empacotar os dados enviados

pela camada de aplicação. O protocolo TCP é o mais utilizado nessa camada. Ele

apresenta grande confiabilidade na transmissão, além de ser full-duplex, ou seja,

durante sua sessão, é possível realizar transferência simultânea nas duas direções

(MARTINS BEZERRA, 2008).

• Camada de Rede: A camada de rede é a responsável por receber e endereçar os

pacotes recebidos da camada de transporte. O protocolo IP é o protocolo utilizado

nessa camada atualmente. Sua fama se deve ao fato dele permitir a elaboração e

transporte dos datagramas IP, que são a unidade básica de dados a nível IP. Os

datagramas são divididos em duas partes, uma para o cabeçalho e uma de dados.

O protocolo IP está disponível em duas versões: IPv4 e Ipv6. A versão 4, de 32

bits, suporta no máximo 4,29 bilhões de dispositivos. Como visto anteriormente,

na Figura 2.1, a quantidade atual de dispositivos conectados já é muito superior a

esse número suportado pelo IPv4. Por isso, a versão IPv6, de 128 bits, é muito mais

adequada para o cenário IoT, visto que ela pode suportar um número muito mais

que suficiente para a realidade atual (DE OLIVEIRA, 2017).

• Camada de Interface: também conhecida como subcamada física, na camada de in-

terface os dados são transformados em sinais (elétricos, magnéticos) e transmitidos.

No universo da Internet das Coisas, o padrão IEEE 802.11, popularmente conhecido

como WiFi, é um dos mais utilizados, pelo fato de usar comunicação sem fio.

23

FIG. 2.5: Esquema representando o modelo MQTT (BUGINGA, 2017)

2.4.2 MQTT

O MQTT, inventado e desenvolvido pela IBM no final da década de 90 com o propósito

de vincular sensores em pipelines de petróleo a satélites, é um protocolo projetado para

comunicação M2M, produzido com base na pilha TCP/IP e que tem como objetivo de-

sacoplar o emissor e o receptor da mensagem tanto temporalmente com espacialmente.

Por ser projetado para ter baixo consumo de banda de rede e de energia, ele é ideal para

aplicações IoT, que ocasionalmente tem conexões com restrições de tamanho de código e

de largura banda de rede (BUGINGA, 2017).

O protocolo MQTT, ilustrado na Figura 2.5, adota, para seu padrão de funciona-

mento, duas entidades na rede, o message server e n clientes. O servidor recebe as men-

sagens dos clientes e as repassa aos clientes de destino relevante. Qualquer entidade com

capacidade de interagir com o servidor pode ser considerado um cliente, tais como senso-

res de aplicação de IoT ou mesmo um aplicativo que processa os dados de IoT (YUAN,

2017). O protocolo MQTT, ilustrado na Figura 2.5, tem seus elementos definidos como:

• Broker : é o servidor responsável por ficar disponível a todo momento, fazendo o

gerenciamento entre os que produzem os dados e os que estão à espera deles. Este

servidor pode ser executado internamente na própria rede, de maneira local, ou ainda

pode ser distribuído de forma global, num servidor externo, com seus dados sendo

armazenados num serviço de Nuvem. O modelo por Nuvem dispensa a presença de

24

um servidor local. Isso é um ponto importante para se levar em consideração de

dispositivos que estão localizados em ambientes hostis e de baixa confiabilidade.

• Publisher : é todo cliente capaz de gerar e enviar dados para o servidor broker. Na

Figura 2.5, os dispositivos publisher estão ilustrados por sensores.

• Subscriber : é todo cliente assinante dos serviços disponibilizados pelo publisher. Os

clientes que são subscribers devem receber as informações produzidas pelos clientes

publishers via o servidor broker. Ainda podem, com as informações recebidas, exe-

cutar ações ou gerar uma interface para sua vizualização (DE OLIVEIRA, 2017).

Na Figura 2.5, os subscribers estão representado pelo celular e pelo computador.

• Tópico: é o canal virtual por onde as mensagens transitam do publisher até o

subscriber. Para que um cliente subscriber receba os dados desejados que estão sendo

gerados por um determinado cliente publisher, ele deve "sintonizar"no mesmo canal

em que esses dados estão sendo enviados ao servidor broker, para que este repasse

a mensagem a todos os clientes que assinam esse tópico.

O arranjo adotado pelo protocolo MQTT permite que os clientes geradores das men-

sagens sejam desacoplados dos clientes assinantes, deste modo, apenas o conhecimento do

endereço do broker é necessário para se estabelecer comunicação. A Figura 2.6 mostra a

extensão das possibilidades de comunicação que este protocolo viabiliza (B. B. TORRES,

2016).

FIG. 2.6: Tipos de distribuição de mensagem suportados pelo protocolo MQTT(B. B. TORRES, 2016)

O emprego do protocolo MQTT para Internet das Coisas simplifica bastante a maneira

de comunicação entre os dispositivos, dispensando a necessidade do desenvolvedor de

conhecer, de antemão, conceitos como de endereços/aberturas de portas em roteadores e

firewalls (DE OLIVEIRA, 2017).

25

3 SISTEMA DE REDE DE TOMADAS INTELIGENTES

3.1 ARQUITETURA

Dentro do que já foi visto, já é possível desenhar uma arquitetura base para a comunicação

entre o usuário e o objeto inteligente. Uma das pontas da linha é o objeto inteligente que

deverá se comunicar com a outra ponta, o usuário. O trânsito dos dados entre partes pode

ser feita de diversas maneiras, tais como via cabo ou via rede sem fio, como o Bluetooth e o

WiFi. Tendo em vista que a conexão via cabo necessita que o usuário opere o sistema em

pontos específicos de dentro da casa e que o Bluetooth tem uma limitação de proximidade

e de velocidade de troca de informação, a melhor opção para o tráfego desses dados é o

WiFi, que também oferece a opção de troca de dados para o usuário que esteja distante

de sua tomada inteligente, via Internet.

Entretanto, para que seja possível usar o WiFi, tanto o usuário, quanto o objeto

inteligente devem ter, integrados no seu sistema, um módulo WiFi. Os celulares atuais

já vem com essa funcionalidade embutida neles. Porém, a tomada inteligente precisaria

acrescentar esta função nela. Dentro do modelo de objeto inteligente, deve-se adicionar

um módulo WiFi, que vai configurar a Unidade de Comunicação, como foi visto no Item

2.2. É interessante que este módulo WiFi englobe também em suas especificações as

Unidades de Processamento e Memória. No Capítulo 4, será mostrado um módulo WiFi

que executa bem estas funções citadas.

FIG. 3.1: Diagrama de blocos da Arquitetura base

O princípio do IoT é justamente comunicar entidades para troca de mensagens e

dados por intermédio da Internet. Nesta arquitetura, o acesso da tomada inteligente à

Internet é feito através de um roteador com um cabo de banda larga conectado a ele para

que sejam transmitidos os dados a Internet. Celulares também podem se conectar aos

26

roteadores para acessar a Internet ou mesmo utilizar o plano de telefonia móvel para fazer

este acesso. Porém, para que ambos consigam conversar é preciso que falem a mesma

língua, ou seja, estejam se comunicando através do mesmo protocolo. Outrossim, essas

mensagens precisam ser expostas ao usuário de forma "amigável". Para isto é necessário

criar uma interface para que o cliente não tenha dificuldades de interagir com a tomada

inteligente. Neste modelo de projeto, um aplicativo de celular que possa se comunicar

com a tomada exerce bem essa função. O App será melhor explorado no Capítulo 4. No

capítulo 2, foram vistos alguns protocolos utilizados, como o HTTP e o MQTT. O HTTP

é o protocolo mais utilizado na camada de aplicação. Todavia, para aplicações de Internet

das Coisas, ele é não é muito indicado, devido a algumas limitações relevantes:

• O HTTP é demasiadamente pesado, necessitando de uma capacidade de processa-

mento que não condiz com os dispositivos utilizados no universo da IoT;

• No HTTP, a conexão é unidirecional e iniciada pelo cliente. Isso se torna um pro-

blema no momento que, no universo IoT os sensores e dispositivos, que geralmente

são clientes, não podem receber os comandos de rede de forma passiva (YUAN,

2017);

• No HTTP, o protocolo funciona de maneira um para um. Após o cliente realizar

uma solicitação, o servidor responde entregando o solicitado. Se for pensar em

aplicações de Internet das Coisas, onde teríamos vários dispositivos conectados à

rede, esse modelo de comunicação se mostraria caro e complexo (YUAN, 2017); e

• O HTTP é um protocolo síncrono, o que não permite desacoplar no tempo e no

espaço o emissor e o receptor da mensagem. Na IoT, a grande quantidade de dis-

positivos tornaria esse sistema um problema (YUAN, 2017).

Como visto no Item 2.4.2, O MQTT lida bem com alta latência, baixa largura de

banda e instabilidade de comunicação. A escolha pelo MQTT se justifica, também, pela

ampla utilização dele pela indústria atual, tanto no âmbito da Internet das Coisas, quanto,

por exemplo, no sistema de troca de mensagens instantâneas, adotado pelo Facebook

(B. B. TORRES, 2016). O modelo MQTT adiciona mais um componente na nossa arqui-

tetura, o servidor, chamado de Broker. Como visto no Capítulo 2, ele é o responsável por

encaminhar as mensagens dos emissores aos receptores, além de desacoplá-los. Isso gera

uma boa infraestrura ao sistema para que o mesmo se aprimore ao ponto de os objetos

realizarem comunicação entre si e tomem decisões independentemente do usuário. Neste

27

projeto, esse nível de automação não foi atingido, foi trabalhado apenas no âmbito do con-

trole remoto. Não obstante, é um bom ponto de partida para um sistema de automação

residencial, propriamente dito.

Pesquisando na Internet, é possível encontrar vários Brokers com diferentes aplica-

bilidades. A subseção abaixo realizará um estudo mais detalhado acerca dos possíveis

Brokers a serem escolhidos.

3.1.1 BROKER

Como foi visto no Capítulo 2, o Broker é um elemento fundamental dentro do projeto.

Sua escolha deve ser tomada com bastante cuidado, haja vista que ele será o grande

orquestrador da troca de mensagens. Essa seção será destinada a analisar o desempenho

de brokers MQTT, rodados dentro de um hardware de baixo custo. O hardware escolhido

para rodar o broker foi o Raspberry Pi 2 Modelo B e com bases nos resultados obtidos

nele, pode-se escolher o broker mais adequado.

Dentre os brokers mais famosos, que foram utilizados no teste, temos o Mosquitto,

com linguagem em C, o Apollo, com linguagem em Java, o Mosca, com linguagem em

Javascript, o eMQTT, com linguagem em Erlang e o Ponto, com linguagem em Javascript.

Para executar a avaliação, foram iniciados processos (threads) aos poucos, em forma

de degraus, até que um máximo fosse atingido, onde este máximo seria mantido por um

tempo de 180 segundos e, após esse tempo, passados 5 minutos, todos os processos de

captura de dados teriam sido encerrados. Usou-se como variável nos processos o número

de clientes subscribers. A Figura 3.3 denota como ocorreu esse processo (B. B. TORRES,

2016).

FIG. 3.2: Gráfico da carga de trabalho progressiva (B. B. TORRES, 2016)

28

Para a primeira análise de desempenho, foi avaliado o uso da CPU. Como pode ser

visto na Figura 3.4, os brokers Mosquitto, Mosca e o Ponte apresentaram os resultados

mais satisfatórios. O Apollo apresentou resultados muito instáveis e não conseguiu termi-

nar os testes. O eMQTT, apesar de ter consumido muita capacidade de processamento,

conseguiu finalizar o experimento.

FIG. 3.3: Gráfico de uso da cpu, em % (B. B. TORRES, 2016)

O segundo teste focou em ponderar o consumo de memória deste brokers. Novamente,

o pior desempenho ficou com o Apollo, com valores incrivelmente altos, superiores a 800

MB. Os brokers Mosca, eMQTT e o Ponte apresentaram resultados similares e satisfató-

rios. O Mosquitto obteve um resultado incrivelmente baixo, com consumo de memória

beirando um valor máximo de apenas 9,5 MB. A Figura 3.5 apresenta o referido teste.

FIG. 3.4: Gráfico de consumo de memória, em MB (B. B. TORRES, 2016)

29

Por fim, o último teste verificou o desempenho dos brokers perante ao número de

pacotes entregues por minuto. Mais uma vez o Ponte e o Mosca apresentaram resultados

bem parecidos. Para esse teste, mais uma vez, estes apresentaram resultados satisfatórios.

O Mosquitto teve uma saturação por volta dos 15 minutos, o que prejudicou seu resultado

nesse teste. E o Apollo, mais uma vez, não obteve resultados satisfatórios. Abaixo, na

Figura 3.6 é possível acompanhar o gráfico dos resultados obtidos.

FIG. 3.5: Gráfico de pacotes/min (B. B. TORRES, 2016)

O broker Mosquitto mostrou-se uma excelente escolha para servidor. Apesar do

problema de agir de maneira não muito constante ao atingir 4 mil conexões, os resultados

deste no consumo de memória e no uso do CPU foram surpreendentemente bons. À vista

disto, o Mosquitto é o escolhido para ser o servidor.

3.1.2 BROKER LOCAL

A análise dos modelos nos leva a duas possíveis candidatas para assumir o papel da ar-

quitetura que será usada no projeto. Numa delas, o Broker é local e noutra ele está

hospedado num servidor na Nuvem. A escolha por broker local exige que se tenha, no

ambiente, um hardware para rodar o servidor. Um dispositivo de baixo custo, como o

Raspberry Pi, já tem capacidade de processamento suficiente para que isso possa ser viá-

vel. Brokers configurados numa rede local tem a vantagem de manter os dados "em casa",

aumentando o fator de segurança dos dados que circulam, uma vez que estariam dispo-

níveis só internamente. É possível que se transmitam esses dados ainda pela internet até

um sistema de armazenamento online. Entretanto, isto adicionaria complexidade extra,

uma vez que entraria em outros conceitos da computação para realizar a comunicação

30

entre a nuvem e a rede local. A figura 3.7 ilustra a arquitetura deste modelo:

FIG. 3.6: Esquema de Arquitetura com Broker Local

Para demonstrar como funcionaria com essa arquitetura, foi utilizado um computa-

dor com o Linux (Ubuntu) instalado. A capacidade de processamento de um compu-

tador é bem superior ao necessário para rodar o broker escolhido, o Mosquitto. O site

https://mosquitto.org/download/, do próprio desenvolvedor, oferece o arquivo para

download para Windows e Mac também. Para que ele seja instalado, abra, primeira-

mente o terminal, e atualize os pacotes do Linux

$ sudo apt−get update

$ sudo apt−get upgrade

ou

$ sudo apt−get update −y && sudo apt−get upgrade −y

Após isso, com o computador conectado à Internet, instale o Mosquitto

$ sudo apt−get i n s t a l l mosquitto

$ sudo apt−get i n s t a l l mosquitto−c l i e n t s

Terminada a instalação, o Mosquitto já está disponível para ser utilizado. Para

executá-lo, basta abrir um terminal e digitar:

$ mosquitto

31

Para testar a publicação e recepção das mensagens, basta escrever e rodar, num

terminal novo, a seguinte linha de código, onde você conectará no seu servidor (-h) e

receberá a mensagem (-m) através do tópico (-t), conforme pode ser visto na Figura 3.8.

$ mosquitto_sub −h l o c a l h o s t −t t op i co

FIG. 3.7: Terminal recebendo mensagens

Para enviar a mensagem, noutro terminal, digite a linha de código a seguir e rode-o.

O resultado pode ser visto na Figura 3.9.

$ mosquito_pub −h l o c a l h o s t −m mensagem −t t op i co

FIG. 3.8: Terminal publicando mensagens

Pode-se ainda, aumentar a segurança desse tráfego de mensagens adicionando um

usuário e uma senha. Para isto, rode o comando abaixo no modo de super usuário, via

sudo, e escolha seu usuário e senha:

$ sudo mosquitto_passwd −c / e t c /mosquitto /passwd seu_usuario

32

Password : sua_senha

Reenter password : sua_senha

Após isso, é necessário dizer ao Mosquitto que ele deve usar esse usuário e essa senha

que foi configurada. Primeiramente, delete o arquivo mosquitto.config,

$ sudo rm / etc /mosquitto /mosquitto . conf

e, então, abra um novo arquivo de texto,

$ sudo nano / e tc /mosquitto /mosquitto . conf

e cole:

allow_anonymous fa l se

password_f i l e / e t c /mosquitto /passwd

A primeira linha diz ao Mosquitto para não aceitar conexões não-autenticadas ao

passo que a segunda mostra onde ele deve procurar para achar as informações dos usuários

e senhas. Para aplicar as modificações, reinicie o servidor:

$ sudo sys t emct l r e s t a r t mosquitto

E, noutro terminal, tente publicar uma mensagem sem utilizar um usuário e uma se-

nha. A mensagem que deve aparecer é uma recusa do servidor em aceitar aquela conexão,

como na Figura 3.10:

FIG. 3.9: Terminal tentando publicar sem as credencias corretas

Caso seja escrita as credencias corretas de usuário e senha, o Mosquitto irá encaminhar

normalmente aquela mensagem aos clientes inscritos naquele tópico, como na Figura 3.11.

33

FIG. 3.10: Terminal com as credencias corretas recebendo mensagens

3.1.3 BROKER NA NUVEM

Um outro modelo possível de se adotar é utilizando o Broker sendo gerenciado na Nuvem.

A grande vantagem de se ter um Broker na Nuvem é a simplicidade que ele oferece

ao projeto, ao mesmo tempo que mantém todas as ferramentas necessárias para que os

dispositivos se conectem da melhor maneira possível. O porém, se deve ao fato de que

as informações não estão mais transitando de maneira local, o que aumentaria um pouco

o risco de ataques cibernéticos. Entretanto, o risco ainda é bem baixo, além de que as

informações que circulariam seriam apenas dados de sensores e comandos, ou seja, nada

de sensível, como dados bancários. A Figura 3.12 ilustra uma arquitetura utilizando esse

modelo:

34

FIG. 3.11: Arquitetura com Broker global

Diveresas empresas disponobilizam esse serviço de servidor global em seus sites. Uma

destas, o CloudMQTT gerencia os servidores do Mosquitto (que mostraram excelente

desempenho nos resultados previamente analisados) na Nuvem, tem um plano de uso

gratuito que oferece uma boa segurança, uma vez que disponibiliza um canal com usuário

e senha para que os dispositivos possam se conectar. Além disso, o CloudMQTT permite

que o foco seja na aplicação em si, sem que se perca tempo configurando ou escalonando

as mensagens.

Para abrir uma conta nele, é necessário ir ao site https://www.cloudmqtt.com e se

cadastrar. Após o cadastramento, faça o login na conta criada e clique em "+ Create New

Instance", para criar uma nova instância.

35

FIG. 3.12: Criando uma nova instância no CloudMQTT

Os planos que o site disponibiliza variam no total de usuários permitidos, suporte

para e-mail e para celular, largura de banda, entre outros. O plano Cute Cat, apesar de

ser bastante limitado, é mais do que suficiente para esta aplicação. Terminada a criação

da instância, você poderá ver os detalhes dela, como endereço do server, usuário e senha.

FIG. 3.13: Detalhes da nova instância criada

NoWebSocket UI é possível visualizar as mensagens que estão atravessando o Broker e

seus respectivos tópicos. É possível, também, publicar mensagens para objetos específicos.

Para realizar o teste de comunicação, foi utilizado o aplicativo MQTTool, disponível na

Apple Store. O aplicativo funciona como um cliente com uma interface gráfica amigável

ao usuário. Nele é possível ser tanto o publisher como o subscriber, bastando inserir as

credenciais corretas da nossa instância. Abaixo, na Figura 3.15, o servidor está publicando

uma mensagem no tópico TestandoMQTT.

36

FIG. 3.14: CloudMQTT publicando uma mensagem

E, na Figura 3.16, é possível ver o celular recebendo ela:

FIG. 3.15: Celular recebendo uma mensagem da Nuvem

Apesar da arquitetura com o broker local oferecer mais segurança, o modelo com

ele hospedado na nuvem traz mais simplicidade ao projeto, com um nível de segurança

bastante satisfatório, além de ’afastar’ o hardware rodando o servidor do usuário, evitando,

assim, que caso algo acontecesse com o servidor, o usuário tivesse que operá-lo para

revir o uso normal. Ainda que seja possível integrar o broker local a um serviço de

37

armazenamento online, isso traria complexidade extra desnecessária para esta aplicação.

Não obstante, para um outro projeto de final de curso, pode ser interessante explorar

mais esta arquitetura. Diante disso, esse padrão com o Broker na nuvem foi o escolhido

para o projeto.

3.2 INTERAÇÃO COM A TOMADA INTELIGENTE

O modelo físico externo da tomada inteligente se assemelha ao de uma tomada comum,

como na Figura 3.15. Tendo em vista que este projeto ainda está aberto e sujeito à

implementações, um modelo mecânico e eletrônico próprio não foi desenvolvido. Porém,

no Capítulo 4 será apresentado um protótipo dele. A instalação e operação da tomada

inteligente podem ser enumeradas nos seguintes itens:

• Primeiramente, desliga-se toda a rede elétrica da casa;

• Após isso, as tomadas são instaladas utilizando as fases e o neutro da rede elétrica

da casa como suas fases e neutro de operação, igual acontece com uma tomada

comum;

• Terminada a instalação das tomadas inteligentes em todos os cômodos desejados, o

operador religa a rede elétrica;

• O usuário baixa o aplicativo de celular para servir como interface e, então, passa a

interagir com a tomada;

• Caso seja necessário trocar alguma tomada por motivos de defeito, deve-se repetir

os três primeiros itens.

38

FIG. 3.16: Modelo de Tomada Inteligente

O diagrama de blocos da tomada inteligente, que será detalhadamente explorado no

capítulo 4, pode ser visto abaixo:

FIG. 3.17: Diagrama de blocos da tomada inteligente

39

4 IMPLEMENTAÇÃO E TESTE

Este capítulo será dedicado a apresentar, na primeira seção, o protótipo da tomada in-

teligente, na segunda, o programa que rodará no processador da tomanda inteligente e

a plataforma utilizada para desenvolvê-lo e, na terceira seção, apresentar o código e a

plataforma empregue na construção do aplicativo de celular que interage com a tomada.

4.1 PROTÓTIPO

Conforme visto no segundo capítulo, os objetos inteligentes dispõe de uma estrutura

mínima segmentada em: unidade de processamento/memória, unidade de comunicação,

unidade de sensores/atuadores e fonte de alimentação. Este projeto se baseou nesta arqui-

tetura para formar a tomada inteligente. Abaixo, listar-se-ão os componentes eletrônicos

que foram escolhidos para montar este trabalho.

4.1.1 ESP8266 E NODEMCU

Visto que o principal protocolo de comunicação empregue na IoT é o WiFi, foram pesqui-

sados microcontroladores que pudessem fazer essa comunicação, via módulo WiFi, com o

meio externo e ao mesmo tempo processar e armazenar as informações recebidas. Dentre

os postulantes à integrante do projeto, um deles ganhou grande destaque: o microcon-

trolador ESP8266, produzido pela fabricante chinesa Espressif Systems. Dentre as razões

que impulsionaram sua escolha, podemos citar as principais (DE OLIVEIRA, 2017):

• Custo: o ESP8266 é incrivelmente barato, pode ser econtrado por cerca de 3 dólares

em sites chineses;

• Ambiente de desenvolvimento: o ESP8266 pode ser desenvolvido em um ambiente

i) com base na linguagem Lua, de fácil integração; ii) noutro com base no sistema

operacional de tempo real RTOS, que possibilita produzir aplicações com caráter

mais profissional; iii) e no ambiente do Arduino, adquirindo assim todo o legado já

desenvolvido para o Arduino; e

• Integração com periféricos: todos os módulos desenvolvidos para arduino são com-

patíveis com o ESP8266, ou seja, uma gama enorme de sensores, de atuadores e

40

outras ferramentas, como de comunicação e processamento. Esse fator fomentou

um ambiente fértil para o rápido desenvolvimento de aplicações de baixo custo na

Internet das Coisas.

Logo após o lançamento do ESP8266, o projeto do NodeMCU foi iniciado. O No-

deMCU é uma plataforma de código livre para IoT que inclui um firmware rodando o

Esp8266 Wi-Fi SoC (System on Chip) e usa a linguagem de script Lua. Não obstante,

optou-se pela utilização de programação em C com base na Arduino IDE (Integated Deve-

lopment Environment), que tem suporte para essa placa, por questões de integrabilidade

e familiaridade com a linguagem. Uma das grandes vantagens do NodeMCU é a presença

de uma porta micro USB para alimentação e programação, ausente em outros modelos do

ESP8266, que facilita muito o upload dos códigos no NodeMCU além de já possuir um

conversor USB serial integrado.

FIG. 4.1: NodeMCU com o ESP8266 incorporado

O NodeMCU possui as especificações abaixo com o esquema da sua pinagem dispo-

nível na Figura 4.2.

• Modelo: NodeMCU v3 Lolin WiFi ESP8266 ESP-12E

41

• Microprocessador L106 32-bit com clock 80-160MHz

• Programação e alimentação via Micro-USB

• Nível lógico: 3,3V

• Alimentação: 4,5V – 9V DC

• IEEE 802.11 b/g/n Wi-Fi

• Temperatura de operação: -40 até +125 oC

• Corrente de operação: 200 mA

• 11 GPIO com função PWM, I2C e SPI

• 1 Entrada analógica (ADC) de 10 bit limitada a 1,1V

• 2 pinos UART em pinos dedicados

• Flash QSPI externo: 512 KiB até 4 MiB (suportando até 16 MiB)

• 64 KiB de RAM de instrução, 96 KiB de RAM de dados

4.1.2 RELÉ

Para controle com ativação das funções ON/OFF e temporização, foi utilizado o disposi-

tivo de acionamento relé. Dentro da arquitetura dos objetos inteligentes, ele se encaixa

na unidade de sensores/atuadores. A Figura 4.3 apresenta um módulo relé:

Ele possui um pino IN, que é a entrada de controle do relé para mudar a posição da

chave e três pinos de saída, sendo eles um comum, um normalmente aberto e um nor-

malmente fechado. Além disso, ele possui dois pinos que estão ligados na sua bobina, um

ground e um Vcc. Seu funcionamento é bastante simples. Quando a bobina é energizada,

o comum fecha o circuito normalmente aberto e quando não está energizada, fecha com o

normalmente fechado. Abaixo, estão as especificações do módulo relé

• Modelo: Songle SRD-05VDC-SL-C

• Alimentação: 5V

• Capacidade: 30 VDC a 10A ou 250VAC a 10A

• LED indicador de status

• Tempo de resposta: 5ms a 10ms

42

FIG. 4.2: Pinagem do NodeMCU. Fonte: www.arduining.com

4.1.3 CONVERSOR DE NÍVEL LÓGICO

O modelo de relé utilizado precisa de um sinal de 5v para que seja ativado. Por esse

motivo, faz-se necessário utilizar um conversor de nível lógico para aumentar a saída do

NodeMCU de 3,3V para 5V. Conversor de nível lógico utilizado foi o:

• Modelo: Conversor de Nível Lógico 3,3-5V Bidirecional

• Nível lógico maior: 5V

• Nível lógico menor:3.3V

4.1.4 SENSOR DE CORRENTE

Para o monitoramento do consumo de energia, se utilizou um sensor de corrente. Dentro

da arquitetura de objeto inteligente, se localiza na unidade de sensores/atuadores. Para

este trabalho, foi escolhido o sensor ACS712 30A. Esse módulo permite monitorar cor-

rentes alternadas de -30A até +30A e tem em sua saída um sinal analógico que varia de

43

FIG. 4.3: Módulo Relé

FIG. 4.4: Conversor de nível lógico

0,52v a 4,48v, na qual cada 1A corresponde a 66mV. Assim, o -30A é representado pelo

0,52V e o +30A pelo 4,48V.

• Modelo: CI ACS712 Allegro 30A

44

• Tensão de operação: 5V

• Faixa de medição: -30A a +30A

• Saída analógica proprocional de 66mV/A

• Tempo de resposta: 0.005ms

FIG. 4.5: Sensor de Corrente

Entretanto, foi visto que a entrada analógica do NodeMCU suporta valores entre 0 e

1,1V. Não obstante, o próprio NodeMCU tem um atenuador de 3,3V para 1,1V, ou seja,

nossa preocupação é somente baixar os 4,48v do sensor até 3,3v. Isso pode ser feito com o

divisor de tensão. O modelo do regulador de tensão pode ser visto na Figura 4.5 abaixo,

onde Vin é a saída do sensor, Vout a entrada da porta analógica do NodeMCU e R1 =

1.2K , R2 = 3.3K .

4.1.5 FONTE DE ALIMENTAÇÃO DC

O último integrante é a fonte de alimentação dos componentes que possa entregar 5V DC.

Qualquer circuito retificador que tem como entrada a alimentação da rede elétrica 127V

AC e saída 5V DC, com limite de corrente controlada a operação dos microeletrônicos,

45

FIG. 4.6: Divisor de tensão

pode fazer esse papel. Por praticidade, um carregador de celular junto a um cabo USB

Serial TTL irão fazer a alimentação do NodeMCU, do Relé e do Sensor de Corrente

com 5V. Por já possuir o modelo de carregador, foi utilizado o carregador da Apple com

saída de 5V e corrente de 1A. Algumas literaturas apontam para a máxima corrente de

alimentação como sendo 2A. Dado que a operação do ESP-12 consome 200mA, ainda

sobram 800mA de corrente disponível. Os modelos e as respectivas especificações podem

ser vistas abaixo:

• Modelo: Apple A1402

• Bivolt: 100 - 240V

• Frequência 50-60Hz

• Tensão de saída: 5V

• Corrente de saída: 1A

46

FIG. 4.7: Fonte de Alimentação DC

4.1.6 MONTAGEM

Por se tratar de um protótipo, a montagem foi feita de modo a ficar bastante intuitiva esimples. Foi utilizado como fonte de alimentação DC uma placa Arduino UNO gerando5V, para alimentar o Relé, o nível lógico alto do Conversor e o Sensor, e 3,3V paraalimentar o NodeMCU e o nível lógico baixo do Conversor. A alimentação de 3,3V tambémpoderia ser obtida usando o carregador de celular em conjunto com um divisor de tensão.O ground do Arduino UNO serviu como ground comum a todos os microeletrônicos.O sinal de ativação do NodeMCU sai do pino D7 e entra no LV2 do Conversor para sertransformado em 5V na saída HV2 que segue normalmente pro Relé. O sensor de Correntetem seu sinal diminuído no divisor de tensão (citado no item 4.1.4) para então entrar com3,3V na porta A0 do NodeMCU. O Led está conectado no ground e no D7 do NodeMCU.As demais conexões são alimentações necessárias ao funcionamento individual de cadacomponente.

47

FIG. 4.8: Circuito da Tomada Inteligente: Alimentação

48

FIG. 4.9: Circuito da Tomada Inteligente

49

FIG. 4.10: Esquemático das ligações dos componentes

4.2 ARDUINO IDE

4.2.1 INSTALAÇÃO E CONFIGURAÇÃO

Para escrever os códigos e enviá-los à nossa placa NodeMCU, o Arduino IDE se mostrou

uma excelente ferramenta. Simples, intuitivo e com grande potencial de implementa-

ção. Para baixar o programa, vá primeiro ao site https://www.arduino.cc/en/Main/

Software e escolha a opção de Download de acordo com o seu sistema operacional, con-

forme a Figura 5.1:

50

FIG. 4.11: Download do Arduino IDE

Após instalar o arquivo, abra-o para iniciar um projeto. A primeira medida que deve

ser tomada é incluir o NodeMCU no Gerenciador de Placas. Para tal, vá em Arduino (ou

Arquivo, no Windows) e depois Preferences, como na Figura 5.2.

51

FIG. 4.12: Arduino Preferências

Em seguida, copie o seguinte link http://arduino.esp8266.com/stable/package_

esp8266com_index.json e cole em Additional Boards Manager URLs, conforme a Figura

5.3.

52

FIG. 4.13: Gerenciamento de Placas

Agora, vá em Tools -> Board -> Boards Manager, segundo a Figura 5.4.

FIG. 4.14: Arduino Placas

Procure por "Esp8266"e instale o pacote de placas da família ESP8266, conforme

ilustrado na Figura 5.5:

53

FIG. 4.15: Instalação da Placa

Para selecionar a placa NodeMCU, vá em Tools -> Board -> NodeMCU 1.0 (ESP-

12E Module). Para instalar uma nova biblioteca, o processo é semelhante, basta ir em

Sketch -> Include Library -> Manage Libraries. Agora já é possível programar no módulo

Wi-Fi.

4.2.2 CÓDIGO: NODEMCU

O código é uma parte vital do projeto. Ele irá definir como os componentes se comportam

de acordo com as variações das necessidades do usuário. A primeira preocupação deve ser

como conectar o NodeMCU à Internet e a segunda, a conexão com o Broker. Dentre as

possibilidades para este projeto, foram investigadas duas formas de se conectar via Wi-

Fi à rede. A primeira com credencias pré-configuradas e, a segunda, pós-configuradas.

Abaixo, serão discutidas as duas possibilidades.

4.2.2.1 WI-FI PRÉ-CONFIGURADO

Nessa opção, a tomada inteligente já viria com as credencias de usuário e senha de Wi-Fi

programadas em seu microcontrolador. Funcionaria da seguinte maneira:

a) Todas as tomadas a serem instaladas na casa do usuário teriam as mesmas credencias

de usuário e senha de Wi-Fi, definidas em fábrica;

54

b) A rede wireless local, onde estão sendo instaladas as tomadas, deve mudar seu ID e

senha para os mesmos que foram programados na tomada; e

c) Ao se ligar a rede elétrica e energizar a tomada, todos os dispositivos se conectariam

automaticamente à rede.

Para a concepção do código, antes deve-se acrescentar a biblioteca ESP8266WiFi ao

Arduino IDE, como foi visto anteriormente. Após isso, insira as credencias de rede, junto

da biblioteca previamente adicionada.

#include <ESP8266WiFi.h>

char* ssid = "SSID"; //Sua rede Wi-Fi

char* password = "password"; //Senha da sua rede Wi-fi

Dentro da função de setup, seguirão as seguintes linhas de código:

void setup() {

[...]

WiFi.begin(ssid, password);

while (WiFi.status() != WL_CONNECTED) {

delay(500);

Serial.println("Tentando se conectar ao Wi-Fi...");

}

Serial.println("Conectado à rede WiFi com sucesso!");

}

Na parte abaixo, o módulo WiFi começa a tentar se conectar aos dados de ssid e

password fornecidos.

WiFi.begin(ssid, password);

Enquanto não conseguir estabelecer a conexão, ele fica preso no while exibindo a

mensagem "Tentando se conectar ao Wi-Fi...".

55

while (WiFi.status() != WL_CONNECTED) {

delay(500);

Serial.println("Tentando se conectar ao Wi-Fi...");

}

Caso a conexão seja estabelecida com sucesso, ele exibe a seguinte mensagem:

Serial.println("Conectado à rede WiFi com sucesso!");

Uma prática importante no projeto é minimizar os possíveis erros a serem causa-

dos por fatores rotineiros, tais quais queda do sinal do Wi-Fi e/ou queda de energia.

Portanto, é indispensável garantir que o programa terá condições suficientes de se reesta-

belecer. Quando uma queda de energia ocorre, o NodeMCU desliga também. Ao retornar

o fornecimento, ele irá executar as linhas de código de forma sequencial, ou seja, ele re-

executará os comandos de conexão com a rede Wi-Fi citados na função void setup(). No

caso de uma queda do sinal, o NodeMCU não irá perder seu fornecimento de alimentação,

desse modo alguma lógica no código deve permitir isso. O subterfúgio encontrado como

solução, foi implementar a lógica dentro do loop. O loop é uma função que ficará sendo

chamada recorrentemente, diferentemente do setup que é executada uma única vez ao se

ligar o componente. Abaixo, seguem as linhas de código dessa implementação:

void loop() {

[...]

while (WiFi.status() != WL_CONNECTED) {

delay(500);

Serial.println("Tentando reestabelecer a conexão com o Wi-Fi...");

}

Serial.println("Conexão reestabelecida com sucesso!");

[...]

}

A adoção desse método de conexão tem, como ponto positivo a auto-conexão de

todas as tomadas à rede Wi-Fi, quando a alimentação é ligada. Isso evita que tenha

que se configurar dispositivo por dispositivo a fim de homogeneizar a rede de conexão.

Entretanto, perde-se em segurança, dado que o protocolo de conexão a se seguir pede que

56

o usuário e senha sejam pré-definidos. Situações, como por exemplo, um vizinho com o

mesmo sistema de tomadas inteligentes, permitiria que o mesmo pudesse se conectar, de

forma proposital ou não, ao complexo de tomadas do usuário e tomar ações nelas.

4.2.3 WI-FI PÓS-CONFIGURADO

A segunda proposta de conexão propõe que as credenciais sejam inseridas após o a ad-

quirição da tomada inteligente, de maneira simples de modo que o usuário não tenha

dificuldade em configurá-la. Os passos a serem tomados estão listados abaixo:

a) Após a tomada ser instalada e energizada, uma rede local com o nome dela será

fornecida para conexão;

b) O usuário, via celular, ou computador, acessa a rede e recebe uma página Web onde

ele pode orientar aquela tomada a se conectar na rede que desejar;

c) Uma vez conectada, a página Web é fechada e as credenciais são salvas na memória

do NodeMCU; e

d) Caso deseje trocar de rede, basta resetar as credenciais, numa função que será

fornecida no código.

Novamente, deve-se adicionar uma biblioteca, chamada WiFiManager. Feito isso, crie

um objeto globalmente e, dentro do setup, adicione a função que irá gerar a rede local do

NodeMCU.

#include <WiFiManager.h>

WiFiManager wifiManager;

void setup() {

[...]

wifiManager.autoConnect("PFC do Felipe");

Serial.println("Conectou!");

[...]

}

57

FIG. 4.16: Rede WiFi do NodeMCU disponível para conexão

Ao acessar a rede do NodeMCU, o usuário será redirecionado para uma página Web

que irá permitir que seja configurada, naquela tomada inteligente, o Wi-Fi que desejar,

abrindo assim flexibilidade de escolha ao cliente. Nesta tela, basta clicar no botão de

"Configure WiFI "para prosseguir para a próxima tela, onde será exibida uma lista das

redes que podem ser conectadas, além da força do sinal e um indicativo, representado por

um cadeado, acerca da segurança dela, caso seja aberta ou protegida. A Figura 5.7 ilustra

a situação descrita acima.

58

FIG. 4.17: Modo de configuração da rede WiFi

Uma vez que conexão é estabelecida, as credenciais de usuário e de senha são salvas

na memória interna e a página é fechada. É importante deixar para o usuário uma opção

de redefinir a rede que ele deseja usar. Para isto, vamos explorar a função callback. A

função callback será explicada melhor mais a frente, quando for abordado sobre a lógica

para a conexão com o Broker, mas é possível adiantar que ela será uma função acionada

toda vez que chegar uma mensagem num tópico ao qual a tomada está inscrita. Dentro

da função callback, teremos:

void callback(char* topic, byte* payload, unsigned int length) {

[...]

//////////////********RESETAR WIFI*********///////////////

59

if (tpc == "resetar")

{

wifiManager.resetSettings();

flagReset = "true";

}

[...]

}

Ao receber uma mensagem no tópico "resetar", ao qual a tomada deve estar inscrita, a

função if é acionada e duas ações ocorrem. Na primeira, é resetada a atual conexão WiFi,

desconectando-se da rede, Na segunda, uma flag pré-definida é atribuída como true para

acionar um processo de reenvio da página de configuração. Esse processo estará na função

loop, junto ao método de reconexão, em caso de perda de sinal.

void loop() {

[...]

mantemConexoes();

}

[...]

void mantemConexoes() {

[...]

while (WiFi.status() != WL_CONNECTED) {

delay(500);

Serial.println("Tentando se conectar ao Wi-Fi...");

if (flagReset == "true")

{

wifiManager.autoConnect("PFC do Felipe");

flagReset = "false";

60

}

}

}

Aqui, é possível ver a atuação da flag setada anteriormente. Quando o módulo é

resetado, ele automaticamente perde conexão com a rede, o que ativa o while acima.

Dentro desse while, a flagReset é o marcador que diz pra ele que essa perda de conexão

foi proposital, a fim de redefinir nossa rede WiFi. Neste ponto, o método de configuração

de rede visto anteriormente é repetido e a flag é setada como false, para que o processo

não fique preso.

O grande diferencial positivo dessa forma de conexão WiFi são a flexibilidade e a

segurança que ela oferece ao usuário. Além de permitir que ele escolha a rede, também

é disponibilizada a opção de mudar de rede, quando bem entender. Esse sistema é mais

seguro, uma vez que tanto o usuário, quanto a senha, não precisam ser ajustadas em

fábrica, evitando a redundância de rede com um vizinho, por exemplo. De negativo, tem-

se a inevitabilidade de configuração individual das tomadas pelo usuário, que aumenta um

pouco a complexidade de uso para o cliente. Entretanto, esse fator tem um peso muito

pequeno para que se justifique a escolha pelo primeiro método, o pré-configurado, em

detrimento do segundo, o pós pós-configurado. Os fatores positivos do segundo método

pesaram à favor para que este fosse o escolhido para o projeto.

4.2.3.1 CONEXÃO COM O BROKER

A tomada inteligente irá se conectar ao Broker sem que haja necessidade do usuário

configurá-la. O simples ato de energizá-la já é suficiente para que, uma vez que o WiFi

já esteja conectado, ela busque a conexão com o servidor. A inscrição e publicação já

vem definidas de fábrica, posto que são virtualização dos dados que transitam para que as

ações sejam realizadas, ações que são as diretrizes do projeto. Para se conectar ao Broker,

inicialmente, deve-se adicionar a biblioteca PubSubClient. Após a inserção da biblioteca,

deve-se adicionar os dados do servidor que estamos usando e criar um objeto espClient

onde, após isto, será instanciado o cliente MQTT, passando o objeto a ele.

#include <PubSubClient.h>

[...]

61

const char* mqttServer = "m12.cloudmqtt.com";

const int mqttPort = 12820;

const char* mqttUser = "woietmcm";

const char* mqttPassword = "_V5T4H0_OxBz";

WiFiClient espClient;

PubSubClient client(espClient);

}

O passo agora é conectar o NodeMCU ao servidor e inscrevê-lo nos tópicos a serem

utilizados. As linhas de código a seguir exibem como será realizada essa etapa:

void setup() {

[...]

initWiFi();

initMQTT();

}

[...]

void initMQTT()

{

client.setServer(mqttServer, mqttPort);

client.setCallback(callback);

while (!client.connected()) {

Serial.println("Conectando ao MQTT...");

if (client.connect("ESP8266Client", mqttUser, mqttPassword )) {

Serial.println("Conectado ao servidor com sucesso!");

62

} else {

Serial.print("Falha com código de erro: ");

Serial.print(client.state());

delay(2000);

}

}

client.subscribe("acender");

client.subscribe("temporizar");

client.subscribe("agendar");

client.subscribe("resetar");

client.subscribe("PedirConsumo");

client.subscribe("PedirNome");

client.subscribe("renomear");

}

A lógica da conexão é bastante similar ao que foi visto no modelo de WiFi pré-

configurado. Porém, vale ressaltar um elemento novo, a função callback que foi atribuída

no início da função setup. A função callback é uma função de chamada que é invocada

toda vez que uma mensagem chega num dos tópicos ao qual o dispositivo está inscrito.

Em razão disso, é de suma importância já realizar a inscrição dos tópicos na função setup,

a fim de não perder nenhum tipo de informação. Caso o servidor caia e a conexão com

o Broker seja perdida, se faz indispensável realimentar o NodeMCU com as informações

acerca do servidor. A função loop terá uma lógica para assegurar que uma eventual perda

de conexão com o Broker não seja um empecilho ao funcionamento da tomada.

void loop() {

delay(10); //Evita instabilidade do wi-fi

client.loop(); //keep-alive das conexões MQTT

mantemConexoes();

}

[...]

63

void mantemConexoes() {

if (!client.connected()) {

Serial.println("Conectando ao servidor MQTT...");

if (client.connect("ESP8266Client", mqttUser, mqttPassword )) {

Serial.println("Conectado!");

client.subscribe("acender");

client.subscribe("temporizar");

client.subscribe("agendar");

client.subscribe("resetar");

client.subscribe("PedirConsumo");

client.subscribe("PedirNome");

client.subscribe("renomear");

}

else {

Serial.print("Falha com código de erro: ");

Serial.print(client.state());

delay(2000);

}

}

Conforme visto acima, o código retoma o que havia sido fixado anteriormente. Como

a função loop fica rodando a todo momento, uma falha que possa ocorrer não precisará

de um gatilho, como por exemplo um botão na tomada, para que a operação normal seja

reintegrada. Abaixo, será visto como a função callback gerencia e envia mensagens:

void callback(char* topic, byte* payload, unsigned int length) {

Serial.print("Uma mensagem chegou no tópico: ");

64

Serial.println(topic);

String msg, tpc, nome;

for (int i = 0; i < length; i++) {

char c = (char)payload[i];

msg += c;

}

char* convertedMessage;

msg.toCharArray(convertedMessage, length);

tpc = topic;

//////////////********LIGA E DESLIGA*********///////////////

if (tpc == "acender" && msg == "off")

{

digitalWrite(13, LOW);

client.publish("Acoes", "A tomada está desligada!");

}

[...]

}

A primeira etapa, dentro da callback é informar que uma mensagem chegou no referido

tópico. Essa parte foi implementada com o objetivo de monitorar as ações, durante a

criação do código, via monitor serial do Arduino IDE, que neste caso, foi o monitor do

computador. Posteriormente, há um loop for com intuito de transformar a mensagem

recebida em uma String. Note que os parâmetros da função callback englobam a mensa-

gem (payload) e seu tamanho. É importante que essa conversão seja feita, uma vez que

o comparativo do if não funciona com char. O restante das ações foram baseadas nessa

lógica. Com isso, a parte do projeto referente ao código do NodeMCU está finalizada. O

algoritmo completo pode ser visto no Apêndice.

65

4.2.4 TROUBLESHOOTING

Muitos problemas surgiram durante a concepção dessa parte do projeto. Alguns o atra-

saram além do esperado e causaram certo desconforto. Algumas vezes, a solução veio de

pesquisas nos fóruns do GitHub, noutras, foi por tentativa e erro. Abaixo, serão listadas

as principais dificuldades, a fim de orientar futuros desenvolvedores.

a) A função publish não publica Strings. Para isso, é necessário que ou se converta a

String para char ou utilize uma biblioteca que já faça isso. Nesse caso, a biblioteca

PubSubClient resolveu esse problema.

b) Caso o Arduino IDE não esteja reconhecendo as funções de alguma biblioteca, tente

atualizar a placa que está utilizando.

c) Caso tenha pego alguma linha de código de algum fórum e as funções dele não

estejam funcionando, verifique se a versão da biblioteca referente está atualizada.

d) Lembre-se que o if não realiza comparações com chars, somente com Strings.

e) A pinagem do NodeMCU não confere com o que é utilizado na plataforma do Ar-

duino. Utilize o mapeamento de pinos do Apêndice.

4.3 ANDROID STUDIO

Na parte final do projeto, será discutido como foi feito o aplicativo de interação entre o

objeto inteligente e o usuário. Para este fim, foi operado o Android Studio IDE, que é

uma plataforma para o desenvolvimento de aplicativos para Android. A escolha por esse

recurso se deve à dificuldade de desenvolvimento de aplicativos para iOS e também por

ser uma interface mais amígável e organizada ao desenvolvimento.

4.3.1 INSTALAÇÃO E CONFIGURAÇÃO

O primeiro passo é ir ao site do desenvolvedor https://developer.android.com/

studio/?hl=pt-br e baixar o arquivo, conforme seu sistema operacional.

66

FIG. 4.18: Download do Android Studio IDE

Após isso, instale o arquivo. Um manual de instalação é fornecido pelo desenvolvedor

em https://developer.android.com/studio/install?hl=pt-br. Terminada a insta-

lação, abra o Android Studio e de um nome ao projeto que deseja iniciar. Para testar

os aplicativos, tenha um celular Android e um cabo USB. Caso não tenha um celular

Android disponível, é possível simular um na plataforma. Para tal, basta ir em Run ->

Run ’app’. Isso fara com que a seguinte tela seja aberta:

67

FIG. 4.19: Configurando um celular virtual

Agora, vá em Create New Virtual Device e prossiga com a escolha do celular. Instale

os pacotes necessários e aguarde o fim da instalação. Terminado o processo, já será

possível escolher o referido celular virtual para emular o app.

4.3.2 CÓDIGO: APP

O Android Studio utiliza a linguagem Java na definição das estruturas de dados e dos

algoritmos e a linguagem XML para interfaces e configurações. A adoção de quaisquer

elementos na tela de desenvolvimento gera um arquivo em XML. Para entender melhor

como isso funciona, comece adicionando um botão genérico. Para isto, vá no arquivo XML

e clique em Design, no canto inferior. Uma tela como na Figura 5.10 deve aparecer com à

sua esquerda uma paleta de opções de botões, caixas de texto, entre outros. Arraste um

botão até a tela do celular para obter o seguinte resultado:

68

FIG. 4.20: Começando com o design do app

A inserção desse botão resulta no seguinte código XML:

<?xml version="1.0" encoding="utf-8"?>

<android.support.constraint.ConstraintLayout

xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:app="http://schemas.android.com/apk/res-auto"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

tools:context=".MainActivity">

<Button

android:id="@+id/button"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="Clique Aqui"

69

tools:layout_editor_absoluteX="135dp"

tools:layout_editor_absoluteY="195dp"

tools:ignore="MissingConstraints" />

</android.support.constraint.ConstraintLayout>

Para mudar o nome do botão, basta alterar em android:text=. É possível associar

esse botão a uma ação MQTT de publicação, por exemplo. Para isto, antes, é neces-

sário associar esse botão a uma função. Isso será feito através do seu id, fornecido em

android:id="@+id/button". Vale ressaltar, que esse id pode ser alterado de acordo com

a preferência do desenvolvedor. Para explorar mais a associação do botão a uma função,

abra o arquivo MainActivity.java dando um clique duplo nele. Ele pode ser encontrado

na barra lateral, conforme a Figura 5.11:

FIG. 4.21: Localizando o MainActivity.java

A lógica é que uma Activity (atividade) está associada a um arquivo XML, definidor

de sua interface. O arquivo MainActivity deve ter o seguinte formato inicial:

[...]

public class MainActivity extends AppCompatActivity {

70

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

}

}

Para associar um botão ao clique e exibir uma mensagem, primeiramente crie uma

função (aqui chamada de clique) no arquivo MainActivity:

package com.example.felipe.myapplication;

import android.support.v7.app.AppCompatActivity;

import android.os.Bundle;

import android.view.View;

import android.widget.Toast;

public class MainActivity extends AppCompatActivity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

}

public void clique (View g){

Toast.makeText(MainActivity.this, "Botão apertado!", Toast.LENGTH_SHORT).show();

}

}

Agora, dentro do arquivo XML, adicione a seguinte linha de código para associar o

botão à função:

android:onClick="clique"

71

Seu arquivo deve ficar assim:

<?xml version="1.0" encoding="utf-8"?>

<android.support.constraint.ConstraintLayout

xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:app="http://schemas.android.com/apk/res-auto"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

tools:context=".MainActivity">

<Button

android:id="@+id/button"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:onClick="clique"

android:text="Clique Aqui"

tools:ignore="MissingConstraints"

tools:layout_editor_absoluteX="138dp"

tools:layout_editor_absoluteY="267dp" />

</android.support.constraint.ConstraintLayout>

Clicando em Run ’app’ e selecionando o celular previamente baixado, você terá uma

interface com o botão. Ao clicar nele, o seguinte resultade será exibido:

72

FIG. 4.22: Mensagem exibida ao clicar no botão

Para que esse botão possa interagir no âmbito do MQTT, é neces-

sário, antes, seguir um tutorial fornecido em https://www.hivemq.com/blog/

mqtt-client-library-enyclopedia-paho-android-service. Com esse tutorial é pos-

sível adicionar funcionalidades de publisher e subscriber ao app, tornando-o assim um

cliente MQTT. Cada botão e caixa de texto foi associado a um tópico o que possibili-

tou a interação com o NodeMCU. O algoritmo completo pode ser visto no Apêndice. O

resultado final do app tem a seguinte interface com as seguintes funcionalidades:

73

FIG. 4.23: Modelo final do App

• Três botões temporizadores para tempos de 1, 5 ou 10 minutos;

• Um botão "DISPOSITIVOS", que retorna o aparelho que está conectado;

• Um botão switch para ligar e desligar a tomada;

• Um botão "CONSUMO", que retorna o consumo do referido aparelho;

• Um botão "RESETARWIFI", que permite ao usuário redefinir a rede a ser utilizada

na tomada inteligente;

• Um botão "CONECTAR À NUVEM", para que, em caso de perda de conexão com

o servidor, possa ser reestabelecido a operação normal.

74

4.3.3 TROUBLESHOOTING

Como foi feito no algoritmo do Arduino, seguirá abaixo algumas dicas em relação ao

código desenvolvido no Android Studio.

a) O nome do tópico no algoritmo do Android Studio e do Arduino devem ter exata-

mente o mesmo nome.

b) Evite a função Log.d();. Utilize a Toast.makeText().show(); ao invés dela.

c) Não esqueça de adicionar as dependências necessárias todas vez que adicionar uma

funcionalidade extra, como uma vibração ao receber uma notificação.

d) Caso não esteja conseguindo usar um método, tente definir o objeto logo abaixo das

definições das credenciais, de forma mais global.

4.4 TESTES E RESULTADOS

No primeiro teste, foi testado o botão "CONECTAR À NUVEM". Após clicar no botão,

uma mensagem é exibida e o celular se conecta à Nuvem, no mesmo servidor que a tomada

se conecta. Na Figura 4.20 é possível ver que após o clique, tanto a tomada, quanto o

celular estão conectados ao CloudMQTT.

75

FIG. 4.24: Conectando à Nuvem

O segundo teste realizado foi o de ligar e desligar o relé. Um led vermelho indica

quando a tomada está em operação ou não. O led aceso denota que o relé fechou o

circuito ao passo que o led apagado simboliza que o circuito foi aberto pelo relé. O

primeiro passo foi mover o switch para a posição "ON":

76

FIG. 4.25: Ligando a tomada

O resultado desta ação foi o acionamento do relé:

FIG. 4.26: Tomada acionada

Deslizando o cursor do aplicativo para a posição "OFF":

77

FIG. 4.27: Desligando a tomada

Tem-se o desacionamento do relé:

FIG. 4.28: Começando com o design do app

O resultado do fluxo de mensagens pode ser acompanhado na imagem abaixo:

78

FIG. 4.29: Fluxo de mensagens durante ON/OFF

No terceiro teste, foi realizado o teste de temporização. Clicou-se no botão de 1 min

e foi observado que o relé ficou acionado exatamente 1 minuto. Os testes com 5 e 10

minutos foram semelhantes. O clique no botão de 1 minuto gerou a seguinte mensagem

no aplicativo:

FIG. 4.30: Temporizador de 1 minuto

79

Passado 1 minuto, o relé desativa normalmente. As mensagens trocadas durante esseprocesso podem ser vistas abaixo:

FIG. 4.31: Fluxo de mensagens durante a temporização

No quarto teste, um ferro de passar foi utilizado para verificar a potência consumida

por ele. Foi ligado o ferro na tomada inteligente, colocado na função ’Algodão’ e, após

acionar no aplicativo o modo "ON", foi clicado no "CONSUMO". O resultado disto foi

uma potência de 823,53W.

80

FIG. 4.32: Consumo do ferro de passar

O quinto teste foi a verificação do nome do dispositivo conectado. A tomada vem

com um nome de série para que seja possível diferenciá-las. É possível redefinir, via

CloudMQTT o nome da tomada através do tópico "renomear". Apertando o botão "DIS-

POSITIVOS", uma mensagem exibe o nome do dispositivo conectado. Caso não haja

mudança no nome, será exibido o id da tomada, caso contrário, será o nome que foi dado

a ela.

81

FIG. 4.33: Nome da tomada

O último teste avaliou se o aplicativo conseguia resetar o WiFi ao qual a tomada

estava conectada. Primeiramente, clicou-se no botão "RESETAR WIFI":

82

FIG. 4.34: Resetar WiFi

A tomada recebeu a informação para resetar e automaticamente desconectou da rede

ao qual estava conectada:

83

FIG. 4.35: Resetando o WiFi

Gerando uma rede em que o cliente poderia se conectar para poder editar novamente

os parâmetros de conexão:

84

FIG. 4.36: Reconfigurando a rede WiFi

Após inserir as novas credencias, a tomada se conecta novamente à rede WiFi e,

posteriormente, ao servidor Broker:

85

FIG. 4.37: Conectando o WiFi

86

5 CONCLUSÃO

Dentro do que foi proposto de elaboração, foi alcançado um sistema de casa inte-

ligente bastante satisfatório. Todas as decisões tomadas tem forte embasamento tanto

teórico quanto a nível de especificação e praticidade. Essas escolhas para o projeto, de-

viam, e foram, minuciosamente analisadas. MQTT, Mosquitto, CloudMQTT, NodeMCU,

Arduino IDE, Android Studio, entre outras definições, trabalharam em perfeito conjunto

para que o resultado final fosse obtido.

O primeiro passo dessa construção foi encontrar algo que, dentro da Internet das

Coisas, que motivasse a construção da concepção do projeto. A partir daí, começou a

se investigar conceitos. O que realmente seria Internet das Coisas? Como se define um

objeto inteligente? Que arquiteturas e protocolos posso adotar?

O questionamento desses termos direcionou o trabalho à tomada das primeiras de-

cisões: os Componentes. Elementos fundamentais neste projeto, eles foram os grandes

orquestradores virtuais. O MQTT foi uma solução leve e simples em frente ao pesado e

complexo protocolo HTTP, além de resolver o problema de múltiplas conexões simultâ-

neas, através do desacoplamento. O Broker, responsável pela troca de mensagens, possi-

bilitou aos clientes que ,para que eles pudessem se conectar, bastasse apenas terem conhe-

cimento da localização do servidor. O CloudMQTT foi uma espécie de facilitador, visto

que localizava-se na Nuvem, rodando os servidores Mosquitto, recebendo informações de

quaisquer dispositivos conectados a quaisquer redes de comunicação WIFi, independente

se eram locais ou não.

A materialização do projeto frente ao campo virtual até então desenvolvido, teve seus

primeiros traços definidos ao se escolher o NodeMCU como o grande cérebro de conexão

entre o virtual e o material. A partir dele, as mensagens chegavam, via sensores ou MQTT,

e eram repassadas aos atuadores como forma de ações ou ao usuário, por meio de uma

interface.

O próximo passo foi definir o código e a interface com o usuário. As IDE do Arduino

e do Android Studio se mostraram bastante eficientes para este propósito. Com elas, foi

possível desenvonver um lógica limpa para o código de execução no NodeMCU e um app

intuitivo para o usuário poder usufruir da tomada inteligente.

Os objetivos deste projeto foram bem desenvolvidos dentro do que se esperava. En-

tretanto, algumas implementações ficaram faltando, tais quais:

87

• Um feedback de operação da tomada, para que o usuário possa saber se a ação que

ele solicitou foi executada ;

• Uma função que possibilite agendar um ligamento ou desligamento da tomada de

acordo com um horário a qual se deseje;

• Ajuste dos campos de Consumo e Dispositivos que, ao serem acionados, ambos

exibem a mesma informação, independentemente se foram acionaos ou não; e

• Implementar a função do consumo de modo que possa exibir a energia gasta por

aquele equipamento num determinado período.

Fica como ideia para futuros projetos a implementação de um nível mais dinâmico.

O ideial seria que ao conectar qualquer eletrodoméstico, a tomada já reconhecesse do que

se trata e, dentro do aplicativo, exibiria uma notificação com um ícone do dispositivo

conectado.O aplicativo teria uma planta da casa, onde o usuário arrastaria esse ícone, na

planta,para a referida tomada inteligente que o eletrodoméstico foi conectado, podendo

assim, instantaneamente, usufruir de todos seus benefícios. Outra sugestão seria a pro-

gramação deste aplicativo em Web, para que não exista o empecilho do modelo de celular

a ser usado, permitindo o seu uso em diferentes plataformas.

88

6 REFERÊNCIAS BIBLIOGRÁFICAS

ASHTON, K. That ’internet of things’ thing. RFID Journal, v. 1, 1999. Disponível

em: <https://www.rfidjournal.com/articles/view?4986>. Acesso em: 05 de setembro

de 2018.

B. B. TORRES, ANDREI, ROCHA, ATSLANDS R., NEUMAN DE SOUZA, JOSE.

Analise de Desempenho de Brokers MQTT em Sistema de Baixo Custo. Disponível

em: <http://www.lbd.dcc.ufmg.br/colecoes/wperformance/2016/009.pdf>. Acesso

em: 09 de setembro de 2018.

BUGINGA, G. C. Sistema de Objetos Inferências (SOI) - Framework para In-

ternet das Coisas. 2017. 32 f. Trabalho de Conclusão de Curso (Graduação em

Engeharia Eletrônica) – Instituto Militar de Engenharia, Rio de Janeiro, 2017.

DE OLIVEIRA, S. Internet das Coisas com ESP8266, Arduino e Raspberry Pi.

1. ed. São Paulo, SP, BRA: Novatec Editora Ltda, 2017. 240 p.

EVANS, DAVE. A Internet das Coisas: Como a pró-

xima evolução da Internet está mudando tudo. Disponível em:

<https://www.cisco.com/c/dam/global/pt_br/assets/executives/pdf/internet_of_

things_iot_ibsg_0411final.pdf>. Acesso em: 07 de setembro de 2018.

FINEP. Kevin Ashton – entrevista exclusiva com o criador do termo “Internet das Coi-

sas”. Disponível em: <http://finep.gov.br/noticias/todas-noticias/4446-kevin-ashton-

entrevista-exclusiva-com-o-criador-do-termo-internet-das-coisas>. Acesso em: 05 de

setembro de 2018.

LOUREIRO, A. A., N. J. M. S. R. L. B. M. R. A. D. F. N. E. F.; FIGUEIREDO. Redes

de sensores sem fio. Simpósio Brasileiro de Redes de Computadores (SBRC),

v. 1, p. 179–226, 2003.

MARTINS, ELAINE. O que é TCP/IP?. Disponível em:

<https://www.tecmundo.com.br/o-que-e/780-o-que-e-tcp-ip-.htm>. Acesso em:

08 de setembro de 2018.

89

MARTINS BEZERRA, ROMILDO. A Camada de Transporte. Disponível em:

<http://www2.ufba.br/r̃omildo/downloads/ifba/transporte.pdf>. Acesso em: 09 de

setembro de 2018.

RUIZ, L. B., CORREIA, L. H. A., VIEIRA, L. F. M., MACEDO,

D. F., NAKAMURA, E. F.,FIGUEIREDO, C. M., VIEIRA, M. A.

M., BECHELANE, E. H., CAMARA, D., LOUREIRO, A. A., ET

AL. Arquiteturas para Redes de Sensores Sem Fio. Disponível em:

<https://www.researchgate.net/publication/251797929_Arquiteturas_Para_Redes

_de_Sensores_Sem_Fio>. Acesso em: 05 de setembro de 2018.

SANTOS, BRUNO P., LUCAS A. M. SILVA, CLAYSON S. F. S. CELES,

JOÃO B. BORGES NETO, BRUNA S. PERES, MARCOS AUGUSTO M. VI-

EIRA, LUIZ FILIPE M. VIEIRA, OLGA N. GOUSSEVSKAIA E ANTONIO

A. F. LOUREIRO. Internet das Coisas: da Teoria à Prática. Disponível

em: <http://homepages.dcc.ufmg.br/m̃mvieira/cc/papers/internet-das-coisas.pdf>.

Acesso em: 04 de setembro de 2018.

SENAR. AGRICULTURA DIGITAL ABRE PERSPECTIVAS PARA PES-

QUISA. Disponível em: <http://www.senar.org.br/agricultura-precisao/tag/futuro-

da-agricultura-internet-das-coisas-iot/>. Acesso em: 04 de setembro de 2018.

WEISER, M. The computer for the 21st century. Scientific American Special Issue

on Communications, Computers, and Networks,, v. Setembro, p. 94–104, 1991.

YUAN, MICHAEL. Conhecendo o MQTT. Disponível em:

<https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-

iot/index.html>. Acesso em: 09 de setembro de 2018.

90

7 APÊNDICES

91

APÊNDICE 1: ALGORITMOS

7.1.1 CÓDIGO ARDUINO: EM C

//#include <MQTTClient.h>

#include <ESP8266WiFi.h>

#include <PubSubClient.h>

#include <WiFiManager.h>

#define ESP_ID Esp8266_001;

//defines - mapeamento de pinos do NodeMCU

#define D0 16

#define D1 5

#define D2 4

#define D3 0

#define D4 2

#define D5 14

#define D6 12

#define D7 13

#define D8 15

#define D9 3

#define D10 1

const char* mqttServer = "m12.cloudmqtt.com";

const int mqttPort = 12820;

const char* mqttUser = "woietmcm";

const char* mqttPassword = "_V5T4H0_OxBz";

String flagReset = "false";

String NomeDisp = "ESP8266_001";

92

char* Name = "ESP8266_001";

unsigned long lastMillis = 0;

int pinoSensor = A0;

int sensorValueAux = 0;

float valorSensor = 0;

float valorCorrente = 0;

float voltsporUnidade = 0.003226;// 3.3V%1023(resolução)

// Consultar o datasheet do ACS712

float sensibilidade = 0.066; //mv/A

//Tensao da rede AC 127V

int tensao = 127;

WiFiManager wifiManager;

WiFiClient espClient;

PubSubClient client(espClient);

/////////*******Prototype das funções*********/////////

void initOutput(void);

void initSerial();

void initWiFi();

void initMQTT();

void reconnectWiFi();

//void verificaConexoesWiFiMQTT(void);

void initPubSub();

void CalculaConsumo();

void setup() {

initOutput();

initSerial();

initWiFi();

initMQTT();

93

}

void initOutput(void)

{

pinMode(D7, OUTPUT);

pinMode(pinoSensor, INPUT);

}

void initSerial()

{

Serial.begin(115200);

}

void initWiFi()

{

wifiManager.autoConnect("ESP Wifi");

Serial.println("Conectou!");

}

void initMQTT()

{

client.setServer(mqttServer, mqttPort);

client.setCallback(callback);

while (!client.connected()) {

Serial.println("Conectando ao MQTT...");

if (client.connect("ESP8266Client", mqttUser, mqttPassword )) {

Serial.println("Conectado ao servidor com sucesso!");

} else {

94

Serial.print("Falha com código de erro: ");

Serial.print(client.state());

delay(2000);

}

}

client.subscribe("acender");

client.subscribe("temporizar");

client.subscribe("agendar");

client.subscribe("resetar");

client.subscribe("PedirConsumo");

client.subscribe("PedirNome");

client.subscribe("renomear");

}

void callback(char* topic, byte* payload, unsigned int length) {

Serial.print("Uma mensgaem chegou no tópico: ");

Serial.println(topic);

String msg, tpc, nome;

for (int i = 0; i < length; i++) {

char c = (char)payload[i];

msg += c;

}

char* convertedMessage;

msg.toCharArray(convertedMessage, length);

tpc = topic;

/// Feedback de conexãoo - Publica uma mensagem a cada segundo ///

95

if (millis() - lastMillis > 10000) {

lastMillis = millis();

client.publish("Conexoes", "A tomada do dispostivo a seguir está conectada: ");

client.publish("Conexoes", String(NomeDisp).c_str(), true);

}

//////////////********LIGA E DESLIGA*********///////////////

if (tpc == "acender" && msg == "off")

{

digitalWrite(13, LOW);

client.publish("Acoes", "A tomada está desligada!");

if (D7 == 0)

{

client.publish("Acoes", "A tomada está desligada!");

}

}

if (tpc == "acender" && msg == "on")

{

digitalWrite(13, HIGH);

client.publish("Acoes", "A tomada está ligada!");

if (D7 == 1)

{

client.publish("Acoes", "A tomada está ligada!");

}

}

//////////////********ENVIAR NOME*********///////////////

if (tpc == "PedirNome")

{

96

client.publish("Name", String(NomeDisp).c_str(), true);

Serial.println(NomeDisp);

}

//////////////********MUDAR NOME*********///////////////

if (tpc == "renomear")

{

NomeDisp = msg;

client.publish("Name", String(NomeDisp).c_str(), true);

Serial.println(NomeDisp);

}

//////////////********TEMPORIZAÇÃO*********///////////////

if (tpc == "temporizar")

{

unsigned long int tempo;

tempo = msg.toInt();

tempo = tempo*1000*60;

digitalWrite(13, HIGH);

delay(tempo);

digitalWrite(13, LOW);

}

//////////////********MEDIR CONSUMO*********///////////////

if (tpc == "PedirConsumo")

{

CalculaConsumo();

float potenciaCalculada = valorCorrente*tensao;

client.publish("consumo", String(potenciaCalculada).c_str(), true);

}

//////////////********RESETAR WIFI*********///////////////

97

if (tpc == "resetar")

{

wifiManager.resetSettings();

flagReset = "true";

}

}

void loop() {

delay(10); //Evita instabilidade do wi-fi

client.loop();

mantemConexoes();

}

void CalculaConsumo()

{

for(int i=10000; i>0; i--){

/* Leitura do sensor analogico A0 subtraindo o ajuste

* pela metade da resolução (1023)vcc/2 */

sensorValueAux = (analogRead(pinoSensor) -511.5);

// Soma dos quadrados das leituras

valorSensor += pow(sensorValueAux,2);

//Delay para evitar overflow

delay(1);

}

// Calculo da média dos quadrados e conversão para Volts

valorSensor = (sqrt(valorSensor/ 10000)) * voltsporUnidade;

// Calculo da corrente considerando a sensibilidade do sensor (185 mV por ampere) para o sensor de exemplo

valorCorrente = (valorSensor/sensibilidade);

/*Tratamento para possivel ruido

O ACS712 de 30 Amperes é projetado para fazer leituras

de valores altos acima de 0.25 Amperes até 30,

por isso é normal ocorrer ruidos de até 0.20A */

if(valorCorrente <= 0.098){

valorCorrente = 0;

98

}

valorSensor = 0;

//Mostra o valor da corrente

Serial.print("Corrente : ");

Serial.print(valorCorrente, 3);

Serial.print(" A ");

//Calculo da Potência

Serial.print(" Potencia (Consumo) : ");

Serial.print(valorCorrente*tensao);

Serial.println(" Watts ");

//Delay para evitar overflow

delay(100);

}

void mantemConexoes() {

if (!client.connected()) {

Serial.println("Conectando ao servidor MQTT...");

if (client.connect("ESP8266Client", mqttUser, mqttPassword )) {

Serial.println("Conectado!");

client.subscribe("acender");

client.subscribe("temporizar");

client.subscribe("agendar");

client.subscribe("resetar");

client.subscribe("PedirConsumo");

client.subscribe("PedirNome");

client.subscribe("renomear");

}

else {

99

Serial.print("Falha com código de erro: ");

Serial.print(client.state());

delay(2000);

}

}

while (WiFi.status() != WL_CONNECTED) {

delay(500);

Serial.println("Tentando se conectar ao Wi-Fi...");

if (flagReset == "true")

{

wifiManager.autoConnect("ESP8266_001 Wifi");

flagReset = "false";

}

}

}

7.1.2 CÓDIGO ANDROID STUDIO: EM JAVA

package com.example.felipe.appmqttpfc;

import android.os.Bundle;

import android.os.Vibrator;

import android.support.design.widget.FloatingActionButton;

import android.support.design.widget.Snackbar;

import android.util.Log;

import android.view.View;

import android.support.design.widget.NavigationView;

import android.support.v4.view.GravityCompat;

import android.support.v4.widget.DrawerLayout;

import android.support.v7.app.ActionBarDrawerToggle;

100

import android.support.v7.app.AppCompatActivity;

import android.support.v7.widget.Toolbar;

import android.view.Menu;

import android.view.MenuItem;

import android.widget.Button;

import android.widget.CompoundButton;

import android.widget.Switch;

import android.widget.TextView;

import android.widget.Toast;

import org.eclipse.paho.android.service.MqttAndroidClient;

import org.eclipse.paho.client.mqttv3.IMqttActionListener;

import org.eclipse.paho.client.mqttv3.IMqttDeliveryToken;

import org.eclipse.paho.client.mqttv3.IMqttToken;

import org.eclipse.paho.client.mqttv3.MqttCallback;

import org.eclipse.paho.client.mqttv3.MqttClient;

import org.eclipse.paho.client.mqttv3.MqttConnectOptions;

import org.eclipse.paho.client.mqttv3.MqttException;

import org.eclipse.paho.client.mqttv3.MqttMessage;

import org.eclipse.paho.client.mqttv3.MqttSecurityException;

import org.w3c.dom.Text;

public class ControleCasa extends AppCompatActivity {

// implements NavigationView.OnNavigationItemSelectedListener {

static String MQTTHOST = "tcp://m12.cloudmqtt.com:12820";

static String USERNAME = "woietmcm";

static String PASSWORD = "_V5T4H0_OxBz";

String topicPubStr1 = "resetar";

String topicPubStr2 = "PedirNome";

String topicPubStr3 = "PedirConsumo";

String topicPubStr4 = "acender";

String topicPubStr5 = "temporizar";

String topicSubStr1 = "consumo";

String topicSubStr2 = "Name";

101

MqttAndroidClient client;

TextView subConsumo;

TextView subName;

Vibrator vibrator;

MqttConnectOptions options;

//private Button pub1;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_controle_casa);

subConsumo = (TextView) findViewById(R.id.subConsumo);

subName = (TextView) findViewById(R.id.subName);

vibrator = (Vibrator) getSystemService(VIBRATOR_SERVICE);

// pub1 = (Button) findViewById(R.id.pub1);

//pub1.setOnClickListener(new View.OnClickListener() {

// @Override

// public void onClick(View v) {

String clientId = MqttClient.generateClientId();

client = new MqttAndroidClient(ControleCasa.this, MQTTHOST, clientId);

options = new MqttConnectOptions();

options.setUserName(USERNAME);

options.setPassword(PASSWORD.toCharArray());

try {

IMqttToken token = client.connect(options);

token.setActionCallback(new IMqttActionListener() {

102

@Override

public void onSuccess(IMqttToken asyncActionToken) {

Toast.makeText(ControleCasa.this, "Conectado!",

Toast.LENGTH_SHORT).show();

setSubscription();

setSubscriptionName();

}

@Override

public void onFailure(IMqttToken asyncActionToken,

Throwable exception) {

Toast.makeText(ControleCasa.this, "Não conectado!",

Toast.LENGTH_SHORT).show();

}

});

} catch (MqttException e) {

e.printStackTrace();

}

//}

//});

client.setCallback(new MqttCallback() {

@Override

public void connectionLost(Throwable cause) {

}

@Override

public void messageArrived(String topic, MqttMessage message)

throws Exception {

subConsumo.setText(new String(message.getPayload()));

subName.setText(new String(message.getPayload()));

vibrator.vibrate(390);

103

}

@Override

public void deliveryComplete(IMqttDeliveryToken token) {

}

});

Switch switch1 = (Switch)findViewById(R.id.switch1);

switch1.setOnCheckedChangeListener(new

CompoundButton.OnCheckedChangeListener() {

@Override

public void onCheckedChanged(CompoundButton buttonView, boolean

isChecked) {

String topic = topicPubStr4;

if (isChecked) {

String message = "on";

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "Tomada ligada.",

Toast.LENGTH_SHORT).show();

}

else {

String message = "off";

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "Tomada desligada",

Toast.LENGTH_SHORT).show();

104

}

}

});

}

public void reset (View g){

String topic = topicPubStr1;

String message = "true";

//byte[] encodedPayload = new byte[0];

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "Internet resetada",

Toast.LENGTH_SHORT).show();

}

public void name (View t){

String topic = topicPubStr2;

String message = "true";

//byte[] encodedPayload = new byte[0];

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "!", Toast.LENGTH_SHORT).show();

}

public void consumo (View y){

105

String topic = topicPubStr3;

String message = "true";

//byte[] encodedPayload = new byte[0];

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "!", Toast.LENGTH_SHORT).show();

}

public void ummin (View b){

String topic = topicPubStr5;

String message = "1";

//byte[] encodedPayload = new byte[0];

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "Temporização: 1 min",

Toast.LENGTH_SHORT).show();

}

public void cincomin (View l){

String topic = topicPubStr5;

String message = "5";

//byte[] encodedPayload = new byte[0];

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

106

}

Toast.makeText(ControleCasa.this, "Temporização: 5 min",

Toast.LENGTH_SHORT).show();

}

public void dezmin (View z){

String topic = topicPubStr5;

String message = "10";

//byte[] encodedPayload = new byte[0];

try {

client.publish(topic, message.getBytes(), 0, false);

} catch (MqttException e) {

e.printStackTrace();

}

Toast.makeText(ControleCasa.this, "Temporização: 10 min",

Toast.LENGTH_SHORT).show();

}

private void setSubscription () {

try {

client.subscribe(topicSubStr1, 0);

} catch (MqttException e) {

e.printStackTrace();

}

}

private void setSubscriptionName () {

try {

client.subscribe(topicSubStr2, 0);

} catch (MqttException f) {

f.printStackTrace();

}

107

}

public void connect (View c){

try {

IMqttToken token = client.connect(options);

token.setActionCallback(new IMqttActionListener() {

@Override

public void onSuccess(IMqttToken asyncActionToken) {

Toast.makeText(ControleCasa.this, "Conectado!",

Toast.LENGTH_SHORT).show();

setSubscription();

}

@Override

public void onFailure(IMqttToken asyncActionToken,

Throwable exception) {

Toast.makeText(ControleCasa.this, "Não conectado!",

Toast.LENGTH_SHORT).show();

setSubscriptionName();

setSubscription();

}

});

} catch (MqttException e) {

e.printStackTrace();

}

}

}

108

7.1.3 CÓDIGO ANDROID STUDIO: EM XML

<?xml version="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:app="http://schemas.android.com/apk/res-auto"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

app:layout_behavior="@string/appbar_scrolling_view_behavior"

tools:context=".ControleCasa"

tools:showIn="@layout/app_bar_controle_casa">

<Button

android:id="@+id/pub1"

android:layout_width="wrap_content"

android:layout_height="46dp"

android:layout_alignParentBottom="true"

android:layout_centerHorizontal="true"

android:layout_marginBottom="43dp"

android:background="#6cb396"

android:onClick="connect"

android:text="Conectar à Nuvem"

tools:layout_editor_absoluteX="148dp"

tools:layout_editor_absoluteY="391dp" />

<Button

android:id="@+id/reset1"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_alignParentBottom="true"

android:layout_centerHorizontal="true"

android:layout_marginBottom="125dp"

android:onClick="reset"

android:text="Resetar WiFi"

109

tools:ignore="NotSibling" />

<EditText

android:id="@+id/subName"

android:layout_width="166dp"

android:layout_height="wrap_content"

android:layout_alignParentEnd="true"

android:layout_alignParentTop="true"

android:layout_marginEnd="66dp"

android:layout_marginTop="99dp"

android:ems="10"

android:inputType="time"

android:layout_alignParentRight="true"

android:layout_marginRight="66dp" />

<TextView

android:id="@+id/textView5"

android:layout_width="98dp"

android:layout_height="29dp"

android:layout_alignParentStart="true"

android:layout_alignParentTop="true"

android:layout_marginStart="18dp"

android:layout_marginTop="25dp"

android:text="Temporizar: "

tools:ignore="RtlCompat" />

<EditText

android:id="@+id/subConsumo"

android:layout_width="138dp"

android:layout_height="wrap_content"

android:layout_alignEnd="@+id/subName"

android:layout_alignTop="@+id/button2"

android:ems="10"

android:inputType="number"

tools:ignore="RtlCompat" />

110

<Button

android:id="@+id/pubdisp"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_alignTop="@+id/subName"

android:layout_toStartOf="@+id/pub1"

android:text="Dispositivos"

android:onClick="name"

android:layout_toLeftOf="@+id/pub1" />

<Button

android:id="@+id/button2"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:layout_alignParentBottom="true"

android:layout_marginBottom="201dp"

android:layout_toStartOf="@+id/reset1"

android:text="Consumo"

android:onClick="consumo"

tools:ignore="RtlCompat" />

<Switch

android:id="@+id/switch1"

android:layout_width="138dp"

android:layout_height="66dp"

android:layout_alignParentTop="true"

android:layout_centerHorizontal="true"

android:layout_marginTop="173dp"

android:text="ON/OFF"

tools:ignore="RtlCompat" />

<Button

android:id="@+id/button5"

android:layout_width="74dp"

111

android:layout_height="35dp"

android:layout_alignBottom="@+id/textView5"

android:layout_alignStart="@+id/pub1"

android:text="1 min"

android:onClick="ummin"

tools:ignore="RtlCompat" />

<Button

android:id="@+id/button6"

android:layout_width="71dp"

android:layout_height="36dp"

android:layout_alignBottom="@+id/textView5"

android:layout_alignParentEnd="true"

android:layout_marginEnd="16dp"

android:text="10 min"

android:onClick="dezmin"

tools:ignore="OnClick,RtlCompat" />

<Button

android:id="@+id/button7"

android:layout_width="71dp"

android:layout_height="36dp"

android:layout_alignBottom="@+id/textView5"

android:layout_alignParentEnd="true"

android:layout_marginEnd="104dp"

android:text="5 min"

android:onClick="cincomin"

tools:ignore="RtlCompat" />

</RelativeLayout>

112