Escola Profissional de Almada

Curso Profissional de Eletrónica, Automação e Comando

Alison Peniche
Iuri Peniche
Rodrigo Martins

Infinity Smart Control

Relatório Final do Projeto de Prova de Aptidão Profissional

Professor Orientador: Luís Bettencourt

Coordenador de Curso: Reinaldo Lourenço

Maio de 2019
Agradecimentos

A concretização de um projeto como a nossa Prova de Aptidão Profissional (PAP) não

se deve apenas a nós como autores, mas antes a todos aqueles que de forma direta
e indireta se envolveram para a realização deste projeto, desde a transmissão de
conhecimentos teóricos, técnicos e de valores, até ao alcance de conquistas,
aprendizagens.

Agradecemos, em primeiro lugar, ao nosso coordenador de curso, Prof. Reinaldo

Lourenço, que com o seu grande apoio, dedicação e orientação nos proporcionou
conhecimentos necessários e nos colocou desafios ao longo destes três anos,
fazendo com que fosse possível a realização da nossa PAP.

Agradecemos em seguida ao Prof. José Caramelo e ao Prof. Luís Bettencourt

também pelo apoio e pela transmissão dos conhecimentos técnicos necessários,
pelas várias conversas de reflexão acerca do nosso desempenho e pela oportunidade
de alcançar conquistas a nível escolar, como também pela ajuda na parte técnica e
prática do nosso projeto.

Também gostaríamos de agradecemos à Prof. Liliete Santos e à Prof. Marta

Reverendo pela a atenção concedida e por todo o tempo despendido a auxíliar-nos na
realização e correção do relatório final, e na preparação da apresentação oral.

Finalmente, agradecemos a todos os professores da EPA e à instituição por tudo o

que fizeram por nós, sempre tendo em conta o nosso bem e sucesso a todos os
níveis.
 Resumo

No contexto da Prova de Aptidão Profissional, desenvolvemos um sistema de segurança e Commented [1]: completem a ideia. Parece-me que
controlo, inteligente e autónomo, que é aplicado a uma estufa - o Infinity Smart Control. Este não pode dizer como foi feito o desenvolvimento de
determinada coisa se não diz o que é a "coisa"...
sistema funciona sem a intervenção humana, de forma eficaz e com margem de erro mínima.
A segurança inerente provém do facto de possuir mecanismos de defesa, seja contra intrusão Commented [2]: Veja agora stora

ou contra catástrofes naturais, como por exemplo incêndios.
O desenvolvimento do Infinity Smart Control foi dividido em duas fases: a primeira engloba a
programação do software e a configuração das plataformas de controlo, resultando num
protótipo inicial; a segunda fase consistiu no desenvolvimento do hardware, dando origem ao
protótipo final.
Commented [3]: Corrigido.
Commented [4]: Liliete, em termos técnicos o resumo
já está revisto. Penso que também tem uma linguagem
coerente, por isso, dá só uma olhadela e passa para
outro capítulo. ASS Marta Reverendo

Para o desenvolvimento do software foi efetuada uma pesquisa sobre o MCU apropriado para Commented [5]: descodifiquem
o nosso projeto. Depois de termos escolhido o modelo ideal, começámos por fazer testes às Commented [6]: MCU é uma sigla que consta da lista
bibliotecas (API do ESP32) e a todas as suas funções, como o WI-FI ou a ligação ao servidor de siglas e acrónimos. Penso que não seja necessário
local. Realizamos ainda testes aos sensores escolhidos para o projeto e uma pesquisa para voltar a traduzir....

aferir os pinos ideais para cada sensor ou atuador. Commented [7]: Adicionar à lista de siglas

De seguida, foi feita uma pesquisa intensiva sobre o protocolo de comunicação MQTT com o
objetivo de passar da rede local para a internet a partir da cloud. Entretanto, testámos o Commented [8]: Não esquecer de alterar este tempo
protocolo com o objetivo deste enviar apenas dados para a cloud, realizando o tratamento dos verbal em todo o documento (com ou sem acento,
escolham) ASS Marta
mesmos a partir de uma plataforma designada de ThingSpeak.

Gradualmente, realizámos os mesmos testes noutras plataformas, nomeadamente, a Ubidots,

pois esta plataforma possibilita enviar dados para o ESP32. Finalizados estes testes,
começámos por construir o protótipo inicial com a eletrónica base numa breadboard,
desenvolvendo o software de controlo com o protocolo MQTT.

Uma vez que a Ubidots tem custos mensais, migrámos para uma última plataforma, a
Adafruit.IO, que oferece o mesmo serviço de forma gratuita. Após a adaptação do código final
às características desta nova plataforma, começamos a aplicar os modos automáticos e a
configurar a dashboard da plataforma. Depois do software finalizado, aplicámos comandos de
voz com o assistente da Google, a partir da plataforma IFTTT da Google e configurámos uma
aplicação já desenvolvida para o nosso próprio projeto (MQTT Dash).

Na segunda fase, desenvolvemos a eletrónica do projeto, tendo em conta a proteção da placa

principal de possíveis tensões elevadas. Assim realizamos uma pesquisa sobre o
microcontrolador, possibilitando aferir os componentes a serem utilizados nas PCBs. Após toda
a pesquisa e o conhecimento adquirido em relação ao ESP32, iniciamos o desenvolvimento da
PCB principal e a PCB extensora no EAGLE (um programa de software que permite a criação
de placas eletrónicas).

O protótipo final apresenta, assim, as funcionalidades de controlo da temperatura, da humidade

do ar e humidade do solo, rega automática e luminosidade.
Palavras-chave: Autonomia; Flexibilidade; Dashboard; Microcontrolador; Linguagem C/C++

Abstract
In the context of the professional aptitude test, we developed a security intelligent and
autonomous system applied to a greenhouse - the Infinity Smart Control.
This system is intelligent and autonomous because it works efficiently and with low error
margin without any human assistance. The inherent security of this system comes from the
fact that it has defence mechanisms either against intrusion detection system or against
natural catastrophes for example fires.

The develop of Infinity Smart Control was divided into two parts. The first one includes the
software and hardware programming and the second part in the development of the hardware
itself, giving the origin of the final prototype.

Initially, for the software development, a research about the microcontroller unit was made
adapted to our project.
After we have chosen the ideal model, we have started to build some tests to the libraries
(Application Program Interface of the ESP32), and all it’s functionality like the WI-FI, the local
server connection, connections to the sensors and tests with necessary sensors for the
project. And research of the ideal pins for each sensor or actuator. Afterwards an intensive
research was made about the communication protocol MQTT with the goal of going through
the local network to the internet thought the cloud. Then we have made some tests to send
only the data for the cloud and we have made the treatment of these tests from a platform
named ThingSpeak.
Gradually we have made the same tests to another platform (Ubidots) because this platform
made possible to send data for the ESP32. After finishing these tests, we have started to build
the initial prototype with the main electronics in a breadboard and all it’s entire control for the
MQTT protocol. Finally we moved to a final platform. The Adafruit.IO, because Ubidots has a
monthly payment while Adafruit.IO offers the same service but for free, after the appliance of
the final code for the newly characteristics of this new platform, we applied small
implementations to the software.
After the finished software, we applied voice commands using google assistant from the IFTTT
platform of google and we configured an application developed for our own project (MQTT
Dash).

The second part included the development of the hardware for the project, considering the
protection of the main board of possible voltage peaks. Therefore we researched about the
MCU, to get a better understanding of the components to be used in the PCBs.
After all the research and the acquired knowledge regarding ESP32, we started the
development of the main board and the extension board on Eagle (A PCB development
application).

The final prototype presents, therefore, temperature, air and soil humidity control, automatic
rinsing and luminosity functionalities. O protótipo final apresenta, assim, as funcionalidades de
controlo da temperatura, da humidade do ar e humidade do solo, rega automática e
luminosidade.
Keywords: Autonomy, Flexibility; Dashboard; Microcontroller unit; C/C++ programming
language
Índice

Agradecimentos
Resumo
Abstact Commented [9]: Assim que o resumo estiver
finalizado devem traduzi-lo para inglês, incluindo as
Índice palavras chave = abstract
Lista de Figuras Commented [10]: O resumo já foi traduzido
Lista de Tabelas
Lista de Siglas e Acrónimos

Introdução

1.Especificação da solução a implementar

2.Concretização da solução encontrada

2.1. O que é o ESP32?
2.1.1. O porquê do microcontrolador ESP32?
2.2. O Software
2.3. O Protótipo
2.4. Plataformas Utilizadas
2.5. A Configuração
2.6. Desenvolvimento das PCB´s
2.6.1. Bibliotecas dos esquemáticos utilizados no EAGLE Cad
2.6.2. Configurações do Eagle (Dimensões das ilhas e pistas)
2.6.3. Diagrama de blocos Infinity Smart Control
2.6.4. Diagrama de blocos Smart Control Extender
2.6.5. Realização da PCB principal
2.6.6. Design das PCB´s
2.6.7. Problemas e soluções nas PCB´s
2.6.8. Processo de impressão e montagem das PCB´s

3.Testes ao sistema desenvolvido

Conclusão

Bibliografia

Glossário

Lista de Figuras

Figura 1 - Bibliotecas utilizadas

