Cargando…
Cargando…
Guía de lectura
Todo lo que ves en esta web son medidas reales de la planta, sin retocar. Esta guía explica de dónde salen, con cuánto retraso llegan y cómo interpretarlas — tanto si vienes por curiosidad como si buscas el detalle técnico.
Cada número que ves aquí ha hecho el mismo recorrido, de la planta a tu pantalla:
4 strings + contador AC
Los medidores registran corriente, tensión, potencia y energía una vez por minuto: 4 strings fotovoltaicos en el lado DC y un contador a la salida del inversor (AC).
UWP 4.0 · Modbus
Un equipo instalado en la propia planta pregunta a los medidores por un bus industrial (Modbus RTU) y almacena todas las lecturas.
SFTP · 1 fichero/día
Poco después de medianoche, el datalogger genera un fichero con todas las medidas del día anterior y lo sube cifrado (SFTP) a un servidor de la UPM.
PostgreSQL · cada 6 h
Un proceso automático comprueba cada 6 horas si hay ficheros nuevos y los vuelca a la base de datos. Reprocesar un fichero nunca duplica una medida.
API + gráficas
Las páginas consultan esa base de datos y muestran los valores tal cual: si una medida no existe, verás un hueco, nunca un cero inventado.
Lo más reciente que verás aquí es la producción de ayer — y la web siempre te dice de cuándo es cada dato.
El dato viaja en un lote diario: el fichero que se genera hoy trae las medidas de ayer, y la web lo incorpora en las horas siguientes. En la práctica, la última muestra disponible tiene entre una y unas 30 horas de antigüedad.
La web no lo disimula: el dashboard indica siempre de cuándo es la última muestra («Datos hasta…») y habla del «último día con datos», nunca de «hoy». Que un dato tenga horas no le quita valor: para entender cuánto produce la planta importa la serie completa, no el minuto actual.
Cinco términos bastan para leer cualquier gráfica de esta web:
Un hueco en una gráfica significa «no hay medida», no «no se produjo». Si el datalogger se cae o un fichero no llega, las medidas de ese tramo no existen — y la web las muestra como ausencia. Convertir un hueco en un cero sería mentir: diría que la planta no produjo cuando lo que pasó es que nadie estaba midiendo.
No es teoría: entre el 26 y el 28 de junio de 2026 el datalogger de la planta estuvo caído, y esos días aparecen sin barra en las gráficas. Así es como debe verse.
Junto a los totales diarios verás la completitud «n/4»: cuántos de los 4 strings midieron ese día. Un día con 3/4 no es directamente comparable con uno de 4/4 — le falta un string entero — y por eso la web lo marca en vez de esconderlo.
Cada string lleva un contador de energía acumulada (kWh) que solo crece, como el cuentakilómetros de un coche. La energía de un día es la diferencia del acumulado entre el cierre del día y su inicio: si un contador marcase 1.900 kWh a medianoche y 1.925 kWh a la medianoche siguiente, ese string habría generado 25 kWh.
Este método aguanta bien los fallos: aunque falten muestras intermedias, el acumulador «recuerda» la energía generada entre medias. El cálculo real va por diferencias entre muestras consecutivas para detectar reinicios o desbordes del contador, y con menos de dos lecturas válidas el día queda en «sin dato», nunca en un cero falso. La energía de la planta es la suma de los 4 strings; si alguno no aporta, el total se marca como parcial (n/4).
Todo lo que muestra esta web puede consultarse también a máquina: una API REST de solo lectura, sin registro ni clave, con respuestas JSON y CORS abierto (peticiones desde cualquier origen). Sirve el mismo dato honesto que las gráficas: lotes diarios, huecos como null y completitud n/4 siempre visibles.
GET /api/monitoring/latestÚltima lectura válida por variable (corriente, potencia, energía acumulada y tensión DC).
| Parámetro | Valores | Descripción |
|---|---|---|
| scope | VMU-S_1 … VMU-S_4 · plant | Ámbito: un string DC concreto o el agregado de planta. Si se omite se sirve VMU-S_1. |
GET /api/monitoring/seriesSerie temporal de una variable, re-muestreada al paso pedido. Máximo 366 días y 1.500 puntos por respuesta.
| Parámetro | Valores | Descripción |
|---|---|---|
| var | A DC · kW DC · kWh (+)DC · V DC | Obligatorio. Variable a consultar. «V DC» no admite scope=plant: la tensión no se suma entre strings (400). |
| scope | VMU-S_1 … VMU-S_4 · plant | Ámbito: un string DC concreto o el agregado de planta. Si se omite se sirve VMU-S_1. |
| from | ISO 8601 | Inicio de la ventana (ISO 8601). Por defecto, una hora antes de «to». |
| to | ISO 8601 | Fin de la ventana (ISO 8601). Por defecto, el momento de la petición. Si la ventana pedida se sale del último dato, la servida se ancla a él conservando la duración (windowFrom/windowTo en la respuesta). |
| step | ≥ 1 | Paso de re-muestreo en minutos (mínimo 1). Si se omite se elige según el rango: 1, 15, 60 o 1440 min. |
GET /api/monitoring/dailyEnergía diaria (kWh/día) con desglose por string DC, en una ventana que termina en el último día con datos. Por defecto sirve el agregado de la planta; también se puede pedir un string concreto.
| Parámetro | Valores | Descripción |
|---|---|---|
| scope | VMU-S_1 … VMU-S_4 · plant | Ámbito: un string DC concreto o el agregado de planta. Si se omite se sirve la planta (a diferencia de latest y series, que sirven VMU-S_1). Con un string, la ventana termina en el último día con datos DE ESE string y el desglose trae una sola entrada. |
| days | 1 – 366 | Días de la ventana (por defecto 7), contados hacia atrás desde el último día con datos. |
| from | YYYY-MM-DD | Inicio de la ventana en días (YYYY-MM-DD, hora Madrid, incluido). Se envía junto a «to» y manda sobre «days»; máximo 366 días. El rango se sirve tal cual: los días posteriores al último con datos salen como null, no se recorta la ventana. |
| to | YYYY-MM-DD | Fin de la ventana en días (YYYY-MM-DD, hora Madrid, incluido). Se envía junto a «from» y no puede ser anterior a él. |
| format | json · csv | Formato de la respuesta: json (por defecto) o csv. El CSV descarga los días de la ventana (day, energy_kwh, strings_with_data, strings_total, complete) con separador decimal punto; un día sin dato es una celda VACÍA, nunca un 0. Los errores se devuelven siempre en JSON. |
Cada fila del CSV es un día de la ventana servida, en hora de Madrid. El nombre del fichero lleva el ámbito y el rango que se han servido de verdad (solar-demo-center_daily-energy_<ámbito>_<desde>_<hasta>.csv), así que dos descargas de ámbitos distintos nunca se pisan en la carpeta de descargas.
| Columna | Descripción |
|---|---|
| day | El día al que corresponde la fila (AAAA-MM-DD, hora de Madrid). |
| energy_kwh | Energía generada ese día en kWh. Celda vacía = no hubo medida ese día; un 0 sí es una medida real de cero. |
| strings_with_data | Cuántos strings aportaron dato ese día. Si son menos que el total, el kWh de la fila es una suma parcial: falta parte de la instalación, no es que produjera menos. |
| strings_total | Cuántos strings cubre el ámbito pedido: todos los de la planta si se pide el agregado, uno solo si has pedido un string concreto. |
| complete | true solo si todos los strings del ámbito aportaron ese día. Con un solo string, el total es 1 y basta con que ese aporte. |
Última lectura del agregado de planta, con curl:
curl "https://proyecto-solar.rlorenzo.com/api/monitoring/latest?scope=plant"Respuesta real (abreviada):
{
"updatedAt": "2026-07-08T22:00:00.000Z",
"values": { "A DC": 0, "kW DC": 0, "kWh (+)DC": 9972.1, "V DC": null },
"source": "postgres",
"scope": "plant",
"stringsWithData": { "A DC": 4, "kW DC": 4, "kWh (+)DC": 4 },
"stringsTotal": 4
}GET abierto desde cualquier origen (Access-Control-Allow-Origin: *), sin clave y sin límite de peticiones impuesto. A cambio, uso razonable: el dato cambia una vez al día y el servidor cachea 15 minutos, así que sondear más rápido no da datos más frescos.
Si reutilizas estos datos, cita la fuente: «UPM/Trina — Solar Demo Center». Se publican tal cual, con fines demostrativos, docentes y de investigación; las condiciones de reutilización están pendientes de acordar con el IES, titular de los datos. El descargo de responsabilidad está en el aviso legal.
El contrato completo (esquemas, parámetros, respuestas y errores) está descrito en una especificación OpenAPI 3.1 legible por máquina, lista para Swagger UI, Postman o generación de clientes:
/api/openapi.jsonCon esto ya puedes interpretar cualquier gráfica del dashboard — huecos incluidos.
Ir al dashboard