Predicción de demanda energética con datos IoT

La predicción de demanda energética estima cuánta electricidad consumirá un edificio, una planta o un emplazamiento en las próximas horas o días. Con contadores IoT que envían lecturas por MQTT, puedes construir un pronóstico a partir de tus propios datos en lugar de depender de las facturas mensuales. Este caso de uso recorre el camino de los datos desde el contador hasta el modelo, las variables que importan para la demanda, un script funcional de predicción del día siguiente y cómo publicar el resultado para que sirva para recortar picos y tomar decisiones de planificación.

Por qué predecir la demanda energética

Un pronóstico de carga responde a preguntas prácticas que los responsables de instalaciones y producción afrontan a diario:

Gestión de la demanda máxima. Muchas tarifas incluyen cargos por potencia basados en el intervalo más alto del mes. Saber de antemano que mañana por la tarde te acercarás al límite te permite desplazar cargas flexibles.
Planificación de cargas flexibles. Los procesos por lotes, la carga de vehículos eléctricos, el preenfriamiento y el calentamiento de agua pueden moverse a horas con menor demanda o precios más bajos.
Compras y autoconsumo. Los emplazamientos con fotovoltaica, baterías o contratos con discriminación horaria necesitan un pronóstico de demanda para decidir cuándo cargar, descargar o comprar.
Detección de anomalías. Una diferencia grande y persistente entre el pronóstico y la carga real suele indicar equipos que se han quedado encendidos, un compresor que falla o un error de medición.

El horizonte de predicción depende de la decisión: los pronósticos intradía (próximas horas) apoyan el control en tiempo real, los del día siguiente apoyan la planificación y las compras, y los horizontes más largos sirven para elaborar presupuestos.

El camino de los datos: del contador al modelo

Una instalación típica tiene contadores o subcontadores eléctricos conectados a un gateway que los lee por Modbus, M-Bus o una API del fabricante y publica las lecturas en un broker MQTT. Los datos meteorológicos y los calendarios de producción u ocupación se publican o almacenan junto a ellos.

Meters (Modbus RTU/TCP) -> gateway -> MQTT broker -> historian subscriber -> forecasting service
                                           ^                                         |
                       weather / schedule publisher                 forecast topic <-+

Una estructura de topics clara mantiene el modelo independiente de los fabricantes de contadores:

connectmq/site1/main/meter1/energy       {"ts":..., "kwh_total": 183422.6}
connectmq/site1/main/meter1/power        {"ts":..., "kw": 142.8}
connectmq/site1/weather/outdoor          {"ts":..., "temp_c": 27.4}
connectmq/site1/main/meter1/forecast     {"generated":..., "points":[...]}

Siempre que puedas, publica la energía como un contador acumulado en lugar de valores por intervalo. Si se pierde un mensaje, el siguiente valor del contador sigue conteniendo el consumo, y la demanda por intervalo se puede reconstruir exactamente por diferencias. La potencia instantánea es útil para dashboards en directo, pero resulta ruidosa para predecir. Si tus contadores son dispositivos Modbus, la guía Modbus TCP a MQTT muestra la parte del gateway.

Variables que determinan la predicción de demanda energética

Grupo de variables	Ejemplos	Por qué importa
Calendario	Hora del día, día de la semana, indicador de festivo, mes	La ocupación y la producción siguen horarios
Carga con retardo	Misma hora de ayer, misma hora de la semana pasada	La demanda tiene una fuerte persistencia
Clima	Temperatura exterior, su pronóstico, humedad, irradiancia solar	Las cargas de calefacción y refrigeración dependen de ella
Clima derivado	Grados-hora de refrigeración y calefacción, retardo de temperatura	Los edificios responden con inercia térmica
Operación	Plan de producción, patrón de turnos, recuento de ocupantes	Explica la variación no debida al clima

En los pronósticos del día siguiente, todas las variables deben estar disponibles antes de hacer la predicción. Eso significa usar el pronóstico meteorológico, no la temperatura medida, para las horas futuras, y usar retardos de al menos 24 horas. Mezclar clima medido y pronosticado durante el entrenamiento es una causa habitual de modelos que parecen excelentes en las pruebas y decepcionan en operación.

Un pronóstico del día siguiente en Python

El siguiente script simula el contador y la temperatura exterior de un edificio comercial durante cuatro semanas, los publica en el servidor MQTT público gratuito (pensado para pruebas y prototipos, no para datos de producción), los vuelve a recoger, convierte el contador en demanda cada 15 minutos, entrena un modelo de gradient boosting y publica un pronóstico de 24 horas. En un despliegue real, el paso de recogida leería de tu historian en lugar de un simulador.