Figura 2 - Configuração inicial do software
Figura 3 - Predefinição dos pinos e de variáveis
Figura 4 - Configuração da classe do cliente MQTT
Figura 5 - Configuração Setup e Inicialização da função MQTT_connect
Figura 6 - Configuração das redes wifi
Figura 7 - Subscrição dos feeds da plataforma Adafruit.IO
Figura 8 - Verificação de conexão à rede wifi
Figura (9 - 9.2) - Recepção para o ESP32 do payload dos estados atuais dos feeds
subscritos
Figura (10 - 10.1) - Envio de dados para a plataforma Adafruit.io
Figura 11 - Estados do alerta
Figura 12 - Lógica do alerta com o sensor de movimento
Figura (13 - 13.1) - Modos automáticos
Figura 14 - Desativação dos modos automáticos
Figura (15 - 15.1) - Função MQTT_connect
Figura 16 - Circuito LDR
Figura (17 - 17.1) - Protótipo Final
Figura (18 - 18.3) - Resolução de problemas com o engenheiro da Ubidots
Figura (19 - 19.1) - Dashboard Adafruit.io final
Figura 20 - Configuração da plataforma thingspeak
Figura (21 - 21.6) - Configuração da plataforma adafruit.io
Figura (22 - 22.12) - Configuração IFTTT
Figura (23 - 23.9) - Configuração da aplicação MQTT Dash
Figura 24 - Pinagem do ESP32 DevKit V1
Figura 25 - Esquemático PCF8574
Figura 26 - Diagrama de blocos do Infinity Smart Control
Figura 27 - Componentes electrónicos da parte lateral digital
Figura 28 - Componentes electrónicos da parte lateral analógica
Figura 29 - Cálculos das resistências de 15 OHMs
Figura 30 - Diagrama de blocos do Smart Control Extender
Figura 31 - Esquemático Smart Control Extender
Figura 32 - Board da placa ESP32
Figura 33 - Demonstração das respetivas posições dos componentes.
Figura 34 - Demonstração da construção de uma placa inicial
Figura 35 - Testes nos dados de temperatura e humidade

Lista de Tabelas

Tabela 1 - Custo do material

Tabela 2 - Custo do projeto
Tabela 3 - Tabela de endereços possíveis de comunicação I2C

Lista de Siglas e Acrónimos

API - Application Programming Interface (Interface de programação de aplicações)

- é um tipo de software que permite a comunicação entre duas aplicações.
GPIO - General Purpose Input Output (Entradas/Saídas para uso geral) - é uma
interface usada para conectar microcontroladores a outros dispositivos eletrónicos.

I2C - Inter-Integrated Circuit (Circuito Inter-Integrado) - é um conjunto de linhas de

comunicação que permitem a interligação entre dispositivos (barramento) que é usado para ligar
periféricos a uma placa principal.

MCU - MicroController Unit (Unidade microcontroladora) - é um circuito integrado

compacto feito para controlar uma operação específica numa combinação de hardware e
software.

PLC - Programmable Logic Controller (Controlador lógico programável) - designado Commented [11]: Todas as siglas devem ter a
também por autómato, é um equipamento que serve para controlar e monitorizar máquinas, definição.
mais precisamente em relação à indústria.

SCL - Serial Clock Line (Linha de CLOCK) - é a linha responsável pelo sinal de CLOCK.

SDA - Serial Data (Dados em Série / Comunicação em Série) - é o processo de envio de

dados, os dados são enviados sequencialmente (bit-bang) através de um fio.

SPI - Serial Peripheral Interface (Interface Periférica) - é um protocolo que permite a

comunicação do microcontrolador com diversos outros componentes, formando uma rede.

SoC - System on a Chip (Sistema num chip) - é um circuito integrado que contém todos os Commented [12]: o que é que refere??? Quando
circuitos eletrónicos necessários . definimos qq coisa não dizemos que ela se refere a qq
coisa, mas sim o que ela é!!! Novamente cópia da
wikipédia!!!!!
UART - Universal Asynchronous Receiver-Transmitter (Transmissor-Receptor
Assíncrono Universal) - é um microchip que comunica em série assíncrona e que controla .

Glossário Commented [13]: O glossário é como um pequeno

dicionário de temos específicos da área científica
abordada e deve ser incluído dp da bibliografia
Baud Rate - é a medida de velocidade da transmissão de dados.
Commented [14]: O glossário deve ser organizado por
ordem alfabética.
CLOCK - é o sinal usado para coordenar as ações de dois ou mais circuitos.

Data (Dados) - são informações que são traduzidas numa forma eficaz para processamento.

Payload - é a capacidade de carregamento de uma unidade de dados entre a origem destes

até ao destino.
 Introdução
O presente relatório pretende explicar detalhadamente a idealização e construção do nosso
projeto de Prova de Aptidão Profissional, designado como Infinity Smart Control. Este projeto
tem como objetivo aplicar os conhecimentos que foram adquiridos durante o Curso Profissional
de Técnico de Eletrónica, Automação e Comando.

A designação do sistema foi pensada pelo facto de este apresentar um funcionamento

extremamente flexível, pois dependendo dos requisitos solicitados pelo cliente, pode ser
alterado facilmente para qualquer tipo de aplicação.

O nosso sistema apresenta-se em dois módulos - o módulo principal e o módulo secundário -

controlados por uma dashboard acessível através de um navegador, uma aplicação para
telemóvel e por comandos de voz. O módulo principal tem o aspecto de um autómato (PLC) e
oferece 6 entradas analógicas que permitem conectar sensores ou qualquer tipo de
componente analógico; apresenta também 11 entradas digitais, que possibilitam a conexão de
qualquer tipo de atuador.

O módulo secundário - que designamos como Smart Control Extender - tem um aspeto
semelhante ao módulo principal e oferece 8 entradas com relés em cada uma destas. O seu
propósito é estender o módulo principal no que diz respeito ao número de entradas e saídas. A
comunicação entre os dois módulos é feita através dos pinos para o protocolo de comunicação
I2C.
A Dashboard, a APP e os comandos de voz têm como objetivo a monitorização de
determinadas variáveis importantes como a temperatura, humidade atmosférica, humidade do
solo e luminosidade para a área de aplicação do nosso sistema, a estufa.
Esta monitorização é possível através de gráficos, têm também como vantagem a manipulação
de atuadores para as necessidades do utilizador.
No contexto do nosso projeto o Infinity Smart Control, a Dashboard e a APP foi focada para o
funcionamento e a automação de uma estufa.

O motivo que nos levou a desenvolver este projeto foi o interesse pela tecnologia Internet of
Things (IoT) que está em franco desenvolvimento e tem sido o alvo das grandes empresas
tecnológicas, pois a ideia principal da IoT é conectar todos os dispositivos inteligentes de forma
global, para total autonomia e monitorização. Hoje em dia esta tecnologia só é vista em Smart
Homes e pequenos projetos, sendo que o nosso objetivo com o projeto Infinity Smart Control é
expandir e aplicar esta tecnologia a qualquer tipo de aplicabilidade, como por exemplo, estufas Commented [15]: A professora mencionou que não
autónomas, sistemas de segurança, automação residencial, etc. gostou do termo "utilidade".

No presente relatório procuramos explicar pormenorizadamente as várias etapas do nosso

trabalho. Em primeiro lugar… Commented [16]: esta parte é feita só no fim de
Ao longo do relatório os conceitos assinalados a negrito encontram-se explicados no glossário. acordo com a estrutura do relatório.

Especificação da solução a
implementar

A nossa prova de aptidão profissional consiste na construção de um sistema de segurança e Commented [17]: Corrigido
de controlo autónomo aplicado a uma estufa. É um sistema comandado de forma remota, via
internet (IoT), através do ESP32, a partir de qualquer ponto geográfico para qualquer dispositivo
móvel ou computador.

Lista de material

Componentes
 Custo/Unidade Custo Total
Materiais Quantidade (C/IVA) (C/IVA)

ESP32 Devkit V1 1 8,73€ 8,73€

Foto Acopladores f817 11 0,45€ 4,95€
Resistências SMD 11 0,05€ 0,55€
Resistências 27 0,03€ 0,81€
LEDS 11 0,59€ 6,49€
Relés 5V 8 2,00€ 16,00€
Sensor de luminosidade LDR 1 0,45€ 0,45€

Sensor de temperatura e humidade 1 8,95€ 8,95€

Sensor de humidade do solo 1 1,94€ 1,94€
PCF8574 1 1,95€ 1,95€
Diodos Zener 3V3 6 0,14€ 0,84€
Diodos In4007 8 0,10€ 0,80€
Transístores 2N3904 8 0,18€ 1,44€
Pinheads 1x15 2 0,13€ 0,26€
Con wago W237-132 (2 pin) 20 0,85€ 17,85€
Con wago W237-103 (3 pin) 8 0,85€ 6,80€
Ventoínha 12V 1 2,31€ 2,31€
Lâmpada de
filamento/aquecimento 1 7,38€ 7,38€
Lâmpada LED 1 1,05€ 1,05€
Custo total do material (C/
IVA): 89,55€
Tabela 1- Custo do material

Custo total do projeto

Custo/hora Total
Mão-de-obra 40€/ 7 040,00€
Material 89,55€
Custo total do projeto 7 129,55€

Tabela 2- Custo do projeto

 Concretização da solução encontrada

O que é o ESP32? Commented [18]: Corrigido

