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

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