2. Solución Propuesta

2.1 Restricciones de diseño identificadas

Técnicas

• La medición debe ejecutarse fuera del hilo principal, por lo que la adquisición corre en una tarea anclada al núcleo 0 y el servidor web en el loop(), sobre el núcleo 1.
• El tablero no puede usar MQTT ni servicios en la nube, por lo que la visualización remota se resuelve con un servidor HTTP embebido en el propio ESP32.
• El tamaño físico del ESP32 sobre la protoboard dejaba una sola fila libre de pines de un costado, lo que hizo que se tuviera que pasar parte del cableado por debajo del módulo.
• El sensor de nivel (HC-SR04) tiene una zona ciega de más o menos 2 cm, por lo que el rango útil de medición queda limitado y por fuera de cierto rango la lectura no es confiable.

Económicas

• Se descartó el uso de un panel solar, puesto que requeriría adicionalmente baterías recargables, que para que sean funcionales elevan el costo en aproximadamente 80.000 COP.
• El material usado para la carcasa resultó siendo PLA, debido a que por costos no era viable usar ABS o PETG.

De espacio

• Todo el sistema debe caber en una carcasa de tamaño relativamente pequeño y ser adaptable a distintos entornos, lo que limita el número de protoboards usables y obliga a ubicar los sensores de forma que puedan leer los valores del ambiente.
• El HC-SR04 necesita una línea de visión despejada hacia la superficie del agua, por lo que también condiciona el montaje.

Temporales

• El desarrollo del proyecto se solapó con las fechas de desarrollo y entrega de múltiples otras materias, en especial en las últimas semanas, por lo que los cambios al prototipo original no pudieron ser muy grandes.

2.2 Arquitectura propuesta

Diagrama de bloques (Hardware y Software)

Descripción de bloques:

• Adquisición de datos: Lee periódicamente nivel de agua (HC-SR04), temperatura/humedad (DHT22), radiación solar (LDR), presión atmosférica (BMP280) y pulsos de caudal (ZJ-S201).
• Lógica de fusión y alertas: Combina las variables ambientales e hidráulicas para determinar el estado (normal, alerta, crítico o falla), implementando una lógica de fusión de señales.
• Visualización in situ: Muestra las variables en tiempo real en el LCD1602.
• Alarma física: Activa el semáforo de LEDs y el buzzer según el estado calculado y sin depender de la red.
• Comunicación y tablero de control: El ESP32 se conecta a la red WLAN de la zona y sirve el tablero desde un servidor web embebido, sin hardware adicional ni intermediarios en la nube.

Arquitectura de concurrencia

La medición se ejecuta por fuera del hilo principal. La tarea de adquisición se crea con xTaskCreatePinnedToCore() sobre el núcleo 0 recorriendo el ciclo de lectura en cada ejecución. El servidor web atiende peticiones desde el loop(), que corre en el núcleo 1. Las dos tareas comparten la estructura de estado del sistema, protegida con un mutex de FreeRTOS, para que el tablero nunca lea valores incompletos.

El conteo de pulsos del sensor de caudal ocurre en una rutina de interrupción (isrPulsoCaudal()) por fuera de ambas tareas. El contador se declara volatile y se protege con portMUX_TYPE para hacer atómica la lectura frente a la ISR.

Esta separación permite que, si se cae la red o el tablero no responde, la tarea de medición y las alarmas físicas pueden seguir operando sin interrumpirse.

2.3 Desarrollo teórico modular

Criterios de diseño establecidos

• Bajo costo: Uso de sensores comerciales económicos y ESP32 como único microcontrolador.
• Bajo consumo: Todos los periféricos de lógica/sensado operan a 3.3V; solo HC-SR04 y LCD requieren 5V (VIN), minimizando el consumo total (~240 mA pico aproximado con un LED encendido). Con el Wi-Fi activo para el tablero el consumo es mayor y no se midió en esta entrega.
• Robustez de cableado: Separación de rieles de alimentación (3.3V / 5V) sobre tierra común, para evitar acoplamientos entre sensores de distinto voltaje.
• Independencia de red: La adquisición, fusión y alarmas físicas se ejecutan por separado en el ESP32. El tablero de control requiere la WLAN, pero es un canal complementario.
• Modularidad por sensor: Cada sensor se integra como un módulo independiente de adquisición, facilitando reemplazo o escalado futuro.