O ESP32 é um SoC MCU de baixo custo e potência, com WI-FI integrado e Bluetooth de modo
duplo. Inclui o microprocessador dual ou single core xtensa 32-bit lx6, sistema de rádio,
aceleração de hardware criptográfico, um grande conjunto de protocolos de comunicação
embebidos, um conjunto de sensores incorporados, como o de temperatura e de toque, entre
outras funcionalidades.

O ESP32 têm vários GPIO's digitais e analógicos e a sua resolução nas entradas dos canais
ADC é de 12 bits.

O porquê do microcontrolador ESP 32? Commented [19]: Corrigido

É barato e ideal para o nosso projeto, pois é um MCU cujo ponto forte é o design para projetos
IoT (Internet of Things) devido à diversidade de módulos relacionados com a mesma, como o
de WI-FI e Bluetooth. Este MCU vêm com GPIOs, com suporte para vários protocolos de
comunicação, como o SPI, I2C, UART. Inclui também redes sem fio, como a rede CAN, o que
o diferencia de outros microcontroladores como o Arduino. Isto significa que pode ser facilmente
usado para controlar e monitorizar dispositivos remotamente via Wi-Fi, a baixo custo. O ESP
32 é um microcontrolador que permite comunicar com qualquer parte do mundo, sendo ideal
para o nosso sistema, permitindo, ainda, adicionar outras funcionalidades no futuro.

O Software Commented [20]: Corrigido

O código foi desenvolvido com o Arduino IDE, cuja linguagem padrão é uma mistura de C e
C++. Este software permite a incrementação de vários sensores e atuadores para a sua
respectiva programação, proporcionando ao cliente um conjunto de algoritmos que permitem o
controlo remoto, através de três plataformas, de forma eficaz.

De seguida, apresenta-se detalhadamente o funcionamento do código implementado no

software:
 Figura 1 - Bibliotecas utilizadas

Na figura 1 incluímos todas as bibliotecas necessárias para que o código funcione. A biblioteca
WiFi.h permite as ligações sem fios para a comunicação entre o ESP32 e os routers
configurados. O WiFiMulti.h serve para configurar vários routers / redes e no caso de um deles
falhar, o ESP têm outras possibilidades de conexão.

A biblioteca SPI.h serve para a utilização do protocolo que permite a comunicação entre
múltiplos dispositivos em distâncias curtas, a grande velocidade. Geralmente é usada por
microcontroladores que são designados como dispositivos master para a comunicação com um
ou mais dispositivos periféricos, designados como slaves, mas pode também ser usada para a
comunicação entre dois microcontroladores. As bibliotecas Adafruit_MQTT.h e
Adafruit_MQTT_Client.h servem para a comunicação MQTT. A biblioteca DHTesp.h inclui todas
as funções necessárias para a facilitação do protocolo one-wire utilizado pelo sensor DHT22
que será explicado mais à frente neste relatório.

A biblioteca Arduino.h serve para incluir todas as funções padrão do arduino IDE.

Finalmente a biblioteca PCF8574.h serve para o funcionamento do circuito integrado PCF,

facilitando a utilização do mesmo.

Figura 2 - Configuração inicial do software

Na figura 2, as bibliotecas de WiFi, DHT22 e do PCF8574, são iniciadas, realizando-se toda a

configuração inicial da plataforma Adafruit.IO, nomeadamente o seu endereço, porta, username
e palavra-passe, bem como o reset da mesma.
 Figura 3 - Predefinição dos pinos e de variáveis

Na figura 3 são definidos todos os pinos a serem utilizados pelo ESP32. Para a manipulação
das suas saídas, toda esta informação é guardada dentro de variáveis, ou seja, estas servem Commented [21]: Clarificar!
para que o microcontrolador saiba qual dos pinos é que têm de sofrer alterações conforme a Commented [22]: Está suficientemente clarificado
programação. Por exemplo, se quisermos mudar o estado do LED para ON, precisamos de stora?
saber qual é o pino a controlar, logo, ao definir o nome e o número do pino ao qual o LED está Commented [23]: ainda acho um pouco confuso, ou
ligado, o MCU pode manipular os estados da sua saída. Na programação são também criadas então é do meu cansaço.
variáveis do tipo booleans. Estas servem para definir o modo de funcionamento da estufa. Commented [24]: Verificar portugues
 Figura 4 - Configuração da classe do cliente MQTT

Na figura 4 é realizada a inicialização do cliente WiFi e a configuração das variáveis na

plataforma, toda esta informação é passada para o cliente WiFi e para os servidores MQTT
quando se realiza o login.
Commented [25]: Explicar!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Commented [26]: verifica

Figura 5 - Configuração Setup e Inicialização da função MQTT_connect

Na figura 5 é iniciada a função MQTT_connect que será explicada mais à frente neste relatório.
É configurada a baud rate para o valor de 115200 para a comunicação da porta série e realizado
um pequeno atraso de 10 milissegundos para o microcontrolador interpretar a configuração.
Finalmente, é feita a definição de todos os pinos anteriormente mencionados como entradas
ou saídas, incluindo a inicialização do protocolo de comunicação I2C para estabelecer
comunicação com o circuito integrado expansor PCF8574. também é necessário utilizar a
função pinMode da biblioteca do PCF8574 com objetivo de configurar todos os seus pinos como
OUTPUT. Commented [27]: rever o Portuga
 Figura 6 - Configuração das redes wifi

Na figura 6 é feita a configuração de todas as redes wifi, utilizando todos os SSID e palavra-
passes parametrizadas no código.

Figura 7 - Subscrição dos feeds da plataforma Adafruit.IO

No excerto de código da figura 7, sempre que um dos botões da plataforma for clicado, esta
função é iniciada, alterando assim o estado do modo de funcionamento. Por exemplo, se fosse
clicado no botão Modo 1 da estufa, esta função no código seria invocada e o valor da feed
alterava-se, ou seja passava do estado 0 para o estado 1.

Figura 8 - Verificação de conexão à rede wifi

Na figura 8 temos um loop (ciclo infinito), o objetivo deste loop é reiniciar o ESP caso não se
consiga ligar a uma das redes de WI-FI disponíveis. Quando estabelecer comunicação acende
um led azul que indica que a ligação wifi foi estabelecida. Commented [28]: Clarificar!
Commented [29]: ve se percebes

Figura 9 - Recepção para o ESP32 do payload dos estados atuais dos feeds subscritos

Figura 9.1
 Figura 9.2

O objetivo do código das figuras 9 (9, 9.1, 9.2) é a recepção de transmissão de dados
(payload) para o ESP32.
Os dados são enviados a partir dos requests da plataforma Adafruit.IO, ou seja, caso um
botão seja acionado na plataforma, este guarda informações no payload (o nome do feed que
foi invocado e o estado em que este se encontra).
Vamos então analisar o código da figura 9.
Na primeira condição if se a subscrição for igual ao feed output1, este têm permissão para
passar para a próxima condição, nesta condição se o último valor de estado do payload for
ON por consequência o out1 (saída1) vai ser ativado, caso o último valor do estado recebido
for OFF, vai ser desativado.
Estas condições são idênticas para todos os outros feeds, sem exceção do alerta, o alerta
têm dois leds diferentes para cada estado.
Toda esta atualização de dados dá-se em um intervalo de 15 em 15 segundos, seja para
enviar ou receber dados.

Figura 10 - Envio de dados para a plataforma Adafruit.io

 Figura 10.1

Nas figuras 10 e 10.1 são enviados todos os dados capturados pelos sensores para a
plataforma Adafruit.io, da seguinte forma:
É armazenado nas variáveis os dados da temperatura e humidade que são tratados com a
biblioteca do sensor DHT22 e são lidos a partir do pino 27.
Os dados do sensor de luz (ldr) e de humidade de solo são armazenados também em
variáveis e obtidos a partir dos seus valores analógicos, lidos diretamente através dos pinos
analógicos onde estes estão ligados (32,34).
Estes dados são visíveis no serial monitor do arduino para fins de testes, e depois são
enviados para os determinados feeds, por exemplo, os dados da temperatura são enviados
para o feed temperature1, onde a sua localização na plataforma é "/feeds/temperature1" caso
haja qualquer problema ao enviar esta informação para a plataforma, é lida a frase “Failed to
Publish Temperature” (Falha ao publicar a temperatura) no serial monitor.
A lógica é a mesma para os restantes dados.

Figura 11 - Estados do alerta

Na figura 11 é feita a lógica necessária para ativar ou desativar o alerta, caso o led de alerta
para estado ON esteja ligado, a condição da boolean muda para verdadeiro caso contrário
muda para falso.

Figura 12 - Lógica do alerta com o sensor de movimento

Na figura 12 se o alerta estiver ligado é lido o valor digital do sensor de movimento a partir do
seu pino digital (23) e é guardado na variável “valorsensmovimento”, depois é feita a condição
que verifica se o estado do sensor estiver a HIGH, ou seja se este estiver a detetar
movimento, se for esse o caso este guarda na variável “notificaçãosms” o valor de 1, caso
contrário guarda o valor de 0, finalmente é enviado para o seu feed “notificaçãosms1”, e para
o serial monitor para fins de teste.

Figura 13 - Modos automáticos

 Figura 13.1

