UNIVERSIDADE FEDERAL FLUMINENSE MARCELO MARQUES DA … · universidade federal fluminense marcelo...
Transcript of UNIVERSIDADE FEDERAL FLUMINENSE MARCELO MARQUES DA … · universidade federal fluminense marcelo...
UNIVERSIDADE FEDERAL FLUMINENSE
MARCELO MARQUES DA ROCHA
DESENVOLVIMENTO OPEN-SOURCE PARA
A INTERNET DAS COISAS
(ARQUITETURAS PARA INTERFACES WEB E MÓVEL)
Niterói
2018
MARCELO MARQUES DA ROCHA
DESENVOLVIMENTO OPEN-SOURCE PARA
A INTERNET DAS COISAS
(ARQUITETURAS PARA INTERFACES WEB E MÓVEL)
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólogo
em Sistemas de Computação.
Orientador:
Luciano Bertini
NITERÓI
2018
MARCELO MARQUES DA ROCHA
DESENVOLVIMENTO OPEN-SOURCE PARA
A INTERNET DAS COISAS
(ARQUITETURAS PARA INTERFACES WEB E MÓVEL)
Trabalho de Conclusão de Curso subme-
tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólogo
em Sistemas de Computação.
Niterói, ___ de _______________ de 2018.
Banca Examinadora:
_________________________________________
Prof. Luciano Bertini, D.Sc. – Orientador
UFF – Universidade Federal Fluminense
_________________________________________
Prof. Alessandro Copetti, D.Sc. – Avaliador
UFF – Universidade Federal Fluminense
Dedico este trabalho aos meus pais (Luís e
Vera) ao meu irmão Márcio (meu primeiro
professor) à minha esposa Rachel e à minha
filha Luiza.
AGRADECIMENTOS
Ao meu Deus, que permitiu que eu chegasse
até aqui. “Todas as coisas foram feitas por
Ele, e sem Ele nada do que foi feito se fez”.
(João 1:3).
A meu Orientador Luciano Bertini pelo estímu-
lo e direcionamento durante a pesquisa neste
trabalho.
À Marta Zanetti, coordenadora do pólo de An-
gra dos Reis, por toda ajuda desde o vestibu-
lar.
Aos Colegas de curso pelo incentivo e troca
de experiências.
A todos os meus familiares e amigos pelo
apoio e colaboração.
“O único aprendizado que influencia signifi-
cativamente o comportamento é a aprendi-
zagem autoapropriada e autodescoberta,
verdade que foi assimilada na experiência”.
Carl R. Rogers (1969)
RESUMO
A IoT (Internet das Coisas) é uma tendência tecnológica atual na qual tudo pode es-tar conectado na Internet, desde interruptores de luz, torradeiras, ou qualquer outroobjeto. Essa tecnologia pretende mudar a vida das pessoas, suas casas, cidades eaté a indústria. A Internet das coisas é vista como um componente fundamental paraa 4ª revolução industrial. Apesar das empresas privadas desenvolverem soluçõespara esta tecnologia, ela é dominada e impulsionada por tecnologias open-source.Como exemplo dessas tecnologias existem, na parte de hardware, o Arduino, oRaspberry Pi e o NodeMcu, que são placas de baixo custo que permitem a imple-mentação da computação embarcada com a comunicação necessária para a IoT. Naparte de software existem o protocolo MQTT, o servidor Mosquitto (MQTT broker), alinguagem Lua e o Node-RED. Este trabalho tem como objetivo apresentar essastecnologias. Pretende mostrar os protocolos usados no processo de comunicaçãoentre os dispositivos. Também vai falar sobre a linguagem utilizada na criação dosfirmwares e da ferramenta de criação da aplicação de controle de IoT web móvel.Mostrará algumas possibilidades de arquiteturas para Internet das coisas e por últi-mo será implementado um protótipo (hardware e software) de um sistema de umaCasa inteligente.
Palavras-chaves: Internet das Coisas, Casas inteligentes, MQTT, Mosquitto.
ABSTRACT
IoT (Internet of Things) is a current technological trend in which everything can beconnected in the Internet, from light switches, toasters, or any other object. This tech-nology aims to change the lives of people, their homes, cities, and even the industry.The Internet of things is seen as a fundamental component of the 4th industrial revo-lution. Although private companies develop solutions for this technology, it is domi-nated and driven by open-source technologies. As an example of such technologiesthere are, in the hardware part, Arduino, Raspberry Pi, and NodeMcu, which are lowcost boards that allow the implementation of embedded computing with the neces-sary communication for the IoT. In the software part, there are the MQTT protocol,the Mosquitto server (MQTT broker), the Lua language, and the Node-RED. Thiswork aims to present these technologies. It aims to show the protocols used in thecommunication process between the devices, and also will talk about the languageused in the creation of firmwares, and the creation tool for mobile web IoT control ap-plications. It will show some possibilities for Internet of Things architectures, and fi -nally, a hardware and software prototype of a Smart House will be implemented.
Key words: Internet of Things, Smart Houses, MQTT, Mosquitto.
LISTA DE CÓDIGOS-FONTE
Código 1: Controlando o led com o Raspberry Pi usando Python............................54
Código 2: Código do objeto msg................................................................................62
Código 3: Importação das bibliotecas para o ThingSpeak........................................70
Código 4: Configuração do canal ThingSpeak...........................................................70
Código 5: ThingSpeak - Inicialização.........................................................................71
Código 6: Loop principal para leitura do sensor e publicação no ThingSpeak..........72
Código 7: Definição dos pinos do DHT11..................................................................75
Código 8: Configuração do acesso à rede, host e campos do canal ThingSpeak....76
Código 9: Configuração da velocidade das portas seriais.........................................76
Código 10: Envio dos dados lidos do sensor DHT11 para o ThingSpeak.................77
Código 11: Função que faz a leitura do sensor DHT11.............................................78
Código 12: Função que envia os comandos AT para o Esp8266..............................78
Código 13: Importando a biblioteca WiFI para o Esp8266........................................84
Código 14: Configurando e conectando ao WiFi.......................................................86
Código 15: Função loop() - Leitura do sensor e envio dos dados para o T. Speak...87
Código 16: Excutando automaticamente com init.lua................................................89
Código 17: Módulo credenciais.lua............................................................................90
Código 18: Módulo tabela.lua.....................................................................................90
Código 19: Módulo conecta_wifi.lua..........................................................................92
Código 20: Módulo thingspeak_http.lua - Declarando variáveis................................93
Código 21: Configurando o timer para o envio de dados..........................................94
Código 22: Postando no ThingSpeak - Cliente HTTP...............................................94
Código 23: Parâmetros de conexão - MQTT broker................................................102
Código 24: Configurando os pinos do node-quarto.................................................103
Código 25: Lendo o estado do sensor de movimento.............................................105
Código 26: Criando o objeto cliente MQTT..............................................................106
Código 27: Conectando ao servidor MQTT parte 1.................................................107
Código 28: Conectando ao servidor MQTT parte 2.................................................108
Código 29: Conectando ao servidor MQTT parte 3.................................................109
Código 30: Recebendo uma mensagem MQTT parte 1..........................................110
Código 31: Recebendo uma mensagem MQTT parte 2..........................................110
Código 32: Publicando mensagens MQTT...............................................................111
Código 33: Iniciando os serviços HTTP e Telnet......................................................112
Código 34: Código fonte - Servidor HTTP parte 1...................................................145
Código 35: Código fonte - Servidor HTTP parte 2...................................................146
Código 36: Código fonte - Servidor HTTP parte 3...................................................147
Código 37: Código fonte - Servidor Telnet...............................................................148
LISTA DE ILUSTRAÇÕES
Figura 1: MQTT Publish / Subscribe...........................................................................27
Figura 2: A arquitetura do MQTT-SN...........................................................................32
Figura 3: IDE do Arduino - Código Blink.....................................................................36
Figura 4: Arduino YÚN.................................................................................................37
Figura 5: Família Esp8266..........................................................................................38
Figura 6: Tamanho do Esp01......................................................................................39
Figura 7: Versão do firmware utilizada no Esp8266...................................................41
Figura 8: Descrição dos pinos do NodeMcu...............................................................43
Figura 9: Lista de módulos disponíveis para o firmware Lua.....................................45
Figura 10: Raspberry Pi - Model B..............................................................................50
Figura 11: Raspberry Pi 1 model B - Pinos de GPIO..................................................51
Figura 12: Nomenclatura dos pinos GPIO - BOARD e BCM......................................52
Figura 13: Circuito de exemplo...................................................................................52
Figura 14: Esquema do Raspberry PI.........................................................................53
Figura 15: Node-RED - Nodes....................................................................................61
Figura 16: Flow - Controlando o led através do Twitter..............................................63
Figura 17: Node twitter-in - Configuração...................................................................64
Figura 18: Configuração - rpi-gpio out........................................................................64
Figura 19: Ethernet Shield W5100..............................................................................65
Figura 20: Sensor LM35..............................................................................................66
Figura 21: Esquema eletrônico - Arduino/Ethernet/LM35...........................................66
Figura 22: LM35 - Modo 1...........................................................................................67
Figura 23: LM35 - Modo 2...........................................................................................67
Figura 24: Criando um canal no ThingSpeak..............................................................68
Figura 25: Configuração do canal ThingSpeak...........................................................69
Figura 26: Channel ID e Write API Key.......................................................................69
Figura 27: Instalando a biblioteca ThingSpeak na IDE do Arduino............................70
Figura 28: Sensor DHT11 e seus pinos......................................................................73
Figura 29: Esquema eletrônico - Arduino / DHT11 / Esp8266 (AT)............................74
Figura 30: Monitor serial - Comandos AT....................................................................79
Figura 31: Configurando o Esp8266 na IDE do Arduino.............................................80
Figura 32: Instalando a placa Esp8266 na IDE do Arduino........................................81
Figura 33: Selecionando a placa Esp8266.................................................................81
Figura 34: Selecionado o modelo do Esp8266 correto...............................................82
Figura 35: Selecionado a porta do Esp8266...............................................................83
Figura 36: Esquema eletrônico - Esp8266/DHT11 - Programando em C++..............84
Figura 37: Casa Inteligente - Cenário.........................................................................96
Figura 38: Servidor Raspberry Pi - IP estático............................................................97
Figura 39: Configurando o DMZ..................................................................................98
Figura 40: Configurando o DNS dinâmico no roteador...............................................98
Figura 41: Tipos de nós (NodeMcu) da rede...............................................................99
Figura 42: Esquema eletrônico do NodeMcu - Tipo 1...............................................100
Figura 43: Esquema eletrônico do NodeMcu - Tipo 2...............................................100
Figura 44: Esquema eletrônico do NodeMcu - Tipo 3...............................................101
Figura 45: Compilando código Lua com o auxílio da IDE Esplorer..........................104
Figura 46: Acessando o servidor HTTP do nó NodeMcu..........................................112
Figura 47: Saída do servidor Telnet...........................................................................113
Figura 48: Interface gráfica da aplicação (Node-RED) - Visão dos controles..........114
Figura 49: Menu da aplicação no NodeRED.............................................................115
Figura 50: Seção de controle da Iluminação da sala................................................116
Figura 51: Ícone do Android......................................................................................116
Figura 52: Seção de controle do ar-condicionado central.........................................116
Figura 53: Seção de controle do Umidificador de ar.................................................117
Figura 54: Seção de gráficos - Temperatura, umidade e nível da cisterna...............118
Figura 55: Interface gráfica - Modo de operação......................................................119
Figura 56: Interface gráfica da aplicação Node-RED - Rede de nós NodeMcu.......119
Figura 57: Esquema do Node-RED - Conexão com a cisterna................................120
Figura 58: Configuração do function-node Switch....................................................121
Figura 59: Tweet de aviso de cisterna em nível crítico.............................................122
Figura 60: Esquema do Node-RED - Publicando em tópicos...................................122
Figura 61: Node-RED (Flow) - node-sala..................................................................124
Figura 62: Raspberry Pi - Servidor MQTT................................................................125
Figura 63: Protótipo dos nós NodeMcu do tipo 1......................................................125
Figura 64: Protótipo do nó NodeMcu do tipo 2.........................................................126
Figura 65: Protótipo do nó NodeMcu do tipo 3.........................................................126
Figura 66: Protóptipo completo da rede de nós NodeMcu.......................................127
Figura 67: Foto da aplicação rodando no Tablet Samsung......................................127
Figura 68: Foto da aplicação rodando em um celular modelo LG X cam................128
Figura 69: Verificando a porta associada ao Esp8266.............................................135
Figura 70: Progresso do upload do firmware para a placa.......................................136
Figura 71: NodeMcu - PyFlasher..............................................................................137
Figura 72: Conectando o NodeMcu à IDE Esplorer..................................................138
Figura 73: Conexão da IDE com o NodeMcu...........................................................138
Figura 74: IDE Esplorer - Funções............................................................................139
Figura 75: IDE Esplorer - Aba AT-based...................................................................140
Figura 76: Verificando o status do servidor Mosquitto..............................................141
Figura 77: Criando um tópico de teste no Mosquitto................................................142
Figura 78: Publicação de teste no servidor Mosquitto..............................................142
Figura 79: Tela de log do serviço Node-RED............................................................144
LISTA DE TABELAS
Tabela 1: Arduinos - Especificações técnicas.............................................................36
Tabela 2: Lista de SDKs para Esp8266......................................................................39
Tabela 3: Lista de comandos AT.................................................................................41
Tabela 4: Relação das GPIO com os pinos do Esp8266............................................85
LISTA DE GRÁFICOS
Gráfico 3.1: Linguagens de script mais usadas em jogos..........................................48
Gráfico 3.2: Plotando gráficos usando o MATLAB......................................................57
Gráfico 3.3: Gráfico da temperatura - LM35 - ThingSpeak.........................................72
Gráfico 3.4: Gráficos de temperatura e umidade - ThingSpeak (Comandos AT).......79
Gráfico 3.5: Leitura do DHT - Esp8266 programado em C++....................................87
SUMÁRIO
RESUMO ...................................................................................................................... 8
ABSTRACT ................................................................................................................... 9
LISTA DE CÓDIGOS-FONTE .................................................................................... 10
LISTA DE ILUSTRAÇÕES .......................................................................................... 12
LISTA DE TABELAS ................................................................................................... 15
LISTA DE GRÁFICOS ................................................................................................ 16
1 Introdução ................................................................................................................ 19
2 Fundamentação Teórica .......................................................................................... 23
2.1 IoT (Internet Of Things) ..................................................................................... 23
2.1.1 Possíveis cenários com a IoT .................................................................... 24
2.2 MQTT ................................................................................................................ 25
2.2.1 O Padrão Publish/Subscribe ...................................................................... 26
2.2.2 Tópicos/Assinaturas ................................................................................... 28
2.2.3 Qualidade de serviço ................................................................................. 29
2.2.4 Retenção de mensagens ........................................................................... 30
2.2.5 Sessão limpa / Conexões duradouras ....................................................... 30
2.2.6 Wills (Testamento) ...................................................................................... 31
2.3 MQTT-SN (MQTT for Sensor Networks) .......................................................... 31
2.3.1 Arquitetura do MQTT-SN ........................................................................... 31
2.4 Mosquitto (MQTT Broker) ................................................................................. 33
3 Componentes e Arquiteturas ................................................................................... 35
3.1 Componentes (Hardware e software) ............................................................... 35
3.1.1 Arduino ....................................................................................................... 35
3.1.2 Esp8266 ..................................................................................................... 37
3.1.2.1 Comandos AT ...................................................................................... 40
3.1.2.2 NodeMcu ( Firmware Lua) .................................................................... 43
3.1.2.3 Linguagem Lua .................................................................................... 46
3.1.2.3.1 eLua (Embe d ded Lua) .............................................................. 48
3.1.3 Raspberry Pi .............................................................................................. 50
3.1.4 ThingSpeak (Uma plataforma open source para IoT) ............................... 55
3.1.4.1 Coleta de dados .................................................................................. 56
3.1.4.2 Análise dos dados ............................................................................... 57
3.1.4.3 Associe uma ação (Trigger an action) ................................................. 58
3.1.5 Node-RED .................................................................................................. 58
3.2 Arquiteturas ....................................................................................................... 65
3.2.1 Arduino com shield ethernet ...................................................................... 65
3.2.2 Arduino com WiFi via Esp8266 (comandos AT) ......................................... 72
3.2.3 Esp8266 (programando o firmware com a IDE do Arduino) ...................... 80
3.2.4 NodeMcu + ThingSpeak (usando Lua) ...................................................... 88
4 Implementando uma Casa Inteligente .................................................................... 95
4.1 Preparando a infraestrutura da rede ................................................................ 97
4.2 Os esquemas eletrônicos dos nós NodeMcu ................................................... 99
4.3 Analisando o funcionamento do código-fonte ................................................ 101
4.4 Construindo a aplicação móvel com o Node-RED ......................................... 113
4.5 Protótipo construído ........................................................................................ 125
CONCLUSÕES E TRABALHOS FUTUROS ........................................................... 129
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 131
APÊNDICE A – Esp8266 (fazendo o upload do firmware Lua) ................................ 134
APÊNDICE B – Usando a IDE Esplorer ................................................................... 138
APÊNDICE C – Instalando e configurando o servidor Mosquitto ............................ 141
APÊNDICE D – Instalando o Node-RED ................................................................. 143
APÊNDICE E – Código do servidor HTTP ............................................................... 145
APÊNDICE F – Código do servidor Telnet ............................................................... 148
19
1 INTRODUÇÃO
Este trabalho apresenta um estudo de tecnologias para a IoT (Internet das Coisas)
que consiste na integração de tudo e qualquer coisa através da Internet. Mas antes de dar
detalhes sobre essas tecnologias é preciso definir o que seria Internet das Coisas. O ter -
mo vem de um conceito bem mais antigo e amplo, o da computação ubíqua1.
Segundo Silva et al (2015), o termo ubiquidade tem relação direta com o significado
da palavra onipresente, que quer dizer: algo que está em todo lugar. Apesar de onipresen-
te essa tecnologia deve ser praticamente imperceptível, ou seja, deve passar despercebi-
da no nosso cotidiano. As características de um cenário ubíquo são:
• Invisibilidade
• Pró-atividade
• Sensibilidade ao contexto
• Interfaces naturais
• Descentralização
A IoT é um termo moderno e que aparece como a possibilidade de implementação
das ideias da computação ubíqua. Um cenário de IoT traz consigo muitas das característi -
cas citadas acima. Das casas inteligentes até dispositivos vestíveis (wearables),2 a IoT
está presente na vida das pessoas.
São muitas as tecnologias que estão surgindo para atender o mercado gerado pela
IoT e a maioria delas vêm do mundo open-source. Desde o hardware necessário para se
implantar um ambiente de IoT até o software que embarca esse hardware com inteligên-
cia, desde os protocolos de comunicação entre esses dispositivos até interfaces web mó-
veis, tudo isso é fornecido e impulsionado pela filosofia open-source.
O objetivo deste trabalho é revelar a existência destes componentes de hardware e
software, suas definições e aplicações, e como eles podem ser interconectados formando
arquiteturas para a construção de produtos de IoT.
1 Onipresente.2 Vestíveis.
20
Toda a ideia do trabalho começa na apresentação do protocolo de comunicação uti-
lizado pelos dispositivos com o intuito de trocar mensagens. O protocolo responsável por
essa troca é o MQTT. Ele é um protocolo leve, ideal para dispositivos com limitações de
processamento, memória e para redes com pequena largura de banda. O MQTT usa o
modelo publish/subscribe3, que permite que dois dispositivos troquem mensagens sem
mesmo saber um da existência do outro. Uma das características do modelo pub/sub é o
desacoplamento, que possibilita que dois dispositivos troquem mensagens, independente
do tempo e do espaço. Para que o MQTT funcione entra em cena o servidor Mosquitto,
que é também chamado de MQTT broker.
Este trabalho é construído em cima dos seguintes dispositivos de hardware:
• Arduino – Hardware open-source que pode se conectar com sensores, atuadores,
shields4 de rede com fio e sem fio. Serão apresentadas ao todo cinco arquiteturas,
e o Arduino será usado nas duas primeiras, onde será também o centro do proces-
samento.
• Esp8266 – Dispositivo que serve como shield WiFi para Arduino mas também pode
funcionar de maneira independente. Possui portas para a conexão com sensores e
já vem com a capacidade de se conectar às redes wireless.
• Raspberry Pi – É um computador completo capaz de funcionar com vários siste-
mas operacionais. Entre eles a distribuição GNU/Linux Raspbian que é uma versão
da distribuição Debian otimizada para o Pi. Também pode se conectar a sensores e
atuadores. Neste trabalho ele é usado como um servidor rodando o Mosquitto e o
Node-RED.
• NodeMcu – É um kit de desenvolvimento pra protótipos de IoT. Usa uma lingua-
gem de programação chamada Lua que permite que com poucas linhas de código
seja criada uma aplicação de IoT.
Na parte de software são abordados os comandos AT, que servem para a comuni-
cação entre o Arduino e o Esp8266, e são mostrados exemplos de códigos escritos nas
linguagens C++ e Lua. Para encerrar a parte de software, há uma descrição do Node-
RED e de seus principais tipos de componentes. O Node-RED é uma linguagem visual
baseada em fluxos (flows) criada pela IBM a fim de facilitar a criação de aplicações IoT.
3 Publica/Assina.4 Placas que adicionam novas funcionalidades ao Arduino.
21
Na parte das arquiteturas, após a apresentação de todos esses conceitos de
hardware e software, são apresentadas cinco possibilidades de se construir aplicações de
IoT. Cada arquitetura é uma combinação progressiva desses componentes e para cada
uma delas, o trabalho mostra os esquemas eletrônicos em protoboard5 e traz o código
fonte explicado detalhadamente.
A quinta arquitetura é a implementação de um protótipo de uma Casa Inteligente. É
nesse ponto do trabalho, que tudo o que foi abordado anteriormente, converge para a
construção da aplicação web e dos códigos dos firmwares6 dos dispositivos. Todos os es-
quemas eletrônicos são mostrados em detalhes e os fontes dos firmwares dissecados li-
nha por linha.
A aplicação da Casa Inteligente implementada faz uso de 6 nós NodeMcu, esses
nós são posicionados nos diversos cômodos da casa. Há um NodeMcu na sala, no quar -
to, no banheiro, na garagem, na cozinha e na cisterna. Todos eles, com exceção do que
fica na cisterna, têm a capacidade de detectar movimento e controlar a iluminação do am-
biente.
A casa é monitorada/controlada pelos nós NodeMcu. A Temperatura e umidade do
ar são aferidas e seus valores visualizados através de gráficos na aplicação. É possível
automatizar o funcionamento do ar-condicionado e do umidificador baseado em valores
determinados na interface da aplicação. O nível de água da cisterna é monitorado cons-
tantemente e se esse nível baixar de um valor especificado, a aplicação twitta o aviso de
alerta. Há um gauge7 que mostra a quantidade de água disponível.
Os nós detectam o movimento e notificam o usuário. Há duas opções globais na
aplicação que são importantes, a primeira permite que em caso de movimento detectado
um e-mail seja enviado para o usuário informando em que cômodo foi detectada a pre-
sença, a segunda opção, é uma opção que foca na acessibilidade, ela permite que os avi-
sos de detecção de movimento e o aviso da cisterna em nível crítico sejam falados atra-
vés de um sintetizador de voz.
É possível simular o controle do ar-condicionado e do umidificador de ar através de
dois leds, também é possível simular o controle da iluminação dos cômodos através de
um terceiro led. Toda a implementação necessária para esses controles, foi realizada. So-
5 Uma placa de ensaio ou matriz de contato. É uma placa com furos e conexões condutoras para monta-
gem de circuitos elétricos experimentais.6 Software responsável pelo funcionamento do dispositivo.7 Instrumento de medição.
22
mente não foi instalada completamente em uma casa devido a dificuldades praticas que
não são escopo deste trabalho, como a passagem de cabos por conduítes por exemplo.
Há uma seção que analisa os códigos-fonte dos firmwares e a partir desse detalha-
mento são abordados conceitos importantes sobre como é feita a conexão ao ThingSpe-
ak, que é uma plataforma open-source para IoT e que permite coletar, analisar e atuar so-
bre os dados vindos dos dispositivos. Uma outra seção vai mostrar como fazer a conexão
com o MQTT broker e como se publica e assina um tópico. Também serão vistos alguns
detalhes importantes sobre programação Lua para o NodeMcu, como o uso dos timers, a
importância da indentação na organização do código Lua e o uso das funções callback.
Será explicado também todo o processo de configuração da infraestrutura de rede neces-
sária para o funcionamento do projeto e como torná-lo acessível via Internet. Também po-
derá ser visto como funciona a interface web (Node-RED) e como conectar seus compo-
nentes. Este trabalho foi subdivido nos seguintes capítulos:
O capítulo 2 vai apresentar o embasamento teórico sobre o protocolo de comunica-
ção e o uso do servidor de mensagens.
O capítulo 3 vai mostrar os componentes e suas arquiteturas. Todo hardware e
software necessário para a implementação de uma Casa Inteligente será apresentado
neste capítulo.
O capítulo 4 será a aplicação de todos os conceitos e ferramentas vistos nos capí-
tulos anteriores. Será mostrado todo o processo de configuração, programação e constru-
ção do protótipo de uma Casa Inteligente. Ao final podem ser vistas algumas fotos do pro -
tótipo (6 nós NodeMcu) montado em bancada.
O trabalho conta ainda com seis apêndices que trazem detalhes técnicos sobre a
instalação e uso das ferramentas: esptool.py, Pyflasher, Esplorer. Eles explicam como fa-
zer a gravação dos firmwares Lua e AT, e, por fim, trazem os códigos-fonte dos servidores
HTTP e Telnet que rodam em alguns dos dispositivos.
23
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresentará conceitos importantes para o desenvolvimento de aplica-
ções de IoT. Ele começa com uma definição do que vem a ser a IoT e seu impacto na so-
ciedade e na indústria, também apresenta um dos protocolos de comunicação mais indi-
cados para utilização em projetos de Internet das coisas.
2.1 IOT (INTERNET OF THINGS)
É muito fácil ter um panorama do impacto da tecnologia sobre o mundo atual. A
roda tornou possível mover e transportar coisas e pessoas. Ela mudou tudo desde a agri-
cultura até as políticas governamentais. Casas e empresas foram iluminadas por lâmpa-
das – mudando completamente o jeito como arquitetos projetam estruturas e cidades in-
teiras são estruturadas. O automóvel trouxe uma rápida viagem de um ponto a outro para
as pessoas – redefinindo a maneira como as pessoas vivem e trabalham. O computador
introduziu um mundo digital com dados que podem ser armazenados e compartilhados de
uma maneira nova e fora do comum.
O entendimento do que significa “Internet das coisas”8 é fácil, todos sabem o que é
a Internet e também o que são “coisas”. Podemos então dizer que “Internet das coisas”
são coisas na Internet. O termo Internet das coisas possui uma relação com um termo
mais antigo chamado computação ubíqua, ou onipresente. Segundo Silva et al (2015), o
termo ubiquidade tem relação direta com o significado da palavra onipresente, que quer
dizer: algo que está em todo lugar.
A Internet das coisas está estritamente relacionada a valor, conhecimento e oportu-
nidades que surgem com a interconexão do mundo digital e físico. Dependendo da situa-
ção, “valor” pode ter vários significados. Se em uma empresa de entregas é preciso moni-
torar remotamente as frotas de veículos, o “valor” obtido com a IoT seria uma possível oti-
8 Segundo a Wikipedea Internet das coisas (IoT) é uma rede de objetos físicos ou “coisas” embarcadas
com eletrônica, software, sensores, e conectividade para que essa seja capaz de alcançar um grande
valor e serviço, trocando dados com o fabricante (inventor, produtor), operador, e/ou outros dispositivos
conectados.
24
mização da rota, melhor aproveitamento do combustível ou maior eficiência no cumpri-
mento dos horários de entrega. Um outro exemplo de “valor” obtido com a IoT seria na
área da saúde, imaginando-se a necessidade de se monitorar o estado de saúde de um
paciente ou mesmo de um parente. Neste caso, o “valor” significaria manter a saúde e até
mesmo salvar a vida de uma pessoa.
O termo Internet das Coisas foi criado em 1999 por Kevin Ashton e desde entãotem sido atribuído a vários jargões tecnológicos. Ao longo dos anos, tem-se ouvidoos termos “Internet das Coisas”, “Internet de Tudo”, “M2M” (Máquina-para-Máqui-na), “Computação Física”, “Computação Ubíqua”, e assim por diante. (DARNELL,2015)
Independente de como o termo pode ser rotulado, a Internet das coisas é a prática
de conectar e monitorar “coisas” ou dispositivos de maneira remota e autônoma. Visa a in-
tegração dos dispositivos físicos com a Internet, a fim de coletar dados trocados pelos dis-
positivos, analisar esses dados, extrair conhecimento a respeito do ambiente onde esses
dispositivos estão posicionados e atuar sobre eles.
2.1.1 Possíveis cenários com a IoT
A IoT pode aparecer no dia a dia de diversas maneiras e em diversas áreas. Sua
presença pode ser percebida em cenários futurísticos da vida cotidiana mas existem tam-
bém outras possibilidades para IoT na indústria, assistência a saúde e etc.
O relógio despertador toca, ao acordar a pessoa percebe que está a 10 minutos
atrasada. O relógio checou o horário de saída dos trens na Internet e viu que o trem atra-
saria 10 minutos. Com isso a pessoa pôde ter uns minutos a mais de descanso.
Na cozinha, uma luz piscando faz lembrar que é a hora de tomar os comprimidos.
Se o paciente esquece, a tampa do frasco de remédio fica online e envia um e-mail para o
médico para que ele fique ciente.
Ao se preparar para sair de casa, percebe-se um brilho no canto dos olhos. O cabo
do guarda-chuvas está aceso, que significa que ele checou o relatório do tempo que pre-
vê que vai chover.
Como se pode ver, há inúmeros exemplos de Internet das Coisas, e o que é co-
mum em todos os cenários é o uso da Internet para enviar, receber, ou comunicar infor -
mação. Em cada caso, o dispositivo que estava conectado à Internet não era um compu-
tador, tablet, ou telefone móvel mas um objeto, uma coisa.
25
Pessoas fazem uso da Internet grandemente através da World Wide Web, que é
um conjunto de aplicações que rodam na Internet. Na Internet das Coisas, em compara-
ção, dispositivos eletrônicos autônomos trocam informação uns com os outros sobre a In-
ternet. Mas estes dispositivos não tem uma aplicação equivalente a um navegador web
para usar. Estas ferramentas e serviços estão ainda no início do seu desenvolvimento. A
comunicação entre estes objetos é feita usando a pilha de protocolos TCP/IP (que é o co-
ração da Internet) e alguns protocolos mais específicos, que funcionam na camada de
aplicação da pilha TCP/IP. É possível citar o protocolo HTTP que é a base do modelo cli-
ente-servidor usado para Web e também o protocolo MQTT que é leve, eficiente e ideal
para conectar pequenos dispositivos a redes restritas.
2.2 MQTT
O MQTT9 é um protocolo de transporte de mensagens do tipo publish/subscribe. É
aberto, leve, simples e projetado para ser de fácil implementação. É ideal para sensores e
pequenos dispositivos móveis, é otimizado para redes TCP/IP não confiáveis ou de alta
latência. Essas características o torna perfeito para uso em muitas situações, incluindo
ambientes restritos, como por exemplo, comunicação de Máquina para Máquina (M2M) e
Internet das coisas (IoT). Há também o MQTT-SN, uma variação do protocolo destinada a
redes que não sejam baseadas em TCP/IP, como ZigBee10. Os termos publish/subscribe
serão explicados na seção 2.2.1
MQTT minimiza a largura de banda usada e requerida para a comunicação; ao
mesmo tempo, uma alta confiabilidade é alcançada para a transmissão dos dados. Estes
requisitos são especialmente predominantes em redes de sensores, Machine-to-Machine
(M2M), telemedicina, monitoramento de pacientes e Internet das coisas. Nestas aplica-
ções, os dispositivos conectados estão “sempre ligados” e comunicam-se constantemente
uns com os outros.
Desde 2013, o OASIS padronizou o MQTT como o protocolo para Internet das coi-
sas. O OASIS é um consórcio sem fins lucrativos que dirige o desenvolvimento, conver-9 Message Queue Telemetry Transport – Transporte de Telemetria da Fila de Mensagens.10 Zigbee designa um conjunto de especificações para a comunicação sem-fio entre dispositivos eletrôni-
cos, com ênfase na baixa potência de operação, na baixa taxa de transmissão de dados e no baixo cus -
to de implementação.
26
gência e adoção de padrões abertos. O OASIS MQTT Technical Committee está produzin-
do um padrão para o MQTT compatível com MQTT V3.1, unido a requisitos para aprimo-
ramentos, exemplos de uso documentados, melhores práticas e orientação para uso dos
tópicos MQTT com mecanismos de registro e descoberta comumente disponíveis. O pa-
drão suporta mensagens bidirecionais para lidar uniformemente com sinais e comandos,
entrega de mensagens determinísticas, níveis básicos de QoS, cenários sempre/às vezes
conectados, baixo acoplamento e escalabilidade para suportar um grande número de dis-
positivos. Os candidatos para aprimoramentos incluem prioridade e expiração de mensa-
gem, tipo da carga útil da mensagem, solicitação/resposta e expiração de assinatura.
Outro aspecto importante é que o MQTT é extremamente fácil de implementar no
lado do cliente. Isso se adapta perfeitamente aos dispositivos restritos com recursos limi -
tados, como os microcontroladores. Na verdade, este foi um dos principais objetivos
quando o MQTT foi inventado.
O MQTT foi inventado por Andy Stanford-Clark (IBM) e Arlen Nipper (Arcom, agoraCirrus Link) em 1999, quando o objetivo deles era criar um protocolo para conectaroleodutos, em uma conexão via satélite, que tivesse o mínimo de consumo de ba-teria e que usasse uma mínima largura de banda. (HIVEMQ, 2018)
Eles especificaram os seguintes objetivos, que o futuro protocolo deveria ter:
• Implementação simples
• Serviço de entrega de dados de qualidade
• Leve e com largura de banda eficiente
• Dados agnósticos
• Consciência de sessão contínua
Essas metas ainda são o núcleo do MQTT. Apenas o foco mudou, de sistemas em-
barcados proprietários para a Internet de coisas.
2.2.1 O Padrão Publish/Subscribe
O padrão publish/subscribe (publica/assina) é bem diferente do modelo cliente-ser-
vidor. No modelo cliente-servidor, um cliente se conecta diretamente com outro nó da
rede. No modelo pub/sub, quem envia uma mensagem é chamado de publisher e quem
27
recebe uma mensagem é chamado de subscriber, nesse modelo, publisher e subscriber
não sabem da existência um do outro, há um desacoplamento. Essa “ponte” é feita por
um terceiro componente chamado broker, ele é um programa intermediário que direciona
cada publicação para o nó interessado na mensagem. O broker conhece ambos, o pu-
blisher e o subsciber. Um exemplo de MQTT broker é o Mosquitto, um message-broker de
código aberto que implementa o protocolo MQTT. A Figura 1 mostra como funciona a inte-
ração entre o publisher, o subscriber e o broker.
O principal aspecto no modelo pub/sub é o desacoplamento do publisher e do
subscriber, que pode ser diferenciado três dimensões: Espaço, Tempo e Sincronização.
• Desacoplamento espacial: O Publisher e subscriber não precisam se conhecer,
por endereço de ip ou porta. Só precisam estar conectados ao broker.
• Desacomplamento temporal: O Publisher e subscriber não precisam rodar simul-
taneamente.
• Desacoplamento de sincronização: As operações em ambos os componentes
não são interrompidas durante a publicação ou recepção.
Figura 1: MQTT Publish / SubscribeFonte: (HIVEMQ, 2018)
Sensor de temperatura
Mosquitto
MQTT-Broker
Notebook
Dispositivo Móvel
Publish: “32ºC”
Publish: “3
2ºC”
Publish: “32ºC”
Subscrib
e
Subscribe
1 Subscribe to topic: “ Temperatura”
2 Publish to topic: “ Temperatura”
28
Através de um mecanismo de filtragem, é possível definir que certas mensagens
sejam somente entregues a clientes específicos. O desacoplamento é a característica
mais importante do modelo pub/sub.
2.2.2 Tópicos/Assinaturas
Na prática, mensagens em MQTT são publicadas em tópicos. E não há a necessi-
dade de configurar qualquer tópico, basta publicar nele que já é o suficiente. Tópicos são
tratados como uma hierarquia, usando uma barra (/) como separador. É semelhante a um
sistema de arquivos. Por exemplo, vários computadores podem publicar suas temperatu-
ras dos seus discos rígidos no seguinte tópico, com seu próprio nome do computador e o
nome do seu disco rígido.
• sensores/NOME_COMPUTADOR/temperatura/DISCO_NOME
Clientes podem receber mensagens assinando aos tópicos. Uma assinatura pode
ser feita a um tópico explícito, neste caso somente as mensagens para aquele tópico se-
rão recebidas, ou a assinatura pode ser feita usando wildcards11 (coringas). Dois coringas
estão disponíveis, + ou #.
O + pode ser usado como um coringa para um nível simples da hierarquia. Ele
pode ser usado com o tópico acima para obter informações sobre todos os computadores
e hds como segue:
• sensores/+/temperatura/+
O # pode ser usado como um coringa para todos os níveis restantes da hierarquia.
Isto significa que ele deve ser o último caractere em uma assinatura. Com um tópico do
tipo “a/b/c/d”, as seguintes assinaturas são válidas:
• a/b/c/d
11 Wildcards são símbolos usados para substituir ou representar um ou mais caracteres.
29
• #
• a/#
• a/b/#
• a/b/c/#
• +/b/c/#
Os níveis de tópicos de comprimento zero são válidos, o que pode levar a um com-
portamento um pouco incompreensível. Por exemplo, um tópico de “a// tópico” concorda-
ria corretamente com uma assinatura de “a/+/tópico”. Da mesma forma, níveis de tópicos
de comprimento zero podem existir no início e no final de uma sequência de tópicos, en-
tão "/a/tópico" combinaria com uma assinatura de "+/a/ tópico", "#" ou "/#", e um tópico “a/
tópico/” corresponderia a uma assinatura de “a/tópico/+” ou “a/tópico/#”.
2.2.3 Qualidade de serviço
O protocolo MQTT define três níveis de qualidade de serviço (QoS). O QoS define
o quão rígido, o broker/client, será na tentativa de garantir que a mensagem seja recebi-
da. Mensagens podem ser enviadas em qualquer nível de QoS, e clientes podem tentar
assinar aos tópicos em qualquer nível de QoS. Isto significa que o cliente escolhe o máxi -
mo QoS em que ele receberá uma mensagem. Por exemplo, se uma mensagem é publi -
cada em QoS 2 e um cliente assinou o tópico com um QoS 0, a mensagem será entregue
ao cliente com QoS 0. Se um outro cliente assinou o mesmo tópico, mas com o QoS 2,
ele receberá a mesma mensagem mas com QoS 2. Um outro exemplo, se um cliente as-
sina um tópico com QoS 2 e uma mensagem é publicada com QoS 0, o cliente receberá a
mensagem com QoS 0.
Altos níveis de QoS são mais confiáveis, mas envolvem uma maior latência12 e re-
querem maior largura de banda.
• QoS 0: O broker/client entregará a mensagem uma vez, sem confirmação.
• QoS 1: O broker/client entregará a mensagem pelo menos uma vez, com um pedi-
do de confirmação.
12 Tempo de resposta entre o envio da mensagem e a confirmação do seu recebimento.
30
• QoS 2: O broker/client entregará a mensagem exatamente uma vez usando um
handshaking13 de quatro passos.
2.2.4 Retenção de mensagens
Todas as mensagens podem ser configuradas como “retidas”. Isto significa que o
broker manterá a mensagem mesmo depois dela ter sido enviada para todos os assinan-
tes do tópico. Se um novo cliente assina este tópico em que a mensagem foi configurada
como retida, a mensagem será enviada a este cliente. Isto é um mecanismo importante.
Se um tópico é atualizado com pouca frequência, sem o mecanismo de reter a mensa-
gem, um novo cliente que assinasse este tópico ficaria muito tempo sem receber uma atu-
alização. Com uma mensagem retida, o cliente receberia uma atualização instantânea.
2.2.5 Sessão limpa / Conexões duradouras
Na conexão, um cliente define o flag da “sessão limpa”, que às vezes também é co-
nhecido como o sinalizador de “início limpo”. Se a sessão limpa for configurada como fal -
sa, a conexão será tratada como durável. Isso significa que quando o cliente se desco-
nectar, todas as assinaturas permanecerão e todas as mensagens subsequentes de ní-
veis QoS 1 ou 2 serão armazenadas até que o cliente se conecte novamente no futuro.
Se a sessão limpa for verdadeira, todas as assinaturas serão removidas para o cliente
quando ele for desconectado.
13 É um processo automático de negociação que dinamicamente define os parâmetros de um canal de co-
municação estabelecido entre duas entidades.
31
2.2.6 Wills (Testamento)
Quando um cliente se conecta a um broker, ele pode informar ao broker que ele
possui um testamento. Esta é uma mensagem que deseja que o broker envie quando o
cliente se desconecta de forma inesperada. A mensagem de testamento tem um tópico,
QoS e o status de mensagem retida, exatamente como qualquer outra mensagem.
2.3 MQTT-SN (MQTT FOR SENSOR NETWORKS)
Conforme em Standford-Clark e Truong (2018), o MQTT-SN foi projetado para ser o
mais próximo possível do MQTT, mas foi adaptado às peculiaridades de um ambiente de
comunicação sem fio com banda baixa de conexão, alta taxa de falhas de conexão, men-
sagens curtas, etc. O MQTT-SN é otimizado para implementação em dispositivos de baixo
custo e com limitação de armazenamento e capacidade de processamento. Foi desenvol-
vido para rodar em cima da camada APS ZigBee, ao contrário do MQTT que exige uma
camada básica de TCP/IP (e isso é muito complexo para dispositivos muito simples e de
baixo custo) o MQTT-SN é projetado de tal maneira que ele é agnóstico em relação às ca-
madas de serviços de rede. Qualquer rede que ofereça uma transferência de dados bidi -
recional entre qualquer nó e em particular um gateway deve ser capaz de suportar MQTT-
SN.
2.3.1 Arquitetura do MQTT-SN
A arquitetura do MQTT-SN pode ser vista na Figura 2. Ela é composta por três
componentes: clientes MQTT-SN, gateways MQTT-SN e forwarders (encaminhadores)
MQTT-SN.
Clientes MQTT-SN conectam-se a um broker MQTT através de um gateway MQTT-
SN usando o protocolo MQTT-SN. Um gateway MQTT-SN pode ou não ser integrado com
um broker MQTT. No caso de um gateway independente, o protocolo MQTT é usado entre
32
o broker MQTT e o gateway MQTT-SN. Sua principal função é a tradução entre MQTT e
MQTT-SN.
Os clientes MQTT-SN também podem acessar um gateway através de um forwar-
der caso o gateway não esteja diretamente ligado à rede. O forwarder simplesmente en-
capsula os quadros MQTT-SN que ele recebe no lado sem fio e os encaminha inalterados
para o gateway; na direção oposta, ele desencapsula os quadros que recebe do gateway
e os envia para os clientes, inalterados também. Dependendo de como um gateway reali-
za a conversão de protocolo entre MQTT e MQTT-SN, podemos diferenciar entre dois ti-
pos de gateway, ou seja, gateway transparentes e agregados.
Figura 2: A arquitetura do MQTT-SNFonte: (STANFORD-CLARK e TRUONG, 2013)
33
2.4 MOSQUITTO (MQTT BROKER)
Mosquitto é um projeto da divisão de IoT do Eclipse14. Ele fornece uma implemen-
tação leve do servidor de protocolos MQTT e MQTT-SN, escrito em C. (LIGHT, 2017)
A motivação para escrevê-lo em C é permitir que o servidor seja executado em
máquinas que não têm capacidade para executar uma JVM (Máquina virtual Java). Os
sensores e atuadores, que são muitas vezes fontes e destinos das mensagens MQTT e
MQTT-SN, podem vir a ser muito pequenos e de baixa potência. Isso também se aplica às
máquinas incorporadas às quais estão conectadas, é onde o Mosquitto poderia ser execu-
tado.
No IBM AlphaWorks15, em 2008, foi lançada a Really Small Message Broker
(RSMB). Seu objetivo era ser um servidor MQTT simples e elementar. Seu código foi fe-
chado e lançado sob uma licença somente de avaliação. Nos próximos dois anos, um se-
guimento pequeno mas entusiasmado aderiu ao projeto. Em 2010, Roger Light16 apren-
deu sobre MQTT e RSMB em uma apresentação de Andy Stanford-Clark17. Roger então
decidiu criar o Mosquitto para ser uma alternativa de código aberto ao RSMB.
A partir daí, o Mosquitto passou a ter um seguimento entusiasmado próprio e cres-
ceu incluindo funções não disponíveis no RSMB. Ele passou a fazer parte de várias distri-
buições Linux. O RSMB teve algumas capacidades do MQTT-SN adicionadas, mas que
não foram lançadas fora da IBM.
Normalmente, a implementação atual do Mosquitto de Roger Light tem um executá-
vel de tamanho em torno de 120kB que consome cerca de 3MB de RAM com 1000 clien-
tes conectados. Há relatos de testes bem-sucedidos com 100.000 clientes conectados
com modestas taxas de mensagens.
O servidor Mosquitto, além de aceitar conexões de aplicativos de cliente MQTT,
possui o recurso bridge (ponte) que permite conectar-se a outros servidores MQTT, inclu-
indo outras instâncias do Mosquitto. Tornando possível que redes de servidores MQTT se-
14 https://iot.eclipse.org/15 IBM AlphaWorks é uma comunidade da Web para desenvolvedores que podem visualizar e colaborar
em tecnologia emergente dos laboratórios de pesquisa da IBM e transformá-los em produtos comerciais.16 Professor assistente na Universidade de Nottingham.17 Engenheiro britânico, pesquisador em tecnologia da informação, especializado em telemetria e no pa-
drão de mensagens publish/subscribe.
34
jam construídas, passando mensagens MQTT de qualquer local na rede para qualquer
outra rede, dependendo da configuração das pontes.
O Eclipse Mosquitto é um MQTT broker. Ele é licenciado pela EPL/EDL que imple-
menta os protocolos versão 3.1 e 3.1.1. O termo “broker”, em alguns textos, tem sido
substituído por “server”. O projeto Mosquitto fornece uma pequena implementação do ser-
vidor de protocolos MQTT e MQTT-SN. Essa pequena implementação possui as seguin-
tes funções:
1. São incluídas somente as funções necessárias (a compilação condicional pode ser
usada para omitir funções desnecessárias para uma aplicação particular).
2. As funções são codificadas da forma mais eficiente possível.
O servidor tem as seguintes características, que não estão descritas na especifica-
ção do protocolo MQTT:
1. Um MQTT bridge, permite ao Mosquitto se conectar a outros servidores MQTT.
2. Comunicação de forma segura usando SSL/TLS.
3. Autenticação de usuário – Podendo restringir a um usuário o acesso a alguns tópi-
cos.
O Mosquitto tem a capacidade de traduzir e transferir mensagens entre MQTT e
MQTT-SN, ele é capaz de atuar como um gateway entre dispositivos que se comunicam
com um dos dois protocolos.
Ele mantém atualizado com qualquer mudança de especificação sobre os protoco-
los MQTT ou MQTT-SN, como por exemplo, o resultado da padronização da especifica-
ção OASIS MQTT. O Mosquitto adere às especificações e padrões do protocolo o mais
próximo possível, portanto, pode ser usado em testes de conformidade. Qualquer compor-
tamento não padronizado incluído é opcional.
35
3 COMPONENTES E ARQUITETURAS
3.1 COMPONENTES (HARDWARE E SOFTWARE)
3.1.1 Arduino
O Arduino pode ser usado para o desenvolvimento de objetos que podem interagir
com o meio físico, através de vários tipos de entradas como switches ou sensores, sendo
assim capaz de controlar vários tipos de elementos como leds, motores DC, motores de
passo, mecanismos, entre outras saídas. O Arduino foi projetado com o intuito de facilitar
o uso da eletrônica em projetos multidisciplinares. O hardware é programado em uma lin-
guagem baseada no Wiring18 (sintaxe + bibliotecas), similar ao C++ com algumas simplifi-
cações e modificações. Também conta com uma IDE baseada no Processing19.
A IDE do Arduino inclui um editor de código fonte com características tais como
destaque na sintaxe, indentação automática e é capaz de compilar e fazer o upload para
a placa com apenas um clique. Não é preciso editar makefiles ou executar utilitários em li-
nha de comando.
A IDE do Arduino vem com uma biblioteca C/C++ chamada "Wiring" (do projeto que
tem o mesmo nome), que torna mais fácil muitas operações comuns de entrada e sáida.
Os programas para Arduino são escritos em C/C++, embora os usuários somente neces-
sitem definir duas funções para fazer um programa executável:
18 É um framework de código aberto para microcontroladores. http://wiring.org.co/19 É um sketchbook de software flexível e uma linguagem para aprender a codificar dentro do contexto das
artes visuais. https://processing.org/
36
setup() - Essa função é executada somente uma vez, no momento em que a placa
é inicializada. Pode ser usada como uma área para inicializar variáveis, criar objetos e de-
finir os parâmetros para estes objetos.
loop() - Função que é a chamada repetidamente. É o mainloop do código Arduino.
Ele fica ativo até que a placa seja desligada.
A IDE do Arduino (Figura 3) usa, para compilar os programas, o kit de ferramentas
GNU e a AVR libc, e para fazer o upload dos programas para a placa, o AVRDUDE.
Na Tabela 1 pode-se observar um comparativo entre três placas com direfentes re-
cursos e aplicações:
Nome ProcessadorTensão de
operação
CPU
speed
Analog
In/Out
Digital
IO/PWM
EE-
PROM
[kb]
SRAM
[kb]
Flash
[kb]USB UART
Uno Atmega328P 5V / 7-12V 16 MHz 6/0 14/6 1 2 32 Comum 1
Due ATSAM3X8E 3.3V / 7-12V 84 MHz 12/2 54/12 - 96 512 2 Micro 4
YúnAtmega32U4
AR9331 Linux5V
16 MHz
400 MHz12/0 20/7 1
2.5
15MB32 64MB Micro 1
Tabela 1: Arduinos - Especificações técnicasFonte: (O autor, 2018)
Figura 3: IDE do Arduino - Código BlinkFonte: (O autor, 2018)
37
O Arduino YÚN (Figura 4) é a placa ideal para conectar dispositivos e, de uma ma-
neira geral, projetos de IoT. É uma combinação do poder de ter um Linux instalado com a
facilidade de uso do Arduino. O seu processador suporta uma distro Linux que se baseia
no OpenWrt20 chamada Linino OS. Seu grande diferencial está na sua capacidade de inte-
ragir com o Linux sendo possível criar scripts shell e python para interações robustas.
3.1.2 Esp8266
O módulo WiFi Esp8266 é um SoC,21 com uma pilha de protocolo TCP/IP integra-
da, que permite que qualquer microcontrolador, conectado a ele, tenha acesso a uma
rede WiFi. O Esp8266 é capaz de rodar um aplicativo ou servir como um shield de acesso
à redes sem fio. Cada módulo Esp8266 vem pré-programado com um firmware do conjun-
to de comandos AT22, tonarndo possível, simplesmente conectá-lo a um Arduino (ou qual-
quer outro microcontrolador) e obter a mesma capacidade Wi-Fi, oferecida pelo WiFi Shi-
eld do Arduino.
Essa foi a primeira aplicação planejada pelos fabricantes do Esp8266, servir como
shield WiFi para a placa Arduino. O Esp8266 é uma placa extremamente econômica com
uma enorme e crescente comunidade.20 O OpenWrt é um sistema operacional GNU/Linux voltado para dispositivos embarcados.21 Um SoC (System-On-Chip) é um microchip com todos os circuitos eletrônicos e peças necessárias para
um determinado sistema, como um smartphone. E tudo em um único circuito integrado.22 O conjunto de comandos AT, oficialmente conhecido como o conjunto de comandos AT padrão Hayes, é
o conjunto padrão de instruções para configurar e controlar modems.
Figura 4: Arduino YÚNFonte: (CURVELLO, 2014)
38
Este módulo tem uma capacidade de processamento e armazenamento poderosa
o suficiente que permite que ele seja integrado com sensores e outros dispositivos espe-
cíficos da aplicação por meio de seus GPIOs23 com o mínimo de desenvolvimento inicial e
carga mínima durante o tempo de execução. Seu alto grau de integração on-chip permite
que o circuito externo mínimo, incluindo o módulo front-end, seja projetado para ocupar
uma área mínima da PCB24.
Há uma fonte quase ilimitada de informações disponíveis para o Esp8266, todas as
quais foram fornecidas pelo incrível apoio da comunidade.
A família de modelos do Esp8266 é muito grande. São versões que variam em po-
der de processamento, quantidade de memória, quantidade de GPIOs e etc. A Figura 5
pode dar uma idéia dos modelos disponíveis.
O Esp01 é o modelo menor e mais barato. Este módulo, é o mais conhecido, ele é
realmente pequeno e custa muito pouco, em torno de 5 dólares. Contudo o número de
GPIOs disponíveis é bastante limitado (apenas dois pinos). Também é bastante trabalho-
so plugá-lo em uma protoboard padrão. Para a gravação do firmware ele depende de um
conversor USB/Serial como o FTDI FT232 por exemplo. Ele não possui um canal de leitu-
23 General purpose input and output – São as conexões de propósitos gerais (entradas ou saídas).24 Uma placa de circuito impresso (PCB) suporta mecanicamente e liga eletricamente componentes ele-
trônicos utilizando trilhas condutoras.
Figura 5: Família Esp8266Fonte: (SINGH, 2016)
39
ra analógica, sendo assim impossível o seu uso em projetos que fazem uso de sensores
analógicos. A Figura 6 mostra o módulo Esp01.
Há vários SDKs para o Esp8266. A Tabela 2 mostra alguns deles.
SDK Descrição
NodeMcu Firmware baseado em Lua
Arduino Arduino like programming
MicroPython Programação Python
Esp8266 BASIC Interpretador BASIC open source para IoT
Zbasic for Esp8266 Um subconjunto do Microsoft Visual BASIC
Espruino JavaScript SDK (emula Node.js)
Mongoose firmware Cloud service
Esp-Open-SDK Implementação open source do SDK padrão
Esp-Open-RTOS Baseado no FreeRTOS
Zerynth Programação PythonTabela 2: Lista de SDKs para Esp8266
Fonte: (O autor, 2018)
Figura 6: Tamanho do Esp01Fonte: (PENNINKHOF, 2015)
40
3.1.2.1 Comandos AT
O conjunto de comandos AT, oficialmente conhecido como o conjunto de comandos
AT padrão Hayes25, é o conjunto padrão de instruções para configurar e controlar mo-
dems. Este conjunto foi desenvolvido pela Hayes Microcomputer Products. Hayes foi um
pioneiro no campo dos modems, e seu padrão é usado em sua totalidade ou em parte por
quase todos os fabricantes de modems para uso com computadores pessoais. Os coman-
dos são sequências curtas de caracteres ASCII26. Todas as strings de comando (ou seja,
sequências de caracteres) devem ser precedidas pelas letras AT, uma abreviação de “at-
tention” (atenção), representando o nome do conjunto.
Geralmente, há alguma variação no conjunto de comandos de acordo com o fabri-
cante do modem. Isto é particularmente verdadeiro para os comandos proprietários. As-
sim, é melhor consultar o conjunto de comandos para um modelo específico de modem,
em vez de confiar em qualquer listagem genérica de comandos.
Um dos comandos AT mais conhecidos é o ATZ, que normalmente aparece na inici-
alização do modem. Essa string é uma combinação de AT, que inicia os comandos, e Z,
que redefine o modem para seu estado padrão. O comando ATDT representa a sequência
de inicialização seguida por D, que representa discagem, e T, que representa discagem
por tom (em oposição a P para discagem por pulso). Os modems são configurados envi-
ando-lhes comandos AT do computador nas mesmas linhas seriais usadas pelo computa-
dor para enviar dados ao modem.
O módulo WiFi Esp8266 é um chip integrado projetado para comunicação com o
mundo da Internet através de sinais de rádio WiFi. Tem processamento e memória inte-
grados que permitem a integração com a eletrônica através de seus GPIOs. O Esp8266,
por exemplo, pode ser usado para conectar projetos com um Arduino à Internet. Em sua
configuração padrão, é inicializado no modo de modem serial. Neste modo, é possível se
comunicar com ele usando um conjunto de comandos AT. A seguir serão apresentados al -
guns dos comandos AT conhecidos que o Esp8266 suporta.
25 Dennis C. Hayes (nascido em 1950) foi o fundador de produtos de comunicação para microcomputador.
Fabricante de modems, foi pioneiro por introduzir um conjunto de comandos de comunicação apelidado
de comandos Hayes, o que foi, posteriormente, utilizado na maioria dos modems produzidos até hoje.26 ASCII (do inglês American Standard Code for Information Interchange; “Código Padrão Americano para
o Intercâmbio de Informação”).
41
A Tabela 3 exibe uma lista com alguns comandos AT separados por camadas. Essa
lista não contém todos os comandos. Para obter uma lista completa é preciso consultar a
documentação referente ao firmware AT instalado no Esp8266. É importante verificar se
os comandos são compatíveis com a versão do firmware que está sendo usada no
Esp8266. Os comandos da Tabela 3 são compatíveis com a versão do firmware mostrada
na Figura 7. A imagem mostra a saída do terminal conectado ao Esp8266 após o coman-
do AT+GMR.
Básico Camada WiFi Camada TCP/IP
AT AT+CWMODE AT+CIPSTATUS
AT+RST AT+CWJAP AT+CIPSTART
AT+GMR AT+CWLAP AT+CIPSEND
AT+GSLP AT+CWQAP AT+CIPCLOSE
ATE AT+CWSAP AT+CIFSR
AT+CWLIF AT+CIPMUX
AT+CWDHCP AT+CIPSERVER
AT+CIPSTAMAC AT+CIPMODE
AT+CIPAPMAC AT+CIPSTO
AT+CIPSTA AT+CIUPDATE
AT+CIPAP +IPDTabela 3: Lista de comandos AT
Fonte: (O autor, 2018)
Alguns comandos podem não funcionar pelas seguintes razões, o firmware pode
ser de uma versão mais antiga, antes do comando ter sido implementado ou o comando
pode ter sido descontinuado em versões de firmware mais recentes. Um exemplo de um
comando descontinuado é o comando AT+UART que era usado para modificar a velocida-
de de comunicação serial do módulo. Este comando foi substituído pelos comandos
Figura 7: Versão do firmware utilizada no Esp8266Fonte: (O autor, 2018)
42
AT+UART_CUR e AT+UART_DEF. O primeiro modifica a velocidade do módulo mas não
salva a configuração na memória flash, sendo assim, após um reset a velocidade volta à
velocidade original que veio gravada no firmware, o segundo comando tem a mesma fun-
ção porém salvando a configuração na memória flash, garantindo assim, que ela perma-
necerá a mesma mesmo após uma reinicialização do módulo.
A seguir uma breve definição de alguns dos comandos da Tabela 3.
1. AT – Verifica se o módulo está conectado corretamente e o seu funcionamento. O
módulo responderá com uma confirmação.
2. AT + RST – Dá um reset na placa. É uma boa prática executar um reset antes ou
depois de qualquer programação.
3. AT + GMR – Mostra a versão do firmware instalada no Esp8266.
4. AT + CWLAP – Detecta e mostra os pontos de acesso disponíveis na área de al-
cance junto com suas respectivas intensidades de sinal.
5. AT + CWJAP = ”SSID”, “PASSWORD” - Conecta o Esp8266 ao SSID especifica-
do no comando AT mencionado.
6. AT + CIFSR – Mostra o endereço IP obtido pelo Esp8266.
7. Se o usuário quiser se desconectar de qualquer ponto de acesso, pode usar o se-
guinte comando AT + CWJAP = ””, ”
8. AT + CWMODE = 1 – Define o modo WiFi. Pode ser configurado no modo Station,
AP ou Station/AP. Deve estar sempre configurado para o Modo 1 se o módulo for
usado como um nó.
43
3.1.2.2 NodeMcu (Firmware Lua)
O NodeMcu, é um firmware de código aberto e um kit de desenvolvimento, que fa-
cilita a criação de um protótipo de produto de IoT, com apenas algumas linhas de script
Lua. O lema do NodeMcu é “Conecte ‘coisas’ facilmente”.
É um firmware interativo, baseado em Lua, para o SoC WiFi Esp8266 (modelo
Esp12E). Baseado no projeto eLua e construído sobre o SDK Non-OS da Espressif para
Esp8266. Também é uma placa de hardware de código aberto que, ao contrário dos mó-
dulos Esp8266 WiFi, inclui um chip CP210227 (conversor USB/Serial), para programação e
depuração, se encaixa facilmente nas protoboards padrão e pode, simplesmente, ser ali-
mentada, via sua porta micro USB. O NodeMcu apresenta seis GPIOs extras em relação
ao Esp12E.
Esse kit de desenvolvimento baseado no Esp8266 integra GPIO, pwm, i²C, ADC e
1-wire, tudo em uma placa. As portas GPIO do NodeMcu e suas respectivas funções são
mostradas na Figura 8.
27 O módulo conversor USB TTL CP2102 é utilizado para comunicação entre o computador e dispositivos
como microcontroladores, módulos e outros equipamentos que utilizam comunicação via interface serial.
Figura 8: Descrição dos pinos do NodeMcuFonte: (VEIGA, 2017)
44
Algumas de suas principais características :
▪ Open-source
▪ Interativo
▪ Programável
▪ Barato
▪ Simples
▪ Inteligente
▪ WiFi
Dentre todas essas características interessantes, há três que se destacam:
i. Arduino like programming – É possível programar como se programa um Ardui-
no, mas, interativamente usando scripts em Lua. Através da IDE Esplorer, que será
vista mais a frente, é possível enviar para o NodeMcu scripts em Lua e até mesmo
comandos AT. É possível também depurar código através do monitor de porta serial
dentro da IDE.
ii. Node.js style network API – O modelo de programação é similar ao Node.js28, só
que em linguagem Lua. É um modelo assíncrono e orientado a eventos. Muitas
funções, portanto, possuem parâmetros para funções callback29, permitindo associ-
ar funções de callback a eventos. Esses eventos podem ser gerados por timers por
exemplo. Também é possível associar callbacks a funções de comunicação MQTT
e HTTP. Diferente de outros modelos, como no Arduino em que existe uma função
principal que fica em loop infinito, na programação em Lua no NodeMcu não 30 exis-
te o looping principal, como dito acima é uma programação assíncrona não bloque-
ante.
iii. Lowest cost WiFi – Custo muito baixo, em torno de US$ 5,00.
28 Node.js é uma plataforma construída sobre o motor JavaScript do Google Chrome. Node.js usa um mo-
delo de I/O direcionada a evento não bloqueante que o torna leve e eficiente, ideal para aplicações em
tempo real com troca intensa de dados através de dispositivos distribuídos.29 Uma função callback é um pedaço de código que é passado como parâmetro para alguma outra função.
É esperado que o método execute o código do argumento em algum momento.30 É possível usar um loop infinito no NodeMcu porém não é recomendado. Essa prática poderia causar
mal funcionamento, devido ao seu próprio modelo assíncrono.
45
Existem muitos módulos de software disponíveis para o NodeMcu, por isso, não há
mais um firmware padrão para download. É possível customizar um firmware com os mó-
dulos necessários para o projeto e assim fazer o upload31 do firmware para o dispositivo.
Alguns dos módulos (bibliotecas) disponíveis podem ser vistos na Figura 9.
É possível destacar alguns dos módulos dessa lista e suas respectivas funções.
• ADC – Serve para trabalhar como conversões AD/DA,
• DHT – Torna fácil trabalhar com a família de sensores de umidade e temperatura
DHT11 e DHT22.
• PWM – Um módulo para trabalhar com sinais do tipo PWM.
• MQTT – Para trabalhar com o protocolo MQTT.
• HTTP – Trabalha com serviços HTTP.
• UART – Comunicação serial.
31 O APÊNDICE A contém uma explicação detalhada do processo de customização do firmware e também
do processo de upload.
Figura 9: Lista de módulos disponíveis para o firmware LuaFonte: (NODEMCU-BUILD, 2017)
46
3.1.2.3 Linguagem Lua
A linguagem Lua foi projetada, implementada e desenvolvida no Brasil. Criada na
PUC-RJ. Os seus criadores são: Roberto Ierusalimschy, Waldemar Celes e Luiz Henrique
Figueiredo. Lua é um software de exportação sendo usado em vários projetos por todo o
mundo.
Lua é, hoje, amplamente usada em todas as áreas que podem se beneficiar deuma linguagem de script simples, extensível, portável e eficiente, como sistemasembarcados, dispositivos móveis e, é claro, jogos. (IERUSALIMSCHY, 2015, pag.V)
O objetivo principal de Lua é de se integrar a linguagens como C/C++. Lua não
busca fazer o que outras linguagens como C já fazem muito bem, como computação de
alto desempenho, interagir direto com o hardware e etc. O que Lua vem a oferecer são
coisas mais complicadas de fazer em C. Lua se mantém distante do hardware, possui es-
truturas dinâmicas, ausência de redundâncias e facilidade para teste e depuração. Lua,
como toda boa linguagem de script tem um ambiente seguro, ou seja, não é possível
acessar serviços não autorizados pelo programa hospedeiro (pelo programa onde ela está
acoplada), também tem gerenciamento automático de memória, facilidades na manipula-
ção de cadeias de caracteres e outros tipos de estruturas com tamanho dinâmico.
Um dos pontos mais fortes de Lua é a ideia de oferecer meta-mecanismos para im-
plementar recursos, em vez de fornecê-los já prontos na linguagem. Apesar de Lua não
ser uma linguagem puramente orientada a objetos, ela permite que se implemente clas-
ses e herança. Com esse conceito a linguagem permanece pequena e permite o uso de
vários paradigmas de programação como: programação procedural; programação orienta-
da a objetos; programação funcional; programação orientada a dados e descrição de da-
dos. Sua tipagem dinâmica possibilita um alto grau de polimorfismo.
Lua é rápida e tem uma reputação merecida de desempenho. “Benchmarks32 inde-
pendentes mostram-na como uma das mais rápidas linguagens de script”. (IERUSALIMS-
CHY, 2015, pag. V)
32 Padrão, ou um conjunto de padrões, usado como ponto de referência para avaliar o desempenho ou o
nível de qualidade.
47
Ela, executa bytecodes33 em uma “máquina virtual, baseada em registradores”34e
possui gerenciamento automático de memória. É possível dividir os usuários de Lua em
três grandes grupos: os que a utilizam embarcada em uma aplicação, os que a utilizam de
maneira autossuficiente, e aqueles que a utilizam combinado com C. Lua é usada em vá-
rias aplicações industriais:
• Adobe Lightroom (Um milhão de linhas de código Lua)
• Sistemas embarcados
◦ Middleware Ginga (programas para Tv digital)
◦ Roteadores (Cisco)
◦ Impressoras (Oliveti)
◦ Dispositivos M2M (Sierra wireless)
• Jogos – World of Warcraft e Angry Birds e muitos outros
• Nmap (linguagem de script embutida na aplicação)
• VLC media player
Lua é uma linguagem simples e pequena. A distribuição completa da linguagem,
isto é, código-fonte, manual, e mais os binários, cabe em um disquete. Ela é capaz de ro-
dar em todos os tipos de Unix e Windows, e na maioria das plataformas existentes como
Symbian, Nintendo DS, PSP, PS3 (PPE e SPE), Android, iOS, IBM z/OS e outros. Tam-
bém roda em microprocessadores embarcados como Arm e Rabbit. Pode-se estender fa-
cilmente programas em Lua usando funções escritas em C e também é possível estender
outras aplicações usando código Lua.
É software livre de código aberto, distribuída sob uma licença muito liberal conheci-
da como licença MIT. A licença MIT foi criada pelo Instituto de Tecnologia de Massachu-
setts (MIT). Ela é uma licença permissiva utilizada tanto em software livre quanto em
software proprietário. A licença é permissiva e seu texto é bem mais explícito ao tratar dos
direitos que estão sendo transferidos, afirmando que qualquer pessoa que obtém uma có-
pia do software e seus arquivos de documentação associados pode lidar com eles sem
33 É um estágio intermediário entre o código-fonte (escrito numa linguagem de programação específica) e
a aplicação final, sendo sua vantagem a dualidade entre a portabilidade e a ausência de pré-processa-
mento típico dos compiladores.34 É uma implementação de máquina virtual em que a estrutura, onde os operandos são armazenados, é
baseada em registradores.
48
restrição, incluindo sem limitação, os direitos a usar, copiar, modificar, mesclar, publicar,
distribuir, vender cópias do software. As condições impostas para tanto são apenas man-
ter o aviso de copyright e uma cópia da licença em todas as cópias do software. Por isso,
Lua pode ser usada para quaisquer propósitos, incluindo propósitos comerciais, sem qual-
quer custo ou burocracia. Basta fazer o download e usá-la.
Como dito anteriormente, Lua é um produto de exportação e tem importância glo-
bal. É a única linguagem de programação de impacto desenvolvida fora do primeiro mun-
do. Tem uma grande importância nas áreas de desenvolvimento de jogos, sistemas em-
barcados e IoT. O Gráfico 3.1 mostra um ranking das linguagens de script mais usadas no
desenvolvimento de jogos.
3.1.2.3.1 eLua (Embedded Lua)
Como foi falado no capítulo 3.1.2.2, o NodeMcu roda uma versão de eLua (Embed-
ded Lua). Ela é uma implementação completa da linguagem Lua para sistemas embarca-
dos e adiciona recursos específicos a estes ambientes, trazendo um nível de portabilidade
sem precedentes ao mundo do software embarcado. eLua segue o mesmo princípio mini-
Gráfico 3.1: Linguagens de script mais usadas em jogos Fonte: (DELOURA, 2009)
49
malista e funcional de Lua, alinhada com a filosofia KISS, Keep It Small and Simple (man-
tenha-o pequeno e simples).
Alguns aspectos sobre eLua:
• eLua roda sobre o “bare-metal”35. Não existe um sistema operacional entre os
programas e o microcontrolador. Embora ela ofereça algumas características de
um SO, como diferentes tipos de sistema de arquivos, um shell de comandos e
etc.
• Como em Lua um programa roda em uma variedade de plataformas e arquitetu-
ras.
• eLua não é um conjunto limitado de Lua com o intuito de caber no ambiente
embarcado. Ao contrário disso, ela oferece as mesmas características que o
ambiente Lua para desktop, mas o complementa com características específi-
cas de uso em sistemas embarcados e ao mesmo tempo descarta a necessida-
de de ter um sistema operacional rodando nos microcontroladores.
• Oferece diferentes “sabores” de uma implementação completa de Lua, pode-se
escolher uma versão de implementação que só trabalha com números inteiros
ou com números em ponto flutuante. Há um esforço muito grande em tornar
Lua mais “embedded-friendly” ampliando recursos que permitam um menor
consumo de memória e uma melhor performance.
• eLua não é uma aplicação para um sistema operacional ou para um microcon-
trolador específico. eLua é independente e suporta uma grande quantidade de
microcontroladores.
• eLua não é um software comercial, ela usa a mesma licença que Lua, a licença
MIT.
eLua traz consigo a oportunidade de programar microcontroladores com recursos
encontrados somente em grandes e caros frameworks de desenvolvimento.
• Tipagem dinâmica
• Multitarefa colaborativa ou multitarefa não preemptiva
• Múltiplos modelos de gerenciamento de memória
• Funções de primeira classe
35 A expressão “Bare Metal” (metal nu ou metal puro, em inglês) serve para descrever ambientes de TI em
que o sistema operacional é instalado diretamente no hardware, em vez de uma camada de sistema
hospedando diversas máquinas virtuais, como é realizado em ambientes virtualizados.
50
3.1.3 Raspberry Pi
Um Raspberry Pi é um computador do tamanho aproximado de um cartão de crédi-
to, originalmente projetado para a educação, inspirado pelo BBC Micro36 de 1981. O obje-
tivo de seu criador, Eben Upton, era criar um dispositivo de baixo custo que melhorasse
as habilidades de programação e compreensão de hardware para alunos do nível pré-uni -
versitário. Mas graças ao seu pequeno tamanho e preço acessível, foi rapidamente adota-
do por desenvolvedores e entusiastas da eletrônica para projetos que necessitavam mais
que um simples microcontrolador (tal como Arduino).
Apesar de ser mais lento que um desktop ou um notebook ele é um computador
completo. É capaz de rodar vários sistemas operacionais. Existem diversas distribuições
Linux pra ele como Raspbian, Pidora e Arch Linux. Ele pode funcionar como um servidor
web ou um servidor FTP e etc. O grande diferencial do Pi está no seu custo e no seu pro-
cessamento que consome pouquíssima energia.
Segundo Upton e Halfacree (2014, p. 15), o hardware do Raspberry Pi é aberto,
com exceção do chip principal, o SoC (System on a Chip) Broadcom BCM2835. Esse
chip é responsável pelas principais funções da placa: CPU, gráficos, memória, controlador
de USB, etc.
36 BBC Microcomputer System é uma série de microcomputadores e periféricos construídos pela Acom
Computers Ltd para o BBC Computer Literacy Project (Um projeto de educação por computador).
Figura 10: Raspberry Pi - Model BFonte: (UPTON e HALFACREE, 2014)
51
Muitos dos projetos feitos com o Raspberry Pi também estão abertos e bem docu-
mentados podendo ser reconstruídos e modificados. O sistema escolhido para rodar no
Raspberry Pi foi o GNU/Linux. Já existem várias distribuições otimizadas pra rodar nele.
Há diversos modelos de Raspberry Pi, variando em capacidade de memória e re-
cursos de processamento, também há diferenças na parte física de acesso aos pinos
GPIO.
São estes os modelos disponíveis hoje:
• Raspberry Pi 3 model B
• Raspberry Pi 2 model B
• Raspberry Pi 1 model B e B+
• Raspberry Pi 1 model A e A+
• Raspberry Pi ZERO W
• Raspberry Pi ZERO
O modelo usado neste trabalho é o Raspberry Pi 1 model B (Figura 10). Uma ca-
racterística poderosa do Raspberry Pi são seus pinos de GPIO que ficam junto à lateral
da placa, próximo ao plug amarelo de saída de vídeo.
Estes pinos (Figura 11) são a interface entre o Pi e o mundo exterior. São entradas
e saídas digitais. É possível ler seus estados, ligado e desligado (entrada) ou através de
software ligar e desligar pinos (saída). Dos 26 pinos, 17 são de propósito geral (entradas
ou saídas), os outros são pinos de tensão (VCC) e pinos de referência 0V (ground). A Fi-
gura 12 mostra as duas nomenclaturas dos pinos que podem ser escolhidas para traba-
lhar dentro do programa. GPIO.BOARD, adota a numeração que está indicada dentro dos
círculos. GPIO.BCM (Broadcom SOC channel), adota a numeração indicada dentro dos
retângulos. O Raspberry Pi é ideal para conectar e controlar dispositivos físicos sobre a
Internet.
Figura 11: Raspberry Pi 1 model B - Pinos de GPIOFonte: (CHAUHAN, 2017)
52
Não é o objetivo deste trabalho usar o Raspberry Pi como dispositivo que controla-
rá os atuadores e ler os sensores, porém é o objetivo citar maneiras de se fazer IoT usan-
do software e hardware de código aberto. Então, abaixo, pode-se ver um exemplo de
como acender um led usando o Raspberry Pi.
Ignorando o Raspberry Pi por um momento, pode ser construído um circuito sim-
ples. Uma bateria é ligada a uma fonte de luz e uma chave (o resistor, no circuito (Figura
13), está ali para limitar a corrente elétrica e proteger o led).
Quando um pino de GPIO é usado como saída, o Raspberry Pi substitui a bateria e
a chave no diagrama acima. Cada pino pode ligar ou desligar, ou ir a nível lógico alto ou
baixo (em termos computacionais). Quando o pino está em nível alto ele passa a ter um
potencial de 3.3 volts; quando ele está em nível lógico baixo ele fica com um potencial de
Figura 12: Nomenclatura dos pinos GPIO - BOARD e BCMFonte: (HAWKINS, 2018)
Figura 13: Circuito de exemploFonte: (O autor, 2018)
53
zero volt. A próxima imagem mostra o mesmo circuito montado no Raspberry Pi. Esquema
da Figura 14 foi criado com o software Fritzing37.
O próximo passo é escrever um programa que faça este controle do pino de saída,
que faça o pino ir para o nível lógico alto ou baixo. A linguagem que será usada neste
exemplo é a linguagem Python, que já vem instalada no Raspbian.
O Código 1, quando executado, faz com que o led acenda e apague em intervalos
de 1s. A linha 1 do código importa o módulo RPI.GPIO e cria uma “Alias” 38 para que seja
possível se referir ao módulo apenas com o nome de GPIO, este dá acesso às portas
GPIO sendo possível setar as suas propriedades. A linha 2 importa o módulo que possibi-
lita trabalhar com o tempo no Python, dar uma pausa de 1s por exemplo. A linha 4 selecio-
na o modo como a GPIO será referenciada, neste caso escolhendo o modo BCM, já cita-
do anteriormente. A linha 5 define que o pino rotulado como 24 será um pino de saída.
Uma questão prática importante, pode ocorrer na interrupção do código, quando se
utiliza o barramento GPIO, neste caso específico, acendendo e apagando o led. O progra-
ma, pode sofrer uma interrupção de três maneiras: a primeira é que ele faça o que foi pro-
posto e encerre naturalmente; a segunda é que o usuário force o encerramento através
das teclas “control + c”; a terceira maneira, é que ocorra algum erro e o programa termine
abruptamente. Nos casos 2 e 3 é possível que a GPIO usada fique no seu estado corren-
te, fique “presa”, ou melhor fique “em uso”. Nessa condição, se o programa for executado
novamente, é possível que apareça a seguinte mensagem: “RuntimeWarning: This chan-
37 Fritzing – É um software de design para automação e eletrônica direcionado a designers, artistas e todo
aquele que tem interesse em computação física e prototipagem.38 Apelido.
Figura 14: Esquema do Raspberry PIFonte: (O autor, 2018)
54
nel is already in use, continue anyway”. A maneira correta de prevenir este erro é proteger
o laço principal através de um bloco try/except/finally, como mostrado no código.
A linha 7 dá início ao bloco try. A linha 9 define um laço infinito, fazendo com que o
led pisque por um tempo indeterminado. A linha 10 é apenas um comentário. A linha 11
coloca o pino 24 com nível lógico alto (1). A linha 12 faz com que o programa pause por
1s. A linha 13 tem outro comentário. A linha 14 leva o pino 24 para nível lógico baixo (0). A
linha 15 espera por mais 1s reiniciando o laço novamente. Se houver qualquer tipo de in-
terrupção, qualquer tipo de exceção, essa exceção será capturada e a execução será di -
recionada para a linha 19, logo após o comando except. A partir daí a linha 19 imprime o
texto que está entre aspas e o programa segue a executar o que está depois do finally (li-
nha 21), executando então, na linha 23, a função GPIO.cleanup() que é responsável por
“limpar” as portas que foram usadas, configuradas no código.
Código 1: Controlando o led com o Raspberry Pi usando Python
55
Há duas maneiras erradas de tentar evitar essa situação, uma delas é chamar a
função GPIO.cleanup() no início do código. Isso não funciona pois a função limpa as con-
figurações de entrada e saída (dos pinos) que foram feitas no código, o que não surte
qualquer efeito nos pinos que estão “presos”, pois foram configurados anteriormente, no
código que foi interrompido. A segunda maneira, apelidada de “chicken’s way out”39, é
chamar a função GPIO.setwarnings(False) no início do código. Ela desabilita os avisos
(advertências), o que esconde o problema mas não o resolve. O jeito correto e seguro de
tratar o problema é como explicado acima, usando o tratamento de exceções.
3.1.4 ThingSpeak (Uma plataforma open source para IoT)
“ThingSpeak é uma plataforma de serviço de IoT analítica que permite coletar, visu-
alizar e analisar fluxos de dados ao vivo na nuvem”. (MATHWORKS, 2018). É possível
enviar dados para o ThingSpeak a partir de dispositivos, criar visualizações instantâneas
de dados ao vivo e enviar alertas usando serviços da web como Twitter e Twilio40. Com o
MATLAB analytics dentro do ThingSpeak, pode-se escrever e executar o código MATLAB
para realizar pré-processamento, visualizações e análises. O ThingSpeak permite que en-
genheiros e cientistas criem protótipos e sistemas IoT sem configurar servidores ou de-
senvolver software para Web. As principais capacidades do ThingSpeak incluem:
• Configuração dos dispositivos para enviar dados para o ThingSpeak usando uma
API REST41 ou MQTT.
• Coleta de dados a partir de dispositivos e fontes de terceiros.
• Obtenção de visualizações instantâneas de dados de sensores ao vivo ou históri-
cos de dados coletados.
• Pré-processamento e análise de dados coletados utilizando o MATLAB integrado.
• Execução de análises IoT automaticamente com base em horários ou eventos.
39 O jeito amedrontado, assustado de se fazer algo.40 O Twilio é uma plataforma de comunicações em nuvem para chamadas telefônicas e mensagens SMS.41 Representational State Transfer (REST), em português, Transferência de Estado Representacional, é
um estilo de arquitetura que define um conjunto de restrições e propriedades baseados em HTTP.
56
• Atualização de dados e de comunicação usando serviços de terceiros como Twilio
ou Twitter.
A Internet das Coisas fornece acesso a uma ampla gama de dispositivos integrados
e serviços Web. ThingSpeak é uma plataforma IoT que permite coletar, armazenar, anali -
sar, visualizar e atuar em dados de sensores ou atuadores, como Arduino, Raspberry Pi,
BeagleBone Black e outros equipamentos. Por exemplo, com o ThingSpeak, é possível
criar aplicativos de log de sensores, aplicativos de localização e uma rede social de coisas
com atualizações de status, para que se possa ter o um termostato doméstico com con-
trole próprio com base em sua localização atual.
O elemento principal da atividade ThingSpeak é o canal, que contém campos de
dados, campos de localização e um campo de status. Depois de criar um canal ThingSpe-
ak, você pode gravar dados no canal, processar e visualizar os dados com o código MA-
TLAB e reagir aos dados com tweets e outros alertas. O fluxo de trabalho típico ThingSpe-
ak permite:
1. Criar um canal e colete dados
2. Analisar e visualizar os dados
3. Atualizar os dados usando qualquer um dos vários aplicativos
3.1.4.1 Coleta de dados
Sensores ou coisas, detectam dados e tipicamente atuam localmente. O ThingSpe-
ak permite que sensores, instrumentos e sites enviem dados para a nuvem onde ele está
armazenado em um canal privado ou público. Por padrão, o ThingSpeak armazena dados
em canais privados, porém, os canais públicos podem ser usados para compartilhar da-
dos com outros usuários. Uma vez que os dados estão em um canal ThingSpeak, pode-
se analisá-lo e visualizá-lo, calcular novos dados ou interagir com redes sociais, serviços
da Web e outros dispositivos.
57
3.1.4.2 Análise dos dados
É possível analisar e visualizar dados com o MATLAB. Armazenar dados na nuvem
fornece acesso fácil aos dados coletados. Usando ferramentas analíticas on-line, pode-se
explorar e visualizar dados, descobrir relacionamentos, padrões e tendências. Calculando
novos dados, visualizando-os em gráficos, tabelas e medidores, como mostra o gráfico
3.2. Mais detalhes práticos sobre o uso do ThingSpeak, como taxa de amostragem e con-
tas de usuário, serão vistos na seção 3.2.1.
O ThingSpeak fornece acesso ao MATLAB a fim de ajudar a entender os dados.
Sendo possível:
• Converter, combinar e calcular novos dados.
• Programar cálculos para executar em determinados horários.
• Compreender visualmente os relacionamentos em dados usando funções de traça-
do integradas.
• Combinar dados de múltiplos canais para construir uma análise mais sofisticada.
Gráfico 3.2: Plotando gráficos usando o MATLABFonte: (MATHWORKS, 2018)
58
3.1.4.3 Associe uma ação (Trigger an action)
Atuar sobre os dados pode ser algo tão simples como receber um tweet quando a
temperatura que está sendo medida vai acima de 70°C. Também é possível configurar
uma ação mais complexa, como ligar um motor quando o nível da água em um tanque de
água cair abaixo de um especificado limite. Pode-se controlar dispositivos de controle re -
moto, como bloqueios de portas operados por bateria, usando o aplicativo TalkBack.
ThingSpeak fornece ferramentas que permitem a comunicação do dispositivo a to-
das essas ações e muito mais. Permitindo:
• Reagir aos dados – dados brutos e novos dados, que são calculados quando eles
entram em um canal.
• Enfileirar comandos para que um dispositivo os execute.
O ThingSpeak oferece todas as ferramentas necessárias para a implementação de
uma Casa Inteligente, sendo possível por exemplo, monitorar a temperatura do ambiente
e ao mesmo tempo controlar o funcionamento do refrigerador de ar. Também se pode
controlar dispositivos através de palavras-chave em tweets ou até mesmo “tweetar” uma
informação importante coletada de um sensor. Pode-se automatizar acões e tarefas base-
adas em tempo usando aplicativo TimeControl42. Tudo isso via web, através do computa-
dor, tablet ou do smartphone.
3.1.5 Node-RED
O Node-RED é uma poderosa ferramenta de programação para Internet das coi-
sas. Ela é baseada na conexão de componentes gráficos, que na verdade são blocos de
códigos que podem enviar, processar e receber informações de diversas fontes e se co-
municar usando diversos tipos de protocolos. Esses blocos de códigos são conhecidos
como nodes. A conexão destes nodes gera fluxos (flows) de informação. Os nodes podem
ser definidos como nodes de entrada (input-nodes), nodes de processamento (function-
42 Permite executar uma ação em um horário específico ou em horários periódicos previamente agenda-
dos.
59
nodes) e nodes de saída (output-nodes). “Originalmente desenvolvida como um projeto de
código aberto na IBM no final de 2013, para suprir a necessidade de rapidamente conec-
tar hardware e dispositivos a serviços web e outros softwares, como uma espécie de ‘cola’
para IoT.” (LEA, 2016)
O Node-RED é uma ferramenta baseada em fluxos que possui um editor que pode
ser acessado eu um navegador web. É muito simples conectar esses fluxos de informa-
ção, encadeando entradas e saídas, processando e transformando os dados através des-
se fluxos. Existe uma grande quantidade de nodes na paleta de opções. Após conectar
esses nodes é possível executar a aplicação com só um clique.
Estas são suas características principais:
• Editor de fluxos baseado em navegador – Basta um navegador web para começar
a conectar o nodes e criar fluxos.
• Construído em Node.js – Aproveitando ao máximo o modelo de I/O direcionada a
evento não bloqueante. O Node-RED é ideal para rodar em hardwares de baixo
custo tais como Raspberry Pi e também na nuvem.
• Fácil compartilhamento – Os fluxos criados em Node-RED são armazenados usan-
do JSON43 e podem ser importados e exportados com facilidade permitindo o com-
partilhamento com outras pessoas.
Com o Node-RED rodando, pode-se ter acesso a seu editor através de um navega-
dor web no endereço http://localhost:1880. É possível também acessar o editor usando
um outro navegador web em outra máquina, se for conhecido o endereço ip da máquina
em que está rodando o Node-RED.
O processo de construção de uma aplicação no Node-RED é feito através de fluxos
(flows) que contém nodes (nós).
A Figura 15 mostra alguns do nodes que estão disponíveis na instalação padrão do
Node-RED, com exceção dos nodes da aba Raspberry Pi que somente estão disponíveis
quando o Node-RED é instalado em um Raspberry Pi. Estes nodes são: input-nodes, out-
put-nodes, function-nodes, dashboard-nodes, social-nodes, network-nodes e raspberry pi-
nodes.
Input-nodes – Estes nodes desencadeiam o início de um fluxo que cria o pacote
inicial de informação. Normalmente esses nodes são conectados a um evento externo
43 JSON (JavaScript Object Notation – Notação de objetos JavaScript) – É uma formatação leve de troca
de dados. Para seres humanos, é fácil de ler e escrever. Para máquinas, é fácil de interpretar e gerar.
60
como uma requisição HTTP, uma mensagem MQTT, a chegada de uma informação na
porta serial e até mesmo um botão. É possível identificar esses nodes pois eles têm ape-
nas um ponto de conexão no lado direito, o conector de saída, isto é, não têm ponto de
conexão de entrada. Sendo assim não é possível conectar dois input-nodes.
Output-nodes – Enviam informação para o meio externo à aplicação. É possível
identificá-los pela ausência do conector de saída do lado direito. Com eles é possível en-
viar uma informação para um MQTT broker, um byte pela porta serial, tocar um arquivo de
áudio e etc.
Function-nodes – Sua função é o processamento do pacote de informação recebi-
do, estes nodes têm ambos conexão de entrada e conexão de saída. Ao receber uma
mensagem na entrada, ele processa a informação (executa uma função) e com isso é ca-
paz de modificá-la e enviá-la por sua conexão de saída.
Raspberry Pi-nodes – Estes nodes são específicos para o uso com o Node-RED
rodando dentro do Raspberry, eles já vêm instalados por padrão nesse caso. Com estes
nodes é possível interagir com o Raspberry e com seus pinos de GPIO.
Dashboards-nodes – A criação da interface com o usuário fica fácil com o uso
destes nodes. São botões, caixas de texto, switches, date picker e objetos para a exibição
de gráficos tipo linha e também gauges.
Social-nodes – Torna possível o enviar e receber e-mails e também a interação
com o Twitter.
Storage-nodes – Permite a interação com arquivos do sistema hospedeiro. É pos-
sível ler o conteúdo de um arquivo, seja ele um String ou buffer binário. Pode-se também
gravar o conteúdo de msg.payload para um arquivo.
Network-nodes – Dentro dessa categoria existe o node chamado ping que possibi-
lita enviar um ping para um endereço ip e receber como retorno o tempo de resposta em
ms, este valor vem dentro do objeto msg.payload.
O pacote de informação que “flui” através dos nodes é um simples objeto JavaS-
cript que se chama msg. Este objeto pode ser estendido por outros nodes sendo possível
adicionar, modificar e remover propriedades dinamicamente. Algumas propriedades mere-
cem um destaque especial:
61
Figura 15: Node-RED - NodesFonte: (O autor, 2018)
62
• payload – Esta é a propriedade mais importante, é através dela que os dados são
transferidos de um node para o outro. Este atributo será sempre lido pelo node que
recebe o pacote de informação e poderá atuar sobre estes dados. O atributo Pay-
load pode vir a ser de um dos seguintes tipos: Object, Date, Boolean, String ou
Number.
• topic – Essa propriedade é do tipo String e é usada para dar uma descrição amigá-
vel do que se está fazendo com o objeto msg. Pode ser utíl quando para depurar
uma mensagem.
• _msgid – É uma propriedade que contém um identificador único que é dado à
mensagem. Este é muito útil no processo de depuração.
Pode-se ver o simples código de um objeto msg (Código 2) com suas propriedades mais
importantes.
Usando o mesmo esquema da Figura 14 onde é possível ver um led conectado a
um pino de GPIO do Raspberry PI e admitindo ter instalado o Node-RED no mesmo, será
mostrado a seguir um exemplo de um flow no Node-RED que torna possível acender e
apagar o led através do node inject e também fazer, através de um twitt, com que o led
acenda por 2s e logo após apague. Esse exemplo faz uso dos nodes inject (input-node),
rpi-gpio out (output-node), trigger (function-node) e do twitter-in (social-node). A Figura 16
mostra o arranjo e as conexões dos nodes.
Esse pequeno arranjo de nodes permite que através de uma conta do Twitter, devi-
damente configurada no node twitter-in (Figura 17), ao se twittar a palavra ledcasa o led
acenda e após 2s apague. O funcionamento básico do arranjo é o seguinte, ao ser twitta-
da a palavra-chave ledcasa o node twitter-in identifica a palavra e gera um evento de saí-
da que alimenta a entrada do node do tipo trigger, esse node, ao receber o evento, envia
para sua saída o valor 1 que é enviado para o rpi-gpio out que então envia o sinal de ligar
o led para a GPIO do Raspberry PI. O trigger está configurado para que após 2s, sem re-
ceber nenhuma entrada, envie um valor 0 para o rpi-gpio out que então apaga o led.
Código 2: Código do objeto msgFonte: (O autor, 2018)
63
A outra ideia que esse arranjo aborda é a possibilidade de acender e apagar o led
usando um node que funciona em tempo de projeto. Esse caso serve para exemplificar o
uso do input-node inject, que permite ao ser clicado, enviar um sinal por sua conexão de
saída.
Nesse caso existem dois nodes deste tipo, o primeiro está configurado para enviar
o valor numérico 1 ao ser pressionado e o segundo o valor numérico 0. Com isso é possí-
vel mudar o estado do pino de GPIO para 1 (ligado – primeiro inject) ou para 0 (desligado
– segundo inject).
É necessário também que o node rpi-gpio out seja configurado para trabalhar com
pino de GPIO correto, como mostra a Figura 18. Foi selecionado o pino 18 que equivale à
GPIO 24, a mesma utilizada no código em python que aparece na Código 1.
Figura 16: Flow - Controlando o led através do TwitterFonte: (O autor, 2018)
64
É importante ressaltar que há uma infinidade de nodes disponíveis e o processo de
instalação é bem simples.
Figura 17: Node twitter-in - ConfiguraçãoFonte: (O autor, 2018)
Figura 18: Configuração - rpi-gpio outFonte: (O autor, 2018)
65
3.2 ARQUITETURAS
Neste capítulo e no próximo, serão apresentadas as arquiteturas para IoT propos-
tas neste trabalho. Cada qual com seus componentes de hardware e software, fazendo
uso de tudo que foi apresentado e descrito nos capítulos anteriores.
3.2.1 Arduino com shield ethernet
A primeira arquitetura tem como componentes de hardware o Arduino, o shield de
ethernet W5100 (Figura 19) e o sensor de temperatura LM35. Os componentes de softwa-
re utilizados são a IDE do Arduino usando a linguagem C++ e em termos de interface web
será utilizada a plataforma ThingSpeak.
Um esquema é montado com o objetivo de ler a temperatura através do sensor
LM35, pegar essa informação e enviá-la para Internet usando o W5100. O shield será co-
nectado a um roteador através de um cabo de rede padrão RJ-45. O ThingSpeak recebe-
rá essa informação através de um canal devidamente configurado e plotará um gráfico da
temperatura em função do tempo. A Figura 21 mostra o esquema eletrônico.
Figura 19: Ethernet Shield W5100Fonte: (THOMSEN, 2014)
66
O sensor LM35 (Figura 20) é um sensor de precisão, funciona de maneira linear e
proporcional à temperatura. A sua saída apresenta 10mV para cada grau Celsius.
O LM35 pode funcionar de dois modos. O primeiro modo, que será usado nesta ar-
quitetura, é indicado na Figura 22 e o segundo modo na Figura 23.
Figura 21: Esquema eletrônico - Arduino/Ethernet/LM35Fonte: (O autor, 2018)
Figura 20: Sensor LM35Fonte: (MOTA, 2017)
67
O ThingSpeak é uma aplicação para IoT e uma API para enviar e receber dados de
“coisas” usando HTTP sobre a Internet ou via rede local. É possível usar esta plataforma
de duas maneiras: a primeira é pelo site www.thingspeak.com, que tem alguma limitação
para contas gratuitas44 (é preciso criar uma conta) mas é o suficiente para esta arquitetu-
ra, a segunda maneira é baixar o código fonte45 e instalar num servidor local. Instalando a
partir do fonte, não há limitação de taxa de atualização dos dados.
44 Um usuário gratuito pode atualizar um canal ThingSpeak a cada 15 segundos. Uma atualização com
maior frequência resulta em erro. Para alterar as configurações a fim de atender a requisitos de frequên -
cias mais altas é preciso fazer o download do código fonte do GitHub e instalar o ThingSpeak.45 https://github.com/iobridge/thingspeak
Figura 22: LM35 - Modo 1Fonte: (MOTA, 2017)
Figura 23: LM35 - Modo 2Fonte: (MOTA, 2017)
68
O elemento principal da atividade no ThingSpeak é o canal. Este canal contém
campos de dados, de localização e um campo de status. É preciso criar um canal (Figura
24) no ThingSpeak e logo após já será possível gravar dados nele, processar estes da-
dos, visualizá-los com código MATLAB e reagir a eles com tweets e outros alertas.
O nível de acesso a um canal pode ser de três tipos: privado (onde só você pode
visualizar os dados), público (onde qualquer um pode ter acesso) e compartilhado com
uma lista de usuários determinados. É preciso configurar o canal ThingSpeak (Figura 25),
definir o nome do campo de dados field1, que neste caso se chamará “temperatura” e
anotar o channel ID que será usado dentro do código do Arduino.
Uma outra informação é necessária para que seja possível enviar dados para o ca-
nal, a Write API key (Figura 26). Essa chave permite que dados sejam enviados para o
canal específicado através do channel ID. Há também a Read API key que permite ter ac-
cesso às informações de um canal.
A maneira de enviar um dado para o canal é através de uma requisição HTTP. Ela
deve seguir o seguinte padrão:
GET https://api.thingspeak.com/update?api_key=RBAYI4C7T5VXHQTT&field1=0
Figura 24: Criando um canal no ThingSpeakFonte: (MATHWORKS, 2018)
69
Para usar o ThingSpeak de maneira mais fácil no Arduino é preciso fazer a instala-
ção da biblioteca ThingSpeak dentro da IDE do Arduino. Para isso, deve-se ir até o menu
Sketch > Incluir Biblioteca > Gerenciar Bibliotecas, selecionar a biblioteca ThingSpeak e
clicar em instalar (Figura 27).
Figura 25: Configuração do canal ThingSpeakFonte: (MATHWORKS, 2018)
Figura 26: Channel ID e Write API KeyFonte: (MATHWORKS, 2018)
70
O Código 3 do Arduino, nas linhas 11, 12 e 13, importa as bibliotecas necessárias
para o uso do ThingSpeak e do shield de ethernet.
As próximas linhas (Código 4) definem algumas variáveis de escopo global. Na li-
nha 16 um vetor de bytes é criado, este vetor é a definição de um endereço MAC para o
shield de ethernet. A linha 17 cria um objeto do tipo EthernetClient. Na linha 18 é criada a
variável que é inicializada com o channel ID, neste caso com o valor 269034. Na linha se-
guinte é criado um ponteiro para uma string que contém a Write API key. E finalmente na
linha 20 uma constante é definida, essa constante é inicializada com o número da porta
Figura 27: Instalando a biblioteca ThingSpeak na IDE do ArduinoFonte: (O autor, 2018)
Código 3: Importação das bibliotecas para o ThingSpeak
Código 4: Configuração do canal ThingSpeak
71
analógica do Arduino, que está ligada à saída do sensor de temperatura. Como foi dito no
capítulo 3.1.1 existem duas funções que devem ser obrigatoriamente definidas quando
programando para o Arduino, são elas: setup() e loop().
O bloco da função setup() (Código 5) vai da linha 22 à linha 26. Esse espaço é utili-
zado para inicializar e configurar alguns objetos e componentes do hardware do Arduino.
Na linha 23 é definida a velocidade de transmissão da porta serial do Arduino, essa porta
é muitas vezes usada como uma forma de depurar os programas na IDE do Arduino, tudo
que é enviado para essa porta pode ser visualizado através do monitor serial da IDE. Na
linha 24 ocorre a inicialização do shield de ethernet passando como parâmetro o número
do endereço MAC. Na linha 25 o objeto ThingSpeak é inicializado tendo como parâmetro
o objeto cliente.
A função loop() (Código 6), como o nome já sugere, fica em loop infinito. Nesse
ponto é que o código faz a leitura do sensor e envia para o canal. Na linha 29 a variável
recebe o valor da leitura da porta analógica, este valor pode variar de 0 até 1023, já que a
resolução do conversor AD do Arduino é de 10 bits. A tensão de referência para a conver-
são AD é de 5V, sendo assim cada unidade de leitura na porta analógica equivalerá a
4,8mV. Na linha 31 é feito o cálculo da quantidade de milivolts obtida no sensor. A linha 33
chega no valor da temperatura em graus Celsius, sabendo que cada 10mV equivalem a 1
ºC. A linha 34 imprime no monitor serial o valor da temperatura (apenas para verificação
local). Na linha 35 o método writeField do objeto ThingSpeak envia o valor da temperatura
para o canal, ele recebe como parâmetros o número do canal (channel ID), o número do
campo (neste caso o field1), o valor da temperatura, e a Write API key. Na linha 36 o co-
mando delay faz com que o Arduino pause por um determinado tempo, o parâmetro que a
função delay recebe é um valor em milissegundos. Neste caso, 1800000ms equivalem a
30 minutos. Este tempo é o intervalo entre os envios da informação para o canal ThingS-
peak.
Código 5: ThingSpeak - Inicialização
72
O Gráfico 3.3 mostra o gráfico da temperatura plotado no site do ThingSpeak. Fo-
ram 12 horas de coleta de dados com intervalos de 30 min.
Gráfico 3.3: Gráfico da temperatura - LM35 - ThingSpeakFonte: (MATHWORKS, 2018)
3.2.2 Arduino com WiFi via Esp8266 (comandos AT)
Nesta arquitetura a conexão com fio é abandonada e o módulo Esp8266 traz para
o Arduino a capacidade de se comunicar com a rede via WiFi. Com isso, existe agora a
facilidade na instalação de diversos dispositivos no ambiente, o que seria muito mais com-
plicado e caro na conexão com cabo. O módulo Esp8266 passa a funcionar como um shi-
Código 6: Loop principal para leitura do sensor e publicação no ThingSpeak
73
eld sem fio para o Arduino. Através de comandos AT o Arduino será capaz de conectar a
um ponto de acesso e assim enviar os dados coletados para o canal ThingSpeak.
Os componentes de hardware para esta arquitetura são: Arduino Uno, Esp8266
(com firmware AT), sensor de temperatura e umidade DHT11 e mais três resistores. Os
componentes de software são: IDE Arduino usando C++, comandos AT enviados para o
Esp8266 e a interface web do ThingSpeak. Neste caso, será criado um novo canal no
ThingSpeak com dois campos de dados (field1 e field2), temperatura e umidade respecti-
vamente. Esse procedimento já foi detalhado na seção 3.2.1.
O sensor usado nesta arquitetura é o DHT11. Um sensor digital de temperatura e
umidade com16 bits de resolução. A faixa de temperatura é de 0ºC a 50ºC e a faixa de
umidade é de 20% a 90%. Uma característica importante deste sensor é que ele só traba-
lha com valores inteiros, uma limitação importante para alguns projetos de maior precisão.
A Figura 28 mostra duas imagens do DHT11. Suas conexões são: Vcc, Gnd e Out.
O esquema eletrônico da arquitetura pode ser visto na Figura 29. Nela estão os
componentes de hardware.
O Esp8266 é alimentado pela saída de 5 V do Arduino, que pode ser conectada na
entrada Vin do Esp8266. Há um problema de compatibilidade entre as tensões de traba-
lho do Arduino Uno e do Esp8266. Portanto, é preciso ter cuidado ao conectar a saída se-
rial do Arduino (TX) para a entrada serial do Esp8266 (RX). A TX do Arduino Uno trabalha
com tensão de 5V enquanto o Esp8266 (TX e RX) trabalha com 3.3V. Por isso, a saída TX
do Arduino precisa ser ligada a um divisor de tensão para que haja a compatibilidade.
Este divisor pode ser montado usando três resistores de mesma resistência. É possível
Figura 28: Sensor DHT11 e seus pinosFonte: (ARDUINO&CIA, 2013)
74
ver na Figura 29 que a entrada RX do Esp8266 vem do divisor de tensão, que neste pon-
to, tem a tensão no valor de 2/3 de 5 V que é aproximadamente 3,3 V.
Existem alguns pontos importantes para que esta arquitetura venha a funcionar
perfeitamente.
• O Esp8266 deve estar com o firmware AT instalado
• A velocidade de comunicação do módulo Esp8266 deve ser a mesma da interface
software serial46 do Arduino, e esta pode não funcionar muito bem com velocidades
muito altas
• É preciso instalar a biblioteca DHT na IDE do Arduino da mesma maneira como a
biblioteca do ThingSpeak foi instalada (Figura 27)
Normalmente o Esp8266 já vem com o firmware AT. No Apêndice A, existe uma ex-
plicação detalhada de como fazer o upload do firmware para o Esp8266. Geralmente, o
firmware vem de fábrica configurado para a velocidade de 115200 bauds47. No Arduino a
46 A biblioteca SoftwareSerial torna possível a comunicação serial através de outros pinos digitais do Ardui-
no, e usa software para emular uma porta serial por hardware.47 Unidade de velocidade de transmissão igual ao número de vezes que um sinal muda de estado por se-
gundo. Um baud é equivalente a um bit por segundo.
Figura 29: Esquema eletrônico - Arduino / DHT11 / Esp8266 (AT)Fonte: (O autor, 2018)
75
interface software serial pode não funcionar bem nessa velocidade, sendo assim, seria
ideal baixar a velocidade do Esp8266. Esta arquitetura usa a velocidade de 9600 bauds
para a comunicação serial por software e por hardware.
O código do Arduino (Código 7) só pode ser compilado após a instalação da biblio-
teca DHT. O código começa importando as bibliotecas e definindo o pino 4 como sendo a
entrada digital que será ligada ao sensor, define também o tipo do DHT, já que a biblioteca
pode trabalhar com os modelos DHT11 e DHT22. São definidos também os pinos digitais
que serão usados pela interface software serial para emular uma porta serial por software,
pino 2 RX (recepção) e pino 3 TX (transmissão). Por último é configurado o intervalo de
tempo (1h) em que as informações serão enviadas para o ThingSpeak.
Das linhas 23 à 29 (Código 8) são criadas variáveis do tipo string que serão usadas
como parâmetros em outras funções, na linha 31 é criado um objeto do tipo “Software Se-
rial” que recebe os pinos RX e TX como parâmetros.
Nas linhas 34 e 36 (Código 9), respectivamente, é feita a configuração da porta se-
rial (por hardware), que será usada para mostrar (no monitor serial) os comandos AT que
estão sendo enviados para o Esp8266 e suas devidas respostas, também é feita configu-
ração da outra porta serial (por software), que efetivamente se comunicará com o módulo
WiFi.
Código 7: Definição dos pinos do DHT11
76
Nas linhas 38, 39 e 41 a função envia_Comando é usada para enviar uma sequên-
cia de comandos AT para o Esp8266, o primeiro comando AT apenas manda o comando
“AT” e espera receber um OK como resposta, logo após, o comando “AT+CWMODE=1” é
enviado, esse comando configura o Esp8266 para o modo station permitindo assim ao
Esp8266 se conectar a um ponto de acesso. O comando seguinte, da linha 41, envia o
comando “AT+CWJAP=” concatenado com as variáveis ssid e senha, esperando um OK
como resposta. O OK vai indicar que a conexão ao ponto de acesso foi um sucesso. Após
a concatenação, a saída do comando fica assim: AT+CWJAP="August
Rush","7036c0014f".
Dentro da função loop() (Código 10) são definidas as variáveis umidade e tempera-
tura e são do tipo float. A linha 47 faz a leitura do sensor usando a função le_Sensor que
coloca o resultado da leitura nas variáveis umidade e temperatura. Na linha 48 é criada a
string que é a requisição HTTP, citada na primeira arquitetura, que é usada para enviar
uma informação para o canal ThingSpeak. Após a concatenação, a variável string_get
contém a seguinte string:
Código 8: Configuração do acesso à rede, host e campos do canal ThingSpeak
Código 9: Configuração da velocidade das portas seriais
77
GET /update?api_key=OVKABCP4PXA85AEG&field1=27.00&field2=64.00
Esta requisição HTTP será enviada ao canal ThingSpeak contendo a Write API key,
os dois campos (field1 e field2) e seus respectivos valores.
Da linha 50 à 54 são executados quatro comandos AT da camada TCP/IP (Tabela
3). O comando “AT+CIPMUX=1” habilita múltiplas conexões, o comando “AT+CIPSTART”
estabelece uma conexão TCP, seus parâmetros são: tipo, endereço do host, porta. Estas
informações são concatenadas ao comando e são envidas ao Esp8266.
O comando seguinte é o “AT+CIPSEND”, que define o tamanho da informação (em
bytes) que será enviada para o host. Este comando recebe apenas um parâmetro, a
quantidades de bytes.
No caso da linha 52 a quantidade de bytes é igual ao número de caracteres de
string_get + 4, estes quatro bytes a mais são por conta dos caracteres \r\n que são auto-
maticamente acrescentados após o conteúdo de string_get no comando seguinte, o
esp8266.println(string_get). Para encerrar o envio o comando “AT+CIPCLOSE=0” fecha a
conexão. O último comando é o delay que é responsável pelo intervalo nos envios da in -
formação para o ThingSpeak.
A função le_Sensor (Código 11) é bem simples, ela recebe como parâmetros dois
ponteiros para variáveis do tipo float (passagem por referência). Dentro da função, estes
ponteiros recebem os valores da umidade e da temperatura do sensor DHT11, que resul-
tam das funções readHumidity() e readTemperature() da biblioteca DHT.
Código 10: Envio dos dados lidos do sensor DHT11 para o ThingSpeak
78
A função envia_Comando (Código 12) tem três parâmetros, o primeiro é
comando_at que é a string com o comando a ser enviado para o Esp8266. O segundo é a
variável inteira tempo_limite que é o número de tentativas de envio do comando, ela serve
como um “tempo limite” para a tentativa de enviar o comando e é baseada nas repetições
do loop de envio. O terceiro parâmetro é um ponteiro para um vetor de caracteres que
passa a string da resposta esperada. Na maioria dos casos essa string é um OK. Essa
função tem como destaque as linhas 68, 69 e 70 que imprimem os comandos no monitor
serial a fim de visualizar as respostas dos comandos. A linha 73 também merece um des-
taque. O método esp8266.find(resposta_esperada) efetua uma busca no buffer de entra-
da da porta serial associada ao Esp8266. Ele busca a string resposta_esperada, caso en-
Código 11: Função que faz a leitura do sensor DHT11
Código 12: Função que envia os comandos AT para o Esp8266
79
contre, retorna o valor booleano true. Todo comando AT enviado para o Esp8266 tem uma
resposta de retorno que pode ser avaliada.
A Figura 30, mostra um exemplo de conexão bem-sucedida e também do sucesso
do envio da informação para o ThingSpeak no monitor serial da IDE do Arduino.
No Gráfico 3.4, é possível ver os gráficos da temperatura e umidade, mostrados no
site ThingSpeak.
Gráfico 3.4: Gráficos de temperatura e umidade - ThingSpeak (Comandos AT)Fonte: (MATHWORKS, 2018)
Figura 30: Monitor serial - Comandos ATFonte: (O autor, 2018)
80
3.2.3 Esp8266 (programando o firmware com a IDE do Arduino)
Nesta arquitetura o Arduino passa a não ser mais necessário. A partir de agora será
possível ver que o Esp8266 pode vir a ser muito mais do que um shield WiFi para o Ardui-
no. As características dessa placa já foram mostradas na seção 3.1.2. Pode-se desenvol-
ver um sistema bem completo apenas com Esp8266. Ele é capaz de se comunicar via
porta serial, fazer leituras de sensores analógicos, se conectar a um ponto de acesso via
WiFi (modo station) e até mesmo funcionar como um ponto de acesso (modo access po-
int).
A IDE do Arduino foi criada para servir à família de placas Arduino, mas com o pas-
sar do tempo, ela foi se adaptando e hoje é capaz de funcionar com outras placas e ou-
tras famílias de microcontroladores. Com isso, hoje é possível usar a IDE do Arduino para
programar o Esp8266, mas antes, é necessário configurar a IDE.
O primeiro passo é ir na IDE do Arduino, no menu Arquivo->Preferências e entrar
com a seguinte url no campo URLs adicionais (Figura 31) para gerenciadores de placas:
http://arduino.esp8266.com/stable/package_esp8266com_index.json
Figura 31: Configurando o Esp8266 na IDE do ArduinoFonte: (O autor, 2018)
81
Após entrar com a url é só clicar em ok. Este procedimento fará com que a IDE te-
nha a opção de trabalhar com o Esp8266.
O segundo passo é ir no menu Ferramentas->Placa->Gerenciador de Placas (Figu-
ra 32), selecionar a placa Esp8266 (Figura 33) e clicar em instalar.
Figura 32: Instalando a placa Esp8266 na IDE do ArduinoFonte: (O autor, 2018)
Figura 33: Selecionando a placa Esp8266Fonte: (O autor, 2018)
82
A partir de agora, a placa Esp8266 fará parte da lista de opções de placas. O ter-
ceiro passo é selecionar o modelo correto do Esp8266. A opção usada nesta arquitetura é
a NodeMcu 1.0 (ESP-12E Module) e pode ser vista na Figura 34. Os parâmetros de confi-
guração da placa como Flash Size, CPU Frequency e os restantes permanecerão com os
valores padrão exceto o parâmetro Porta.
O quarto e último passo (Figura 35) é selecionar a porta em que Esp8266 aparece
no sistema. É importante lembrar que todas as arquiteturas estão sendo implementadas
usando GNU/Linux.
A Figura 36 mostra o esquema eletrônico da arquitetura. Ela é alimentada por uma
fonte de corrente contínua de 5V. O Esp8266 trabalha com tensão de 3.3V nos seus pi-
nos, essa tensão pode ser insuficiente para alimentar o sensor DHT11, no datasheet do
sensor diz que sua tensão de alimentação de ser de 3.5V à 5.5V, por isso o circuito será
alimentado por uma fonte externa de 5V.
O Esp8266 possui uma entrada chamada Vin que permite que ele seja alimentado
por uma tensão de 5V sem que ele sofra qualquer dano. Ele possui um regulador interno
de 3.3V. A saída do sinal do DHT11 opera em 5V e não pode ser conectada na entrada di -
gital do Esp8266, logo, será usado o mesmo divisor de tensão especificado na Seção
Figura 34: Selecionado o modelo do Esp8266 corretoFonte: (O autor, 2018)
83
3.2.2. A entrada para o pino D0 do Esp8266 vem do divisor de tensão, e já vem com a
tensão compatível com o Esp8266.
O trecho inicial do Código 13 começa com o processo de importar as bibliotecas
necessárias para a aplicação, as bibliotecas das linhas 11 e 12 já foram vistas anterior-
mente. Na linha 13 será usada pela primeira vez a biblioteca ESP8266WiFI, essa bibliote-
ca traz para aplicação os recursos de conexão WiFi do Esp8266.
Das linhas 15 à 19 há o procedimento padrão de definição e inicialização de variá-
veis como numero_canal, ssid, senha, host e etc. Na linha 21 há um ponto importante, a
definição dos pinos do Esp8266, quando programando na IDE do Arduino, usa uma no-
menclatura diferente da que vem serigrafada na placa do Esp8266.
Figura 35: Selecionado a porta do Esp8266Fonte: (O autor, 2018)
84
A Tabela 4 mostra essa relação. Dentro do código (na IDE) a referência adotada é
o número das GPIO (coluna ESP8266 pin) enquanto na placa a referência é a coluna IO
index. Sendo assim, a definição do PINO_DHT como 5 na linha 21 (Código 13) se refere à
Código 13: Importando a biblioteca WiFI para o Esp8266
Figura 36: Esquema eletrônico - Esp8266/DHT11 - Programando em C++Fonte: (O autor, 2018)
85
GPIO5 que equivale ao pino 1 (D1) impresso na placa Esp8266. Na linha 25 é criado um
objeto WiFiClient.
O Código 14 contém a função setup() que como já é conhecida, ele faz a maior
parte das inicializações do hardware interno da placa. A linha 28 define a velocidade da
porta serial, a linha 30 inicializa o objeto dht, as linhas 29 e 31 usam um delay de 10ms
apenas para dar um tempo para que as configurações sejam terminadas pelo hardware
da placa, afinal toda operação tem um custo de tempo, mesmo que seja muito pequeno.
Na linha 32 o objeto ThingSpeak é inicializado e tem como parâmetro o objeto cli -
ente (WiFiClient). A linha 33 tenta se conectar à rede WiFi, o bloco while (das linhas 36 à
39) fica verificando, num intervalo de 0,5 s, o valor de retorno da função WiFi.status(), se
não conectou, um ponto é impresso no monitor serial e um novo teste será feito até que a
conexão tenha sucesso.
O próximo fragmento de código, o da função loop() (Código 15), faz a leitura do
sensor atribuindo os valores lidos às devidas variáveis. O bloco if que vai das linhas 47 à
50 testa a integridade dos valores retornados na leitura do sensor, a função isnan ( is not a
number) retorna 1 se o valor contido na variável testada não for um número, caso não
seja um número, o loop reinicia e é feita outra leitura. Sendo um sucesso a leitura do sen-
sor é hora de enviar estes dados para o site. Aqui aparecem duas novas funcões (méto-
dos) do objeto ThingSpeak.
Tabela 4: Relação das GPIO com os pinos do Esp8266Fonte: (NODEMCU, 2018)
86
Na Seção 3.2.1 foi usada a função ThingSpeak.writeField() que enviava apenas um
campo para o canal ThingSpeak, esta arquitetura precisa que dois campos sejam envia-
dos. A maneira correta de proceder neste caso é usando a função ThingSpeak.setField(),
que tem como parâmetros o número do campo e o valor a ser enviado. Ela faz uma asso-
ciação entre campo e valor.
A outra função é a ThingSpeak.writeFields(), com os parâmetros numéricos do ca-
nal e a api de escrita. Ela é capaz de enviar de uma só vez, os campos definidos anterior-
mente.
Após a execução destas funções os valores de umidade e temperatura são mostra-
dos no monitor serial para averiguação, na linha 62 é encerrada a conexão do cliente com
o servidor e define-se um intervalo de 60 s até a próxima leitura e envio de dados.
Código 14: Configurando e conectando ao WiFi
87
Pode-se ver o gráfico da temperatura e umidade (Gráfico 3.5) gerados pelo ThingS-
peak. Os dados foram coletados com intervalos de 60 s apenas para demonstralção da
arquitetura.
Gráfico 3.5: Leitura do DHT - Esp8266 programado em C++Fonte: (MATHWORKS, 2018)
Código 15: Função loop() - Leitura do sensor e envio dos dados para o T. Speak
88
3.2.4 NodeMcu + ThingSpeak (usando Lua)
A partir de agora, as duas últimas arquiteturas passam a usar o kit de desenvolvi-
mento NodeMcu, que vem a ser um Esp8266 rodando o firmware Lua. Para seguir nesta
configuração é necessário gravar o firmware Lua no Esp8266, esse processo é descrito
com detalhes no Apêndice A. Toda programação será feita usando a linguagem Lua com o
auxílio da IDE Esplorer, o Apêndice B descreve as funcionalidades da IDE. O esquema
eletrônico é o mesmo da Figura 36.
O código desta arquitetura será composto por cinco arquivos:
• init.lua
• crendeciais.lua
• tabelas.lua
• conecta_wifi.lua
• thingspeak_http.lua
Estes arquivos podem ser chamados de módulos. A aplicação poderia ser escrita
em apenas um arquivo, mas, a modularização será importante para mostrar alguns deta-
lhes da programação Lua. O NodeMc ao iniciar, procura por um arquivo que se chama
init.lua. Se ele for encontrado será então executado, se ele não existir, o NodeMcu exibirá
o prompt de linha de comando e ficará aguardando que algo seja digitado. É através do
init.lua que a aplicação pode ser executada automaticamente. O objetivo do init.lua é dar
o start na aplicação principal.
O Código 16 mostra a pequena quantidade de linhas do init.lua. Ele imprime no ter-
minal a mensagem dizendo que a aplicação será iniciada em 3 segundos, na linha 5, a
função delay do objeto tmr, que recebe como parâmetro o tempo em microsegundos, pau-
sa o NodeMcu por 3 segundos. A função tmr.delay() é muito semelhante à função delay
da biblioteca Arduino, só que seu uso no ambiente Lua é desencorajado, pois essa função
pára completamente o funcionamento do NodeMcu e como já foi visto, o firmware Lua é
assíncrono e baseado em eventos, portanto, a função tmr.delay() bloqueia o NodeMcu
prejudicando a sua resposta assíncrona aos eventos. Essa função só é usada no init.lua
por dois motivos: o primeiro é que a aplicação principal ainda não está em execução, en-
tão, não há problema nesse pequeno bloqueio, o segundo motivo é que essa pausa de 3
89
segundos permite que o arquivo init.lua seja removido através do comando no prompt fi -
le.remove(“init.lua”), caso haja a necessidade de reprogramar o NodeMcu. Na prática isso
significa que, se não houver essa pequena pausa, o init.lua iniciará e rapidamente chama-
rá a aplicação principal. Assim, não será mais possível se conectar ao NodeMcu a fim de
programá-lo, somente será possível acessá-lo se o firmware for regravado e com a opção
“yes, wipes all data” selecionada (ver ilustração na Figura 71), o que apagará completa-
mente a memória flash e com isso o init.lua.
A linha 7 executa o comando dofile(“conecta_wifi”) que executa o módulo
conecta_wifi. A função dofile() também funciona como um comando de importação, seme-
lhante à diretiva include da linguagem C++. Se o módulo tiver apenas declarações de vari-
áveis, de funções, de estruturas de dados, o dofile() chama o módulo e todas essas variá -
veis e funções passam a estar disponíveis. Agora, se o módulo for uma sequência de co-
mandos, então esses comandos serão executados por dofile().
O próximo o módulo (Código 17) se chama credenciais.lua. Ele tem uma tabela (li-
nha 3) e nas linhas 4 e 5 são criados dois índices para essa tabela e seus respectivos va -
lores associados. O indíce ssid e o pwd representam o ssid da rede e sua senha. Tabelas
em Lua são arrays associativos implementados eficientemente como uma combinação de
array e hash (tabela de dispersão) e podem ter qualquer valor como índice menos nil
(sem valor em Lua), podem haver inclusive índices negativos. Esse módulo será importa-
do mais em frente e o uso da tabela ficará mais claro.
O módulo tabelas.lua (Código 18) é semelhante ao módulo anterior, sua função é
apenas criar tabelas que serão usadas em outros módulos. São criadas três tabelas, uma
com os modos do WiFi, outra com os estados da conexão WiFi e a terceira com os moti-
vos de erros com o MQTT broker. O código mostra que, em Lua, há mais de uma maneira
de criar uma tabela e declarar seus índices e valores associados. É importante destacar a
presença de índices negativos (linhas 21 à 25), uma característica da linguagem Lua.
Código 16: Excutando automaticamente com init.lua
90
O Código 19, referente ao módulo de nome conecta_wifi.lua é chamado pelo módu-
lo init.lua. O seu início importa os já conhecidos módulos tabela.lua e crendenciais.lua. A
linha 7 coloca o WiFi no modo station, o que significa que o NodeMcu será capaz de se
Código 18: Módulo tabela.lua
Código 17: Módulo credenciais.lua
91
conectar a um ponto de acesso. A linha 8 configura o ssid e senha passando como parâ-
metro a tabela config que foi criada dentro do módulo credenciais.lua. A linha 12 usa o ob-
jeto tmr (timer), o mesmo que foi usado no módulo init.lua, só que agora ele é usado de
uma maneira bem interessante.
O NoceMcu possui 7 timers numerados de 0 à 6. Eles podem funcionar de três mo-
dos:
• tmr.ALARM_SINGLE – Que dispara apenas uma vez e não necessita da função
tmr.unregister().
• tmr.ALARM_SEMI – Que dispara uma vez mas pode ser reiniciada pela função
tmr.start().
• tmr.ALARM_AUTO – Que repete automaticamente.
Para programar os timers usa-se a função tmr.alarm() e ela recebe os parâmetros
id (de 0 à 6), intervalo em milisegundos, modo, func(). O id é o número do timer utilizado,
o intervalo de tempo é o tempo em que o timer vai esperar para disparar, o modo é um
dos três citados anteriormente, e a função é uma função que será executada pelo timer no
intervalo determinado. Para o timer, pode ser passada uma função (com nome) definida
em alguma parte do módulo ou pode ser usada uma função anônima que é definida den-
tro do parâmentro função de tmr.alarm().
Na linha 12 (Código 19) pode-se ver que o timer utilizado é o 2 e está configurado
assim: intervalo de tempo de 1 segundo, modo automático (tmr.ALARM_AUTO) e que re-
cebe uma função anônima para ser executada periodicamente.
O bloco dessa função vai da linha 13 à 26. Na linha 13 verifica-se se a placa tem
um IP, se esse valor for nil então será impresso no monitor serial o estado do WiFI (base-
ado na tabela estado_wifi) e a funcão será reiniciada no segundo seguinte. Mas, se o No-
deMcu tiver um IP válido a função então imprimirá o estado da rede (conectado), o ende-
reço de IP e o MAC adress do NodeMcu. Na linha 23 o timer é desativado e o seu id fica
liberado para a programação de outro timer. Na linha 24 o módulo principal é então carre-
gado e executado.
As linhas de 9 à 12 (Código 20) declaram variáveis já conhecidas de arquite-
turas anteriores e cujo os nomes são autoexplicativos. A linha 15 faz uma primeira leitura
do sensor que retorna um tupla e as variáveis recebem os valores na devida ordem.
Na linha 41 (Código 21) o timer 1 é registrado para funcionar em intervalos de 15
segundos no modo de repetição automática e como corpo de sua função anônima ele
92
executa a linha 43, que chama a função postThingSpeak(), que será explicada mais em
frente, e na linha 44 chama a função le_DHT11() que faz mais uma leitura do sensor. O ti -
mer será disparado novamente nos próximos 15 segundos até que a aplicação seja inter-
rompida.
A linha 17 do Código 22 declara a função. Na linha 18 um objeto cliente HTTP é cri-
ado, na linha 19 é definida uma função callback para o evento receive do cliente. Assim
que o cliente receber alguma informação o corpo da função callback será executado. A
função recebe dois parâmetros, o primeiro é o próprio objeto cliente e o segundo é uma
string que guardará a resposta enviada pelo servidor. Dentro do corpo da callback a string
com a resposta é varrida (função string.find) em busca de uma indicação de sucesso da
parte do servidor, a string buscada é “Status: 200 OK” que indica o sucesso na resposta
do servidor. Em caso de sucesso uma mensagem de OK é impressa no monitor serial,
caso contrário nada ocorre.
Código 19: Módulo conecta_wifi.lua
93
Na linha 26 uma nova função callback é definida, desta vez para o evento connecti-
on que é disparado quando o cliente se conecta ao servidor. Essa função tem o mesmo
formato da anterior, ou seja, recebe primeiro o objeto cliente e depois uma string que ar-
mazena a resposta do servidor. Essa string é opcional, como não há interesse na string
de resposta, ela não será utilizada.
Na linha 29, o método send do objeto cliente envia a string com a requisição HTTP
contendo: a api de escrita, temperatura e umidade no formato adequado. Isso já foi mos-
trado anteriormente. A concatenação de strings em Lua é feita usando .. (dois pontos se-
guidos).
Por último, ainda dentro da função postThingSpeak(), o método connect do objeto
cliente é chamado tendo como parâmetros a porta padrão para serviços HTTP (porta 80)
e a string api.thingspeak.com. A partir desse comando um evento connection ocorre, o cli-
ente então responde ao evento enviando a requisição HTTP.
O servidor responde e um outro evento ocorre, só que desta vez é um evento recei-
ve. Então, o cliente responde a este evento executando o código que verifica o conteúdo
da resposta. E assim, o código vai executando indefinidamente em intervalos de 15 se-
gundos.
Código 20: Módulo thingspeak_http.lua - Declarando variáveis
94
Código 22: Postando no ThingSpeak - Cliente HTTP
Código 21: Configurando o timer para o envio de dados
95
4 IMPLEMENTANDO UMA CASA INTELIGENTE
O projeto da casa inteligente é a implementação da quinta arquitetura. Ela faz uso
de praticamente tudo que foi visto nas arquiteturas anteriores. Apesar de usar muitas das
tecnologias já apresentadas até o momento, esta arquitetura acrescenta novos compo-
nentes de hardware e de software.
Componentes de hardware adicionados:
• LED
• PIR48 – Sensor de movimento
• DHT22 – Sensor de temperatura e umidade
• Sensor ultrassônico
Componentes de software adicionais:
• Protocolo MQTT
• Servidor HTTP
• Servidor Telnet
Nas arquiteturas anteriores, durante a interação com o ThingSpeak, a comunicação
era basicamente unidirecional, ou seja, a informação era enviada do Arduino ou Esp8266
para o site. Em nenhum momento o ThingSpeak controlou os dispositivos, não que isso
não pudesse ser feito, mas esse não era o foco deste trabalho. A aplicação da casa inteli-
gente implementa uma interação bidirecional. O hardware continua coletando dados do
ambiente e enviando para o servidor, mas, a aplicação que está no servidor passa a ter o
controle sobre dispositivos.
A proposta desta arquitetura é implementar um software de controle que é capaz
de ser acessado remotamente a partir de um computador, celular ou tablet. Essa aplica-
ção vai interagir com uma rede de nós NodeMcu instalados pelos cômodos de uma casa.
48 Sensor infravermelho passivo.
96
Cada NodeMcu terá suas funções bem definidas de acordo com o ambiente em que ele
se encontrar.
Na Figura 37 é possível ver o cenário da casa inteligente. Através da imagem pode-
se ter uma ideia do esquema de posicionamento dos nós NodeMcu. São ao todo seis, um
para cada parte da casa, cada qual com seus sensores e funções. Essa rede (WiFI) de
nós NodeMcu se conecta ao roteador. Um Raspberry Pi que está conectado à rede local
através do mesmo roteador é usado como servidor. Os serviços fornecidos por ele podem
ser acessados através das portas 1880 (serviço do Node-Red) e 1883 (Mosquitto/MQTT
broker).
Figura 37: Casa Inteligente - CenárioFonte: (O autor, 2018)
97
4.1 PREPARANDO A INFRAESTRUTURA DA REDE
Para que a aplicação seja acessível de fora da rede local, via web, é necessário al-
gumas configurações no modem, no roteador e também usar de um serviço de DNS49 di-
nâmico. Neste cenário são usados o Modem SAGEMCOM F@st 5310 (Tim Live), o rotea-
dor sem fio TP-LINK modelo TL-WR1043ND e como serviço de DNS dinâmico, o site
www.noip.com, que é gratuito. É preciso então, configurar o modem para o modo bridge50.
Sem estar nesse modo, o modem da Tim Live bloqueia o acesso externo a todas as por -
tas, por mais que elas estejam abertas localmente. A forma mais fácil de fazer a configura-
ção para o modo bridge, é ir no site da Tim Live, baixar o arquivo do firmware já configura-
do e fazer o upload para o modem. Após essa mudança, deve-se conectar o roteador TP-
LINK ao modem. A partir desse ponto, é preciso fazer alguns ajustes importantes no rote-
ador.
Primeiro, deve-se definir um endereço de ip estático (Figura 38) para o servidor
Raspberry PI. Segundo, é preciso expor esse endereço de ip à Internet. No TP-LINK, isso
é feito ativando a função DMZ (Figura 39) e entrando com o ip do servidor no campo DMZ
Host IP Adress. O endereço ip do servidor está configurado como 192.168.0.50. Após o
término da configuração, o roteador encaminhará todos os pacotes, de todos os serviços,
para o DMZ host.
Para configurar o serviço de DNS,é necessário criar uma conta na modalidade gra-
tuita no site www.noip.com, escolher o nome do host desejado e fazer uma pequena confi-
guração no roteador. Para isso, é preciso ir no roteador na seção Dynamic DNS (Figura
49 DNS é a sigla em inglês para Domain Name System (Sistema de Nomes e Domínios).50 Um equipamento em modo bridge apenas recebe a informação de um lado e entrega do outro, fazendo
apenas as conversões de padrão necessárias.
Figura 38: Servidor Raspberry Pi - IP estáticoFonte: (O autor, 2018)
98
40), entrar com o endereço do serviço de DNS, nome de usuário e senha (registrados no
site) e o nome do domínio escolhido.
Com essa configuração, o roteador periodicamente envia o seu ip (que pode mudar
a qualquer momento) para o site de DNS. Assim, mesmo que o ip venha a mudar, o nome
do host vai sempre apontar para o ip do roteador. O nome do host usado para acessar a
aplicação no servidor Raspberry Pi é http://tccmrocha.webhop.me:1880/ui/#/0. O noip fun-
ciona muito bem, apesar de ser gratuito. Ele exige apenas que, a cada 30 dias, o nome do
host seja confirmado no site deles.
Após esse processo inicial de configuração, tem-se o servidor Raspberry Pi confi-
gurado com o ip fixo, seus serviços expostos à Internet através da opção DMZ host, e o
nome de host apontando para o ip do roteador.
Figura 40: Configurando o DNS dinâmico no roteadorFonte: (O autor, 2018)
Figura 39: Configurando o DMZFonte: (O autor, 2018)
99
4.2 OS ESQUEMAS ELETRÔNICOS DOS NÓS NODEMCU
Há seis nós NodeMcu na casa, e de acordo com suas funções e recursos eles po-
dem ser separados em três tipos (Figura 41). Os nós NodeMcu do tipo 1 (quatro ao todo),
estão instalados no quarto, na cozinha, na garagem e no banheiro. Eles podem detectar
movimento e controlar a iluminação. O do tipo 2, fica instalado na cisterna e usa um sen-
sor ultrassônico. Sua função é monitorar o nível de água da cisterna. O do tipo 3, fica ins-
talado na sala. Ele pode detectar movimento, medir a temperatura e a umidade ambiente,
pode ligar e desligar o ar-condicionado, ligar e desligar o umidificador de ar e pode contro-
lar a iluminação.
A Figura 42 mostra o esquema eletrônico dos nós NodeMcu do tipo 1. Como é
mostrado, um sensor PIR e um led vermelho são conectados à placa. O led vermelho re-
presentará o controle da iluminação do ambiente. Há também um led azul, que é interno
ao NodeMcu, e que ao acender, indicará que um movimento foi detectado.
Figura 41: Tipos de nós (NodeMcu) da redeFonte: (O autor, 2018)
100
O esquema eletrônico da Figura 43 é o esquema do NodeMcu do tipo 2. O único
componente ligado a ele é o sensor ultrassônico. Este NodeMcu fica instalado dentro da
cisterna e sua função é detectar o nível de água.
Figura 42: Esquema eletrônico do NodeMcu - Tipo 1Fonte: (O autor, 2018)
Figura 43: Esquema eletrônico do NodeMcu - Tipo 2Fonte: (O autor, 2018)
101
A Figura 44 mostra o esquema eletrônico do NodeMcu do tipo 3. Este é o mais im-
portante da arquitetura, e se encontra instalado na sala da casa inteligente. Ligado a ele,
estão, o sensor PIR, o sensor de temperatura e umidade DHT22, três leds (vermelho, azul
e amarelo), que representarão, respectivamente, os controles da iluminação, do ar-condi-
cionado e do umidificador, e também o led interno da placa, que indicará, que um movi-
mento foi detectado na sala da casa. Todas as arquiteturas anteriores, fizeram uso do
sensor DHT11, que não trabalhava com valores decimais. Nesta quinta arquitetura, será
usado o DHT22, que é capaz de trabalhar com valores em ponto flutuante.
4.3 ANALISANDO O FUNCIONAMENTO DO CÓDIGO-FONTE
A análise do código, será iniciada por um NodeMcu do tipo 2, usado no quarto, ba-
nheiro, garagem e cozinha. O firmware do NodeMcu que fica instalado no quarto é com-
posto de sete arquivos:
• init.lua
Figura 44: Esquema eletrônico do NodeMcu - Tipo 3Fonte: (O autor, 2018)
102
• conecta_wifi_quarto.lua
• credenciais.lua
• tabelas.lua
• firmware_node_quarto.lc
• node_http_server.lc
• node_telnet_server.lc
Esta ideia de modularizar o firmware usando vários arquivos já foi vista na Seção
3.2.4. É possível notar que três arquivos têm uma extensão diferente, a extensão .lc. Essa
extensão indica que o arquivo já foi compilado para o formato de bytecodes. Há dois ar-
quivos extras nesta arquitetura. Ela traz embarcada um servidor HTTP que pode ser aces-
sado através do ip do NodeMcu (na rede local) e que exibe informações como: o ID do
chip, endereço MAC, total de memória, nome do ssid, nome do NodeMcu e etc. Há tam-
bém, rodando no NodeMcu, um servidor Telnet que pode ser acessado via terminal, tor-
nando possível acompanhar o funcionamento do NodeMcu.
Esta arquitetura usa o protocolo MQTT, sendo assim, cada NodeMcu usa uma se-
quência de variáveis que contêm os campos para usar como parâmetros na função que
conecta ao servidor Mosquitto. O Código 23, mostra a declaração desses campos. O pri-
meiro, node_nome é uma string definida arbitrariamente para representar o nome do No-
deMcu, essa string nada tem a ver como o id da placa, que vem gravado de fábrica dentro
do NodeMcu. As variáveis host e porta_mqtt representam o ip do servidor MQTT na rede
local e a porta do serviço, respectivamente. Por padrão, o Mosquitto opera na porta 1883.
A variável mais importante desse trecho de código é a top_base, que representa o tópico
Código 23: Parâmetros de conexão - MQTT broker
103
base em que o node-quarto vai publicar e assinar. Todo nodeMcu da rede tem o seu tópi -
co base.
O próximo trecho (Código 24) configura alguns pinos do NodeMcu. O pino led_pre-
senca, está associado ao estado do sensor PIR. Esse led é interno ao NodeMcu e funcio-
na com lógica inversa, isto é, quando está em nível alto, o led está apagado, quando está
em nível baixo, o led está aceso. Ao acender, o led indica que um movimento foi detecta-
do. Uma outra configuração de pino importante precisa ser citada aqui. Na linha 29, o pino
referenciado como pino_luz, é definido como uma saída do tipo PWM51(Pulse-width mo-
dulation). Este pino está conectado a um led vermelho, ele representa o controle da ilumi-
nação. A configuração para o modo PWM permite que a intensidade do brilho do led seja
controlada, simbolizando assim, um controle total da luz do ambiente. O PWM do NodeM-
cu é de 10 bits, logo, permite valores de 0 à 1023. O valor 0 apaga completamente o led,
o valor 1023 o acende completamente. Os pinos das linhas 27 à 31 funcionam como pi -
nos de saída que enviam um sinal para o meio externo. Na linha 33, pode-se ver um
exemplo de um pino configurado como entrada, este pino lê o sinal do sensor de movi-
mento conectado a ele. Nas linhas 36 e 37, são criadas duas tabelas que implementarão
duas estruturas de dados do tipo fila (FIFO52). Essas duas tabelas (filas) têm um papel im-
portantíssimo no processo de publicação dos tópicos.
O processo de boot dos nós NodeMcu foi programado para seguir a seguinte se-
quência: O init.lua executa, espera por três segundos e chama o arquivo conecta_wifi.lua.
Que por sua vez, tenta conectar ao WiFI. Após obter seu ip na rede, o conecta_wifi.lua
51 Modulação por largura de pulso – É uma técnica para conseguir resultados analógicos usando saídas
digitais.52 First in is first out – O primeiro a entrar é o primeiro a sair.
Código 24: Configurando os pinos do node-quarto
104
chama o arquivo principal, que nesse caso é o firmware_node_quarto.lc. Esse último ar-
quivo conecta ao servidor MQTT e tenta assinar os tópicos definidos no seu código. Após
o sucesso na assinatura dos tópicos, uma função faz o led interno piscar três vezes. O ob-
jetivo dessa simples função é dar uma indicação visual ao usuário de que o dispositivo ini-
ciou corretamente. Sendo assim, se o led piscou três vezes durante a inicialização, signifi-
ca que o NodeMcu se conectou ao WiFi, se conectou a servidor MQTT e assinou os tópi-
cos com sucesso.
É possível compilar um código Lua usando o comando node.compile(“arquivo.lua”).
A IDE Esplorer permite fazer o mesmo através da interface gráfica (Figura 45). O código
compilado tem um tamanho menor. Na memória flash do dispositivo, além do firmware
principal e dos arquivos auxiliares, estão os servidores HTTP e Telnet, exigindo o máximo
do espaço disponível. Portanto, qualquer redução no tamanho do código é bem-vinda.
A próxima função, no Código 25, faz a leitura do pino em que está conectado o
sensor de movimento. Se um movimento foi detectado, essa informação precisa ser publi -
cada em um tópico. Esse tópico é a concatenação do tópico base (do node-quarto) com a
string “/presenca”. Então, o nome do tópico em que será publicada a detecção do movi-
mento será “tccmrocha/quarto/presenca”. A informação a ser publicada será 1 (para movi-
mento detectado) ou 0 (para ausência de movimento). Um ponto importante nesse código,
é que ele analisa o sinal do sensor, define o nome do tópico e o valor a ser publicado,
Figura 45: Compilando código Lua com o auxílio da IDEEsplorer
Fonte: (O autor, 2018)
105
mas não faz a publicação diretamente. A maneira mais estável de se publicar quando há
vários tópicos, é inserir tópico e valor em duas tabelas (filas), como já foi citado. Toda pu-
blicação feita neste código segue este mesmo princípio, de adicionar a publicação a uma
fila de tópicos e valores. Mais em frente será analisada a função que se encarrega de pro-
cessar essa fila e publicar tópicos e valores periodicamente. Este procedimento é usado
por todas as funções que têm algum tipo de informação a publicar. E isso vale para todos
os nós NodeMcu nesta aplicação.
O processo de se conectar ao servidor MQTT pode ser visto no Código 26. Ele tem
o seu início com a criação do objeto cliente MQTT (linha 101) onde são passados alguns
parâmetros para a função construtora do objeto. O primeiro parâmetro é o clientid, que foi
passado como a variável nodeNome. O segundo, determina o tempo em que a função
callback, associada ao evento offline, vai esperar para iniciar depois que o NoceMcu se
encontrar sem conexão. A linha 103, registra a função callback para o evento offiline do
NodeMcu, ou seja, se a rede cair por algum motivo, o corpo da função anônima, que é
passada como parâmetro, será executado. O código da função imprime uma notificação
no monitor serial, desabilita os timers de id 0, 1 e 2 (que são usados por outras funções) e
Código 25: Lendo o estado do sensor de movimento
106
reprograma o timer 0 para que ele chame a função conecta_servidor em 2s. Essa função
tenta retomar a conexão com o roteador.
Após a criação do objeto cliente, é o momento de se conectar ao servidor MQTT
(Mosquitto) e assinar alguns tópicos. O Código 27 mostra esse processo. É importante
observar, através do layout do código, um nível de indentação bastante grande. Ele serve
pra mostrar a importância da organização visual do código, e que sem essa indentação
organizada, o entendimento do programa se torna quase impossível. Muitas funções têm
como parâmetros funções anônimas, que também usam funções anônimas. E isso pode
bagunçar as coisas.
Código 26: Criando o objeto cliente MQTT
107
A função connect (linha 161) faz uso de quatro parâmetros, o host, a porta MQTT,
uma callback associada ao sucesso na conexão e outra associada ao fracasso. Há um
detalhe importante, só é possível assinar um tópico quando existe uma conexão com o
MQTT broker, por isso, é no corpo da callback associada ao sucesso da conexão que os
tópicos são assinados um a um, sendo que, cada tópico só é assinado após o sucesso na
assinatura do seu antecessor. Esse é o outro motivo do nível de indentação do código, há
um encadeamento de funções. A linha 181 chama a função que pisca o led três vezes e
as linhas 184 e 185 mandam para as tabelas tópico e valor, um comando que faz com que
a interface gráfica da aplicação seja reiniciada. Esse procedimento faz parte da inicializa-
ção da interface gráfica da aplicação web. O Código 28 continua dentro da função que co-
necta ao servidor MQTT. A função registra dois timers (linhas 188 e 197). O timer de id 1
fica encarregado de ler o sensor de movimento periodicamente em intervalos de 300ms.
O timer de id 2 é o responsável por fazer a publicações dos tópicos, que serão feitas em
Código 27: Conectando ao servidor MQTT parte 1
108
intervalos periódicos de 200ms. Da linha 204 à 212, tem-se o fechamento dos blocos de
funções declaradas dentro da função associada ao sucesso da conexão.
A parte 3 do código de conexão ao servidor (Código 29) define o corpo da função
callback chamada no caso de insucesso na conexão. Ela exibe algumas mensagens e
mostra qual foi o motivo do insucesso. Exibe o tipo do erro, fazendo uso dos índices da ta-
bela err_conn declarada no arquivo tabelas.lua, desabilita os timers usados no programa
e por fim, registra um timer que inicia uma nova tentativa de conexão.
O Código 30 trata do recebimento de mensagens do servidor MQTT. São mensa-
gens publicadas nos tópicos assinados anteriormente, durante o processo de conexão ao
servidor. A chegada de uma mensagem é sinalizada através do evento message, e como
quase todas as funções declaradas até agora, ela tem uma função callback que será cha-
mada quando o evento ocorrer. Essa função possui no seu cabeçalho, parâmetros que re-
tornam informação. Os parâmetros topic e data, trazem consigo, o tópico e a informação
contidas na mensagem. A partir daí, o que se faz é verificar tópico e informação a fim de
Código 28: Conectando ao servidor MQTT parte 2
109
reagir de acordo com o programado. É possível ver os tópicos: “top_base/luz”, “top_base/
luz/intensidade”. Os tópicos com a palavra “luz” estão relacionados ao controle dos leds.
O tópico “tccmrocha/all/pergunta” é uma mensagem enviada pela aplicação Node-
RED com o objetivo de saber se os nós NodeMcu estão online. Caso esteja, o nó respon-
de essa mensagem publicando no tópico “tccmrocha/all/resposta/quarto” a string conten-
do o seu número ip concatenado à string “Online”. A resposta fica dessa forma:
192.168.0.3 – Online.
A última função do programa pode ser vista no Código 32. Essa função é responsá-
vel por pegar os itens da fila de tópicos e valores e publicá-los. A função começa verifican-
do se o primeiro item, tanto dos tópicos quanto dos valores, tem o valor nil.
Código 29: Conectando ao servidor MQTT parte 3
110
Um erro de leitura em algum sensor pode ter retornado um valor nil e ele ter sido
enviado para a fila de publicação. Há duas situações que certamente provocarão um pa-
nic no NodeMcu fazendo com que ele reinicie, são elas: tentar publicar um valor nil e ten-
tar concatenar uma string a um valor do tipo nil. Essa situação ocorre geralmente quando
se tenta concatenar uma variável que contém uma string a uma variável a qual não foi
atribuída valor algum. Em Lua, toda variável sem atribuição de valor, possuirá inicialmen-
te, o valor nil. Lua é dinamicamente tipada, ou seja, as variáveis não possuem tipos, os
valores possuem tipo.
Após a verificação da ausência de valor nil na tabela tópico e na tabela valor, o pro -
grama segue chamando o método (publish) do objeto mqtt_cliente que publica a informa-
ção no tópico. Os parâmetros da função publish são: tópico, valor (payload), QoS, retain
Código 30: Recebendo uma mensagem MQTT parte 1
Código 31: Recebendo uma mensagem MQTT parte 2
111
(valor_retido), callback. Os significados dos parâmetros tópico e valor, dispensam comen-
tários. A explicação detalhada sobre os parâmetros QoS e retain pode ser vista nas Se-
ções 2.2.3 e 2.2.4, respectivamente. O último parâmetro é a função callback que é cha-
mada caso a publicação seja bem-sucedida. Após o sucesso no envio da informação, o
programa imprime no monitor serial a mensagem dizendo que está publicando, em segui-
da, remove da fila de tópicos e da fila de valores, as informações já enviadas. A função
publish, após ser chamada, retorna um valor booleano true, em caso de sucesso na publi-
cação, ou false, em caso de fracasso. Esse valor é atribuído à variável pub_status, que é
testada na linha 71. Em caso de pub_status possuir o valor false, será impresso no moni-
tor serial, a mensagem indicando o erro na publicação.
O trecho final do programa é mostrado no Código 33. Ele simplesmente inicia o
servidor HTTP, inicia o servidor Telnet e agenda o início da chamada à função
conecta_servidor, que dá início a todo ciclo de código explicado até aqui.
Os nós NodeMcu do tipo 2 e tipo 3, node-cistena e node-sala, respectivamente, fa-
zem uso da mesma filosofia usada neste tipo 1. Os timers são usados para, periodica-
mente, executar funções de leitura de sensores e também ler a tabela de tópicos e pu -
blicá-los. Esta é uma idéia padrão seguida em todos os firmwares desta aplicação.
Código 32: Publicando mensagens MQTT
112
Para acessar o servidor HTTP (Figura 46) que roda no node-quarto ou em qualquer
outro nó NodeMcu da rede (exceto o node-cisterna) é só entrar o ip do NodeMcu no nave-
gador. O servidor fornece uma página com informações sobre o nó NodeMcu. É possível
ter acesso ao código do servidor HTTP no Apêndice E.
O servidor Telnet espelha as informações enviadas para o monitor serial. Pode-se
ter acesso ao código do servidor Telnet no Apêndice F. Para acessar o servidor (Figura
47) é preciso abrir um terminal e digitar:
telnet <no. do ip do NodeMcu> 2323
Código 33: Iniciando os serviços HTTP e Telnet
Figura 46: Acessando o servidor HTTP do nó NodeMcuFonte: (O autor, 2018)
113
Há uma observação importante sobre o NodeMcu que monitora a cisterna. O calcu-
lo da distância usando o sensor ultrassônico implica em medir intervalos de tempos muito
pequenos, sendo assim, neste NodeMcu não estão disponíveis os servidores HTTP e Tel-
net pois eles comprometiam o resultado dos valores aferidos.
4.4 CONSTRUINDO A APLICAÇÃO MÓVEL COM O NODE-RED
Esta seção trata da aplicação construída no Node-RED. Uma ferramenta poderosa
que permite a criação de interfaces gráficas, a comunicação utilizando diversos protocolos
(HTTP, MQTT), permite a plotagem de gráficos, criação de botões e sliders, comunicação
serial com Arduino, comunicação direta com o Raspberry Pi (quando instalado nele), per-
mite interagir com contas de Twitter, enviar e-mails, tocar áudio, permite a comunicação
com o sistema de arquivos local e permite obter informações sobre clima, usando o node
openweathermap. Há, na verdade, uma infinidade de nodes para aplicações diversas.
Figura 47: Saída do servidor TelnetFonte: (O autor, 2018)
114
Com o Node-RED, é muito fácil assinar e publicar em tópicos no MQTT broker. Há
um componente para cada ação. Uma outra grande vantagem em desenvolver com o
Node-RED, é que a interface gráfica gerada por ele pode ser acessada por um navegador
de Internet, seja na rede local ou via web, e isso tudo, em qualquer dispositivo, seja ele
um Pc, tablet ou celular.
A aplicação pode ser acessada localmente através do endereço
http://192.169.0.50:1880/ui/#/0 ou via Internet com a url
http://tccmrocha.webhop.me:1880/ui/#/0.
Antes de falar sobre a utilização dos componentes do Node-RED, é interessante
mostrar uma imagem da aplicação e falar sobre suas características e recursos. A aplica-
ção é dividida em duas telas. A Figura 48 mostra a primeira tela da aplicação.
Estas telas podem ser acessadas através do menu no canto superior esquerdo da
aplicação (Figura 49).
Figura 48: Interface gráfica da aplicação (Node-RED) - Visão dos controlesFonte: (O autor, 2018)
115
Na imagem que descreve o cenário da aplicação, que é uma casa inteligente (veja
a Figura 37), pode-se ver que seis nós NodeMcu, que são dispositivos WiFi, estão conec-
tados a sensores (de movimento, temperatura, umidade, ultrassom) e a leds. Cada led,
representa o envio de um sinal para o meio externo. Dentro da rede, os nós NodeMcu são
dispositivos inteligentes. Aqui o termo inteligente acompanha a definição dada por BOL-
ZANI:
O termo “inteligente” é utilizado neste trabalho como diferenciador entre o estadomais simples do sistema em questão e o seu estado de valores agregados ou evo-luído. No momento que o dispositivo é construído com a possibilidade de gerir elepróprio ou outros equipamentos acredita-se que o termo “inteligente” possa serempregado sem restrições. Vale ressaltar que o termo tem sido muito utilizado co-mercialmente e com fins publicitários para enaltecer novas funcionalidades deequipamentos, dispositivos, sistemas ou serviços. Porém, na verdade, muitas ve-zes não desempenham efetivamente uma capacidade de aprender, compreender,interpretar ou desenvolver alguma forma de intelecto ou perspicácia como descritonos dicionários. (2004, p. IX)
A aplicação se comunica com a rede de nós NodeMcu, recebendo os dados vindos
dos sensores processando esses dados e enviando comandos de controle para os dispo-
sitivos. Há integração, análise e processamento de eventos, que como foi dito na Seção
2.1, são os três pilares da IoT.
Primeiro serão mostrados os elementos pertencentes à tela 1 (menu – casa). Para
começar a falar sobre os comandos da interface da tela 1, foi escolhido como objeto de
análise, a interação da aplicação como o node-sala. O node-sala está conectado a um
sensor de temperatura e umidade, a um sensor de movimento e é capaz de controlar
leds. Esse controle engloba os sinais de ligar e desligar, além do o controle de intensidade
do brilho do led. Como já tem sido falado anteriormente neste capítulo, esses leds simboli-
Figura 49: Menu da aplicaçãono NodeRED
Fonte: (O autor, 2018)
116
zam um sinal digital de controle, a fim de simular o controle de um dispositivo externo,
como um ar-condicionado, um umidificador de ar e lâmpadas.
O node-sala foi escolhido para a análise por ser o dispositivo que mais ocupa a in-
terface gráfica, e também pela variedade de componentes que essa interação requer. A
Figura 50, mostra a seção da interface que controla o led que simboliza a iluminação da
sala, o led vermelho (veja a figura Figura 44).
Na Figura 50, O item (1) é o botão que liga e desliga o led vermelho, o item (2) é o
controle de brilho do led e o item (3) é o ícone que indica a presença de movimento na
sala, quando o ícone aparece como um olho, significa que o sensor está atento, tomando
conta e não há movimento, quando o ícone se transforma em um robozinho (Figura 51), é
a indicação de movimento detectado no local.
Figura 51: Ícone do AndroidFonte: (O autor, 2018)
Figura 52: Seção de controle do ar-condicio-nado central
Fonte: (O autor, 2018)
Figura 50: Seção de controle da Iluminaçãoda sala
Fonte: (O autor, 2018)
117
O node-sala, usa três seções de controle na interface. A primeira seção já foi vista,
a segunda seção, é a que controla a parte do ar-condicionado central (Figura 52). O item
(1) representa a capacidade de ligar manualmente o ar-condicionado. O led que simula
este controle é o azul. O item (2) é o controle do termostato, que regula a temperatura em
que o ar-condicionado deve ligar ou desligar. Esse controle usa uma variável, a nível da
aplicação Node-RED, que guarda o valor selecionado permitindo que ele possa ser com-
parado com a informação vinda do NodeMcu e assim, desligar ou ligar o ar-condicionado
automaticamente.
A terceira seção de controle do node-sala, é a parte que controla a umidade do ar.
O item (1) da Figura 53, é o botão de controle manual do umidificador. O item (2) é a con-
figuração do mínimo e do máximo da umidade relativa do ar, se ela estiver abaixo do míni-
mo, o umidificador é acionado automaticamente, se estiver acima do máximo, o aparelho
é desligado. O led amarelo, simboliza o umidificador de ar no circuito.
A última seção ocupada pelo node-sala, é a seção de plotagem de gráficos tipo li-
nha e pode ser vista na Figura 54. Esta seção é responsável por traçar dois gráficos, um
da temperatura e outro da umidade, todos em função do tempo. Os dados são enviados
pelo NodeMcu em intervalos de 1 minuto. A segunda seção gráfica, ainda da mesma figu-
ra, é a que desenha um gauge exibindo o nível de água da cisterna, em litros. Esta seção
está associada ao node-cisterna. A capacidade máxima da cisterna é de 5000 litros.
Os nós NodeMcu restantes, node-garagem, node-quarto, node-cozinha e node-
banheiro usam uma seção com os mesmos controles da Figura 50.
Figura 53: Seção de controle do Umidifica-dor de ar
Fonte: (O autor, 2018)
118
A última seção da tela 1 (Figura 48), é uma seção que define o modo de operação
da aplicação e pode ser vista na Figura 55. Nela é mostrada a data e a hora do sistema e
mais dois botões que acionam dois modos de operação, que podem funcionar simultanea-
mente. Um dos modos é o modo ausente, que quando ativado, envia um e-mail para o
usuário caso seja detectado um movimento em um determinado cômodo da casa. O outro
modo de operação é o de notificação por voz. Neste modo, a aplicação passa a usar uma
voz sintetizada para emitir algumas notificações, por exemplo, quando um movimento é
detectado e também quando o nível da cisterna está em nível crítico. Uma observação im-
portante, quando a notificação por voz é ativada, a string “sim” é atribuída a uma variável
Figura 54: Seção de gráficos - Temperatura, umidade e nível da cisternaFonte: (O autor, 2018)
119
global chamada “notivoz”. Essa variável será comentada logo adiante. Com relação ao ní-
vel da cisterna, a aplicação sempre envia um twitter quando a cisterna se encontra em ní-
vel crítico, abaixo de 2000 litros.
A Figura 56, mostra os elementos da tela 2 (menu – Rede de nós NodeMcu). Esta
parte da interface mostra informações sobre a rede de nós NodeMcu. Na seção Status
dos dispositivos, é possível ver os endereços ip dos nós NodeMcu e também ver quais
estão online. Essa listagem do status é atualizada automaticamente a cada 1 minuto, mas
pode ser atualizada manualmente pressionando o botão “atualizar”. O botão limpar, limpa
a lista.
Na seção Reiniciar dispositivos, existem sete botões que permitem que os nós se-
jam reiniciados, isto é claro, se eles estiverem online. O primeiro botão reinicia todos os
nós e os outros seis botões reiniciam cada nó individualmente.
Figura 56: Interface gráfica da aplicação Node-RED - Rede denós NodeMcu
Fonte: (O autor, 2018)
Figura 55: Interface gráfica - Modo deoperação
Fonte: (O autor, 2018)
120
Daqui em diante, será apresentado como estabelecer a comunicação com o MQTT
broker. Será visto como assinar e como publicar nos tópicos através dos componentes do
Node-RED.
O que acontece nos “bastidores” do sistema, e entenda-se por sistema (os firmwa-
res nos nós NodeMcu, o código Node-RED e a interface gráfica) é a troca de mensagens
no protocolo MQTT. Todas as informações vindas dos nós Node-Mcu, todos os comandos
enviados pela aplicação web para os nós NodeMcu, são mensagens MQTT. O Node-RED
permite que essa comunicação bidirecional seja implementada de uma maneira muito
prática e rápida.
A fim de demonstrar uma parte importante do desenvolvimento da aplicação com o
Node-RED, dois exemplos serão detalhados.
O primeiro exemplo é o do recebimento da informação do nível da cisterna, vinda
do node-cisterna. A Figura 57, mostra o fluxo (flow) da conexão dos componentes do
Node-RED para a se comunicar com o NodeMcu da cisterna. Para criar uma aplicação
entrando com os componentes no Node-RED, é preciso ter acesso à tela de edição de flu-
xos, ela pode ser acessada através do navegador usando o endereço do servidor Node-
RED junto com a porta do serviço, desta maneira http://192.168.0.50:1880.
Figura 57: Esquema do Node-RED - Conexão com a cisternaFonte: (O autor, 2018)
121
O componente (1) é um input-node MQTT. Seus parâmetros de configuração são o
endereço ip e a porta do MQTT broker mais o tópico a ser assinado. Quando o NodeMcu
da cisterna publica o nível da água no tópico “tccmrocha/cisterna/nivel” essa informação é
recebida pelo input-node MQTT. Ao receber a informação, ela é passada para o compo-
nente (2), o function-node switch. Ele é capaz de rotear várias saídas baseadas em crité -
rios que são definidos dentro da sua configuração. A conexão (3) é usada para valores
maiores que 5000. A conexão (4) é usada para valores no intervalo [0, 5000]. A conexão
(5) para valores menores do que 0 e por último a conexão (6) que é usada quando o valor
se encontra no intervalo [0, 2000). Essas faixas de valores são definidas na tela de confi-
guração do componente (Figura 58). As saídas (3) e (5) carregam valores maiores que
5000 e menores que 0, respectivamente. Elas são encaminhadas para outros dois func-
tion-nodes chamados change que limitam o valor máximo para 5000 e o mínimo para 0.
As saídas desses changes, conexões (7) e (8), alimentam o componente gráfico (15) que
desenha um gauge com o valor recebido em sua entrada.
Seguindo a rota da conexão (6) que carrega um valor no intervalo [0, 2000). A infor-
mação é direcionada para o function-node function (9), que recebe o valor do nível, gera
uma string com a data e a hora do sistema e cria uma string única com uma mensagem
de aviso. Essa mensagem passa para o function-node delay (10) que tem a função de li -
mitar a taxa na qual a informação passará adiante, está taxa está configurada para 1 mi -
nuto. A partir daqui, a informação é duplicada e direcionada para o componente (14) que
vai tweetar a mensagem na conta do usuário (Figura 59) e para o componente (11) que
Figura 58: Configuração do function-node SwitchFonte: (O autor, 2018)
122
verifica se a variável global “notivoz” é igual a “sim”, caso a condição seja verdadeira, a
mensagem segue para o function-node function(12) que troca a mensagem recebida por
um texto que será falado pela aplicação, esse texto é “Cisterna em nível crítico, fique
atento!”. Essa string é passada para o output-node audio-out que falará o texto contido na
string.
O segundo exemplo será a publicação de mensagens em um tópico MQTT. Para
isso será usado o fluxo que gera a seção Reinicia dispositivos (Figura 56) da interface
gráfica. A Figura 60, mostra o fluxo responsável pela criação dos botões de reset individu-
al dos nós NodeMcu na interface e também o componente responsável pela publicação
das mensagens. Os componentes (1) são dashboard-nodes do tipo botão, eles são ele-
mentos da interface com o usuário e são exibidos na tela da aplicação.
Figura 60: Esquema do Node-RED - Publicando em tópicosFonte: (O autor, 2018)
Figura 59: Tweet de aviso de cisterna em nível críticoFonte: (O autor, 2018)
123
Esses botões respondem ao evento de clique do mouse. Após clicados enviam
para o componente (2) (output-node MQTT) a informação como o tópico e valor a serem
publicados. Cada botão, envia o seu tópico e valor específico e o componente MQTT se
encarrega da publicação. A configuração do componente (2) usa somente um parâmetro,
o endereço e a porta do MQTT broker.
A Figura 61 mostra o esquema (flow) que interage com o node-sala, o nó NodeMcu
que tem mais funções e que publica e assina um maior número de tópicos. É possível ver
que há uma complexidade muito maior neste flow do que no do node-cistena (Figura 57).
Os princípios de comunicação com o MQTT broker (publicando/assinando) são os mes-
mos já explicados.
124
Figura 61: Node-RED (Flow) - node-salaFonte: (O autor, 2018)
125
4.5 PROTÓTIPO CONSTRUÍDO
Esta seção apresenta o protótipo que foi construído com os elementos reais, po-
rém, não instalados em uma casa real. As montagens foram realizadas em bancada por
questões práticas. A Figura 62 mostra o Raspberry Pi, onde roda o MQTT broker (servidor
Mosquito) e o serviço Node-RED.
A Figura 63 mostra a montagem em protoboard de três nós NodeMcu do tipo 1, da-
queles que ficam no quarto, na cozinha, no banheiro e na garagem.
Figura 62: Raspberry Pi - Servidor MQTTFonte: (O autor, 2018)
Figura 63: Protótipo dos nós NodeMcu do tipo 1Fonte: (O autor, 2018)
126
A Figura 64 mostra o protótipo do nó NodeMcu do tipo 2 usado na cisterna. Este nó
usa somente o sensor ultrassônico.
O protótipo do nó NodeMcu do tipo 3, pode ser visto na Figura 65. Este nó é o que
interage com mais sensores e também atua em mais leds.
Figura 64: Protótipo do nó NodeMcu do tipo 2Fonte: (O autor, 2018)
Figura 65: Protótipo do nó NodeMcu do tipo 3Fonte: (O autor, 2018)
127
A Figura 66 mostra o protótipo completo, ou seja, a rede de seis nós NodeMcu da
casa inteligente.
A Figura 67 mostra uma imagem da aplicação rodando em um Tablet da Samsung
com sistema Android.
Figura 66: Protóptipo completo da rede de nós NodeMcuFonte: (O autor, 2018)
Figura 67: Foto da aplicação rodando no Tablet SamsungFonte: (O autor, 2018)
128
A Figura 68 mostra uma imagem da aplicação rodando também em um celular LG
X cam.
Figura 68: Foto da aplicação rodando em um celular modelo LG X camFonte: (O autor, 2018)
129
CONCLUSÕES E TRABALHOS FUTUROS
Após a definição do tema deste trabalho, eu comecei a pesquisar sobre o as-
sunto Internet das Coisas. Eu tinha alguma experiência no desenvolvimento de alguns
projetos de computação física com o Arduino e já tinha ouvido falar do termo, porém não
tinha idéia da dimensão e do poder de transformação da IoT.
Pude perceber, com profundidade, a ideia de ubiquidade e constatar que a IoT
é uma tendência sem limites que vai mudar a nossa maneira de viver, afetando vários se-
tores da sociedade. A vida das pessoas está sendo transformada através da automação
residencial com as casas inteligentes. Cidades estão reduzindo custos e economizando
energia usando a IoT. Fábricas “inteligentes” estão aprimorando o seu processo de produ-
ção usando o conceito da “Indústria 4.0” que tem como sinônimos os termos manufatura
avançada e indústria inteligente. O setor automotivo já possui um pneu inteligente que é
capaz de monitorar as condições de pressão e desgaste e se comunicar com o computa-
dor de bordo do carro, agendando futuras revisões. Dispositivos vestíveis monitoram ativi-
dades. Na medicina há um projeto open-source de um pâncreas artificial chamado Ope-
nAPS. Na agricultura, o cultivo inteligente baseado em IoT é altamente eficiente quando
comparado com a abordagem convencional.
Foi uma experiência muito rica usar somente tecnologias open-source para a
construção do protótipo da Casa Inteligente. Sou fã do GNU/Linux e da filosofia open-
source já há algum tempo e vejo como é possível aprender muito mais fazendo uso des-
sas ferramentas.
Quando se trata de sistemas open-source, nem tudo é tão simples. Muitas das
ferramentes de software e de hardware não possuem uma boa documentação, muitas ve-
zes ela é escassa e existe muita informação confusa e divergente. Eu tive bastante dificul-
dade na hora de publicar em vários tópicos MQTT usando o NodeMcu. Alguns exemplos
na documentação do NodeMcu são fora de contexto e muitas vezes são pequenos frag-
mentos de código mal comentados. Foi preciso testar várias ideias e gastar muitas horas
trabalhando em cima dos firmwares em linguagem Lua até encontrar uma solução. Foi
130
muito difícil implementar a parte do sensor de ultrassom com o NodeMcu usando Lua. Na
verdade o funcionamento dessa função ainda demonstra instabilidade e falta de precisão.
No geral as tecnologias usadas no trabalho corresponderam às expectativas e o
sistema se comportou como o esperado.
Todo este trabalho foi feito somente com ferramentas open-source, desde o edi-
tor de textos até as ferramentas de desenho vetorial e editores de imagem. Eu gostaria de
citá-los:
• Inkscape (Desenho vetorial)
• Gimp (Editor de imagem)
• Fritzing (Criação de esquemas eletrônicos em protoboard)
• LibreOffice (Editor de textos)
• Geany e Atom (Editores de código fonte)
• Deepin Scrot e Shutter (Print screen e edição de gráficos)
• Debian OS
• Ubuntu OS
• Raspbian OS
Como trabalhos futuros, há algumas áreas no desenvolvimento da IoT que po-
dem ser exploradas. A questão da segurança e da privacidade em IoT é muito importante.
Com carros, cidades inteiras e indústrias conectadas à Internet, o acesso indevido a es-
sas redes pode ser catastrófico. Imagine um carro ou um reator nuclear sendo hackeado.
Outro desafio que pode servir como ponto de partida para um projeto futuro é a questão
da conectividade. Os sistemas de IoT usam muitas tecnologias de transmissão sem fio
como Wi-Fi, Bluetooth, LoRa WAN, SigFox, Zigbee e etc. Cada um desses sistemas pos-
sui suas próprias vantagens e especificações. A implementação de plataformas de tecno-
logia múltipla é um desafio para os desenvolvedores, uma vez que a informação deve ser
compartilhada entre dispositivos e aplicativos.
O meu objetivo é seguir meus estudos e ingressar no mestrado. A minha área
de interesse é a Inteligência artificial e as redes neurais artificiais. Pretendo também inten-
sificar os experimentos sobre as arquiteturas exploradas neste trabalho, talvez definir no-
vas arquiteturas e cenários de IoT, e publicar um livro com o mesmo título desta monogra-
fia.
131
REFERÊNCIAS BIBLIOGRÁFICAS
ARDUINO&CIA. Sensor de umidade e temperatura DHT11. Disponível em: <https://
www.arduinoecia.com.br/2013/05/sensor-de-umidade-e-temperatura-dht11.html>. Acesso
em: 10/05/2018.
BOLZANI, Caio Augustus M. Residências inteligentes: Um curso de domótica. São
Paulo: Editora Livraria da Física, 2004.
CHAUHAN, Akshay. Building a security alarm using Raspberry Pi. Disponível em:
<https://hackernoon.com/building-a-security-alarm-using-raspberry-pi-725a18f42e84>.
Acesso em: 25/05/2018.
CURVELLO, André. Arduino Yún. Disponível em: <https://www.embarcados.com.br/ar-
duino-yun/>. Acesso em: 13/05/2018.
DARNELL, Lucus. The Internet of Things: A Look at Real-World Use Cases and Con-
cerns. : Lucus Darnell, 2015.
DELOURA, Mark. The Engine Survey: General Results. Disponível em: <http://www.sa-
tori.org/2009/03/the-engine-survey-general-results/>. Acesso em: 26/05/2018.
HAWKINS, Matt. Simple Guide to the Raspberry Pi gpio Header and Pins. Disponível
em: <https://www.raspberrypi-spy.co.uk/2012/06/simple-guide-to-the-rpi-gpio-header-and-
pins/>. Acesso em: 25/05/2018.
HiveMQ. Interprise MQTT broker. Disponível em: <https://www.hivemq.com/blog/mqtt-
essentials-part2-publish-subscribe>. Acesso em: 22/05/2018.
132
IERUSALIMSCHY, Roberto. Programando em Lua: Tradução de Ana Lúcia DeMoura. 3.
ed. Rio de Janeiro: LTC, 2015.
LEA, Rodger. Node-RED: Lecture 1: A brief introduction to Node-RED. Disponível em:
<http://noderedguide.com/nr-lecture-1/>. Acesso em: 10/05/2018.
LIGHT, Roger A. Mosquitto: server and client implementation of the MQTT protocol,
The Journal of Open Source Software, vol. 2, no. 13, May 2017, DOI: 10.21105/
joss.00265.
MOTA, Allan. Sensor de temperatura LM35 – Medindo temperatura com Arduino. Dis-
ponível em: <https://portal.vidadesilicio.com.br/lm35-medindo-temperatura-com-arduino/>.
Acesso em: 26/05/2018).
NodeMCU. NodeMCU custom builds. Disponível em: <https://nodemcu-build.com/>.
Acesso em: 20/10/2017.
NodeMCU. NodeMCU Documentation: GPIO Module. Disponível em: <https://nodem-
cu.readthedocs.io/en/latest/en/modules/gpio/>. Acesso em: 20/10/2017.
PENNINKHOF, Jan. Getting started with the ESP8266. Disponível em: <https://www.-
penninkhof.com/2015/01/getting-started-with-the-esp8266/>. Acesso em: 26/05/2018.
SILVA, Everton; et al. Computação Ubíqua: Definição e Exemplos. 2015. Disponível
em: <https://seer.imed.edu.br/index.php/revistasi/article/download/926/739>. Acesso em:
27/05/2018.
SINGH, Pradeep. Esp8266. Disponível em: <https://iotbytes.wordpress.com/esp8266-2/>.
Acesso em: 01/03/2018.
STANFORD-CLARK, Andy; TRUONG, Hong Linh. MQTT For Sensor Networks (MQTT-
SN): Protocol Specification. Disponível em: <http://mqtt.org/new/wp-content/uploads/
2009/06/MQTT-SN_spec_v1.2.pdf>. Acesso em: 07/05/2018.
133
THE MATHWORKS, Inc. Analyze Your Data. Disponível em: <https://www.mathworks.-
com/help/thingspeak/analyze-your-data.html#visualize_dew_point_measurement>. Aces-
so em: 20/10/2017.
THOMSEN, Adilson. Como comunicar com o Arduino Ethernet Shield W5100. Disponí-
vel em: <https://www.filipeflop.com/blog/tutorial-ethernet-shield-w5100/>. Acesso em:
05/05/2018.
UPTON, Eben; HALFACREE, Gareth. Raspberry Pi User Guide 2nd Edition. United
Kingdom: Wiley, 2014.
VEIGA, Ricardo. Wireless RFID door lock using NodeMcu. Disponível em: <http://
www.instructables.com/id/Wireless-RFID-Door-Lock-Using-Nodemcu/>. Acesso em:
25/05/2018.
134
APÊNDICE A – Esp8266 (fazendo o upload do firmware Lua)
Para usar o Esp8266 com a linguagem Lua, é necessário fazer o upload do firmwa-
re que roda o interpretador Lua. Normalmente, o firmware que vem gravado por padrão é
o firmware AT. Todos os protótipos implementados neste trabalho fizeram uso do módulo
Esp12E NodeMcu. Devido à grande quantidade de bibliotecas (ou módulos) que estão
surgindo para o NodeMcu, agora não é mais disponibilizado um firmware Lua padrão,
pronto para download.
Um firmware customizado pode ser gerado no site do NodeMcu53. É importante não
confundir o uso do termo módulo, usado para referenciar a placa Esp8266 (hardware)
com o termo módulo usado para se referir às bibliotecas (software).
Neste site cada módulo pode ser excluído ou adicionado na customização. Assim
pode-se economizar espaço selecionando somente as bibliotecas necessárias ao projeto.
Por exemplo, se a aplicação não trabalha com sinal pwm, não será necessário ter este
módulo no firmware, assim economizando memória. Para ter acesso ao firmware customi-
zado é preciso fornecer um e-mail para receber o link para download. Duas versões do
firmware serão disponibilizadas, uma que será capaz de trabalhar com ponto flutuante e
outra que trabalhará somente com números inteiros. Elas também diferem em tamanho, a
que trabalha só com números inteiros ocupa um pouco menos de memória. O tempo de
espera, para a geração do firmware e a disponibilização do link no e-mail, fica em torno de
10 minutos.
Existem basicamente duas maneiras de gravar o firmware no Esp8266. Primeira-
mente será mostrada a que usa puramente a linha de comando:
(1) Para fazer o upload no Linux você pode usar o programa em python chamado:
esptool.py
Basta baixá-lo usando:
git clone https://github.com/themadinventor/esptool.git
53 https://nodemcu-build.com/
135
Após baixar é só entrar na pasta esptool e digitar o comando abaixo para instalar a
ferramenta.
sudo python setup.py install
É preciso conectar o Esp8266 na porta usb e digitar o comando a seguir para ver
em que porta ele está aparecendo no sistema. A Figura 69 mostra que ele está na porta
ttyUSB0.
dmesg | grep tty
Para fazer o upload do firmware é preciso copiar o arquivo do firmware para a pas-
ta do esptool e executar a próxima linha de comando:
*** Lembrando que o programa esptool.py tem como dependência o módulo python-serial
que pode ser instalado facilmente via apt-get.
sudo python esptool.py --port /dev/ttyUSB0 --baud 115200 write_flash 0x00000 NodeMcu_float_0.9.6-dev_20150704.bin
A Figura 70 mostra o progresso do upload do firmware para a placa.
Agora será mostrado como fazer o upload do firmware usando o PyFlasher, um
frontend para o esptool.py.
Ele é escrito em Python, é baseado no esptool.py e tem como dependência as bi-
bliotecas pyserial e wxpython que podem ser instaladas facilmente nas distribuições GNU/
Linux.
O PyFlasher pode ser baixado através do link:
https://github.com/marcelstoer/nodemcu-pyflasher.git
Figura 69: Verificando a porta associada ao Esp8266Fonte: (O autor, 2018)
136
É possível rodar o programa da seguinte forma:
python nodemcu-pyflasher.py
A Figura 71 mostra a interface do PyFlasher. A seguir, uma explicação básica dos
elementos da interface do programa.
(1) Seleciona a porta do NodeMcu.
(2) Seleção do firmware a ser gravado.
(3) Escolha da velocidade de gravação. Nada tem a ver com a velocidade de comuni-
cação da placa como a IDE Esplorer.
(4) A opção “yes, wipes all data” deve ser usada no caso em que o firmware já gravado
na placa, tenha sido corrompido ou em casos de pane no firmware.
(5) Inicia o processo de gravação do firmware.
(6) Terminal de saída que exibe o processo de gravação.
Figura 70: Progresso do upload do firmware para a placaFonte: (O autor, 2018)
137
Figura 71: NodeMcu - PyFlasherFonte: (O autor, 2018)
138
APÊNDICE B – Usando a IDE Esplorer
Após o upload do firmware a ferramenta usada para escrever e fazer o upload dos
códigos escritos em Lua é o Esplorer.
Deve-se baixar o Esplorer daqui:
https://esp8266.ru/esplorer/
Descompactar o arquivo e entrar na pasta.
Para executar o Esplorer digita-se na linha de comando java -jar esplorer.jar (é pre-
ciso ter o Java instalado). Para fazer o upload de código é necessário que o NodeMcu es-
teja ligado a uma porta usb.
Após clicar em open é preciso apertar e soltar o botão de reset da placa (Figura 8).
A Figura 73 exibe a tela com a conexão aberta entre a IDE e a placa. É possível ver os
módulos que estão contidos no firmware e também a versão de Lua que é 5.1.4. No final
Figura 72: Conectando o NodeMcu à IDE EsplorerFonte: (O autor, 2018)
Figura 73: Conexão da IDE com o NodeMcuFonte: (O autor, 2018)
139
da imagem pode se ver uma mensagem dizendo que Lua não conseguiu abrir o arquivo
init.lua. Toda vez que o NodeMcu é iniciado, seja no momento em que ele é energizado
ou em um reset, o NodeMcu procura pelo arquivo init.lua e caso o encontre o executa. A
função principal deste arquivo é chamar o módulo principal e fazer com a aplicação se ini -
cie automaticamente.
A Figura 74 tem o objetivo de mostrar resumidamente algumas funções da IDE Es-
plorer. (1) Área de digitação do código fonte. (2) Monitor serial que serve para exibir as sa-
ídas dos comandos print e também usar o NodeMcu interativamente, como um Shell de
comandos. (3) Gerenciador de arquivos que permite executar, compilar, renomear e remo-
ver um arquivo. (4) Botões para conectar e desconectar à placa, e selecionar a velocidade
de conexão serial. (5) Área de Snippets.54 (6) Caixa de entrada de comandos no modo in-
terativo. Para executar um comando basta digitá-lo e apertar o botão à direita, Send. (7)
Menu de abertura, salvamento, criação e fechamento de arquivos no hd. (8) Faz o upload
do código para a memória flash do NodeMcu.
A IDE, também oferece o recurso, de trabalhar com o NodeMcu usando o firmware
AT. Para isso, é só selecionar a aba AT-based (Figura 75), na parte superior da interface,
indicada pela seta vermelha. Este recurso é muito útil, principalmente para quem está co-
54 São fragmentos de códigos que podem ser executados (disparados) através dos botões Snippets.
Figura 74: IDE Esplorer - FunçõesFonte: (O autor, 2018)
140
meçando a estudar comandos AT. Existem botões, que ao serem clicados, enviam código
AT para o NodeMcu, permitindo assim interagir como a placa, de maneira fácil e amigável.
Figura 75: IDE Esplorer - Aba AT-basedFonte: (O autor, 2018)
141
APÊNDICE C – Instalando e configurando o servidor Mosquitto
A distribuição GNU/Linux usada no Raspberry Pi, é a Raspbian, que é baseada noDebian 9 (Stretch). Para instalar o servidor Mosquitto no Raspbian, é preciso abrir um ter-minal e usar o camando apt-get. O Mosquitto já se encontra nos repositórios do Debian,sendo assim, é só digitar o comando no terminal:
sudo apt-get install mosquitto
Agora, é precisso instalar o cliente MQTT, usando o camando:
sudo apt-get install mosquitto-clients
A instalação do Mosquitto está feita e o seu serviço, por padrão, roda na porta
1883. Agora, será criado um usuário, e lhe será atribuída uma senha. Esses dados de lo-
gin, foram utilizados na conexão como o Mosquitto, dentro do código Lua, no NodeMcu.
sudo mosquitto_passwd -c /etc/mosquitto/passwd marcelo
Será necessário entrar uma senha para o usuário marcelo.
Pode-se fazer um teste, a fim de verificar se o Mosquitto está rodando e conferir a
versão instalada. Para isso, será usado o comando:
sudo /etc/init.d/mosquitto status
A Figura 76, mostra o status do serviço do Mosquitto na tela do terminal.
Figura 76: Verificando o status do servidor MosquittoFonte: (O autor, 2018)
142
É possível testar o servidor, criando um tópico, que receberá mensagens de um cli-
ente, que publicará neste tópico. Para isso, será necessário usar duas telas de terminal. A
Figura 77, mostra a tela do primeiro terminar. É preciso digitar o comando a seguir:
mosquitto_sub -d -t tccmrocha/teste
Para publicar neste tópico, basta abrir outro terminal e entrar o comando:
mosquitto_pub -d -t tccmrocha/teste -m "Hello from UFF/CEDERJ"
A Figura 78, mostra o envio da informação e as respostas enviadas pelo servidor. E
assim, se encerra, a instalação e configuração do Mosquitto, que são necessárias para o
funcionamento da casa inteligente.
Figura 77: Criando um tópico de teste no MosquittoFonte: (O autor, 2018)
Figura 78: Publicação de teste no servidor MosquittoFonte: (O autor, 2018)
143
APÊNDICE D – Instalando o Node-RED
O Node-RED tem como dependência o Node.js. Sendo assim, é preciso instalá-lo
antes de tudo. O comando a seguir instalará o Node.js e o seu gerenciador de pacotes, o
npm.
sudo apt-get install nodejs npm
Após a instalação, pode-se verificar a versão instalada do Node.js com o comando:
node --version
A versão do Node.js utilizada neste projeto é a 6.12.0. Para instalar o Node-RED,
pode-se executar o script:
bash <(curl -sL https://raw.githubusercontent.com/node-red/raspbian-deb-package/master/resources/update-nodejs-and-nodered)
Após o final da execução do script o Node-RED estará instalado. O comando a se-
guir levanta o servidor:
node-red-start
Para fazer com que o serviço rode automaticamente após a reiniciaçização do sis-
tema, é só executar o comando:
sudo systemctl enable nodered.service
A Figura 79, mostra o resultado comando:
node-red-log
Após o comando, são exibidas as versões do Node-RED, do Node.js, do Kernel Li-
nux, os diretórios de instalação, a porta (1880) em que o serviço Node-RED está rodando
e também a porta (1883) do serviço do MQTT broker.
144
Figura 79: Tela de log do serviço Node-REDFonte: (O autor, 2018)
145
APÊNDICE E – Código do servidor HTTP
Embutido nos nós NodeMcu do tipo (1) e tipo (3), um servidor HTTP retorna uma
página com informações sobre o hardware da placa e também detalhes a respeito da
rede. Pode ser acessado via navegador de Internet usando o endereço de ip do nó No-
deMcu.
Código 34: Código fonte - Servidor HTTP parte 1
146
Código 35: Código fonte - Servidor HTTP parte 2
147
Código 36: Código fonte - Servidor HTTP parte 3
148
APÊNDICE F – Código do servidor Telnet
Um servidor Telnet está disponível nos nós NodeMcu do tipo (1) e (3). Ele funciona
na porta 2323 e pode ser acessado através de um terminal, basta usar o comando:
telnet <ip do NodeMcu> 2323
O que esse servidor faz é espelhar, na saída do servidor Telnet, toda a informação
que é enviada para o monitor serial.
Código 37: Código fonte - Servidor Telnet