Diagramas UML (basados en el código real)

El firmware está escrito en C/C++ estilo Arduino (procedural, sin clases propias), así que un único diagrama de clases no alcanza a mostrar bien su comportamiento. Por eso se documentan tres vistas complementarias: estructura, comportamiento en tiempo de ejecución y lógica de decisión, todas construidas a partir de las funciones y constantes reales del .ino.

a) Diagrama de clases (estructura, notación UML clásica)

Los módulos del firmware se modelan como clases estáticas (agrupan funciones y constantes relacionadas), y se incluyen las clases reales de las librerías con las que interactúan:

b) Diagrama de secuencia (comportamiento de un ciclo de medición y de una consulta al tablero)

Muestra la ejecución concurrente: la tarea de medición en el núcleo 0 y el servidor web en el núcleo 1, sincronizados únicamente en el estado compartido mediante un mutex.

El conteo de pulsos del sensor de caudal (isrPulsoCaudal()) no ocurre dentro de este ciclo, sino que corre en segundo plano como una interrupción (attachInterrupt sobre FLOW_PIN), y leerCaudalLmin() solo lee el acumulado.

c) Diagrama de actividades (lógica de fusión, evaluarAlerta())

Este es el corazón del reto: cómo se combinan las señales (nivel, evaporación, caudal) para decidir el nivel de alerta:

Esquemático de hardware

Como esquemático se aporta el montaje de validación en Wokwi, junto con la tabla de conexiones, que recoge pines, voltajes y elementos de acondicionamiento del prototipo físico. No se levantó un esquemático en una herramienta de diseño electrónico. El circuito del prototipo entregado difiere del de la simulación en el uso de BMP280 y ZJ-S201 reales en lugar de los proxies.

En la simulación, el circuito se organizó en dos buses de alimentación separados:

• Bus 5V: sensor ultrasónico (HC-SR04), LCD1602, LEDs y buzzer.
• Bus 3.3V: DHT22, LDR y el proxy del BMP280.

Como Wokwi no incluye de forma nativa el BMP280 ni el sensor de caudal, en la simulación se reemplazaron por componentes equivalentes en comportamiento eléctrico: un potenciómetro como proxy del BMP280 (salida analógica variable) y un pulsador como proxy del sensor de caudal (generación de pulsos digitales, misma lógica que el conteo por interrupción del código real). Por esto existen dos versiones del firmware. La de simulación corresponde al Challenge #1 y se conserva en el historial del repositorio; la del prototipo físico, documentada en la sección 7.5, usa los sensores reales sin cambios en la lógica de fusión ni en los pines.

A continuación la tabla de conexiones equivalente al esquemático:

Componente	Pin componente	Pin ESP32	Alimentación
HC-SR04	TRIG	GPIO 5 (D5)	VCC → VIN (5V), GND → riel negativo
HC-SR04	ECHO	GPIO 18 (D18)	(sin alimentación propia)
DHT22	DATA (+ pull-up 10kΩ a 3.3V)	GPIO 15 (D15)	VCC → 3.3V, GND → riel negativo
LDR + resistencia 10kΩ	Nodo central del divisor	GPIO 35 (D35)	LDR → 3.3V, resistencia → riel negativo
BMP280	SDA / SCL (I2C, addr 0x76)	GPIO 21 (D21) / GPIO 22 (D22)	VCC → 3.3V, GND → riel negativo
BMP280	CSB → 3.3V (fija modo I2C), SDO → GND (fija dirección 0x76)	—	—
LCD1602 + I2C	SDA / SCL (bus compartido con BMP280)	GPIO 21 (D21) / GPIO 22 (D22)	VCC → VIN (5V), GND → riel negativo
LED verde	Ánodo (+ resistencia 220Ω)	GPIO 25 (D25)	Cátodo → riel negativo
LED amarillo	Ánodo (+ resistencia 220Ω)	GPIO 26 (D26)	Cátodo → riel negativo
LED rojo	Ánodo (+ resistencia 220Ω)	GPIO 27 (D27)	Cátodo → riel negativo
Buzzer	Terminal +	GPIO 33 (D33)	Terminal − → riel negativo
ZJ-S201 (caudal)	Señal	GPIO 32 (D32)	VCC → VIN (5V), GND → riel negativo