Nas figuras 13 (13, 13.1) é onde se encontra toda a lógica para o funcionamento dos modos
automáticos da nossa estufa, podem também ser adicionados mais modos dependendo da
exigência do utilizador, neste caso temos três modos diferentes.
Vamos ter em conta as figuras 13 e 13.1 para a explicação.
Como mostra a figura 13, o estado da boolean modo1 passa para verdadeiro se o out3 (LED
que informa se o modo 1 está ativado ou não) estiver ligado, se for esse o caso, o código
segue para as próximas condições, caso contrário o modo 1 fica a falso e ignora todo o bloco
de código do modo 1.
As seguintes condições manipulam todas as variáveis necessárias para a estufa ou seja,
temperatura, humidade atmosférica e de solo e luminosidade.
Exemplo: Se a temperatura for menor ou igual a 24ºC o atuador de aquecimento é ligado, e o
de refrigeração é desligado, caso este valor seja maior o atuador de aquecimento é desligado
e o de refrigeração é ligado. Todas as condições seguem esta lógica, seja para a
manipulação da humidade atmosférica, de solo ou da luminosidade.
Todos os modos automáticos seguem a lógica do exemplo de cima.
 Figura 14 - Desativação dos modos automáticos

Na figura 14 mostra a condição que faz com que se todos os modos automáticos forem
desativados, todos os atuadores que dependem dos mesmos são também desligados.

Figura 15 - Função MQTT_connect

Figura 15.1
O código das figuras 15 e 15.1 trata-se da função MQTT_connect, que têm como função
como o nome indica, a conexão com a plataforma Adafruit.io (que funciona com o protocolo
de comunicação MQTT).
Primeiramente como mostra o código da figura 15, ao entrar na função MQTT_connect é
verificado se o MQTT está ligado, se sim, o código regressa ao início da função void loop,
caso contrário como mostra na figura 15 e figura 15.1, é feito três tentativas de conexão ao
MQTT, cada tentativa têm um período de cinco segundos e enquanto isto acontece é ligado o
led vermelho para indicar que não há acesso ao MQTT e é desligado o led verde que têm o
significado contrário.
Se passar das três tentativas o ESP32 é reiniciado com a função previamente apresentada
“ESP.restart()” para que este se conecte a uma rede wi-fi disponível e repita o processo.
Caso o esp tenha conseguido ligar-se ao MQTT dentro das três tentativas, é ligado o LED
verde e desligado o vermelho.
As linhas de código “Serial.println” dão o feedback necessário de cada etapa do código para
fins de debugging.

O Protótipo

O protótipo foi realizado em três breadboards, onde foram ligados e testados todos os
componentes, sensores, atuadores e leds ao SoC MCU ESP32.
O protótipo contém diferentes circuitos, circuitos para sensores, atuadores reais, atuadores
simulados com leds e leds para o feedback da conexão ao broker mqtt e para a ativação ou
desativação do alarme, como também um circuito para o circuito integrado expansor de
entradas e saídas digitais, o pcf8574. Abaixo explicaremos todo o seu processo.

Existem quatro tipos diferentes de sensores no protótipo, o DHT22, o LDR, o sensor de

humidade de solo e o sensor de movimento. O sensor DHT22 captura os valores da
temperatura e da humidade atmosférica, o LDR capta a luminosidade, o sensor de humidade
de solo capta como o nome diz, a humidade de um determinado solo e o sensor de movimento,
detecta o movimento de alguém ou de algo lendo entre os valores digitais 1 ou 0, 1 sendo que
está a detectar movimento e 0 para o contrário.

O DHT22 é composto por um componente de detecção de humidade junto com um sensor de

temperatura NTC (ou termistor).
O componente de detecção de humidade é usado para medir a humidade, este tem dois
eletrodos com substrato de retenção de humidade (geralmente sal ou um polímero plástico
condutor).
Os íons são libertados pelo substrato à medida que o vapor de água é absorvido por ele, o que,
por sua vez, aumenta a condutividade entre os eletrodos.
A mudança na resistência entre os dois eletrodos é proporcional à humidade relativa. A
humidade relativa mais alta diminui a resistência entre os eletrodos, enquanto a humidade
relativa menor aumenta a resistência entre os eletrodos.
O sensor de temperatura NTC (ou termistor) é uma resistência térmica, a resistência muda o
seu valor resistivo com a temperatura.
Os termistores são feitos de modo que a resistência mude drasticamente com a temperatura,
de modo que possa ser 100 ohms ou mais de mudança por grau.
O termo “NTC” significa “Coeficiente Negativo de Temperatura”, o que significa que a
resistência diminui com o aumento da temperatura.

O sensor DHT22 funciona com o seu próprio protocolo one-wire, que é semelhante ao original
do Dallas (Empresa que desenvolveu este protocolo). Este é baseado na estrutura Master
(MCU, por exemplo o ESP32) - Slave (Sensor), o sensor responderá apenas quando o mestre
solicita os dados.
Caso contrário, o sensor ficará quieto (permanece no modo de suspensão).
Para acessar ao sensor, o mestre têm que seguir a sequência de barramento único, se houver
uma sequência de confusão, o sensor não responderá ao mestre.
O DHT22 têm três pinos, dois para a alimentação (vcc e ground) e outro para o envio de dados
para o MCU, os pinos da alimentação são ligados aos 5v e ground do ESP32, enquanto que o
pino de dados é ligado ao pino 27. Commented [30]: Stor veja se o DHT22 já têm
informação suficiente

LDR, como o próprio nome indica, é uma resistência dependente de luz, é feito a partir de um
material semicondutor exposto, como o sulfureto de cádmio que muda a sua resistência elétrica
de vários milhares de ohms no escuro para algumas centenas de ohms quando exposto à luz.
As suas ligações são feitas como mostra a figura 16.

O circuito apresentado denomina-se como divisor de tensão, pois uma parte dos 5V irão ficar
retidos na LDR e os restantes na R1 que é uma resistência de 10k ohms em série com o LDR. Commented [31]: Português

Figura 16 - Circuito LDR

O valor do divisor de tensão irá mudar consoante a intensidade da luz no LDR, pois esta irá
mudar o seu valor ohmico consoante o nível de luz.
Abaixo é exibida a fórmula utilizada para o estudo e funcionamento do LDR.

Vs=Ve(R1/Rldr+R1))
Ve: Tensão de Entrada
Vs: Tensão de Saída
Rldr: Resistência ohmica do LDR que varia em função da luz recebida
R1: Resistência fixa

As ligações e funcionamento do sensor de humidade de solo é semelhante ao sensor LDR. Os

pinos para a alimentação seguem a mesma lógica, como também o pino de dados, que funciona
com a entrada ADC, para este caso foi utilizado o pino ADC 32.

Para o sensor de movimento PIR as ligações dos pinos para a alimentação seguem a mesma
lógica que os sensores DHT22 e de humidade de solo, porém o seu pino de sinal é ligado a um
pino digital, neste caso, o pino 23 do ESP32, pois os pinos digitais apenas lêem valores entre
1 ou 0.

Os circuitos para os atuadores reais / simulados, e para o expansor de entradas e saídas foram
feitos da seguinte forma:

Relativamente aos circuitos dos LEDs para a simulação de atuadores reais e LEDs para o
feedback de conexão à plataforma MQTT e para o feedback do estado do alerta, todos os seus
circuitos são idênticos, ou seja, o pino positivo do LED é ligado em série com uma resistência
de 220 ohms, que por sua vez liga a um pino digital, o pino negativo é ligado ao ground do
ESP32.

No protótipo existe um circuito com um atuador de refrigeração (uma ventoinha) para uma
simulação real em vez de LED’s para fins de representação real para o produto final.

O circuito é constituído por um diodo 1N4007, um relé omron g5la-14, um transistor npn, uma
resistência de 1K e uma fonte de alimentação de 12v.
As respetivas ligações do circuito são feitas da seguinte forma:
Um dos terminais da bobina é ligado aos 5V, e o outro é ligado ao anodo do diodo, onde vai
sair outro jumper do mesmo para o coletor, o catodo do diodo é também ligado aos 5v do
ESP32.
O emissor do transistor npn é ligado ao ground, a sua base é ligada em série com uma
resistência de 1K, onde vai sair do outro terminal da resistência um jumper para o determinado
pino digital, que vai ativar ou desativar o estado do relé.
O terminal comum do relé é ligado ao terminal positivo da fonte de alimentação, e o terminal
normalmente aberto (NO) é ligado ao terminal positivo do atuador de refrigeração (a ventoinha),
o terminal negativo do atuador é ligado ao terminal negativo da fonte de alimentação.

O circuito integrado expansor de saídas digitais designado como PCF8574 utiliza o protocolo
I2C para como o nome indica, expandir as suas entradas e saídas existentes, utilizámos este
integrado no nosso protótipo com o objetivo da criação de um módulo expansor.
O seu respectivo circuito foi feito da seguinte forma:

O pino SDA do circuito integrado é ligado ao pino 21 do MCU, em conjunto com uma resistência
de 1K ohm para o strong pull-up (strong pull-up é uma técnica utilizada para dar corrente
necessária a um circuito ou pino), o SDL é ligado ao pino 22, este também com um strong pull-
up.
Os pinos A0, A1 e A2 são ligados ao ground com o objetivo de definir o endereço i2c do pcf
para 0x20, tal como o pino ground do mesmo, que como o nome indica também é ligado ao
ground.
O VCC do circuito integrado é ligado ao VIN do ESP32, e os pinos P0 até ao P7 servem para
a utilização de sensores e atuadores digitais necessários para o sistema.
Estes pinos usam também um strong pull-up com uma resistência de 1K ohm para que tenham
corrente suficiente para alimentar as suas respetivas entradas e saídas.

