Figura 1: Sistema de Controle de Estufa Inteligente - arquitetura conceitual do sistema proposto.
O sistema projetado é um dispositivo "always-on" que automatiza as tarefas de manutenção de uma estufa, agrupadas em três domínios principais: * **Controle Climático (Núcleo):** * Monitora continuamente a temperatura do ar, a umidade do solo e a luminosidade. * Atua automaticamente em relés para ligar/desligar ventiladores (controle de temperatura), bombas d'água (irrigação) e LEDs de crescimento (fotoperíodo). * **Controle de Qualidade e Segurança:** * Monitora a qualidade do ar (níveis de CO2/gases voláteis) e aciona a exaustão se os níveis se tornarem perigosos [8]. * Detecta o status de portas/janelas (aberta/fechada) usando sensores magnéticos. * Detecta presença humana no interior da estufa usando um sensor de movimento. * **Interface e Interação (HMI):** * Permite ao usuário ajustar manualmente os setpoints (ex: temperatura alvo) via Encoder Rotativo. * Fornece feedback local via Display OLED (que liga automaticamente com a presença) e LED RGB (indicador de status). * Emite alarmes sonoros (Buzzer) para condições críticas (temp. extrema, porta aberta por muito tempo, gás elevado). * Publica todos os dados de sensores e recebe comandos via Wi-Fi (MQTT). ### 2.2. Público-Alvo e Contexto de Uso
Figura 2: Exemplo de estufa agrícola - ambiente típico de aplicação do sistema proposto.
A solução se destina a três perfis de usuários com necessidades distintas: * **Hobbista / Horticultor Urbano:** Busca automação para reduzir o trabalho manual e garantir a saúde das plantas durante ausências (férias). Valoriza o baixo custo, a facilidade de uso (OLED, Encoder) e o monitoramento remoto (App via MQTT). * **Pesquisador / Instituição Acadêmica:** Necessita de um ambiente de cultivo rigorosamente controlado (fitotron). Valoriza a coleta de dados (datalogging) para análise posterior e a capacidade de replicar condições ambientais específicas. A capacidade de registrar dados de gás, luz e temperatura é crucial [5]. * **Pequeno Produtor Comercial:** Foca no ROI (Retorno sobre Investimento). O sistema visa otimizar o uso de recursos (água, energia), prevenir perdas (alarmes de temperatura e porta) e padronizar a qualidade da produção. ### 2.3. Análise de Mercado Produtos comerciais (como Growlink, AgroSmart) se diferenciam da nossa proposta de protótipo não apenas nas funções, mas na robustez dos componentes: * **Sensores Ambientais:** Em vez do DS18B20, usam sensores I2C/SDI-12 de alta precisão como o Bosch BME280 ou Sensirion SHT31, que medem temperatura, umidade e pressão com calibração de fábrica. * **Sensores de Solo:** Onde usamos um sensor resistivo (Sensor de Chuva), o mercado usa sensores capacitivos. Eles medem a constante dielétrica do solo e não sofrem de corrosão eletrolítica, oferecendo meses ou anos de operação sem manutenção. * **Conectividade:** Onde usamos Wi-Fi (curto alcance), sistemas rurais dependem de LoRaWAN ou NB-IoT para cobrir longas distâncias com baixo consumo de energia, um dos maiores desafios da agricultura inteligente [4]. ### 2.4. Justificativa da Proposta Acadêmica Este projeto é um exercício acadêmico ideal pois: * **Explora Múltiplos Domínios:** Força o projetista a lidar com sinais analógicos (LDR, Gás), digitais (Reed, PIR), protocolos de barramento (I2C, One-Wire) e comunicação de rede (Wi-Fi). * **Impõe Restrições Reais:** A obrigação de usar a lista de componentes da disciplina simula um cenário real de engenharia, onde o projetista deve otimizar o design para um "Bill of Materials" (BOM) restrito, usando de forma criativa (ex: Sensor de Chuva como sensor de solo). * **Requer Software Robusto:** Um sistema com tantas entradas e saídas não pode ser implementado com um `loop()` simples. Ele exige uma arquitetura de software que gerencie estados, timers e interrupções para funcionar de forma confiável. ----- ## 3\. Análise Técnica do Funcionamento ### 3.1. Detalhamento das Tecnologias Críticas A operação deste sistema complexo depende da orquestração de múltiplas tecnologias de hardware e software pelo ESP32. * **ESP32 e o ESP-IDF (FreeRTOS):** O microcontrolador ESP32 é o cérebro. Sua arquitetura dual-core (Xtensa LX6) é uma vantagem significativa. A arquitetura padrão do ESP-IDF (o framework de desenvolvimento oficial) reserva o Core 0 para tarefas de baixo nível (stack de Wi-Fi e Bluetooth) e libera o Core 1 inteiramente para o código do usuário. Além disso, o ESP-IDF é construído sobre o FreeRTOS (Sistema Operacional de Tempo Real), permitindo a criação de tarefas (tasks) concorrentes. Em uma versão final, em vez de um loop monolítico, teríamos tarefas separadas para `task_sensores`, `task_controles`, `task_mqtt`, etc., garantindo que uma tarefa (como publicar dados) não bloqueie outra (como verificar um alarme crítico). * **Barramento I2C (Inter-Integrated Circuit):** É um protocolo de barramento serial, síncrono, mestre-escravo, que usa dois fios: Serial Data (SDA) e Serial Clock (SCL). Em nosso projeto, o ESP32 atua como mestre e o Display OLED como escravo. A principal vantagem é o endereçamento: múltiplos dispositivos (ex: um OLED, um BME280) podem compartilhar os mesmos dois pinos, cada um respondendo ao seu endereço único. * **Barramento One-Wire:** É um protocolo de barramento mestre-escravo que, notavelmente, requer apenas um pino de dados (e o GND). É a tecnologia do DS18B20. Cada sensor possui um ID único de 64 bits gravado a laser, permitindo que múltiplos sensores de temperatura sejam ligados no mesmo pino GPIO, uma enorme economia de pinos. O ESP32 (mestre) envia um comando de "iniciar conversão" no barramento e, após \~750ms, lê o resultado de todos os sensores (escravos) individualmente. * **Protocolo MQTT (Message Queuing Telemetry Transport):** É a tecnologia central da nossa comunicação IoT [3]. Diferente do HTTP (modelo cliente-servidor), o MQTT usa um modelo Publish-Subscribe (Pub/Sub). * Um **Broker** (servidor central) gerencia os "tópicos". * O **ESP32** (Cliente) "publica" dados em tópicos (ex: `estufa/temperatura`, `25.5`). Ele não sabe nem se importa quem está ouvindo. * Um **Aplicativo** (Cliente) "assina" esses tópicos (ex: `estufa/temperatura`) e recebe os dados instantaneamente do Broker. * Este modelo é leve, rápido e ideal para sistemas embarcados, pois minimiza o tráfego de rede e o processamento no dispositivo. * **Interfaces GPIO (General-Purpose Input/Output):** São a forma mais direta de comunicação. * **Entrada Digital:** Reed-Switch, Botão do Encoder, Sensor de Movimento. Lógica binária (0 ou 1, LIGADO ou DESLIGADO). * **Entrada Analógica (ADC):** LDR, Sensor de Chuva, Sensor de Gás. Esses sensores variam sua resistência, e o ESP32 usa seu Conversor Analógico-Digital (ADC) para traduzir uma voltagem (ex: 0-3.3V) em um valor numérico (ex: 0-4095), permitindo leituras de intensidade. * **Saída Digital:** Relés, Buzzer Ativo, LED RGB. O ESP32 envia um sinal LIGADO (3.3V) ou DESLIGADO (0V) para controlar esses atuadores. * **Interrupções (ISRs) vs. Polling:** Esta é a decisão de software mais crítica para a responsividade do sistema. * **Polling (Verificação):** O `loop()` principal pergunta a cada sensor, um por um: "Você mudou?". Isso é ineficiente e lento. Se o `loop()` estiver ocupado (ex: atualizando o display), o sistema pode não perceber que o usuário girou o encoder. * **ISR (Interrupção):** Configuramos o ESP32 para "escutar" mudanças em pinos específicos (ex: os pinos do Encoder Rotativo e do Sensor de Movimento). Quando uma mudança ocorre (o encoder gira, o PIR detecta movimento), o hardware pausa o `loop()` principal, executa uma função de interrupção (ISR) (ex: `on_movimento_detectado()`), atualiza uma variável (ex: `presenca_detectada = TRUE`), e retorna ao `loop()`. Isso garante que nenhuma ação do usuário ou evento de segurança seja perdido. ----- ## 4\. Proposta de Reprodução com ESP32 ### 4.1. Detalhamento dos Componentes Selecionados A tabela abaixo detalha cada componente da lista da disciplina, sua função no projeto, a interface de hardware utilizada e a justificativa técnica da escolha. | Categoria | Componente (Lista da Disciplina) | Função no Projeto | Interface/Protocolo | Justificativa Técnica da Escolha | | :--- | :--- | :--- | :--- | :--- | | **Microcontrolador** | ESP32 DevKit V1 | Unidade central de controle (Cérebro) | Wi-Fi, I2C, One-Wire, GPIO, ADC | Escolha principal devido à conectividade Wi-Fi nativa para IoT, alto poder de processamento (Dual-Core, FreeRTOS) e número de pinos suficiente para o projeto. | | **Controle Manual** | Encoder Rotativo + Botão | Ajustar setpoints (T° alvo) e acionar ações (irrigação manual). | GPIO Digital (com ISRs) | Superior a um potenciômetro por permitir ajuste incremental infinito e preciso (sem fim de curso). O botão integrado oferece uma segunda entrada. | | **Sensor (Temperatura)** | Sensor Digital DS18B20 | Medir a temperatura do ar ambiente. | One-Wire (Digital) | Sensor digital com ID único. Permite alta precisão e a adição de múltiplos sensores no mesmo pino, ideal para monitorar diferentes zonas da estufa. | | **Sensor (Umidade Solo)** | Sensor de Chuva | Medir a umidade do solo (por condutividade). | GPIO Analógico (ADC) | Adaptação de componente. Usado de forma criativa (inserido no solo) para medir a condutividade elétrica entre suas trilhas, que varia com a umidade. | | **Sensor (Luz)** | LDR (Fotoresistor) | Medir a intensidade da luz ambiente. | GPIO Analógico (ADC) | Sensor analógico simples e eficaz para determinar se a luz natural é suficiente ou se os LEDs de crescimento devem ser acionados. | | **Sensor (Qual. Ar)** | Sensor de Gás | Detectar níveis de CO2 / Amônia / Gases voláteis. | GPIO Analógico (ADC) | Essencial para a saúde das plantas (CO2) e segurança (outros gases). Aciona a ventilação de exaustão em níveis elevados. | | **Sensor (Segurança)** | Chave Magnética (Reed-Switch) | Detectar se a porta ou janela está aberta. | GPIO Digital | Sensor de segurança crítico para eficiência energética (evitar perda de clima controlado) e para alarmes de acesso. | | **Sensor (Segurança)** | Sensor de Movimento (PIR) | Detectar presença humana na estufa. | GPIO Digital (com ISR) | Usado para ligar a tela OLED sob demanda (economia) e para fins de segurança (detectar movimento em horários não autorizados). | | **Atuador (Controle)** | Relé 1 Canal | Acionar a Bomba d'Água (carga AC). | GPIO Digital | Interface de potência. Permite que o ESP32 (3.3V, baixa corrente) controle uma bomba d'água (ex: 110V/220V, alta corrente) de forma segura. | | **Atuador (Controle)** | Relé 2 Canais | Acionar o Ventilador e os LEDs de Crescimento. | GPIO Digital | Mesmo princípio do relé de 1 canal, mas otimizado para controlar duas cargas de potência (Ventilador, Luzes) de forma independente. | **Imagens dos Sensores e Componentes:** | Sensor de Temperatura DS18B20 | Sensor de Umidade de Solo | Sensor de Luz (LDR) | |:---:|:---:|:---:| |
| 
| 
|
| Sensor de Qualidade do Ar | Sensor de Segurança Porta/Janela | Sensor de Presença |
|:---:|:---:|:---:|
| 
| 
| 
|
| Relé 1 Canal | | |
|:---:|:---:|:---:|
| 
| | |
| **Atuador (Feedback)** | Buzzer Ativo | Emitir alarme sonoro para condições críticas. | GPIO Digital | Atuador de feedback auditivo. "Ativo" significa que basta um sinal de LIGA (3.3V) para ele emitir um som fixo, simplificando o código. |
| **Atuador (Feedback)** | Led RGB 5mm | Emitir feedback visual de status. | GPIO Digital (x3) | Feedback visual de alta fidelidade (Verde=OK, Azul=Irrigando, Vermelho=Alarme). Usa 3 pinos (R, G, B) ou PWM para cores misturadas. |
| **Atuador (Interface)**| Tela OLED 0.98" (I2C) | Exibir dados locais para o usuário. | I2C (Digital) | Interface de feedback visual principal. I2C permite alta taxa de dados usando apenas 2 pinos, e a tecnologia OLED oferece alto contraste e zero consumo em pixels pretos. |
### 4.2. Diagrama Conceitual
O diagrama de blocos a seguir ilustra a arquitetura completa do sistema, mostrando o fluxo de dados e controle entre os módulos.
Figura 3: Diagrama de blocos do sistema - mostra a interconexão entre sensores, microcontrolador ESP32, atuadores e interface de comunicação.
### 4.3. Lógica de Controle e Arquitetura de Software A robustez do sistema é definida pelo seu software. Uma arquitetura baseada em máquina de estados, timers e interrupções é essencial. Para atender à solicitação de focar no detalhamento conceitual sem pseudocódigo, a lógica de programação é descrita textualmente a seguir. #### 4.3.1. Gerenciamento de Estado, Setpoints e Histerese O núcleo da lógica de controle opera comparando as leituras atuais dos sensores com setpoints (valores-alvo) configuráveis pelo usuário e limites de segurança fixos. * **Setpoints:** O usuário, através do Encoder Rotativo, pode ajustar os valores-alvo principais, como a temperatura desejada (`setpoint_temp`, ex: 25°C), o nível de umidade do solo (`setpoint_umidade_solo`) e o limiar de luz (`setpoint_luz`). * **Limites de Alarme:** Valores fixos são definidos no software para condições perigosas (ex: `TEMP_CRITICA_ALTA` em 35°C, `GAS_CRITICO` em 700ppm). * **Histerese:** Para evitar que os relés (ventilador, bomba) liguem e desliguem rapidamente (conhecido como "flickering") quando a leitura flutua em torno do setpoint, uma banda de histerese é aplicada. Por exemplo, com um `setpoint_temp` de 25°C e histerese de 1°C, o ventilador só ligaria ao atingir 26°C (`setpoint` + histerese) e só desligaria ao cair abaixo de 24°C (`setpoint` - histerese). #### 4.3.2. Responsividade via Interrupções (ISRs) Para garantir que o sistema responda instantaneamente a ações do usuário ou eventos de segurança, o uso de Interrupções de Hardware (ISRs) seria fundamental, em vez de depender de verificação (polling) no loop principal. * **Controle Manual:** A rotação do Encoder Rotativo e o clique de seu botão seriam capturados por ISRs. Isso garante que, mesmo que o sistema esteja ocupado (ex: publicando dados via Wi-Fi), o ajuste do setpoint pelo usuário seja registrado imediatamente. * **Segurança e Eficiência:** O Sensor de Movimento (PIR) também seria ligado a uma ISR. Ao detectar movimento (`onMovimentoDetectado()`), ele definiria uma flag de "presença detectada" e resetaria um timer. Isso permite que a tela OLED ligue instantaneamente, sem atrasos perceptíveis. #### 4.3.3. Fluxo de Operação (Arquitetura Não-Bloqueante) O fluxo principal do software (o `loop()`) seria projetado para ser não-bloqueante, utilizando a técnica de "Blink Without Delay" (timers baseados em `millis()`). Isso é crucial para um sistema embarcado que precisa gerenciar múltiplas tarefas concorrentes (ler sensores, controlar relés, atualizar tela, escutar a rede) sem que uma tarefa "trave" as outras. * **Inicialização (`setup()`):** A função de setup inicializaria todos os pinos de GPIO, configuraria as interrupções (ISRs), inicializaria os protocolos de barramento (I2C para o OLED, One-Wire para o DS18B20) e estabeleceria a conexão com o Wi-Fi e o broker MQTT. * **Loop Orquestrado:** O `loop()` principal atuaria como um orquestrador, verificando timers: * **Timer de Sensores** (ex: a cada 2 segundos): Chama a função `lerSensores()` (DS18B20, LDR, Gás, Chuva, Reed). * **Timer de Lógica** (ex: a cada 500ms): Chama a função `processarLogica()` (compara leituras com setpoints e aciona relés). * **Timer de Interface** (ex: a cada 250ms): Chama `atualizarInterface()` (atualiza o LED RGB e o OLED). * **Timer de Rede** (ex: a cada 60 segundos): Chama `publicarMQTT()` (envia dados para a nuvem). * **Manutenção de Rede:** Em cada ciclo do `loop`, a função `manterConexaoMQTT()` seria chamada para garantir que a conexão com o broker esteja ativa. #### 4.3.4. Lógica de Controle Detalhada * **Controle Climático:** A função `processarLogica()` conteria a lógica de histerese para o ventilador (baseado na `temp_atual` e `gas_atual`). A irrigação seria acionada se a `umidade_solo_atual` caísse abaixo do setpoint, mas funcionaria com um timer (ex: "ligar bomba por 10 segundos") para evitar encharcamento. * **Lógica de Segurança:** Esta função gerenciaria os timers de alarme. Se o Reed-Switch indicasse "porta aberta", um timestamp seria salvo. Se `millis() - timestamp_porta_aberta` ultrapassasse 5 minutos, uma flag de alarme de porta seria ativada. * **Lógica de Feedback (LED e Buzzer):** A função `atualizarInterface()` operaria um sistema de prioridade. Alarmes críticos (Temperatura Extrema, Gás Crítico, Porta Aberta) teriam a prioridade mais alta, setando o LED RGB para Vermelho e ligando o Buzzer, independentemente de qualquer outro estado. Se não houvesse alarme, o LED indicaria ações (ex: Azul para irrigação) ou estado normal (Verde). * **Lógica de Eficiência (OLED):** A mesma função de interface verificaria a flag de "presença detectada" (controlada pela ISR do PIR). Se houvesse presença, a tela ligaria. Se `millis() - ultimo_movimento_timestamp` ultrapassasse 1 minuto, a tela desligaria para economizar energia. ----- ## 5. Pesquisa Bibliográfica e Tecnológica A proposta não se baseia apenas em componentes, mas em práticas estabelecidas na literatura acadêmica. ### 5.1. Síntese da Pesquisa A literatura revisada [2, 3, 4, 8] converge em um ponto: a agricultura de precisão está migrando de sistemas de monitoramento passivos para sistemas de controle ativos e conectados (IoT). O ESP32 é frequentemente citado [2] como uma plataforma de prototipagem ideal devido ao seu Wi-Fi e LoRa integrados. Os artigos [4, 8] destacam que os maiores desafios não são o hardware, mas a conectividade em larga escala (daí a pesquisa em LoRaWAN) e o gerenciamento de dados [6]. Nosso projeto aborda o primeiro desafio superficialmente (com Wi-Fi/MQTT) e o segundo ao fornecer os dados brutos para futuras análises de Machine Learning [5] ou até mesmo rastreabilidade via Blockchain [7]. ### 5.2. Resumos Individuais dos Artigos * **[1] Espressif Systems (2022). “ESP32 Technical Reference Manual.”** * **Resumo:** Documento técnico oficial que detalha a arquitetura do ESP32, incluindo periféricos (GPIO, I2C, SPI), modos de *deep-sleep* e gerenciamento de rádio (Wi-Fi/Bluetooth). Fundamental para entender o hardware base. * **[2] Verma, A. & Bodade, R. (2025). “Design and Implementation of a Low-Cost IoT-Based Smart Agricultural System Using ESP32 and LoRa Technology.”** * **Resumo:** Apresenta a implementação de um sistema agrícola inteligente e de baixo custo com ESP32 e LoRa. O trabalho integra sensores de umidade do solo, temperatura e umidade do ar, além de um módulo ESP32-CAM para captura de imagens. Destaca a escalabilidade e o baixo custo como fatores-chave. * **[3] Jawhar, I. et al. (2024). “An Efficient and Scalable Internet of Things Framework for Smart Farming.”** * **Resumo:** Propõe um *framework* de IoT escalável baseado em redes sem fio de sensores e atuadores (WSAN) para otimizar o uso de água e monitorar o ambiente agrícola. Os resultados mostram redução no consumo hídrico e aumento da confiabilidade do sistema. * **[4] Tzounis, A. et al. (2017). “Internet of Things in Agriculture: Recent Advances and Future Challenges.”** * **Resumo:** Revisão abrangente sobre tecnologias IoT aplicadas à agricultura, abordando comunicação via WSN, LoRaWAN e computação em nuvem. Identifica desafios de interoperabilidade e padronização. * **[5] Chlingaryan, A. et al. (2018). “Machine Learning Approaches for Crop Yield Prediction and Nitrogen Status Estimation in Precision Agriculture.”** * **Resumo:** Revisa técnicas de *machine learning* aplicadas à predição de produtividade e estimativa de nitrogênio. Demonstra o potencial de integração entre sensores embarcados e algoritmos de aprendizado. * **[6] Wolfert, S. et al. (2017). “Big Data in Smart Farming – A Review.”** * **Resumo:** Analisa como grandes volumes de dados agrícolas podem ser processados para apoiar decisões em tempo real e prever cenários produtivos. Destaca questões de governança e modelos de negócio para compartilhamento de dados. * **[7] Kamilaris, A. et al. (2019). “The Rise of Blockchain Technology in Agriculture and Food Supply Chains.”** * **Resumo:** Examina o uso de *blockchain* para garantir rastreabilidade e transparência em cadeias de suprimento de alimentos, identificando barreiras técnicas e regulatórias à adoção em larga escala. * **[8] Ray, P. P. (2017). “Internet of Things for Smart Agriculture: Technologies, Practices and Future Direction.”** * **Resumo:** Revisão ampla que unifica hardware, software e comunicação aplicados à agricultura inteligente, oferecendo uma visão das práticas atuais e futuras do setor. ----- ## 6\. Comparativo com Produtos Similares ### 6.1. Tabela Comparativa | Produto | Fabricante | Sensores Principais | Comunicação | Controle de Irrigação | Interface | Preço Médio (USD) | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | **AgroSmart IoT** | AgroSmart | Temp., Umidade, Solo (Prof.) | Wi-Fi/4G | Sim | App móvel | 249 | | **Mi Smart Garden** | Xiaomi | Temp., Umidade, Luz | Wi-Fi | Sim | App + Display | 199 | | **Growlink Smart Controller**| Growlink | BME280, Solo (Cap.), Luminosidade | Wi-Fi | Sim | Painel Web | 289 | | **Arduino Smart Greenhouse Kit** | Elegoo | DHT22, LDR, Solo (Res.) | USB/Wi-Fi (ESP8266) | Sim | LCD 16x2 | 129 | | **Sistema Proposto** | - | DS18B20, LDR, Gás, Reed, PIR | Wi-Fi | Sim | OLED + Encoder + RGB + Web | \~75 | ### 6.2. Análise Comparativa A tabela demonstra um claro "gap" no mercado. Produtos comerciais (AgroSmart, Growlink) focam na robustez e conectividade (4G, sensores profissionais), com preços acima de $200. Kits educacionais (Elegoo) são mais baratos, mas limitados em sensores e conectividade. O Sistema Proposto (v2.0) se posiciona de forma única: * **Custo-Benefício:** Com um custo de material estimado em \~$75, ele oferece uma gama de sensores de segurança (Gás, Reed, PIR) e feedback (RGB, Buzzer) que nem mesmo os produtos comerciais de entrada (como o Mi Smart Garden) possuem. * **Interface Rica:** A combinação de controle local (OLED + Encoder) com controle remoto (MQTT) oferece uma flexibilidade de HMI (Interface Homem-Máquina) superior à de kits básicos. * **"Calcanhar de Aquiles":** Sua fraqueza, em comparação com os produtos "Pro", é a qualidade e durabilidade dos sensores (analógicos vs. digitais calibrados, resistivos vs. capacitivos), o que é explorado na próxima seção. ----- ## 7\. Limitações e Desafios de Engenharia Esta seção detalha a diferença crítica entre o protótipo acadêmico e um produto comercial viável. ### 7.1. Lacuna Funcional: Ausência de Umidade do Ar * **Limitação:** Esta é a lacuna funcional mais crítica. A lista de componentes da disciplina não inclui um sensor de umidade relativa do ar (como o DHT22 ou BME280). * **Impacto:** Em uma estufa, a umidade do ar (VPD - Déficit de Pressão de Vapor) é tão importante quanto a temperatura, afetando a transpiração das plantas e o risco de fungos. Sem medi-la, nosso controle ambiental é incompleto [8]. ### 7.2. Calibração e Confiabilidade do Sensor de Gás * **Limitação:** O Sensor de Gás (como o MQ-135) é um sensor analógico de baixo custo. * **Impacto:** Esses sensores são notórios por sua baixa seletividade (podem ser disparados por múltiplos gases), deriva (drift) ao longo do tempo, e alta sensibilidade à temperatura e umidade ambiente. O valor "300" lido hoje pode não ser o mesmo que "300" lido amanhã. * **Solução Comercial:** Exigiria uma lógica de compensação de software (usando a leitura de temperatura do DS18B20 para corrigir a leitura do gás), um processo de calibração em ar limpo (para definir o "zero") e, para CO2, o uso de sensores NDIR (Non-Dispersive Infrared), que são muito mais estáveis e caros. ### 7.3. Durabilidade do Sensor de Solo (Corrosão) * **Limitação:** O uso do Sensor de Chuva como sensor de solo (resistivo). * **Impacto:** O princípio de funcionamento envolve passar uma corrente elétrica entre duas trilhas expostas no solo úmido. Isso causa eletrólise, corroendo e "comendo" o metal das trilhas em questão de semanas ou meses. * **Solução Comercial:** Uso de sensores de umidade capacitivos. Eles medem a constante dielétrica do solo (que muda com a água) sem expor eletrodos, garantindo anos de vida útil. ### 7.4. Robustez e Proteção Ambiental (IP Rating) * **Limitação:** O protótipo usa um DevKit, fios e módulos em protoboard/fios. * **Impacto:** O ambiente de uma estufa é altamente hostil (umidade, condensação, poeira, respingos de água). O sistema falharia em dias. * **Solução Comercial:** Exigiria o design de uma PCB (Placa de Circuito Impresso) customizada, com revestimento conformal (verniz protetor) e encapsulada em uma caixa com classificação IP67 (à prova de poeira e resistente à imersão temporária). ### 7.5. Confiabilidade da Conectividade * **Limitação:** Dependência de uma conexão Wi-Fi estável. * **Impacto:** Inviável em ambientes rurais ou estufas grandes, longe do roteador [4]. * **Solução Comercial:** Tecnologias LPWAN (Low-Power Wide-Area Network), como LoRaWAN ou NB-IoT, como apontado nas revisões de tendências da área [4, 8]. ### 7.6. Escalabilidade do Software * **Limitação:** A lógica de loop, mesmo com timers (não-bloqueante), se torna complexa de gerenciar. * **Impacto:** Adicionar um novo sensor pode quebrar a lógica de tempo. Uma falha na publicação MQTT pode travar a verificação de alarmes. * **Solução Comercial:** Uso intensivo do FreeRTOS (nativo do ESP32). Cada módulo (Clima, Segurança, MQTT, Interface) rodaria em sua própria tarefa (task) com prioridades distintas. A tarefa de Alarme teria a prioridade mais alta, garantindo que o Buzzer soe imediatamente, não importa o que as outras tarefas estejam fazendo. ----- ## 8\. Conclusão Este estudo teórico-exploratório detalhou com sucesso o projeto de um Sistema de Controle de Estufa Automatizada (v2.0), utilizando exclusivamente componentes da disciplina. O projeto demonstrou como integrar múltiplos domínios de engenharia, controle ambiental, segurança, interface HMI e conectividade IoT, em uma única plataforma ESP32. A arquitetura de software proposta, baseada em gerenciamento de estado, timers e interrupções (ISRs), é robusta o suficiente para lidar com a complexidade de 10 dispositivos de entrada/saída. A inclusão de sensores de movimento, acesso (reed-switch) e qualidade do ar, juntamente com atuadores de feedback (LED RGB, Buzzer), eleva o projeto de um simples controlador para um sistema embarcado complexo e genuinamente útil. A fundamentação na literatura acadêmica [1-8] permitiu não só justificar as escolhas de design (como o uso de MQTT [3]), mas também realizar uma análise crítica das limitações do protótipo (Seção 7). A distinção entre a solução acadêmica (focada na criatividade com restrições) e a solução comercial (focada na robustez e durabilidade) é talvez o aprendizado mais importante deste trabalho. O projeto, como documentado, atende plenamente aos objetivos da disciplina, demonstrando um entendimento aprofundado da integração de múltiplos subsistemas embarcados para resolver um problema do mundo real. ----- ## 9. Referências 1. **ESPRESSIF SYSTEMS.** *ESP32 Technical Reference Manual.* [S. l.], 2022. Disponível em: [https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf](https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf). Acesso em: 9 nov. 2025. 2. **VERMA, A.; BODADE, R.** Design and implementation of a low-cost IoT-based smart agricultural system using ESP32 and LoRa technology. *2025 International Conference on Computational, Communication and Information Technology (ICCCIT)*, Indore, India, 2025. p. 1–6. DOI: [10.1109/ICCCIT62592.2025.10928022](https://doi.org/10.1109/ICCCIT62592.2025.10928022). 3. **JAWHAR, I.; SINDIAN, S.; SHREIF, S.; EZZDINE, M.; HAMMOUD, B.** An efficient and scalable Internet of Things framework for smart farming. *IEEE Sensors Letters*, v. 8, n. 11, p. 1–4, nov. 2024. DOI: [10.1109/LSENS.2024.3476940](https://doi.org/10.1109/LSENS.2024.3476940). 4. **TZOUNIS, A.; KATSOULAS, N.; BARTZANAS, T.; KITTAS, C.** Internet of Things in agriculture: recent advances and future challenges. *Biosystems Engineering*, v. 164, p. 31–48, 2017. DOI: [10.1016/j.biosystemseng.2017.09.007](https://doi.org/10.1016/j.biosystemseng.2017.09.007). 5. **CHLINGARYAN, A.; SUKKARIEH, S.; WHELAN, B.** Machine learning approaches for crop yield prediction and nitrogen status estimation in precision agriculture: a review. *Computers and Electronics in Agriculture*, v. 151, p. 61–69, 2018. DOI: [10.1016/j.compag.2018.05.012](https://doi.org/10.1016/j.compag.2018.05.012). 6. **WOLFERT, S.; GE, L.; VERDOUW, C.; BOGAARDT, M.-J.** Big data in smart farming – a review. *Agricultural Systems*, v. 153, p. 69–80, 2017. DOI: [10.1016/j.agsy.2017.01.023](https://doi.org/10.1016/j.agsy.2017.01.023). 7. **KAMILARIS, A.; FONTS, A.; PRENAFETA-BOLDÚ, F. X.** The rise of blockchain technology in agriculture and food supply chains. *Trends in Food Science & Technology*, v. 91, p. 640–652, 2019. DOI: [10.1016/j.tifs.2019.07.034](https://doi.org/10.1016/j.tifs.2019.07.034). 8. **RAY, P. P.** Internet of things for smart agriculture: technologies, practices and future direction. *Journal of Ambient Intelligence and Smart Environments*, v. 9, n. 4, p. 395–420, 2017. DOI: [10.3233/AIS-170440](https://doi.org/10.3233/AIS-170440).