6. Mejoras respecto al Challenge #1 - Bedoya1905/iot_challenge2 GitHub Wiki
6.1 Resumen
Tras la retroalimentación recibida con el Challenge #1, se abordaron todas las deficiencias señaladas en la evaluación. Las filas siguen el orden de los indicadores del archivo de evaluación que se recibió, y cada una enlaza con la evidencia correspondiente dentro de esta wiki. Los hallazgos que no se pudieron cerrar se declaran en la sección 6.6.
6.2. Diseño de la solución
| Deficiencia recibida | Acción de mejora | Evidencia |
|---|---|---|
| Restricciones de diseño incompletas: la sección 2.1 listaba únicamente restricciones técnicas, y una sola. Señalada como la debilidad principal del indicador 1 | Se identificaron y documentaron restricciones en 4 categorías que pide el enunciado: técnicas, económicas, de espacio y temporales, cada una explicando qué decisión de diseño impuso | Sección 2.1 |
| Presión atmosférica: no cumple. El BMP280 se contempló, se cableó y falló en el montaje, y el equipo lo desacopló | El BMP280 quedó operativo e integrado al cálculo de evaporación. Su lectura se verificó contra el reporte meteorológico para Bogotá convertido a presión local, con una diferencia de 0,25 % | Secciones 3.1.1 y 3.3; análisis en 3.4 |
| Contradicción documental: varias secciones presentaban el BMP280 como parte del sistema y la sección 3.3 afirmaba que alimentaba el índice de evaporación, lo cual no era cierto en ninguna de las dos versiones del firmware | La presión medida entra efectivamente en el cálculo, a través de la constante psicrométrica de la ecuación de Priestley-Taylor. La documentación describe ahora con precisión qué variable alimenta qué cálculo | Sección 3.1.3 |
calcularRadiacionPct() devolvía el valor del ADC normalizado a 0-100 %, no una irradiancia |
La función se reemplazó por calcularRadiacionWm2(), que entrega irradiancia en W/m² mediante una calibración de dos puntos. Las constantes de calibración se ajustaron con lecturas propias del sensor instalado, en sombra exterior y en sol directo |
Sección 3.1.3 y tabla de calibración del LDR en 3.3 |
Índice de evaporación heurístico: calcularIndiceEvaporacion() ponderaba temperatura, humedad y radiación con pesos 0,4/0,3/0,3 asertados por el equipo |
Se reemplazó por la ecuación de Priestley-Taylor (1972), que entrega evaporación potencial en mm/día y cuenta con respaldo en la literatura. La humedad relativa dejó de entrar en el cálculo, ya que el método no la utiliza | Sección 3.1.3 y referencia [8] |
| Referencia a Hargreaves laxa: ese método usa radiación extraterrestre y el rango térmico, no la humedad relativa | Se eliminó toda mención a Hargreaves de la documentación y del firmware | Secciones 3.1.3 y 5 |
| Sin histéresis: el sistema podía oscilar en las fronteras del 30 % y el 15 % | Se implementó histéresis con márgenes de 3 puntos de nivel, 0,5 mm/día de evaporación y 2 L/min de caudal, aplicados únicamente para salir de un estado de alerta | Sección 3.1.3 |
| Bug de propagación de NaN: si el DHT22 fallaba, el índice quedaba en NaN y la comparación resultaba falsa, desactivando silenciosamente la rama de evaporación | El NaN se detecta, se reporta por el monitor serial y escala a estado FALLA. La falla del DHT22 no se oculta, y tampoco oculta un estado crítico confirmado | Sección 3.1.3 |
| Diseño fail-unsafe: si el HC-SR04 no daba lectura válida, la evaluación retornaba «normal» | Se agregó un cuarto estado, FALLA, señalizado con los LED verde y rojo encendidos simultáneamente, pitido corto de 500 Hz y mensaje en el LCD. Un sensor caído ya no produce un estado verde | Sección 3.1.3 |
| Diagrama de bloques: incluía el BMP280, ausente del prototipo final | El diagrama se regeneró con el BMP280 operativo y con el bloque de comunicación y tablero de control que incorpora esta entrega | Figura 1, sección 2.2 |
| Estándares de ingeniería: buenas prácticas documentadas, pero sin citar ninguna norma con número formal | Los estándares se citan con su identificación: NXP UM10204 para el bus I2C e IEEE 802.11 para la WLAN | Sección 2.3 |
| Modelo de negocio: bien anclado al contexto, pero sin una sola cifra | Se incorporó el costo unitario de materiales, el costo de instalación por punto y una estimación del número de puntos que cubriría un convenio | Sección 2.3 |
| Umbrales sin justificación externa: los pesos y los cortes eran razonables pero asertados | Cierre parcial. El método de cálculo de la evaporación pasó a tener fuente citable, pero los umbrales de nivel, caudal y evaporación siguen siendo parámetros de diseño pendientes de calibrar contra datos del sitio | Secciones 3.1.3 y 6.6 |
6.3. Validación a nivel de prototipado
| Deficiencia recibida | Acción de mejora | Evidencia |
|---|---|---|
| Resultados sin datos: el análisis era narrativo, sin tabla de resultados, valores medidos, error, repeticiones, instrumento de referencia ni tiempo de respuesta. Señalada como la pérdida principal de la evaluación | Se diseñó y ejecutó un banco de pruebas que calibra cada sensor contra una referencia conocida y reporta los resultados en tablas, con cinco repeticiones por punto en la medición de nivel | Secciones 3.2 y 3.3 |
ALTURA_TANQUE_CM = 7,0 cm frente a la zona ciega de ~2 cm del HC-SR04: el rango útil queda estrecho y por encima de ~71 % la lectura no es confiable. El equipo detectaba el síntoma sin relacionarlo con la limitación dimensional |
Se identificó la zona ciega como causa de las lecturas inconsistentes, se amplió el rango de medición a 12 cm y se ajustó la posición del sensor. Tras la corrección el error se mantuvo por debajo de 5 puntos porcentuales en los seis puntos medidos, y la clasificación de la zona de alerta fue correcta en todos | Tabla de calibración de nivel en 3.3 y análisis en 3.4 |
| La falla del BMP280 que afectaba al LCD y al sistema no se investigó a fondo (probable I2C o alimentación) | Se revisó el montaje del bus I2C y la alimentación del sensor. [Describir el hallazgo concreto y la corrección aplicada.] El sensor quedó operativo y entregó lecturas estables durante los cinco minutos de prueba | Sección 3.4 |
3.1.2 listaba Adafruit_BMP280.h y Adafruit_Sensor.h como librerías usadas, ausentes del sketch físico entregado |
Ambas librerías se usan efectivamente en el firmware de esta entrega, al estar el BMP280 integrado. La lista de librerías de 3.1.2 corresponde exactamente a los #include del código |
Sección 3.1.2 y código fuente en anexos |
| La autoevaluación 4.1 sobreafirmaba: «ningún sensor descalibrado… todos funcionan como deberían», cuando el LDR no estaba calibrado, el BMP280 había fallado y no hubo calibración contra referencia | La autoevaluación se reescribió sobre los datos reales del banco de pruebas, separando lo que el protocolo permite afirmar, lo que queda apoyado en supuestos y lo que no se alcanzó a verificar | Página 4 completa |
6.4. Comunicación escrita
| Deficiencia recibida | Acción de mejora | Evidencia |
|---|---|---|
| El buzzer estaba documentado al revés: la wiki asignaba a advertencia el tono continuo de 1000 Hz y a crítico el intermitente de 2200 Hz, cuando el código hace lo contrario | La documentación corresponde ahora al comportamiento del firmware: advertencia es intermitente a 1000 Hz y crítico es continuo a 2200 Hz | Sección 3.1.3 y video |
| Confusión de librerías: 3.1.2 describía «LiquidCrystal, de beegee-tokyo» como gestora del protocolo del DHT22 | Se separaron correctamente: LiquidCrystal_I2C controla la pantalla y DHTesp, de beegee-tokyo, gestiona el DHT22. Se agregaron además las librerías nuevas de esta entrega |
Sección 3.1.2 |
| No se inserta ninguna cita [n] en el cuerpo del texto, pese a tener siete referencias correctamente formateadas | Las referencias se citan ahora desde el cuerpo, en el punto donde se usa cada afirmación | Secciones 1.1, 2.3, 3.1.3 y 3.2 |
| Falta literatura académica de los últimos cinco años sobre monitoreo hídrico con IoT | Cierre parcial. Se incorporaron referencias académicas que respaldan los métodos aplicados: la fuente original de Priestley-Taylor, el documento FAO-56 y un trabajo sobre calibración de sensores LDR para medición de irradiancia. No se incorporó literatura reciente específica sobre sistemas de monitoreo hídrico con IoT, lo que se declara en la sección 6.6 | Página 5, referencias [8] a [15] |
| Erratas sin corregir y una frase duplicada; se nota redacción apurada en la página 3 | Se revisó la ortografía de la wiki y se eliminó la duplicación | Todas las páginas |
| Las figuras no están numeradas, no tienen pie ni se referencian desde el texto | Todas las figuras se numeraron correlativamente, llevan pie descriptivo y se citan desde el cuerpo del texto | Todas las páginas |
La imagen de la sección 6.3 está rota (atributo src vacío) |
Se resubió la imagen y se verificó su visualización | Anexos |
| El Home es un índice de enlaces sin texto de presentación: una portada pobre frente a la calidad del contenido interior | El Home incluye ahora una presentación del proyecto, una fotografía del prototipo terminado y el enlace al video de demostración | Home |
6.5. Comunicación oral y proceso de equipo
| Deficiencia recibida | Acción de mejora | Evidencia |
|---|---|---|
| La wiki no menciona los nombres ni los roles de los integrantes: solo aparecen en el video. Incumplimiento directo del enunciado | Se agregó una página dedicada con el rol, las actividades y las contribuciones de cada integrante | Página 9 |
| No existen actas de reunión, bitácora ni evaluación entre pares | Se documentaron las actas de reunión del equipo, con fecha, asistentes y acuerdos, junto con la evaluación entre pares | Página 9 |
| En el video los integrantes se presentaban únicamente por nombre | En el video de esta entrega cada integrante aparece con cámara encendida y explica su contribución específica al proyecto | Video |
| Sobreafirmación técnica en el video: se afirmaba que la fusión combinaba el índice de evaporación con el nivel y su tasa de descenso, cuando esa derivada no estaba implementada | La tasa de descenso sigue sin implementarse, por lo que no se menciona en el video ni en la documentación de esta entrega. Ver sección 6.6 | Video |
6.6. Hallazgos no cerrados
El equipo considera que declarar lo que quedó pendiente es parte de la mejora. Los siguientes puntos de la retroalimentación no se cerraron en esta entrega:
- Tasa de descenso del nivel. La evaluación del Challenge #1 la señaló como la variable que habría completado la solución, y el enunciado del Challenge #2 vuelve a nombrarla al pedir la detección de tasas anómalas de descenso bajo condiciones de calor extremo. No se implementó por limitaciones de tiempo. Con el histórico de lecturas ya almacenado en memoria, su cálculo es inmediato y queda como la primera línea de trabajo futuro.
- Adaptación de nivel en las líneas de 5 V. El pin ECHO del HC-SR04 y la señal del sensor de caudal entregan 5 V sobre GPIO que toleran un máximo de 3,6 V. En el Challenge #1 esto se declaró como recomendación para despliegue; en esta entrega se mantiene igual, pero se documenta explícitamente como condición fuera de especificación en lugar de presentarse como una decisión de diseño. La corrección es un divisor resistivo de 1 kΩ / 2 kΩ en cada línea.
- Esquemático formal. No se levantó un esquemático en herramienta de diseño electrónico. Como sustituto se aportan la captura del montaje de validación y la tabla de conexiones con pines, voltajes y elementos de acondicionamiento.
- Calibración absoluta de la radiación solar. Los dos puntos de la conversión a W/m² están anclados a lecturas del sensor instalado, pero los valores de irradiancia asignados a esos puntos provienen de literatura y no de una medición con instrumento. La escala es coherente en orden de magnitud, pero su exactitud absoluta no está verificada.
- Calibración de los umbrales contra datos del sitio. El coeficiente α de Priestley-Taylor y el umbral de 5 mm/día son parámetros de diseño razonados a partir de la literatura, no ajustados con series históricas del embalse del Neusa.
- Detección de falla en el LDR y en el sensor de caudal. El estado FALLA cubre el HC-SR04 y el DHT22, que son los sensores de los que depende directamente la evaluación de riesgo. El LDR siempre entrega un valor por ADC aunque esté desconectado, y en el sensor de caudal la ausencia de pulsos es indistinguible de la ausencia de flujo.
- Bloques del banco de pruebas sin ejecutar. Latencia de la notificación, comportamiento de la histéresis, robustez ante pérdida de red y acceso no autorizado, y repetibilidad con consumo. Se detallan en la sección 4.3.
- Alcance del sensor de nivel frente al escenario real. El HC-SR04 tiene un alcance de aproximadamente 4 metros y mide contra una superficie que en un embalse se ve afectada por el oleaje. Es adecuado para el prototipo y para tanques de almacenamiento, pero el despliegue en el cuerpo del embalse requeriría un sensor de mayor alcance.
- Literatura reciente sobre monitoreo hídrico con IoT. Las referencias académicas incorporadas respaldan los métodos de cálculo y calibración empleados, pero no incluyen trabajos de los últimos cinco años sobre sistemas de monitoreo hídrico con IoT, que es lo que señalaba la retroalimentación. Incorporarlos permitiría contrastar las decisiones de diseño de este prototipo con las de soluciones publicadas recientemente.