Depois de todos os circuitos terem sido realizados na breadboard com todos os seus
componentes, sensores e atuadores, o protótipo final ficou como mostra nas seguintes figuras.

Figura 17 - Protótipo Final

Figura 17.1
Plataformas utilizadas

Utilizámos duas plataformas diferentes ao longo do tempo, para a publicação e subscrição de

dados.

Primeiramente a ubidots que tinha todas as ferramentas necessárias para a implementação

do nosso código e projeto, dês de publicação de dados para a visualização dos mesmos em
gráficos na plataforma, até à criação de botões digitais para a subscrição de estados na
plataforma para controlo de atuadores e leds do nosso projeto.

Porém tivemos desafios ao implementar o nosso código à plataforma ubidots, mas com a
ajuda de um dos engenheiros responsáveis pela plataforma, conseguimos contornar todos
estes desafios.
Inicialmente o exemplo para conectar o ESP32 à plataforma ubidots com o protocolo MQTT
não estava a funcionar, isto porque o endereço que estava a ser utilizado no exemplo era o
incorreto, ao apresentarmos este problema ao engenheiro, foi nos dado o endereço correto.

Surgiu mais tarde um outro problema, o exemplo estava feito apenas para enviar uma variável
de dados de cada vez na payload, com o auxílio do engenheiro responsável desta área, foi
nos alterado o código para que funcionasse com o envio de diversas variáveis ao mesmo
tempo para o payload.

Nas figuras 18 (18, 18.1, 18.2, 18.3) vê-se o sucedido.

Figura 18 - Resolução de problemas com o engenheiro da ubidots

Figura 18.1
Figura 18.2
 Figura 18.3

O único contra que esta plataforma tinha era o seu trial gratuito de apenas 30 dias, portanto
para solucionar este problema, começámos por fazer uma pesquisa sobre alternativas para
esta plataforma e encontrámos a plataforma indicada, a adafruit.io.

A adafruit.io permitia que aplicássemos todo o código que foi utilizado na plataforma Ubidots
de forma mais simplificada para a nova plataforma adafruit.io, isto devido às bibliotecas que
estavam disponíveis para os utilizadores da plataforma (Adafruit_MQTT.h e
Adafruit_MQTT_Client.h).
Depois de toda a configuração (que será discutida no próximo tópico) o resultado final ficou
como mostra nas figuras 19 e 19.1.
 Figura 19 - Dashboard Adafruit.io final

Figura 19.1

Configuração das Plataformas

A primeira configuração foi na plataforma ThingSpeak para fins de testes, a configuração era
feita nas opções do canal da plataforma, onde definimos o nome do canal e mencionámos os
nomes dos feeds para determinada variável, observemos o exemplo da figura 20.
 Figura 20 - Configuração da plataforma thingspeak

A próxima configuração é relacionada com a plataforma principal da nossa dashboard, a

adafruit.io. Esta configuração é idêntica à que foi feita na plataforma ubidots, portanto vamos
dar como exemplo a plataforma final.

Primeiramente é criada uma nova dashboard clicando nas “actions” e depois na opção que
diz “Create a New Dashboard” (figura 21). De seguida, ao clicar na opção “Create a new
block” (figura 21.1) escolhemos as widgets apropriadas para as nossas variáveis: gráficos;
botões e textos para visualizar os dados em tempo real (figura 21.2). Depois criamos o feed
com o nome que está identificado no software, neste caso output1 (figura 21.3) selecionamos
e clicamos em “Next step”, mudamos o nome do bloco atribuído e o texto que enviará para o
payload e clicamos em “Create block” (figura 21.4). Finalmente clica-se no bloco “Edit
dashboard layout” (figura 21.5) para organizar todas as widgets, e clicamos em “Save layout
changes” para guardar todos os ajustes (figura 21.6).

Figura 21 - Configuração da plataforma adafruit.io

Figura 21.1

Figura 21.2

Figura 21.3
 Figura 21.4

Figura 21.5

Figura 21.6

Para a configuração de controlo por voz e para todas as notificações foi utilizado o serviço
IFTTT.
IFTTT é um serviço gratuito baseado em web para criar cadeias de instruções condicionais
simples, chamadas applets. Um applet é acionado por alterações que ocorrem em outros
serviços da web, como Gmail, Facebook, Telegram, Instagram ou Pinterest.
Abaixo explicaremos a configuração para os comandos de voz e para as notificações
consecutivamente.
Na página my applets do IFTTT existe um botão com a opção para criar um novo applet
(figura 22), de seguida clica-se no botão “+ this” para escolher um serviço para efectuar a
condição se, neste caso, como estamos a configurar o controlo por voz com o google
assistant, escolhemos a opção “Google Assistant” (figuras 22.1 e 22.2).
Clicamos no trigger (gatilho para a ação ocorrer) que é feito a partir de uma “frase simples”
(figura 22.3), é feita a respetiva configuração, isto é, as opções de frases possíveis para que o
assistente da google reconheça qual das saídas têm que controlar, como também
configuramos o que é que o assistente da google diz quando este consegue executar a
condição como mostra na figura 22.4.
Feito isto clica-se na consequência da condição “+ that” (figura 22.5), escolhe-se o serviço da
nossa plataforma, ou seja o adafruit (figuras 22.6 e 22.7) e finalmente escolhe-se o
determinado feed, para o envio da informação configurada, neste caso ON e clica-se no botão
para criar a ação (figura 22.8).

Para a configuração das notificações o procedimento é exatamente o mesmo, com exceção

da escolha de serviços, neste caso o único serviço é da adafruit, seja para a condição “+ this”
ou para a consequência “+ that”.
Nas figuras 22.9, 22.10, 22.11 e 22.12 podemos ver alguns exemplos das configurações
efetuadas para as notificações, escolhemos o feed para a notificação, a condição e a
mensagem de notificação.

Figura 22 - Configuração IFTTT

Figura 22.1

Figura 22.2

Figura 22.3
Figura 22.4

Figura 22.5
Figura 22.6

Figura 22.7
Figura 22.8
Figura 22.9
Figura 22.10
 Figura 22.11

Figura 22.12

Finalmente para a aplicação móvel “MQTT Dash” foi feita a configuração com os dados de
acesso e com os feeds necessários para cada botão digital, ou texto para a monitorização do
nosso sistema.
Abaixo será explicada a sua configuração.

Ao iniciar a APP clicamos no botão “+” para se fazer a configuração com os dados de acesso
à nossa plataforma (figura 23).
A configuração é feita através dos seguintes campos:
nome da dashboard, endereço, porta, nome de utilizador e finalmente palavra-passe, com os
dados preenchidos, finalizamos a configuração ao clicar no símbolo da disquete no canto
superior direito (figuras 23.1 e 23.2).

Feita a configuração à plataforma adafruit.io, clica-se então na dashboard (figura 23.3) e ao

clicar novamente no símbolo “+” são exibidas as opções com os widgets disponíveis para a
visualização e controlo dos dados.
Para os botões digitais, utilizamos a widget “Switch/button” (figura 23.4), a sua configuração é
feita com o preenchimento do nome do botão, localização do feed e informação que envia,
todas as outras opções que têm marcado com um certo não são alteradas.
Finalmente é feita a configuração estética, isto é, tamanho do botão, cor e símbolo, como
podemos visualizar nos exemplos das figuras 23.5 e 23.6.
Para a visualização dos dados dos sensores, utilizamos o widget “Text”, toda a sua
configuração à plataforma é idêntica à configuração dos botões digitais, as únicas diferenças
são as opções de configuração estética como o prefixo ou o sufixo dos textos. Acabando
todas as configurações, clica-se no símbolo para guardar (figuras 23.7 e 23.8).
O resultado final é visível na figura 23.9.

Figura 23 - Configuração da aplicação MQTT Dash

Figura 23.1
Figura 23.2

Figura 23.3
Figura 23.4

Figura 23.5
Figura 23.6

Figura 23.7
Figura 23.8

Figura 23.9
Desenvolvimento das PCBs

Foram desenvolvidas duas PCBs após toda a pesquisa realizada, a PCB principal (Infinity Commented [32]: PT
Smart Control) e a PCB secundária (Smart Control Extender).
Neste capítulo vamos explicar todo esse processo:

Microcontrolador ESP32

O ESP32 disponibiliza 30 Pinos como demonstrado na figura 24:

Figura 24 - Pinagem do ESP32 DevKit V1

Os pinos que não são mencionados são irrelevantes para o nosso projeto.

- VIN é o pino de alimentação do ESP32, que deve ser alimentado por uma fonte de
alimentação externa.
O VIN pode suportar entre 6 a 20 Volts, embora não seja recomendável os 20 volts devido ao
sobreaquecimento que possa ocorrer no regulador do ESP32.

- 3V3 oferece uma tensão regulada de 3.3V como saída do microcontrolador(ESP32).

- DIO são pinos digitais que podem ser configurados tanto como entradas ou saídas.

- Analog são os pinos analógicos do ESP32, estes leem tensões de uma forma muita precisa.

- GND são pinos Ground.

