Sistema de Controle de Estufa Automatizada (Greenhouse Control System)

Identificação

Disciplina: Fundamentos de Sistemas Embarcados — 2025/2 Curso: Engenharia de Software — Universidade de Brasília (UnB) Integrantes:

1. Introdução e Objetivos

Este trabalho apresenta um estudo teórico-exploratório aprofundado para a reprodução conceitual de um produto embarcado: o Sistema de Controle de Estufa Automatizada. O estudo vai além de um simples controlador climático, propondo um sistema multifacetado que integra controle ambiental, gerenciamento de eficiência energética e segurança patrimonial.

A proposta é fundamentada inteiramente nos componentes de hardware disponibilizados pela disciplina, demonstrando a viabilidade de construir um sistema complexo e robusto a partir de sensores e atuadores de baixo custo, orquestrados pelo microcontrolador ESP32.

1.1. Objetivo Geral

O objetivo geral é projetar a arquitetura de hardware e software de um sistema embarcado complexo, capaz de monitorar e atuar em múltiplas variáveis de uma estufa, utilizando o microcontrolador ESP32 e o ecossistema de sensores da disciplina, e fundamentar as decisões de engenharia com base na literatura acadêmica.

1.2. Objetivos Específicos

1. Analisar os requisitos funcionais e não funcionais de um sistema de automação de estufa comercial.
2. Selecionar e justificar o uso de cada componente da lista da disciplina, mapeando-os para uma função específica no projeto (clima, segurança, interface).
3. Projetar a arquitetura de hardware, detalhando os protocolos de comunicação (I2C, One-Wire, GPIO) e a integração dos módulos.
4. Projetar a arquitetura de software, descrevendo textualmente o fluxograma operacional, o gerenciamento de estado, a lógica de controle com histerese e o uso de interrupções (ISRs) para responsividade.
5. Integrar funcionalidades de IoT (Internet das Coisas) através da conectividade Wi-Fi do ESP32 e do protocolo MQTT, para monitoramento e controle remoto [3].
6. Discutir as limitações técnicas da prototipagem com componentes de baixo custo (ex: precisão de sensores, corrosão) e compará-las com soluções de engenharia de nível comercial.
7. Fundamentar a proposta com base em artigos científicos relevantes, conectando a prática do projeto com o estado da arte em IoT agrícola [4, 8].

2. Descrição e Análise do Produto

2.1. Funções Principais do Sistema Proposto

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.

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.
Atuador (Feedback)	Led RGB 5mm	Emitir feedback visual de status.
Atuador (Interface)	Tela OLED 0.98" (I2C)	Exibir dados locais para o usuário.

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

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. 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.

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.

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.

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.

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.

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.

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.