Estándares de diseño de ingeniería aplicados

• Bus I2C (NXP UM10204, I2C-bus specification and user manual) [11]: Bus compartido por BMP280 y LCD1602, cada uno con dirección distinta (0x76 y 0x27), con las resistencias de pull-up y los niveles lógicos que define la especificación.
• IEEE 802.11 (WLAN) [16]: El ESP32 opera en modo estación como un cliente más de la red inalámbrica provista por las autoridades, sin montar su propio punto de acceso ni exponer servicios fuera de esa red.
• Buenas prácticas de pull-up en líneas digitales: Resistencia de 10 kΩ en DHT22 y uso del pull-up interno del ESP32 en el sensor de caudal, para asegurar lecturas digitales estables.
• Separación de dominios de alimentación: Riel de 3,3 V para lógica/sensores de bajo consumo y riel de 5 V (VIN) independiente para HC-SR04 y LCD, con tierra común única. Las líneas de señal que provienen de componentes de 5 V (ECHO del HC-SR04 y salida del sensor de caudal) se conectan sin adaptación de nivel, por encima del máximo de 3,6 V de los GPIO. Se documenta como limitación en la sección 3.4.
• Diseño de bajo consumo: Selección de sensores de consumo reducido (µA–mA) y activación de un solo LED a la vez en el semáforo de alerta.

Modelo de negocio

• Propuesta de valor: Se ofrece un sistema de monitoreo de bajo costo que mide en tiempo real el nivel de un embalse o punto de captación y el caudal de salida hacia el acueducto, generando una alarma física local automática para las autoridades ambientales (como la CAR) y los operadores del embalse y los acueductos municipales.
• Segmento de clientes: Autoridades ambientales y operadores de infraestructura hídrica en Sabana Centro: la CAR como administradora de embalses y puntos de captación, y las empresas de acueducto municipales. Como segmento secundario, Juntas de Acción Comunal y acueductos veredales en puntos de almacenamiento más pequeños, donde el mismo equipo aplica sin cambios.
• Canales: Instalación directa por parte de la alcaldía/CAR en puntos de almacenamiento (tanques, reservorios, cauces).
• Estructura de costos: 159.400 COP aproximadamente en componentes electrónicos, más 60.000 COP de carcasa y ensamblaje, para un total aproximado de 219.400 COP por equipo. El mantenimiento se reduce a recalibración periódica y limpieza del sensor ultrasónico, sin consumibles.
• Fuentes de ingreso / financiamiento: Convenios con la Corporación Autónoma Regional de Cundinamarca (CAR) o la Gobernación, en el marco de los planes de contingencia por El Niño ya vigentes en la región.

2.4 Madurez del prototipo

• Carcasa: Impresa en 3D con material PLA. Se montan los sensores de medición, incluyendo el de nivel, y la pantalla LCD en la parte inferior de la carcasa, para dejarlos visibles y que puedan recopilar datos reales del ambiente. También, el LDR se colocó en la tapa, con acceso directo a luz solar para su medición.
• Alimentación: Se alimenta por USB desde una fuente externa de 5 V. En este challenge se descartó el panel solar y la batería por costos y tiempo.
• Consideraciones de despliegue: La instalación del dispositivo requiere cobertura de la WLAN local en el punto de captación, una fuente de 5 V, montaje fijo de la carcasa sobre el nivel máximo del agua y un tramo de tubería donde se pueda intercalar el sensor de caudal. El arranque del dispositivo consiste en configurar las credenciales de la WLAN y verificar el acceso al tablero desde un dispositivo de la red.
• Integración: Los módulos de percepción, cómputo, actuación, conectividad y tablero operan de forma conjunta en una sola unidad. El montaje pasó de dos protoboards sueltas, con parte del cableado por debajo del ESP32, a una sola protoboard que cabe dentro de la carcasa, lo que hace el conjunto instalable en campo.