- SCL é o pino responsável pela comunicação do Master para os Slaves, esta comunicação é
sempre inicializada através do Master para os Slaves por um sinal que tem dois estados, 1 ou
0, alguns dispositivos Slave por vezes podem forçar o sinal Clock a 0 para impedir que o
Master envie mais data.

- SDA é o pino responsável pela transmissão de data.

Bibliotecas dos esquemáticos utilizados no Eagle Cad

Esquemático ESP32

Sendo o ESP32 o "cérebro" do Infinity Smart Control, foi fundamental a pesquisa de

bibliotecas do esquemático do ESP32, o esquemático é um esquema de todas as ligações
disponíveis do microcontrolador.
Pelo facto do esquemático pretendido não ter sido encontrado foi necessário simular o
esquemático do ESP32 de raiz, para tal utilizámos dois componentes (pinheads 1x15) como
"substituto" de cada parte lateral da pinagem do ESP32. Como cada jumper contém 15 pinos
conseguimos facilmente simular a pinagem do mesmo e assim conseguir embutir o
esquemático original do microcontrolador como representado na figura 24.

Esquemático PCF8574

O esquemático do PCF8574 foi encontrado na biblioteca principal (pré definida) do Eagle Cad
após digitar o nome do circuito integrado como demonstra a figura 25:
 Figura 25 - Esquemático PCF8574

Configurações do Eagle (Dimensões das ilhas e pistas)

Foram definidos parâmetros específicos para que na impressão das placas não ocorresse
falhas no tamanho das pistas e das ilhas, isto por ser muito comum ocorrer esse tipo de
problemas. O tamanho das pistas foi definido para 0.6 milímetros e o tamanho das ilhas dos
componentes foi definido com as seguintes medidas:

- mínimo superior 20 milímetros

- máximo superior 25 milímetros
- mínimo inferior 20 milímetros
- máximo inferior 25 milímetros
Realização da PCB principal

Figura 26 - Diagrama de blocos do Infinity Smart Control

O diagrama de blocos da figura 34 representa, de forma simplificada, os locais das respetivas

ligações da placa principal (Infinity Smart Control). De seguida, descrevemos em detalhe a
constituição da placa.

A PCB principal (Infinity Smart Control) tem um aspeto muito idêntico a um autómato, dispõe
um número total de 67 componentes electrónicos, dentro destes componentes electrónicos
encontram-se os fotoacopladores, resistências, conectores e diodos Zener.
No centro enquadra-se o ESP32 de onde saem todas as ligações para as entradas
disponíveis da board, sendo elas as digitais (parte lateral esquerda) e as analógicas (parte
lateral direita).

Com base na figura 26, iremos explicar a função de cada componente electrónico.
 Figura 27 - Componentes electrónicos da parte lateral digital

Na placa existem 11 fotoacopladores (PC817), estes foram utilizados para proteger e evitar
tensões superiores ao que as entradas digitais do ESP32 suportam.
Se for aplicado uma tensão nos pinos 1 e 2 o LED interior do fotoacoplador emite uma luz
para a base do transistor interno, se a luz for suficiente para polarizar a base, o fotoacoplador
conduz e faz a corrente circular para o ESP32.
As resistências de 1K (1000 OHMs) que se encontram à esquerda dos fotoacoplador servem
para proteger o LED interno de cada um deles para evitar danificá-los.
Os componentes “X5-1 a X7-2” são designados de con-wago W237-132 são os conectores
que vão ser utilizados para interligar atuadores à placa.
As resistências de 10k são designadas como resistências de Pull-Up servem para definir o
estado lógico a 1.
 Figura 28 - Componentes electrónicos da parte lateral analógica

A figura 27, mostra a parte lateral direita da PCB principal, os componentes electrónicos
mostrados na figura são utilizados com o objetivo de proteger cada entrada/saída analógica
do ESP32.
Os diodos representados na figura, são diodos comuns IN4004, estes não foram utilizados na
prática, a razão de terem sido utilizados no esquemático foi por oferecerem as mesmas
dimensões do que os diodos Zener.
Os diodos a serem utilizados na prática são Diodos Zener de 3.3V (IN746), porque a maioria
dos pinos do ESP32 têm um InPut máximo de 3.3V.
Os diodos Zener podem funcionar diretamente ou inversamente. Quando estão polarizados
diretamente, funcionam como um diodo comum.
Os Zeners não conduzem desde que não ultrapassem a tensão de ruptura, ao atingirem a
tensão de Zener estes permitem a passagem de correntes maiores ás de saturação dos seus
terminais.
As resistências de 15 Ohms foram calculadas com base na tensão dos sensores idealizados
a serem utilizados com um valor máximo de 5V.
Na figura 28 é mostrado os cálculos que foram realizados para os valores pretendidos para as
resistências.
 Figura 29 - Cálculos das resistências de 15 OHMs

PCF8574

O PCF8574 é um circuito integrado expansor de portas entradas que permite o controlo de 8

entradas digitais adicionais (as portas podem ser configuradas tanto como entradas ou
saídas).
A comunicação deste circuito integrado é realizada através de 2 pinos, o I2C (SDA e o SCL),
o PCF8574 é excelente para projetos em que o microcontrolador tenha um número limitado
de portas disponíveis, o que é o caso do nosso projeto.
O circuito integrado PCF8574 funciona com tensões contínuas entre 2.5 a 6V , e os pinos A0,
A1 e A2 servem para definir o endereço a ser utilizado para a comunicação I2C que vai entre
0x20 a 0x27 (o seu endereço predefinido é 0x20 (20 em hexadecimal)).
A tabela seguinte mostra as combinações possíveis para os endereços de comunicação:

Tabela 3 - Tabela de endereços possíveis de comunicação I2C

O L significa Low ou seja “0” e o H é High ou seja “1”, estes estados podem ser manipulados
de forma a obter diferentes endereços de comunicação como mencionado posteriormente.
Realização da Smart Control Extender

Figura 30 - Diagrama de blocos do Smart Control Extender

Na figura 35, o diagrama de blocos representa os locais das respetivas ligações da placa
secundária (Smart Control Extender). De seguida, descrevemos em detalhe a constituição da
placa.

A necessidade para a realização de uma PCB secundária foi pelo facto da PCB principal ser
limitada a 30 pinos e não oferecer relés.
O Smart Control Extender têm um número total de 51 componentes electrónicos, dentro
destes componentes electrónicos encontram-se os relés, resistências, conectores,
transistores e diodos.
A figura 29 mostra o esquemático do Smart Control Extender.
 Figura 31 - Esquemático Smart Control Extender

Na figura 29 existem 8 relés para cada uma das entradas adicionais oferecidas pelo PCF8574
(P0 - P7). Commented [33]: estou aqui!
A razão de utilizarmos relés na PCB secundária é pelo facto da PCB principal não conseguir
alimentar alguns atuadores que necessitam de tensões mais elevadas do que a PCB principal
fornece à Smart Control Extender. O funcionamento do relé acontece quando é aplicada uma
corrente na bobina do relé criando um campo eletromagnético sobre o contacto móvel,
atraindo-o e assim fechando-o. Quando a corrente deixa de circular pela bobina o contacto
móvel volta ao estado inicial pela a ação da mola.
Em cada relé existe dois contatos NO e NC (normalmente aberto e normalmente fechado),
estes contatos definem se o output é aberto ou fechado, por exemplo quando a bobina é
excitada e se o relé estiver com o contato NO em utilização então o contato passa a NC e
vice versa.
O conector (JP1) disponibiliza 5 contatos (VIN, GND, 3V3, SDA e SCL) estes interligam o
Smart Control Extender ao módulo principal (Infinity Smart Control).
Os pinos A0, A1 e A2 estão conectados ao ground para obtermos o endereço predefinido
(0x20) para a comunicação I2C como explicado anteriormente.
Os pinos SCL e SDA do PCF8574 estão ligados aos contatos SCL e SDA do JP1, entre a
ligação do SCL e SDA existem duas resistências Pull-Up interligadas ao contato VIN do JP1
que é responsável por receber a tensão de VIN da PCB principal.
Na base do transistor está ligada uma resistência de 1K ohm, o que irá permitir o transistor
funcionar como interruptor (ao corte e à saturação) tendo em conta o estado lógico
proveniente do PCF8574. Em cada relé tivemos o cuidado de ligar diodos invertidos em
paralelo com a bobina de relé, para proteger os componentes de acionamento neste caso os
transistores. Chama-se a este diodo, de “diodo roda livre”, porque quando estamos a controlar
uma carga indutiva (motor, relé, etc.) e desligamos irá criar um campo magnético que gera
uma tensão inversa que pode queimar o transistor de acionamento.
Em cada uma das entradas do PCF8574 (P0-P7), encontram-se resistências de 1K
designadas de “Strong Pull-UPs” estas resistências estão interligadas entre cada entrada
adicional do PCF8574 ao VIN ( alimentação da placa principal (Infinity Smart Control) ). para
que cada relé seja acionado, pois estes “Strong Pull-Ups” aumentam a corrente de cada
entrada acionada.
Não seria possível acionar os relés sem os Strong Pull-Ups, pois cada entrada do PCF8574
não fornece a corrente necessária para tal efeito.
Os conectores (X3-3 a X10-3) são conectores que servem para ligar atuadores como
lâmpadas, ventoinhas, etc.
Estes conectores oferecem 3 conexões, os pinos superiores estão ligados aos contatores NC,
os pinos centrais estão ligados aos contatores C (Comuns) e os pinos inferiores aos
contatores NO dos relés.
Design das PCBs

