Readme y Architecture actualizados
EMOTIONS-HUNTER
6 days ago
parent
71870b6f16
commit
2f33e59fe8
@ -1,229 +0,0 @@
|
|||||||
# Project Status - Photobioreactor Dashboard v1.0 + Phase 3
|
|
||||||
|
|
||||||
## Estado general
|
|
||||||
|
|
||||||
Este repositorio contiene un sistema de monitoreo local para un fotobiorreactor basado en sensores Atlas Scientific EZO. La arquitectura actual separa la captura de datos en C, los archivos de intercambio en `data/`, los historiales CSV en `logs/` y un dashboard web estatico en `frontend/`, pensado para desplegarse posteriormente en Raspberry Pi con Nginx.
|
|
||||||
|
|
||||||
## Arquitectura actual
|
|
||||||
|
|
||||||
El flujo principal del sistema es:
|
|
||||||
|
|
||||||
1. Los sensores Atlas Scientific se comunican por I2C con la Raspberry Pi.
|
|
||||||
2. Los programas en `sensors/` leen cada circuito EZO.
|
|
||||||
3. Cada lectura actual se escribe como JSON en `data/`.
|
|
||||||
4. Los historiales se almacenan como CSV en `logs/`.
|
|
||||||
5. Nginx sirve el repositorio como contenido estatico.
|
|
||||||
6. `frontend/index.html` carga `dashboard.css`, Chart.js y `dashboard.js`.
|
|
||||||
7. El navegador consulta los JSON cada segundo y actualiza las lecturas actuales.
|
|
||||||
8. La seccion `Alarm Summary` evalua umbrales desde `config/alarms.json`.
|
|
||||||
9. La seccion `Historical Trends` consulta los CSV cada 10 segundos y actualiza las graficas.
|
|
||||||
|
|
||||||
No hay backend web ni base de datos en esta version. El filesystem funciona como interfaz entre los daemons de sensores y el frontend.
|
|
||||||
|
|
||||||
## Sensores y archivos de datos actuales
|
|
||||||
|
|
||||||
| Sensor | Variable | Archivo JSON | Unidad |
|
|
||||||
|---|---|---|---|
|
|
||||||
| EZO-RTD | Temperatura | `data/EZORTD.json` | degC |
|
|
||||||
| EZO-pH | pH | `data/EZOPH.json` | pH |
|
|
||||||
| EZO-DO | Oxigeno disuelto | `data/EZODO.json` | mg/L |
|
|
||||||
| EZO-EC | Conductividad | `data/EZOEC.json` | uS/cm |
|
|
||||||
|
|
||||||
## Archivos de historial
|
|
||||||
|
|
||||||
| Variable | Archivo CSV | Grafica |
|
|
||||||
|---|---|---|
|
|
||||||
| Temperatura | `logs/temperature.csv` | Temperature vs Time |
|
|
||||||
| pH | `logs/ph.csv` | pH vs Time |
|
|
||||||
| Oxigeno disuelto | `logs/do.csv` | Dissolved Oxygen vs Time |
|
|
||||||
| Conductividad | `logs/ec.csv` | Conductivity vs Time |
|
|
||||||
|
|
||||||
Formato CSV soportado:
|
|
||||||
|
|
||||||
```csv
|
|
||||||
timestamp,value
|
|
||||||
1717027200,25.488
|
|
||||||
```
|
|
||||||
|
|
||||||
El frontend tambien acepta timestamps ISO 8601 en la primera columna.
|
|
||||||
|
|
||||||
## Archivos utilizados
|
|
||||||
|
|
||||||
| Ruta | Proposito |
|
|
||||||
|---|---|
|
|
||||||
| `frontend/index.html` | Estructura del dashboard, seccion `System Status` y seccion `Historical Trends`. |
|
|
||||||
| `frontend/dashboard.css` | Estilos responsive para metricas, estado del sistema y graficas. |
|
|
||||||
| `frontend/dashboard.js` | Lectura periodica de JSON, validacion de datos, lectura CSV y actualizacion de Chart.js. |
|
|
||||||
| `data/EZORTD.json` | Lectura actual de temperatura. |
|
|
||||||
| `data/EZOPH.json` | Lectura actual de pH. |
|
|
||||||
| `data/EZODO.json` | Lectura actual de oxigeno disuelto. |
|
|
||||||
| `data/EZOEC.json` | Lectura actual de conductividad. |
|
|
||||||
| `logs/temperature.csv` | Historial de temperatura para graficas. |
|
|
||||||
| `logs/ph.csv` | Historial de pH para graficas. |
|
|
||||||
| `logs/do.csv` | Historial de oxigeno disuelto para graficas. |
|
|
||||||
| `logs/ec.csv` | Historial de conductividad para graficas. |
|
|
||||||
| `config/sensors.json` | Configuracion declarativa de sensores Atlas Scientific. |
|
|
||||||
| `config/alarms.json` | Umbrales configurables para estados NORMAL, WARNING y CRITICAL. |
|
|
||||||
| `sensors/EZORTD/` | Codigo C existente para lectura EZO-RTD. |
|
|
||||||
| `sensors/EZOPH/` | Codigo C existente para lectura EZO-pH. |
|
|
||||||
| `sensors/EZODO/` | Codigo C existente para lectura EZO-DO. |
|
|
||||||
| `sensors/EZOEC/` | Codigo C existente para lectura EZO-EC. |
|
|
||||||
|
|
||||||
## Funciones implementadas en v1.0
|
|
||||||
|
|
||||||
- Dashboard profesional para monitoreo del fotobiorreactor.
|
|
||||||
- Lectura de temperatura, pH, oxigeno disuelto y conductividad.
|
|
||||||
- Actualizacion automatica de lecturas actuales cada 1 segundo.
|
|
||||||
- Fecha y hora de ultima actualizacion.
|
|
||||||
- Validacion independiente por sensor.
|
|
||||||
- Estado `OFFLINE` cuando un JSON no existe, no responde, contiene JSON invalido o no incluye un valor numerico valido.
|
|
||||||
- Estado global del sistema: `ALL SYSTEMS ONLINE`, `PARTIAL DATA` o `SYSTEM OFFLINE`.
|
|
||||||
- Seccion inferior `System Status`.
|
|
||||||
- Conteo de sensores activos y sensores offline.
|
|
||||||
- Diseno responsive para escritorio, tablet y movil.
|
|
||||||
|
|
||||||
## Funciones implementadas en Phase 2 - Historical Trends
|
|
||||||
|
|
||||||
- Nueva seccion `Historical Trends` debajo de `System Status`.
|
|
||||||
- Integracion de Chart.js para graficas de linea.
|
|
||||||
- Cuatro graficas independientes:
|
|
||||||
- Temperature vs Time.
|
|
||||||
- pH vs Time.
|
|
||||||
- Dissolved Oxygen vs Time.
|
|
||||||
- Conductivity vs Time.
|
|
||||||
- Lectura de historiales desde `logs/temperature.csv`, `logs/ph.csv`, `logs/do.csv` y `logs/ec.csv`.
|
|
||||||
- Actualizacion automatica de graficas cada 10 segundos.
|
|
||||||
- Estado visual `No historical data available` cuando un CSV no existe, esta vacio o no contiene datos numericos validos.
|
|
||||||
- Parser CSV reutilizable con soporte principal para `timestamp,value` y compatibilidad adicional con encabezados como `time`, `date`, nombres de variable y `reading`.
|
|
||||||
- Las instancias Chart.js se conservan en memoria y las actualizaciones cambian datasets existentes con `chart.update("none")`.
|
|
||||||
- Configuracion Chart.js para dashboard cientifico: `responsive: true`, `maintainAspectRatio: false` y `animation: false`.
|
|
||||||
- Funciones reutilizables para futuras graficas:
|
|
||||||
- `readHistoricalData()`
|
|
||||||
- `parseHistoricalCsv()`
|
|
||||||
- `buildChartDataset()`
|
|
||||||
- `getChartOptions()`
|
|
||||||
- `renderHistoricalChart()`
|
|
||||||
- `updateHistoricalTrends()`
|
|
||||||
- Diseno responsive para dos columnas en escritorio y una columna en movil.
|
|
||||||
|
|
||||||
## Funciones implementadas en Phase 3 - Alarmas y umbrales configurables
|
|
||||||
|
|
||||||
- Archivo `config/alarms.json` normalizado con umbrales por variable:
|
|
||||||
- Temperatura: 20 a 30 degC.
|
|
||||||
- pH: 6.8 a 7.5.
|
|
||||||
- Oxigeno disuelto: 4.0 a 12.0 mg/L.
|
|
||||||
- Conductividad: 500 a 2500 uS/cm.
|
|
||||||
- El frontend lee `../config/alarms.json` durante el ciclo de actualizacion.
|
|
||||||
- Cada sensor se evalua como:
|
|
||||||
- `NORMAL`: valor dentro del rango y fuera de la banda de advertencia.
|
|
||||||
- `WARNING`: valor dentro del rango, pero cerca de `min` o `max`.
|
|
||||||
- `CRITICAL`: valor por debajo de `min` o por encima de `max`.
|
|
||||||
- `OFFLINE`: JSON faltante, invalido o sin valor numerico.
|
|
||||||
- La banda `WARNING` usa el 10% del ancho del rango configurado, definido en `WARNING_MARGIN_RATIO`.
|
|
||||||
- Las tarjetas cambian visualmente por estado:
|
|
||||||
- Verde para `NORMAL`.
|
|
||||||
- Amarillo para `WARNING`.
|
|
||||||
- Rojo para `CRITICAL`.
|
|
||||||
- Gris para `OFFLINE`.
|
|
||||||
- Nueva seccion `Alarm Summary` con:
|
|
||||||
- `Active Critical Alarms`.
|
|
||||||
- `Active Warnings`.
|
|
||||||
- `Offline Sensors`.
|
|
||||||
- `Overall Risk Level`.
|
|
||||||
- Lista activa de sensores en alarma u offline.
|
|
||||||
- Estructura de eventos de alarma preparada para integraciones futuras:
|
|
||||||
- `sensorId`
|
|
||||||
- `sensorName`
|
|
||||||
- `severity`
|
|
||||||
- `value`
|
|
||||||
- `message`
|
|
||||||
- `createdAt`
|
|
||||||
|
|
||||||
## Arquitectura de alarmas
|
|
||||||
|
|
||||||
El flujo de alarmas es:
|
|
||||||
|
|
||||||
1. `dashboard.js` lee los JSON de sensores desde `data/`.
|
|
||||||
2. `dashboard.js` lee los umbrales desde `config/alarms.json`.
|
|
||||||
3. `evaluateSensorAlarm()` compara cada valor contra `min` y `max`.
|
|
||||||
4. `renderSystemStatus()` actualiza el estado general.
|
|
||||||
5. `renderAlarmSummary()` actualiza conteos, riesgo global y lista de alarmas.
|
|
||||||
|
|
||||||
La logica queda encapsulada para que una fase posterior pueda enviar los eventos generados por `getAlarmEvents()` a correo, Telegram o MQTT sin acoplar esas salidas al renderizado visual.
|
|
||||||
|
|
||||||
## Dependencias nuevas
|
|
||||||
|
|
||||||
| Dependencia | Uso | Carga |
|
|
||||||
|---|---|---|
|
|
||||||
| Chart.js | Renderizado de graficas historicas de linea | CDN en `frontend/index.html` |
|
|
||||||
|
|
||||||
Nota de despliegue: Chart.js por CDN requiere conectividad desde el navegador. Para una Raspberry Pi aislada o una red local sin internet, se recomienda descargar una copia local versionada y servirla desde `frontend/vendor/`.
|
|
||||||
|
|
||||||
## Nomenclatura de historiales CSV
|
|
||||||
|
|
||||||
Se detecto una inconsistencia entre `logs/temp.csv` y `logs/temperature.csv`:
|
|
||||||
|
|
||||||
- `frontend/dashboard.js` consume `logs/temperature.csv`.
|
|
||||||
- El archivo presente en `logs/` es `temperature.csv`.
|
|
||||||
- Versiones anteriores de `ARCHITECTURE.md` y `sensors/EZORTD/ezortd_daemon.c` apuntaban a `logs/temp.csv`.
|
|
||||||
|
|
||||||
Nomenclatura unica propuesta y aplicada para todo el proyecto:
|
|
||||||
|
|
||||||
| Variable | Nombre canonico |
|
|
||||||
|---|---|
|
|
||||||
| Temperatura | `logs/temperature.csv` |
|
|
||||||
| pH | `logs/ph.csv` |
|
|
||||||
| Oxigeno disuelto | `logs/do.csv` |
|
|
||||||
| Conductividad | `logs/ec.csv` |
|
|
||||||
|
|
||||||
La razon es mantener nombres descriptivos, consistentes con las etiquetas cientificas del dashboard y faciles de extender en exportaciones futuras.
|
|
||||||
|
|
||||||
## Proximas fases
|
|
||||||
|
|
||||||
1. Historial CSV persistente
|
|
||||||
- Unificar la escritura de logs en `logs/` o `data/`.
|
|
||||||
- Definir encabezados estables para cada sensor.
|
|
||||||
- Registrar timestamp ISO y valor numerico por lectura.
|
|
||||||
|
|
||||||
2. Controles de rango para graficas
|
|
||||||
- Agregar rangos de tiempo: 5 min, 1 h, 24 h.
|
|
||||||
- Permitir pausa/reanudacion de actualizacion historica.
|
|
||||||
- Mostrar minimos, maximos y promedios por ventana.
|
|
||||||
|
|
||||||
3. Notificaciones de alarmas
|
|
||||||
- Enviar eventos de `getAlarmEvents()` por correo.
|
|
||||||
- Enviar alertas por Telegram.
|
|
||||||
- Publicar alarmas por MQTT.
|
|
||||||
- Preparar salidas GPIO locales para alarmas criticas.
|
|
||||||
|
|
||||||
4. Exportacion CSV
|
|
||||||
- Descargar historiales por sensor.
|
|
||||||
- Exportar ventanas de tiempo seleccionadas.
|
|
||||||
- Mantener compatibilidad con herramientas de analisis cientifico.
|
|
||||||
|
|
||||||
5. Exportacion Excel
|
|
||||||
- Generar archivos `.xlsx` con hojas por sensor.
|
|
||||||
- Incluir metadatos del experimento.
|
|
||||||
- Preparar tablas y graficas basicas.
|
|
||||||
|
|
||||||
6. Calibracion Atlas Scientific
|
|
||||||
- Crear interfaz guiada para rutinas de calibracion.
|
|
||||||
- Registrar fecha, operador y resultado de calibracion.
|
|
||||||
- Proteger comandos criticos con confirmaciones.
|
|
||||||
|
|
||||||
7. Comandos EZO desde la web
|
|
||||||
- Agregar una API local para enviar comandos a los circuitos EZO.
|
|
||||||
- Implementar endpoints seguros para lectura, calibracion y diagnostico.
|
|
||||||
- Separar permisos de monitoreo y administracion.
|
|
||||||
|
|
||||||
## Notas de despliegue
|
|
||||||
|
|
||||||
Para Raspberry Pi con Nginx, el `root` del sitio debe apuntar al directorio raiz del repositorio. El dashboard se abre desde:
|
|
||||||
|
|
||||||
```text
|
|
||||||
/frontend/index.html
|
|
||||||
```
|
|
||||||
|
|
||||||
Desde esa ubicacion, el frontend lee los datos usando rutas relativas hacia `../data/*.json` y `../logs/*.csv`.
|
|
||||||
|
|
||||||
Chart.js se carga desde CDN en esta fase. Para uso sin internet en la Raspberry Pi, la siguiente mejora recomendada es descargar una copia local versionada de Chart.js y servirla desde `frontend/vendor/`.
|
|
||||||
@ -1,62 +1,219 @@
|
|||||||
# Sistema de Monitoreo de Parámetros Fisicoquímicos para Fotobiorreactor
|
# Sistema de Monitoreo de Parámetros Fisicoquímicos para Fotobiorreactor
|
||||||
|
|
||||||
**Estado del Proyecto:** Desarrollo Activo (Fase de Pruebas de Integración y Simulación I2C)
|
**Plataforma de hardware:** Raspberry Pi 4 Model B
|
||||||
**Plataforma de Hardware:** Raspberry Pi 4 Model B
|
**Estado del proyecto:** Desarrollo activo — Integración de hardware en curso (Fase 9)
|
||||||
**Pila Tecnológica:** Node.js, Express, Vanilla JavaScript, Nginx, C/C++
|
**Pila tecnológica:** C, Node.js, Express, Vanilla JavaScript, Nginx
|
||||||
|
**Protocolo de comunicación físico:** I²C (Inter-Integrated Circuit), 100 kHz — 400 kHz
|
||||||
|
|
||||||
## 1. Resumen del Proyecto
|
---
|
||||||
|
|
||||||
Este repositorio documenta la arquitectura de software y los lineamientos de diseño de hardware para un sistema de adquisición de datos en tiempo real orientado a fotobiorreactores. Aunque el repositorio fue inicializado bajo el título de un proyecto para la sonda de temperatura PT1000, el sistema actual constituye una plataforma integral para el monitoreo simultáneo de cuatro parámetros críticos utilizando módulos OEM de la serie EZO de Atlas Scientific:
|
## 1. Resumen Ejecutivo
|
||||||
|
|
||||||
* **Temperatura** (Sonda RTD PT1000)
|
Este repositorio documenta la arquitectura de software y las especificaciones de diseño de hardware de un sistema de adquisición de datos (DAQ) en tiempo real orientado a fotobiorreactores de escala de laboratorio. El proyecto se inició como un sistema de medición de temperatura de precisión basado en el módulo **EZO-RTD™** de Atlas Scientific y una sonda de platino PT1000; sin embargo, ha evolucionado en una plataforma integral de monitoreo que gestiona de forma simultánea cuatro parámetros fisicoquímicos críticos para el control de cultivos fotosintéticos.
|
||||||
* **Potencial de Hidrógeno** (Sonda de pH)
|
|
||||||
* **Oxígeno Disuelto** (Sonda DO galvánica/óptica)
|
|
||||||
* **Conductividad Eléctrica** (Sonda EC)
|
|
||||||
|
|
||||||
## 2. Arquitectura del Sistema
|
Los cuatro parámetros monitoreados y los módulos OEM asociados son los siguientes:
|
||||||
|
|
||||||
La solución implementa una topología de red distribuida localmente, utilizando un modelo Cliente-Servidor optimizado por un proxy inverso para la gestión del tráfico y la mitigación de restricciones de intercambio de recursos de origen cruzado (CORS).
|
| Parámetro | Módulo EZO | Dirección I²C | Unidad de medida |
|
||||||
|
|---|---|---|---|
|
||||||
|
| Temperatura | EZO-RTD™ (ISCCB-2) | `0x66` | °C |
|
||||||
|
| Potencial de Hidrógeno | EZO-pH™ | `0x63` | pH |
|
||||||
|
| Oxígeno Disuelto | EZO-DO™ | `0x61` | mg/L |
|
||||||
|
| Conductividad Eléctrica | EZO-EC™ | `0x64` | µS/cm |
|
||||||
|
|
||||||
|
La arquitectura del sistema implementa una topología de red distribuida localmente, separando de forma explícita las responsabilidades en cuatro capas: presentación (frontend), enrutamiento (Nginx), lógica de negocio y API (Node.js/Express) y adquisición de datos en hardware (demonios en C). Este diseño por capas garantiza la extensibilidad del sistema y permite la sustitución o incorporación de nuevos módulos sensores sin alterar la lógica de presentación.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Pila Tecnológica
|
||||||
|
|
||||||
### 2.1. Capa de Presentación (Frontend)
|
### 2.1. Capa de Presentación (Frontend)
|
||||||
Interfaz gráfica de usuario (GUI) asíncrona desarrollada en HTML5, CSS3 y JavaScript puro (ES6+). Implementa rutinas de *polling* de alta frecuencia (1000 ms) para la actualización de métricas en tiempo real y renderizado de series temporales mediante la biblioteca `Chart.js`.
|
|
||||||
|
|
||||||
### 2.2. Capa de Enrutamiento y Proxy (Nginx)
|
- **Lenguaje:** Vanilla JavaScript ES6+, HTML5, CSS3 puro
|
||||||
Servidor web Nginx configurado en el puerto `8888`. Actúa como servidor de archivos estáticos para la capa de presentación y opera como proxy inverso, redirigiendo todas las solicitudes HTTP bajo el prefijo `/api/` hacia el proceso de Node.js en el puerto `3000`.
|
- **Biblioteca de visualización:** Chart.js (entregada vía CDN)
|
||||||
|
- **Biblioteca de exportación tabular:** SheetJS (`xlsx.full.min.js`, vía CDN)
|
||||||
|
- **Ciclo de actualización de lecturas en vivo:** 1000 ms (intervalo de *polling*)
|
||||||
|
- **Ciclo de actualización de tendencias históricas:** 10 000 ms
|
||||||
|
- **Idioma de la interfaz:** Español neutro
|
||||||
|
|
||||||
|
### 2.2. Capa de Enrutamiento y Proxy
|
||||||
|
|
||||||
|
- **Servidor:** Nginx
|
||||||
|
- **Puerto de entrada:** `8888`
|
||||||
|
- **Función:** Entrega de archivos estáticos del frontend y proxy inverso transparente hacia el puerto `3000` para el prefijo `/api/`
|
||||||
|
|
||||||
### 2.3. Capa de Lógica de Negocio y API (Backend)
|
### 2.3. Capa de Lógica de Negocio y API
|
||||||
Servidor HTTP desarrollado en entorno Node.js utilizando el framework Express. Sus responsabilidades principales incluyen:
|
|
||||||
* Exposición de endpoints RESTful para la transmisión de telemetría.
|
|
||||||
* Simulación de retardos y latencias físicas inherentes al protocolo I2C (300 ms - 900 ms).
|
|
||||||
* Implementación de un analizador léxico (*Lexical Parser*) capaz de procesar el conjunto de instrucciones oficial de Atlas Scientific (calibración, compensación ambiental y diagnóstico).
|
|
||||||
|
|
||||||
### 2.4. Capa Física (Adquisición de Datos)
|
- **Entorno de ejecución:** Node.js (≥ v18)
|
||||||
Demonios ejecutables compilados en C/C++ responsables de la interrogación directa de los registros de hardware en el bus I2C de la Raspberry Pi a través de los pines GPIO (SDA/SCL).
|
- **Framework HTTP:** Express v5
|
||||||
|
- **Puerto de escucha:** `3000`
|
||||||
|
- **Dependencias de producción:** `express ^5.2.1`, `cors ^2.8.6`
|
||||||
|
|
||||||
## 3. Características Técnicas Implementadas
|
### 2.4. Capa de Adquisición de Datos (Hardware)
|
||||||
|
|
||||||
* **Motor de Evaluación de Alarmas:** Subsistema lógico que compara la telemetría en tiempo real contra umbrales de operación críticos y de advertencia definidos paramétricamente en el archivo `config/alarms.json`.
|
- **Lenguaje:** C (estándar C99)
|
||||||
* **Consola de Hardware Virtual:** Emulador integrado en la interfaz de usuario que permite la inyección de cadenas de comandos estandarizadas hacia los módulos EZO, facilitando rutinas de calibración multipunto y configuración de registros de compensación.
|
- **Interfaz de hardware:** Bus I²C del sistema operativo Linux mediante `/dev/i2c-1`
|
||||||
* **Módulo de Exportación de Datos:** Procesamiento de arreglos de datos históricos en el cliente y serialización a formato `.xlsx` utilizando la biblioteca `SheetJS`, permitiendo la extracción de registros tabulares para análisis posterior.
|
- **Encabezados del sistema utilizados:** `<linux/i2c-dev.h>`, `<sys/ioctl.h>`
|
||||||
|
- **Sistema de construcción:** GNU Make
|
||||||
|
|
||||||
## 4. Estructura del Directorio Fuente
|
---
|
||||||
|
|
||||||
|
## 3. Estructura del Directorio Fuente
|
||||||
|
|
||||||
```text
|
```text
|
||||||
/
|
/
|
||||||
├── api/
|
├── api/
|
||||||
│ └── server.js # Lógica de enrutamiento Express y simulador de protocolo EZO
|
│ └── server.js # Servidor Express: endpoints REST y parser léxico EZO
|
||||||
|
│
|
||||||
├── config/
|
├── config/
|
||||||
│ ├── alarms.json # Definición de límites operativos de seguridad
|
│ ├── alarms.json # Umbrales operativos configurables por variable
|
||||||
│ └── sensors.json # Metadatos y resolución de los instrumentos
|
│ └── sensors.json # Metadatos declarativos de los módulos EZO (dirección I²C, habilitación)
|
||||||
|
│
|
||||||
├── data/
|
├── data/
|
||||||
│ └── *.json # Vectores de estado transitorios poblados por procesos C++
|
│ ├── EZORTD.json # Vector de estado actual: temperatura (escrito por el demonio C)
|
||||||
|
│ ├── EZOPH.json # Vector de estado actual: pH
|
||||||
|
│ ├── EZODO.json # Vector de estado actual: oxígeno disuelto
|
||||||
|
│ └── EZOEC.json # Vector de estado actual: conductividad eléctrica
|
||||||
|
│
|
||||||
├── frontend/
|
├── frontend/
|
||||||
│ ├── index.html # Interfaz principal de control
|
│ ├── index.html # Punto de entrada del dashboard de monitoreo
|
||||||
│ ├── dashboard.js # Rutinas de renderizado y evaluación de estado
|
│ ├── dashboard.css # Hoja de estilos responsiva del sistema
|
||||||
│ ├── mock-service.js # Interfaz de comunicación asíncrona con el backend
|
│ ├── dashboard.js # Lógica principal: polling, evaluación de alarmas, gráficas
|
||||||
│ ├── export-service.js # Lógica de construcción de conjuntos de datos para gráficos
|
│ ├── mock-service.js # Capa de comunicación asíncrona con el backend (fetch/POST)
|
||||||
│ └── export-excel.js # Formateo y serialización de archivos de hoja de cálculo
|
│ ├── export-service.js # Serialización de datos históricos a formato CSV
|
||||||
|
│ └── export-excel.js # Generación de reportes multipagina en formato XLSX
|
||||||
|
│
|
||||||
├── logs/
|
├── logs/
|
||||||
│ └── *.csv # Registros históricos persistentes para series temporales
|
│ ├── temperature.csv # Historial persistente de temperatura (escrito por el demonio)
|
||||||
|
│ ├── ph.csv # Historial persistente de pH
|
||||||
|
│ ├── do.csv # Historial persistente de oxígeno disuelto
|
||||||
|
│ └── ec.csv # Historial persistente de conductividad eléctrica
|
||||||
|
│
|
||||||
├── sensors/
|
├── sensors/
|
||||||
│ └── */*.c # Código fuente de los controladores de hardware (I2C)
|
│ ├── EZORTD/
|
||||||
└── README.md
|
│ │ ├── ezortd.h # API pública: constante de dirección I²C y firma de getTemperature()
|
||||||
|
│ │ ├── ezortd.c # Implementación del protocolo I²C para el EZO-RTD
|
||||||
|
│ │ ├── main.c # Ejecutable de lectura única (one-shot), salida JSON a stdout
|
||||||
|
│ │ ├── ezortd_daemon.c # Demonio de lectura continua: escribe JSON y appends CSV
|
||||||
|
│ │ └── Makefile # Sistema de construcción del módulo RTD
|
||||||
|
│ │
|
||||||
|
│ ├── EZOPH/
|
||||||
|
│ │ ├── ezoph.h # API pública del módulo pH
|
||||||
|
│ │ ├── ezoph.c # Implementación del protocolo I²C para el EZO-pH
|
||||||
|
│ │ ├── main.c # Ejecutable de lectura única
|
||||||
|
│ │ └── Makefile
|
||||||
|
│ │
|
||||||
|
│ ├── EZODO/
|
||||||
|
│ │ ├── ezodo.h # API pública del módulo DO
|
||||||
|
│ │ ├── ezodo.c # Implementación del protocolo I²C para el EZO-DO
|
||||||
|
│ │ ├── main.c # Ejecutable de lectura única
|
||||||
|
│ │ └── Makefile
|
||||||
|
│ │
|
||||||
|
│ └── EZOEC/
|
||||||
|
│ ├── ezoec.h # API pública del módulo EC
|
||||||
|
│ ├── ezoec.c # Implementación del protocolo I²C para el EZO-EC
|
||||||
|
│ ├── main.c # Ejecutable de lectura única
|
||||||
|
│ └── Makefile
|
||||||
|
│
|
||||||
|
├── package.json # Manifiesto de dependencias Node.js
|
||||||
|
├── package-lock.json # Árbol de dependencias resuelto y bloqueado
|
||||||
|
├── README.md # Este documento
|
||||||
|
├── ARCHITECTURE.md # Especificación técnica de la arquitectura del sistema
|
||||||
|
└── PROJECT_STATUS.md # Estado de hitos, riesgos y fases pendientes
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Instrucciones de Despliegue
|
||||||
|
|
||||||
|
### 4.1. Requisitos Previos
|
||||||
|
|
||||||
|
- Node.js v18 o superior instalado en el sistema anfitrión
|
||||||
|
- Nginx instalado (`sudo apt install nginx` en sistemas Debian/Ubuntu)
|
||||||
|
- Acceso al directorio raíz del repositorio
|
||||||
|
|
||||||
|
### 4.2. Inicialización del Servidor de Backend (Node.js)
|
||||||
|
|
||||||
|
Desde el directorio raíz del repositorio, instalar las dependencias de producción y levantar el servidor:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm install
|
||||||
|
node api/server.js
|
||||||
|
```
|
||||||
|
|
||||||
|
El servidor quedará escuchando en `http://localhost:3000`. Verificar el inicio exitoso con el mensaje:
|
||||||
|
|
||||||
|
```
|
||||||
|
[MOCK SERVER] Backend Node.js corriendo en http://localhost:3000
|
||||||
|
```
|
||||||
|
|
||||||
|
Para ejecución persistente en segundo plano se recomienda el gestor de procesos `pm2`:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
npm install -g pm2
|
||||||
|
pm2 start api/server.js --name fotobiorreactor-api
|
||||||
|
pm2 save
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.3. Configuración del Proxy Inverso Nginx
|
||||||
|
|
||||||
|
Crear o editar el bloque de servidor activo de Nginx. En sistemas Debian-based, el archivo de configuración canónico es `/etc/nginx/sites-available/fotobiorreactor`:
|
||||||
|
|
||||||
|
```nginx
|
||||||
|
server {
|
||||||
|
listen 8888;
|
||||||
|
server_name localhost;
|
||||||
|
|
||||||
|
# Raíz del contenido estático: directorio raíz del repositorio
|
||||||
|
root /ruta/absoluta/al/repositorio;
|
||||||
|
index frontend/index.html;
|
||||||
|
|
||||||
|
# Entrega de archivos estáticos del frontend
|
||||||
|
location / {
|
||||||
|
try_files $uri $uri/ =404;
|
||||||
|
}
|
||||||
|
|
||||||
|
# Proxy inverso transparente hacia el backend Node.js
|
||||||
|
location /api/ {
|
||||||
|
proxy_pass http://127.0.0.1:3000;
|
||||||
|
proxy_http_version 1.1;
|
||||||
|
proxy_set_header Host $host;
|
||||||
|
proxy_set_header X-Real-IP $remote_addr;
|
||||||
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Habilitar el sitio y recargar el servicio:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo ln -s /etc/nginx/sites-available/fotobiorreactor /etc/nginx/sites-enabled/
|
||||||
|
sudo nginx -t
|
||||||
|
sudo systemctl reload nginx
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4.4. Acceso al Cliente
|
||||||
|
|
||||||
|
Abrir un navegador web y dirigirse a:
|
||||||
|
|
||||||
|
```
|
||||||
|
http://localhost:8888/frontend/index.html
|
||||||
|
```
|
||||||
|
|
||||||
|
El dashboard iniciará automáticamente el ciclo de polling hacia la API y las lecturas en vivo comenzarán a actualizarse con los datos simulados del backend.
|
||||||
|
|
||||||
|
### 4.5. Construcción de los Demonios en C (Hardware Real)
|
||||||
|
|
||||||
|
Para compilar los controladores de hardware en la Raspberry Pi, ejecutar el siguiente procedimiento por módulo sensor (se ilustra con el módulo RTD):
|
||||||
|
|
||||||
|
```bash
|
||||||
|
cd sensors/EZORTD
|
||||||
|
make
|
||||||
|
```
|
||||||
|
|
||||||
|
Esto generará el ejecutable `EZORTD`. Antes de compilar el demonio continuo (`ezortd_daemon.c`), actualizar las rutas absolutas codificadas en el código fuente para que correspondan al directorio de despliegue real en la Raspberry Pi.
|
||||||
|
|
||||||
|
**Nota:** El bus I²C debe estar habilitado en la Raspberry Pi mediante `sudo raspi-config` → *Interface Options* → *I2C* → *Enable*. Se recomienda agregar el usuario de ejecución al grupo `i2c` para evitar la ejecución con privilegios de superusuario:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo usermod -aG i2c $USER
|
||||||
|
```
|
||||||
Loading…
Reference in New Issue