import json
import math
import random
import time
import uuid

import numpy as np
import pandas as pd
import paho.mqtt.client as mqtt
from sklearn.ensemble import HistGradientBoostingRegressor

BROKER = "broker.connectmq.com"
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/site1"
START = 1767225600  # 2026-01-01 00:00 UTC
STEPS = 28 * 96     # 4 semanas de intervalos de 15 minutos
rows = []


def on_message(client, userdata, msg):
    p = json.loads(msg.payload)
    p["kind"] = msg.topic.rsplit("/", 1)[1]
    rows.append(p)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="elf-" + uuid.uuid4().hex[:8])
client.on_message = on_message
client.connect(BROKER, 1883, keepalive=60)
client.subscribe([(f"{BASE}/meter1/energy", 1), (f"{BASE}/weather/temp", 1)])
client.loop_start()
time.sleep(1)

counter = 100000.0
for i in range(STEPS):
    t = START + i * 900
    hour = (t % 86400) / 3600
    workday = time.gmtime(t).tm_wday < 5
    temp = 24 + 7 * math.sin((hour - 9) / 24 * 2 * math.pi) + random.gauss(0, 1)
    occupied = workday and 7 <= hour < 19
    kw = 40 + (90 if occupied else 0) + 6 * max(temp - 22, 0) + random.gauss(0, 5)
    counter += kw * 0.25
    client.publish(f"{BASE}/meter1/energy", json.dumps({"ts": t * 1000, "kwh_total": round(counter, 2)}))
    client.publish(f"{BASE}/weather/temp", json.dumps({"ts": t * 1000, "temp_c": round(temp, 2)}))
    time.sleep(0.21)  # dos mensajes por paso, por debajo de 10 msg/s

time.sleep(3)

df = pd.DataFrame(rows)
df["ts"] = pd.to_datetime(df["ts"], unit="ms", utc=True)
energy = df[df.kind == "energy"].set_index("ts")["kwh_total"].sort_index().resample("15min").last()
temp = df[df.kind == "temp"].set_index("ts")["temp_c"].sort_index().resample("15min").mean()

data = pd.DataFrame({"kw": energy.interpolate().diff() * 4, "temp": temp.interpolate()})
data["hour"] = data.index.hour + data.index.minute / 60
data["dow"] = data.index.dayofweek
data["lag_1d"] = data["kw"].shift(96)
data["lag_7d"] = data["kw"].shift(7 * 96)
data["cdh"] = (data["temp"] - 22).clip(lower=0)
FEATS = ["hour", "dow", "lag_1d", "lag_7d", "temp", "cdh"]
data = data.dropna()

train, test = data.iloc[:-96], data.iloc[-96:]
model = HistGradientBoostingRegressor(max_iter=300, learning_rate=0.05).fit(train[FEATS], train["kw"])
pred = model.predict(test[FEATS])
mae = np.mean(np.abs(pred - test["kw"]))
print(f"Day-ahead MAE: {mae:.1f} kW, peak forecast {pred.max():.0f} kW, actual peak {test['kw'].max():.0f} kW")