Figura 32 - Board da placa ESP32

Para que todos os componentes ficassem colocados de uma forma organizada foram
realizadas medidas e cálculos. A posição X corresponde à linha horizontal e a posição Y à
linha vertical como representa figura seguinte:
 Figura 33 - Demonstração das respetivas posições dos componentes.

Começando pelos conectores 20 con-wago W237-132, que estão nas extremidades da placa,
foram posicionados verticalmente de forma mais alinhada e próxima possível.
Visto que o primeiro conector das entradas digitais (canto superior esquerdo) apresenta um
valor Y de 124.4, se subtrairmos sempre por 11.6, irá dar um valor, e se subtrairmos 11.6 a
esse valor, obtemos sempre o aspecto como representado na figura 31, excepto do 5º para o
6º conector que é de 15.3 , visto que as pistas têm assim uma única hipótese de obter as
ligações corretas.
Em relação ao X foram todos definidos com o valor -5.3 para que fiquem todos alinhados em
“coluna”. Foi feito o mesmo processo para todos os restantes componentes presentes na
placa.
Nas resistências SMD, bem como nos fotoacopladores e nas resistências Pull-up, o processo
para que estes componentes fiquem alinhados horizontalmente, foi o mesmo, ou seja foi
aplicado o mesmo valor para cada sequência (conetor, resistência SMD, foto acoplador,
resistência de pull up) na posição Y.
Nas dimensões do ESP32, foi medido com um paquímetro e ajustado com a régua do EAGLE
para 26 mm de distância de largura de um conetor do outro.
As pistas estão desenhadas numa forma diagonal, pois há uma menor possibilidade de falhas
na impressão desta. O mesmo processo é realizado na Smart Extender Board
Problemas e soluções nas PCBs

Figura 34 - Demonstração da construção de uma placa inicial

Contudo, como é normal, ocorreram problemas e desafios, e sendo assim mostramos

uma das nossas placas iniciais.
Inicialmente foi estabelecido criar uma placa apenas com 4 entradas digitais e 4
entrada analógicas.
Entretanto, devido a ter sido um processo muito rápido de se concretizar e com
algumas correções a fazer, foi determinado realizar uma outra placa mais complexa e mais
completa com base nesta. Sendo assim todos os pinos de possível utilização com efeito para
o nosso projeto, foram usados.
Foram acrescentados mais 2 ligações às entradas analógicas e mais 7 ligações às
entradas digitais. Foi alterado ainda a forma de desenho e o tamanho das pistas, tal como das
respetivas ilhas e os conectores onde o ESP32 se vai encontrar embutido, pois os conetores
iniciais (con amps MTA1X15) não eram os mais indicados devido ao espaçamentos entre
onde os pinos se irão embutir.
Como a placa extensora não funciona apenas com o SCL e SDA, foi ainda
acrescentado mais um conector que deriva do pino com tensão de 3.3V, com a função de
poder alimentar a placa extensora. Foi corrigido a parte de ligação à alimentação da placa
principal, pois se esta não for alimentada, nada do que está inserido nela funciona e assim,
ainda foi acrescentado mais um conector com a função de receber tensão para alimentar a
board que então vai ligar ao pino VIN.
Para que o LED no interior do fotoacoplador suporte a tensão sem causar danos
neste, foi acrescentado uma resistência de 1K OHM. A segunda placa foi realizada sem
problemas e sem reparações a fazer. O progresso das placas envolveu ainda muita pesquisa,
recolha de informação e muito raciocínio, para que os objetivos a atingir fossem criados com
sucesso e sem problemas a reter.

Na impressão destas ocorreram alguns problemas sendo que muitas das pistas
revelaram-se com algumas falhas. Consequentemente para corrigir o devido problema de
uma forma mais rápida, utilizamos solda por cima de onde era suposto estar revelado o cobre
desejado. Devido a não observarmos um aspeto mais profissional e de uma melhor estética
decidimos procurar ajuda e sendo assim conseguir aumentar uma melhor definição

Processo de impressão e montagem das placas

Após a conclusão dos passos anteriores, passámos então à fase da construção física e
prática das 2 placas.
Para a construção foram realizados vários passos.
A fase de corte das placas de monoface foi o primeiro passo, é chamada placa mono face
devido ao facto de ter apenas uma face onde é possível imprimir o circuito desejado,
enquanto que a placa de dupla face é possível a impressão de frente e verso.

A impressão das placas foi o segundo passo, para isto foram imprimidos os desenhos
realizados no eagle das placas usando uma impressora comum, com as definições de
impressão a alta qualidade e a opção “folha de papel vegetal”, para uma folha de papel
vegetal. Para que fossem reveladas nas placas usámos uma máquina de impressão de luz
ultravioleta. Esta máquina faz a revelação do desenho que se encontra nos papeis vegetais
para as placas a serem desenvolvidas através da luz ultravioleta, que é transmitida na
revelação. O tempo necessário para as impressões foi de 150 segundos e estas foram
realizadas com a luminosidade baixa na sala para que não influenciasse as suas impressões.

Após as impressões das placas colocámos estas de molho num primeiro ácido para remover
o verniz, ou seja este processo foi realizado até que ficassem reveladas as pistas e as ilhas.
Depois colocou-se a placa num segundo ácido para remover todo o cobre com uma duração
aproximada de 20 minutos.
Com todos os passos anteriores concluídos limpou-se a placa, e começamos então a furação
das ilhas com uma broca de 0.75mm para os furos mais pequenos e entre 0.85mm a 1mm
para os furos maiores (furos dos zeners).
Com a furação feita, passámos à parte da microsoldadura, que consistiu em soldar os
respetivos componentes nos respetivos locais.
Testes ao sistema desenvolvido

Ao longo de todo o projeto foram realizados alguns testes para a aprendizagem de alguns
circuitos e para a compreensão de alguns sensores, também como protocolos de
comunicação ou bibliotecas para o ESP32, e todo o seu funcionamento.

Foi necessário fazer testes individuais para cada sensor, esses testes serviram para aprender
o seu funcionamento, ou para entender como funcionam, cada sensor era um caso diferente,
por exemplo, o dht22, que para ler valores era necessário o auxílio de uma biblioteca, não só
para o sensor como também para o MCU, ou seja a biblioteca do dht22 para o arduino não
funcionava para o ESP32, e devido a isso foi necessário realizar testes com várias bibliotecas
para saber qual biblioteca seria a apropriada para o funcionamento do sensor com o MCU.
Houve outros testes com sensores onde não havia problemas com bibliotecas, pois não eram
necessárias para o seu funcionamento, visto que tais sensores liam os valores diretamente a
partir das entradas ADC do ESP32, porém inicialmente não entendemos o porquê de lermos
valores tão altos até 4095, com alguns testes e pesquisa, percebemos que tinha a haver com
a resolução do ESP32, que era de 12 bits e não de 10 como o arduino.
Houve também outros testes simples para a aplicação de determinados sensores para o
nosso código.
Foi feito também testes de possíveis circuitos para o funcionamento de atuadores com
tensões superiores às que o ESP32 nos possibilita, testámos vários circuitos, circuitos com
relés, transistores e resistências, e determinámos que a melhor solução para este problema
eram circuitos com relés.

Depois de todos os testes com os sensores e atuadores, passámos a fazer testes ao

funcionamento do ESP32, testámos os exemplos que vinham com o API do ESP32 e
aplicámos ao nosso código, começamos por aplicar as nossas ideias com a funcionalidade
local de WI-FI.
Fizémos uma pequena dashboard com HTML no servidor web do ESP32 e aplicámos botões
e texto para a visualização e controlo de dados em tempo real, depois deste teste ter tido
sucesso com a monitorização dos mesmos, aplicámos o mesmo código e ideias com o
protocolo MQTT que permitiu o mesmo controlo, mas de forma remota a partir de qualquer
lugar do mundo.
Utilizamos a plataforma ThingSpeak para efectuar testes de envío de simples dados tais
como a temperatura e humidade com o protocolo MQTT. Podemos observar o sucedido na
figura 33.

Figura 35 - Testes nos dados de temperatura e humidade.

Depois de terem sido finalizados todos os testes simples com os dados enviados do ESP32
para a plataforma thingspeak, passámos para o próximo passo, que foi encontrar uma
plataforma que nos desse a funcionalidade de subscrever dados para além de os publicar, e
encontrámos a plataforma ubidots, que mais tarde foi substituída pela adafruit.io.

Contributo Individual para o Projeto

Neste projeto trabalhámos em equipa, no entanto, cabe aqui realizar uma reflexão pessoal
sobre o nosso desempenho individual.

x.1) Alison Peniche

