# Estado del Proyecto

## Resumen

El proyecto implementa un dashboard web para monitoreo de fotobiorreactor con
Raspberry Pi y circuitos Atlas Scientific EZO. La aplicacion puede trabajar en
modo demo para desarrollo sin hardware y en modo hardware usando `/dev/i2c-1`.

## Estado Actual

Implementado:

- Dashboard responsive.
- Lecturas en vivo desde `data/*.json`.
- Adquisicion automatica con `api/acquisition.js`.
- Helper C `EZO_ACQUIRE` para lecturas agrupadas.
- Helper C `EZO_COMMAND` para comandos y calibracion.
- Historial CSV por sensor.
- Graficas con Chart.js.
- Exportacion CSV y Excel con SheetJS.
- Alarmas configurables.
- Bitacora de alarmas en `logs/alarms.csv`.
- Notificaciones por webhook y Telegram.
- Configuracion de sensores habilitados.
- Retencion historica configurable.
- Servicios `systemd` para API y adquisicion.
- Configuracion Nginx.
- Instalador para Raspberry Pi.

## Componentes Principales

| Componente | Responsabilidad |
|---|---|
| `frontend/` | Dashboard, graficas, controles, exportaciones y consola EZO |
| `api/server.js` | API HTTP, configuracion, historicos, comandos y seguridad |
| `api/acquisition.js` | Proceso continuo de adquisicion |
| `api/acquisition-service.js` | Lectura, escritura atomica, alarmas y retencion |
| `api/notification-service.js` | Webhook y Telegram |
| `sensors/EZOCommand/EZO_ACQUIRE` | Lectura agrupada de sensores EZO |
| `sensors/EZOCommand/EZO_COMMAND` | Comandos individuales EZO |
| `config/*.json` | Configuracion operativa |
| `deployment/` | Servicios systemd, Nginx y variables de entorno |
| `scripts/install-raspberry-pi.sh` | Instalacion automatizada en Raspberry Pi |

## Sensores

| Sensor | Direccion esperada | Estado en software |
|---|---:|---|
| EZO-RTD | `0x66` | Implementado |
| EZO-pH | `0x63` | Implementado |
| EZO-DO | `0x61` | Implementado |
| EZO-EC | `0x64` | Implementado |

El sistema tambien puede detectar otros EZO en el bus, por ejemplo ORP, pero el
dashboard actual solo modela RTD, pH, DO y EC.

## Modos De Operacion

| Modo | Uso |
|---|---|
| `EZO_MODE=demo` | Desarrollo sin Raspberry ni sensores |
| `EZO_MODE=auto` | Usa hardware si esta disponible; si no, demo |
| `EZO_MODE=hardware` | Produccion estricta; no simula datos |

En Raspberry Pi de produccion se usa `EZO_MODE=hardware`.

## Datos

Lecturas actuales:

- `data/EZORTD.json`
- `data/EZOPH.json`
- `data/EZODO.json`
- `data/EZOEC.json`

Historicos:

- `logs/temperature.csv`
- `logs/ph.csv`
- `logs/do.csv`
- `logs/ec.csv`

Formato:

```csv
timestamp,value
2026-07-07T17:26:13.459Z,25.132
```

Las graficas muestran el dia actual. Los CSV conservan el periodo configurado
por `historyRetentionDays`.

## Alarmas

Los umbrales viven en:

```text
config/alarms.json
```

Estados:

- `NORMAL`
- `WARNING`
- `CRITICAL`
- `OFFLINE`
- `DISABLED`

Los eventos se guardan en:

```text
logs/alarms.csv
```

Los sensores deshabilitados no generan alarma ni riesgo global.

## Notificaciones

Configuracion:

```text
config/notifications.json
```

En produccion:

```text
/etc/photobioreactor/notifications.json
```

Canales:

- Webhook HTTP.
- Telegram Bot API.

El backend redacta secretos cuando envia configuracion al navegador.

## Seguridad

Implementado:

- `API_AUTH_TOKEN` para endpoints criticos.
- Header `X-API-Token`.
- Comparacion de token en tiempo constante.
- Rate limit para acciones criticas.
- Headers HTTP defensivos basicos.
- API escuchando en `127.0.0.1` detras de Nginx.

Pendiente si se expone fuera de LAN:

- HTTPS.
- Autenticacion de usuario completa.
- Politica de acceso por VPN o red privada.

## Validacion

Validado en desarrollo:

- Pruebas automatizadas Node.
- Modo demo.
- Dashboard por HTTP local.
- Chart.js y SheetJS locales.
- Comandos EZO simulados.
- Configuracion de alarmas y notificaciones.

Validacion en Raspberry:

- I2C mediante `/dev/i2c-1`.
- Servicios `systemd`.
- Lecturas reales parciales cuando los sensores estan conectados.

La calibracion metrologica y la estabilidad final deben verificarse siempre con
sondas reales, soluciones de referencia y operacion continua.

## Trabajo Pendiente Recomendado

- Prueba continua de 8 a 24 horas en Raspberry.
- Validacion con los cuatro sensores conectados.
- Calibracion real documentada con fecha y soluciones usadas.
- Confirmar notificaciones Telegram en la red final.
- Evaluar integracion futura de ORP si se decide usar ese sensor.
- Mejorar exportaciones para seleccionar rango: dia actual, ultimas 24 horas o
  todo el historico.

## Documentos Relacionados

- `README.md`
- `docs/README.md`
- `docs/QUICK_START.md`
- `docs/RASPBERRY_PI_DEPLOYMENT.md`
- `docs/EZO_COMMANDS.md`
- `docs/TROUBLESHOOTING.md`
- `docs/STORAGE_ESTIMATE.md`
- `docs/TELEGRAM_BOT_SETUP.md`
- `ARCHITECTURE.md`