forecast = {
    "generated": int(time.time() * 1000),
    "model": "gbr-load-v1",
    "unit": "kW",
    "points": [{"ts": int(ts.timestamp() * 1000), "kw": round(float(v), 1)} for ts, v in zip(test.index, pred)],
}
client.publish(f"{BASE}/meter1/forecast", json.dumps(forecast), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()

Instálalo con pip install paho-mqtt pandas numpy scikit-learn. La ejecución tarda unos diez minutos porque el simulador respeta el límite de mensajes del broker público. El día de prueba usa aquí la temperatura medida simulada como sustituto de un pronóstico meteorológico; en producción, proporciona al modelo la temperatura pronosticada para las horas futuras. Para profundizar en el backtesting con varios orígenes de predicción y la comparación con una línea base ingenua, consulta predicción de series temporales IoT.

Convertir el pronóstico en acciones

Un pronóstico solo compensa cuando cambia decisiones. Patrones habituales:

Alertas de pico. Compara el pico pronosticado con tu límite de potencia y avisa al equipo de mantenimiento la tarde anterior.
Desplazamiento de cargas. Un script de planificación se suscribe al topic del pronóstico y mueve cargas flexibles, como la carga de vehículos eléctricos o el calentamiento por lotes, a intervalos de baja demanda.
Preenfriamiento y precalentamiento. La climatización puede aprovechar horas baratas o de baja demanda para almacenar energía térmica en la masa del edificio, un patrón que se trata en optimización HVAC con IA.
Seguimiento de pronóstico frente a real. Publica la desviación en directo como un topic propio y genera alertas ante diferencias persistentes.

Con ConnectMQ puedes observar los topics del pronóstico y de la potencia medida en el explorador de topics en directo y definir reglas de alerta por umbral sobre la demanda medida, de modo que el registro de alertas recoja cada intervalo que haya superado tu límite. Las acciones más avanzadas se ejecutan en tus propios clientes, como flujos de Node-RED o servicios Python suscritos al mismo broker.

Actualizar los pronósticos a lo largo del día

Un pronóstico del día siguiente se hace una sola vez, pero el día rara vez transcurre exactamente según lo previsto. Un turno extra no planificado o una tarde más calurosa de lo esperado modifican la carga. Una mejora sencilla es volver a ejecutar el pronóstico cada hora usando la última demanda medida como entrada adicional, y publicar cada nueva versión en el mismo topic retenido con una marca de tiempo de generación. Los consumidores siempre ven la visión más reciente, y puedes almacenar todas las versiones para medir cuánto mejoran la precisión las actualizaciones intradía respecto a la ejecución original del día anterior.

Errores prácticos frecuentes

Reinicios y desbordamientos del contador. Los contadores dan la vuelta o se reinician tras una sustitución; trata las diferencias negativas como reinicios, no como demanda negativa.
Zonas horarias y horario de verano. Almacena en UTC y calcula las variables de calendario en hora local, o tu arranque de las 08:00 se desplazará una hora dos veces al año.
Festivos y paradas. Sin un indicador de festivo, el modelo pronosticará la carga de un día laborable normal en un festivo.
Líneas base cambiantes. Equipos nuevos, reformas o cambios de horario hacen que el historial antiguo resulte engañoso; da más peso a los datos recientes o reentrena con una ventana deslizante.
Sumas de subcontadores que no cuadran con el contador principal. Existen cargas no medidas y pérdidas; pronostica directamente el contador principal en lugar de sumar pronósticos de subcontadores, y usa los subcontadores para diagnóstico.

Escalar a varios emplazamientos

Un edificio es un script; cincuenta emplazamientos, repartidos por ejemplo entre Monterrey, Bogotá y Valencia, son una plataforma. Mantén la misma estructura de topics en todos los emplazamientos, ejecuta un único servicio de predicción que se suscriba con comodines y almacena los resultados por emplazamiento. Un broker MQTT gestionado elimina el trabajo operativo de mantener la capa de mensajería, y ConnectMQ ofrece clústeres Dedicated y despliegues BYOC cuando los emplazamientos requieren aislamiento. Para saber más sobre cómo combinar modelos con dispositivos conectados, consulta la guía de IA e IoT, y para una visión basada en modelos de los sistemas energéticos, gemelos digitales para energía. Si además quieres ver la demanda y el pronóstico sobre el propio edificio, un gemelo digital 3D permite situar cada contador en su planta y su zona.

Empieza con ConnectMQ

Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Conecta tu gateway de contadores y tu servicio de predicción con los YOUR_USERNAME, YOUR_PASSWORD y YOUR_CLIENT_ID generados, y empieza a construir el historial que necesita tu modelo de predicción de demanda energética. A medida que añadas emplazamientos, pasa a un plan de broker MQTT en la nube más grande sin cambiar tus topics.

Preguntas frecuentes

¿Qué es la predicción de demanda energética?

La predicción de demanda energética estima la demanda eléctrica de un edificio, una planta o una zona de la red para intervalos de tiempo futuros, normalmente a partir de datos históricos de contadores, información meteorológica y de calendario.

¿Cuántos datos necesito para predecir la demanda energética?

Unas pocas semanas de datos cada 15 minutos pueden producir un pronóstico del día siguiente utilizable para un edificio con horarios estables. Se necesita un año o más para capturar los patrones estacionales de calefacción y refrigeración y los festivos.

¿Debo publicar energía o potencia desde mis contadores?

Publica el contador de energía acumulada para lograr precisión en la predicción y la facturación, porque los mensajes perdidos no hacen que se pierda consumo. Publica además la potencia instantánea si necesitas dashboards en directo.

¿Qué modelo funciona mejor para predecir la demanda?

El gradient boosting sobre variables de calendario, retardos y clima es una opción por defecto sólida y explicable. Compáralo con una línea base de mismo día de la semana anterior y cámbialo solo si otro modelo gana en un backtest móvil.

Predicción de demanda energética con datos de contadores IoT y MQTT