bioreactor-multiparametric-daq-shield/PROJECT_STATUS.md

Estado del Proyecto

Estado actual

El dashboard integra monitoreo en vivo, alarmas configurables, tendencias, exportación CSV/Excel, consola EZO y calibración. La adquisición puede operar en modo demo o en Raspberry Pi mediante /dev/i2c-1.

Arquitectura operativa

Componente	Responsabilidad
api/server.js	API, históricos, configuración y comandos EZO
api/acquisition.js	Ciclo continuo de adquisición
api/acquisition-service.js	Escritura atómica de JSON/CSV y configuración
sensors/EZOCommand/EZO_ACQUIRE	Lectura agrupada de los cuatro EZO
sensors/EZOCommand/EZO_COMMAND	Comandos y calibración de un circuito
frontend/	Dashboard, gráficas, alarmas, exportación y consola

Los dos helpers C usan /tmp/photobioreactor-i2c.lock. El recolector inicia la conversión de los cuatro sensores antes de esperar, por lo que comparte una sola ventana de procesamiento en vez de bloquear un segundo por sensor.

Funciones implementadas

• Lecturas de RTD, pH, DO y EC con publicación en data/*.json.
• Históricos normalizados como logs/temperature.csv, ph.csv, do.csv y ec.csv, todos con formato timestamp,value.
• Escritura atómica de JSON y estado online: false ante fallos globales o lecturas individuales inválidas.
• Detección de datos obsoletos con tolerancia proporcional a la frecuencia.
• Frecuencia persistente de 1, 5, 10 o 60 segundos en config/runtime.json.
• Exportaciones alimentadas por CSV reales, sin generación aleatoria en la API.
• Verificación automática Cal,? después de una calibración enviada desde web.
• Chart.js 4.5.1 y SheetJS 0.20.3 instalados localmente.
• Servicios systemd, configuración Nginx e instalador para Raspberry Pi.

Configuracion parcial de sensores

• config/runtime.json guarda enabledSensors.
• Los sensores deshabilitados se muestran como DESHABILITADO.
• Un sensor deshabilitado no cuenta como OFFLINE, alarma ni riesgo global.

Seguridad operativa

• API_AUTH_TOKEN protege endpoints criticos cuando esta configurado.
• El dashboard envia el token como X-API-Token desde almacenamiento local del navegador.
• La API compara tokens en tiempo constante y emite headers defensivos basicos.
• Los POST criticos usan rate limit configurable en memoria.
• Sin API_AUTH_TOKEN, el modo desarrollo permanece sin autenticacion.

Bitacora de alarmas

• logs/alarms.csv registra transiciones a WARNING, CRITICAL, OFFLINE y recuperaciones RECOVERY.
• GET /api/alarms expone los eventos para dashboard y futuras notificaciones.
• Los sensores DISABLED no generan eventos de alarma.

Umbrales configurables

• GET /api/config/alarms expone los limites actuales.
• POST /api/config/alarms valida y persiste cambios en config/alarms.json.
• El dashboard permite editar min/max por sensor; guardar requiere token si API_AUTH_TOKEN esta activo.

Retencion historica

• historyRetentionDays en config/runtime.json controla poda automatica de CSV.
• Valores permitidos: 7, 30, 90, 365 o 0 para retencion indefinida.
• La poda conserva los nombres actuales de archivos para no romper graficas ni exportaciones.

Notificaciones

• config/notifications.json permite activar webhook y Telegram.
• GET /api/config/notifications devuelve configuracion redactada.
• POST /api/config/notifications valida y persiste canales con token.
• El recolector despacha notificaciones desde eventos de logs/alarms.csv.
• docs/TELEGRAM_BOT_SETUP.md documenta creacion del bot, obtencion de chatId, configuracion, pruebas y diagnostico.

Modos

• EZO_MODE=demo: adquisición y comandos simulados.
• EZO_MODE=auto: hardware cuando existen el bus y los helpers; demo en otro caso.
• EZO_MODE=hardware: producción estricta; un despliegue incompleto falla y no genera valores simulados.

Verificación realizada

• 16 pruebas automáticas aprobadas.
• Validación sintáctica de todos los JavaScript modificados.
• Dashboard, Chart.js, SheetJS y comando pH comprobados por HTTP en modo demo.
• npm audit --omit=dev: cero vulnerabilidades conocidas.

La compilación ARM, el bus I2C, la estabilidad de las sondas y las calibraciones metrológicas solo pueden verificarse en la Raspberry Pi con hardware real.

Trabajo pendiente en hardware

1. Ejecutar i2cdetect -y 1 y confirmar 0x61, 0x63, 0x64 y 0x66.
2. Compilar ambos helpers con make -C sensors/EZOCommand.
3. Validar i, Status, R y Cal,? individualmente.
4. Realizar las calibraciones con soluciones de referencia.
5. Probar desconexiones, reinicio automático y operación continua de varias horas.

Consulte docs/RASPBERRY_PI_DEPLOYMENT.md para el procedimiento completo.