Telemetría de generación eléctrica en tiempo real
Construí el servicio que lee cinco medidores de energía cada 2 segundos, integra la energía por periodo horario, la compara contra el despacho del mercado y alimenta un tablero en vivo y un reporte de Power BI.
Ficha del proyecto
- Rol
- Ingeniero de datos y backend, único desarrollador
- Periodo
- mar de 2026 a hoy
- Enlaces públicos
- Sistema interno: el código es privado, y los nombres, datos y diagramas se omitieron o se recrearon.
2 s
intervalo de lectura de 5 medidores por Modbus TCP, con latencia p50 de 15 a 25 msFuente: Configuración del servicio y mediciones de latencia, 2026 300 MB a 5 MB
reducción del tamaño del despliegue al pasar de un navegador automatizado a lectura directa de medidoresFuente: Registro de decisiones de arquitectura del proyecto 410+
casos de prueba automatizados entre Vitest y pytestFuente: Suites del repositorio, septiembre de 2026
El problema
La operación necesitaba ver en una sola pantalla la generación real de cuatro unidades frente a lo despachado por el operador del mercado, y la lectura existente dependía de un sistema centralizado que era un punto único de falla.
Mi rol
- Diseñé la lectura directa de los medidores, la integración de energía por periodo y el cruce con el despacho del mercado.
- Construí el backend en Node.js, el tablero en React y el servicio en Python que alimenta el lakehouse de datos.
- Validé estadísticamente los medidores de respaldo y documenté la convención de signos de cada frontera de medición.
- Opero dos instancias en producción, una por planta, con el mismo build.
Restricciones
- Lecturas cada 2 segundos sin perder la integración de energía si el servicio se reinicia.
- Dos plantas con convenciones de signo distintas según la frontera de medición.
- Un medidor caído no debe contaminar los totales con ceros falsos.
Decisiones
- 01
Lectura directa de los medidores por Modbus TCP
Elimina el punto único de falla y el navegador automatizado del despliegue, y permite medir la latencia de cada lectura.
Descartado
- Seguir raspando la interfaz web del sistema centralizado
- 02
Nulo significa sin lectura, nunca cero
Distinguir la ausencia de dato del valor cero permite detectar un medidor caído en lugar de reportar generación nula. La regla vive en un módulo de dominio que comparten el backend y el tablero.
Descartado
- Rellenar con cero las lecturas faltantes
- 03
Validación estadística antes de usar los medidores de respaldo
Una captura en paralelo de una hora con criterios de sesgo, p95 y energía integrada demostró que los medidores de respaldo son intercambiables.
Descartado
- Asumir que los medidores de respaldo leen igual
- 04
Un solo build para dos plantas, configurado al cargar
La identidad visual y el orden de las unidades de cada planta se leen de un archivo de configuración en tiempo de ejecución, así una corrección se despliega una vez y sirve a ambas.
Descartado
- Compilar una versión del tablero por planta
Arquitectura
Fuentes
- Medidores de energía5 medidores, Modbus TCP cada 2 s
- Archivos del operador del mercadoDespacho diario y redespacho cada 5 min
- Correos de redespachoLeídos con Microsoft Graph
Procesamiento
- Lector de medidoresAislamiento de fallas por unidad
- Integrador de energíaMW a MWh por periodo horario
- Servicio de telemetría en PythonTablas Delta sin Spark
Almacenamiento
- SQL ServerPeriodos, despacho e historial de cambios
- Lakehouse en Microsoft FabricCon espejo en PostgreSQL
Consumo
- Tablero en vivoReact por WebSockets
- Reporte de Power BI
Cómo se mueven los datos
- Medidores de energíahaciaLector de medidoresLecturas cada 2 s
- Lector de medidoreshaciaIntegrador de energíaPotencia por unidad, nula si falta un medidor
- Archivos del operador del mercadohaciaIntegrador de energíaDespacho programado por periodo
- Correos de redespachohaciaIntegrador de energíaDespacho final del periodo
- Integrador de energíahaciaSQL ServerPunto de control cada 30 s
- Integrador de energíahaciaTablero en vivoGeneración, proyección y desviación
- Medidores de energíahaciaServicio de telemetría en PythonLectura independiente
- Servicio de telemetría en PythonhaciaLakehouse en Microsoft FabricEscritura cada 15 s
- Lakehouse en Microsoft FabrichaciaReporte de Power BIModelo del reporte corporativo
Resultados
- La operación ve en una sola pantalla la generación real de cuatro unidades frente a lo despachado, con la proyección del periodo en curso.
- Desapareció el punto único de falla y la latencia de lectura bajó de cerca de 1,1 s a entre 15 y 25 ms (p50).
- Tras un reinicio, el servicio recupera los periodos cerrados desde la base de datos y no pierde energía integrada.
- La misma telemetría alimenta un reporte corporativo de Power BI sin tocar el tablero.
Qué haría distinto
- Mediría la latencia y la tasa de lecturas nulas desde el primer día; esas cifras justificaron el cambio de protocolo y habrían adelantado la decisión.
- Dejaría un único servicio de lectura de medidores que publique para ambos consumidores, en lugar de mantener la misma topología en Node.js y en Python.
Tecnologías
- Node.js
- Python
- Modbus TCP
- WebSockets
- SQL Server
- Microsoft Fabric
- PostgreSQL
- Power BI
- Microsoft Graph
- React
- Linux
- systemd