No nosso projeto, fui responsável maioritariamente pela parte da electrónica (Hardware), um
dos meus colegas (o Rodrigo Martins), trabalhou comigo nesta área apesar de termos dividido
tarefas.
A ideia principal foi construir uma placa que tivesse como núcleo o ESP32 que é o
microcontrolador principal do projeto pelo facto de disponibilizar o IoT (Internet Of Things).
Para a construção desta placa foi necessário fazer uma pesquisa muito extensa e o meu
colega ajudou-me na pesquisa.
Eu pesquisei de forma a encontrar soluções para a proteção das entradas analógicas do
ESP32 na placa. Enquanto que o Rodrigo fez a pesquisa para a proteção das entradas
digitais do ESP32 na placa.
Após a minha pesquisa, e a pesquisa do meu colega avançámos para a esquematização da
placa principal usando o software Eagle CAD.
No Eagle CAD tive que procurar todos os componentes necessários para a construção da
placa, o que foi mais demorado foi a organização das pistas da placa no software Eagle CAD,
pois foi necessário várias tentativas para o produto final.
A placa secundária foi uma inovação minha e do meu colega Rodrigo.
Inicialmente, esta placa não iria disponibilizar relés, só iria disponibilizar mais entradas
digitais, no entanto foram adicionados para podermos interligar actuadores de elevada
tensão.
Mas para tal efeito, tive que pesquisar sobre o circuito a ser desenvolvido para a inclusão dos
relés.
A pesquisa e a adaptação do circuito foi concluída com êxito, embora tivesse que alterar o
modelo do relé porque este modelo não correspondia às dimensões e características para o
circuito pretendido.
A furação das PCBs foi realizada por mim, e fui o responsável pela micro soldadura da placa
secundária.
Ao longo deste projeto aprendi muito acerca do protocolo de comunicação I2C, e apesar de já
ter conhecimento no software Eagle Cad aumentei este conhecimento para além daquele que
já tinha na criação das placas eletrónicas mais complexas desenvolvidas.
Enfrentei alguns obstáculos ao longo deste projeto, como por exemplo problemas de
sobreposição das pistas que poderiam gerar curtos circuitos em ambas as placas e tentativas
falhadas nas revelações das placas.
Apesar de todos estes obstáculos consegui concluí-los, como também aprofundei o trabalho
em equipa, pois todos nós contribuímos imenso neste projeto.

x.2) Iuri Peniche

Ao longo deste projeto, o meu enfoque foi maior no desenvolvimento do código para o
sistema, na configuração das plataformas e no desenvolvimento do protótipo.
No desenvolvimento do código, realizei a pesquisa e os testes necessários sobre as
bibliotecas que necessitasse para o desenvolvimento do código, bibliotecas de (sensores,
atuadores, para o protocolo de comunicação MQTT, e bibliotecas necessárias para a
plataforma).
Implementei todo o código que permite o uso dos modos automatizados para o sistema, como
também para a incrementação dos mesmos.
Para além disso trabalhei na área de segurança do sistema, as notificações da aplicação e de
SMS, e o sistema de detecção de movimento.
No setor de configuração tive como responsabilidade, a configuração das plataformas que
utilizámos para o nosso sistema (Dashboard da Adafruit.IO, aplicação móvel, e plataforma de
notificações e controlo por comandos de voz).
Estive também encarregado pelo desenvolvimento do protótipo, isto porque, como tinha a
função do desenvolvimento do código e a função da configuração das plataformas, tinha a
vantagem de implementar mais funções e de realizar alterações futuras no código, visto que
as três áreas são dependentes umas das outras.
Ao longo do projeto fui responsável por algumas das inovações e soluções do nosso projeto,
tais como a implementação do controlo do sistema por comandos de voz, com a utilização do
assistente da Google, e a incrementação de uma aplicação para dispositivos móveis para o
controlo do mesmo, visto que existe dispositivos móveis mais antigos que não têm um
navegador web suficientemente avançado para interagir com a dashboard na plataforma
adafruit.io, fui também responsável pela resolução de problemas no código em relação à
incompatibilidade com as plataformas.
Ao longo de todo o projeto no que diz respeito ao desenvolvimento nestas três áreas, aprendi
muitas coisas novas, protocolos, sensores como o DHT22 e o sensor de humidade de solo, a
aplicação da programação em contexto real, entre outras vertentes que estive a trabalhar com
os meus colegas, como o desenvolvimento de PCBs de maiores dimensões.
Porém ao longo do projeto deparei-me com alguns desafios, como foi o caso com a
compreensão do protocolo de comunicação MQTT, e a aplicação do mesmo no código.
Com este projeto conseguimos aprofundar o nosso trabalho de equipa devido à diversidade
de conhecimentos de cada membro, permitindo a resolução dos problemas encontrados de
forma mais eficaz, resultando no reforço das competências de cada um.

x.3) Rodrigo Martins

Visto que cada elemento ficou mais focado na parte em que se sentia mais à vontade e com
mais conhecimento, eu tratei então mais em conjunto com o meu colega Alison a parte de
hardware. Ficando nós os dois encarregues por esta parte de hardware, subdividimos as
tarefas, começando por organizar um esquema para saber que componentes precisou bem
como os cálculos (já mencionados na página “X” relatório) para definir quais os valores
precisos para os componentes eletrónicos como as resistências e os diodos zener.
Contudo estudei as funções do ESP32 para perceber então quais as entradas
digitais bem como podem estas ser protegidas para não danificar o microcontrolador bem
como as ligações a fazer, para que entretanto começar a montar o esquema da placa
principal. Visto que foi subdividido e de uma forma de simplificar o trabalho, unimos ambas as
nossas informações a níveis destes dos tipos de entradas e então avançámos para uma
próxima etapa. Pesquisei várias maneiras possíveis de encontrar o modelo ideal para o
ESP32 e cheguei à conclusão de não haver nenhum modelo específico, ocorrer a solução de
“fazer manualmente” o modelo do microcontrolador. Sendo esta a placa principal, obteve-se
uma placa com muitas pistas, e para que tudo estivesse certo sem nenhum curto circuito e de
uma forma mais bonita a nível estético abdiquei de várias horas e de algumas aulas, e sendo
estas necessárias para que nenhum erro acontecesse.
Como a parte de hardware envolve programas como o Eagle Cad bem como o
desenvolvimento e desenho de placas, fiquei responsável então pelo processo desde o início,
o esquemático até ao fim, a impressão e soldadura para esta e devido a esta utilização
aumentei a minha prática relativamente projetos anteriores .
Com o decorrer do nosso projeto e com o bom desempenho deste foi implementado e
desafiado assim realizar uma segunda placa, que é a extender board, ou seja a extensora
que envolve o PCF8574 visto que queríamos dar mais algum extra ao nosso trabalho eu e o
meu colega Alison tivemos a ideia de assim aumentar a possibilidade do uso de sensores ou
atuadores incluindo relés que assim permite utilizar então os tais atuadores.
Contudo, aprendi duma forma mais aprofundada e quais as funções dos componentes
utilizados nas placas devido a perceber o porquê da sua necessidade de utilização.
Com este projeto consegui perceber o quanto empenhado uma pessoa deve ser, perante uma
prova como esta e quanto é importante é para nós, organizar as tarefas entre outras coisas
com o tempo definido com as tarefas definidas. Superei dificuldades como sobreposições de
pistas e até algumas falhas que ocorreram na revelação mas com tempo e com persistência
consegui chegar ao objetivo.
Ainda assim conseguimos aprofundar o nosso trabalho de equipa devido à diversidade de
conhecimentos de cada membro que assim entre ajudamo-nos uns aos outros e
consequentemente permitir uma boa resolução dos problemas encontrados de forma mais
eficaz, resultando no reforço das competências de cada um.

Conclusão
Na nossa prova de aptidão profissional surgiu-nos a ideia de fazer um sistema autónomo
universal e de segurança para o controlo de qualquer tipo de sistema dependente do
manuseamento humano.
Focamos então este sistema autónomo a uma estufa devido ao facto de uma estufa
necessitar de um grande auxilio da mão humana.

Inicialmente tínhamos em mente um sistema que usasse apenas uma dashboard num
navegador web para o controlo dos modos autónomos, e um pequeno sistema de segurança
implementado no mesmo.
Superámos todas as expectativas iniciais, e aplicámos mais funcionalidades ao nosso projeto,
isto na área de software como também na área de eletrónica, entre estas, controlo por
comandos de voz, uma aplicação móvel com o mesmo objetivo da dashboard, notificações
com a aplicação IFTTT e SMS e um módulo expansor de entradas e saídas à parte do
módulo principal com o protocolo de comunicação I2C e o circuito integrado PCF8574.
Desenvolvemos duas placas eletrónicas, a primeira (Infinity Smart Control), que usa o ESP32
(um microcontrolador) como o “cérebro”. O ESP32 é programável e de baixo custo e baixo
consumo de energia. Esta placa oferece também entradas analógicas e digitais para os
respectivos sensores a serem utilizados para a estufa (sensor de luminosidade, sensor de
temperatura, sensor de humidade, etc).
A placa secundária (Smart Control Extender), é uma placa que permite aumentar o número de
entradas digitais da placa principal graças ao PCF8574 como mencionado anteriormente. A
diferença da placa secundária e a principal, é que a secundária oferece relés em cada
entrada digital adicional para que possamos ligar atuadores que necessitem de tensões mais
elevadas do que a placa principal fornece, por exemplo ventoinhas, motores, lâmpadas de
filamento, etc.
Conseguimos concluir os nossos objetivos iniciais e até para além destes.
Por outro lado surgiu-nos outras ideias para além das iniciais durante o processo de
desenvolvimento do projeto que gostaríamos de implementar no futuro, como por exemplo o
desenvolvimento de invólucros de plástico para cobrir cada uma das placas e incorporar as
LEDs na placa principal que nos notifica que estamos conectados à cloud tal como foi feito no
protótipo.