Previsão de Carga de Energia com Dados de Medidores IoT e MQTT

A previsão de carga de energia estima quanta eletricidade um prédio, uma fábrica ou uma unidade vai consumir nas próximas horas ou dias. Com medidores IoT enviando leituras via MQTT, você pode construir uma previsão a partir dos seus próprios dados, em vez de depender da conta mensal. Este caso de uso percorre o caminho dos dados do medidor até o modelo, as variáveis que importam para a demanda, um script funcional de previsão para o dia seguinte e como publicar o resultado para que ele oriente decisões de redução de picos e de programação.

Por que prever a carga de energia

Uma previsão de carga responde a perguntas práticas que gestores de instalações e de produção enfrentam todos os dias:

• Gestão do pico de demanda. Muitas tarifas incluem cobrança de demanda com base no intervalo mais alto do mês. Saber com antecedência que a tarde de amanhã vai se aproximar do limite permite deslocar cargas flexíveis.
• Programação de cargas flexíveis. Processos em lote, recarga de veículos elétricos, pré-resfriamento e aquecimento de água podem ser movidos para horários de menor demanda ou de preços mais baixos.
• Compra de energia e autoconsumo. Unidades com energia solar, baterias ou contratos com tarifa horária precisam de uma previsão de demanda para decidir quando carregar, descarregar ou comprar.
• Detecção de anomalias. Uma diferença grande e persistente entre a carga prevista e a real costuma indicar equipamento esquecido ligado, um compressor com defeito ou uma falha de medição.

O horizonte de previsão depende da decisão: previsões intradiárias (próximas horas) apoiam o controle em tempo real, previsões para o dia seguinte apoiam a programação e as compras, e horizontes mais longos apoiam o orçamento.

O caminho dos dados: do medidor ao modelo

Uma configuração típica tem medidores ou submedidores de eletricidade conectados a um gateway que os lê via Modbus, M-Bus ou uma API do fabricante e publica as leituras em um broker MQTT. Dados meteorológicos e programações de produção ou de ocupação são publicados ou armazenados junto.

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

Uma estrutura de topics clara mantém o modelo independente dos fabricantes de medidores:

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":[...]}

Sempre que possível, publique a energia como um contador acumulado em vez de valores por intervalo. Se uma mensagem se perder, o próximo valor do contador ainda contém o consumo, e a demanda por intervalo pode ser reconstruída com exatidão pela diferença. A potência instantânea é útil para dashboards ao vivo, mas ruidosa para previsão. Se os seus medidores são dispositivos Modbus, o guia Modbus TCP para MQTT mostra o lado do gateway.

Variáveis que determinam a previsão de carga de energia

Em previsões para o dia seguinte, toda variável precisa estar disponível antes de a previsão ser feita. Isso significa usar a previsão do tempo, e não a temperatura medida, para as horas futuras, e usar defasagens de pelo menos 24 horas. Misturar clima medido e clima previsto no treinamento é um motivo comum para modelos que parecem excelentes nos testes e decepcionam na operação.

Uma previsão para o dia seguinte em Python

O script abaixo simula o contador do medidor e a temperatura externa de um prédio comercial ao longo de quatro semanas, publica os dados no servidor MQTT público gratuito (apenas para testes), coleta-os de volta, converte o contador em demanda de 15 minutos, treina um modelo de gradient boosting e publica uma previsão de 24 horas. Em uma implantação real, a etapa de coleta leria do seu historiador em vez de um 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 weeks of 15-minute intervals
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)  # two messages per step, stay under 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()

Instale com pip install paho-mqtt pandas numpy scikit-learn. A execução leva cerca de dez minutos porque o simulador respeita o limite de taxa do broker público. O dia de teste aqui usa a temperatura medida simulada como substituta de uma previsão do tempo; em produção, alimente o modelo com a temperatura prevista para as horas futuras. Para entender o backtesting com várias origens de previsão e a comparação com uma linha de base ingênua, veja previsão de séries temporais em IoT.

Transformando a previsão em ação

Uma previsão só se paga quando muda decisões. Padrões comuns:

1. Alertas de pico. Compare o pico previsto com o seu limite de demanda e avise a equipe de facilities na noite anterior.
2. Deslocamento de carga. Um script de programação assina o topic de previsão e move cargas flexíveis, como recarga de veículos elétricos ou aquecimento em lote, para intervalos de baixa demanda.
3. Pré-resfriamento e pré-aquecimento. O HVAC pode usar horários baratos ou de baixa demanda para armazenar energia térmica na massa do prédio, um padrão abordado em otimização de HVAC com IA.
4. Monitoramento de previsto versus real. Publique o desvio ao vivo em um topic próprio e gere alertas para diferenças persistentes.

Com o ConnectMQ, você pode acompanhar os topics de previsão e de potência medida no explorador de topics ao vivo e definir regras de alerta por limite na demanda medida, de modo que o registro de alertas guarde cada intervalo que ultrapassou o seu limite. Ações mais avançadas rodam nos seus próprios clientes, como fluxos Node-RED ou serviços Python inscritos no mesmo broker.

Atualizando previsões ao longo do dia

Uma previsão para o dia seguinte é feita uma vez, mas o dia raramente sai exatamente como planejado. Um turno extra não programado ou uma tarde mais quente do que o previsto altera a carga. Uma melhoria simples é executar a previsão novamente a cada hora usando a demanda medida mais recente como entrada adicional e publicar cada nova versão no mesmo topic retido, com um timestamp de geração. Os consumidores sempre veem a visão mais recente, e você pode armazenar todas as versões para medir quanto as atualizações intradiárias melhoram a precisão em relação à execução original do dia anterior.

Armadilhas práticas

• Zeramento e estouro de contadores. Medidores dão a volta ou são zerados após uma substituição; trate diferenças negativas como zeramentos, não como demanda negativa.
• Fusos horários e horário de verão. Armazene em UTC e calcule as variáveis de calendário no horário local, ou a sua partida das 08:00 vai se deslocar uma hora duas vezes por ano.
• Feriados e paradas. Sem um indicador de feriado, o modelo vai prever uma carga normal de dia útil em um feriado.
• Linhas de base que mudam. Equipamentos novos, retrofits ou mudanças no horário de funcionamento tornam o histórico antigo enganoso; dê mais peso aos dados recentes ou treine novamente em uma janela deslizante.
• Somas de submedidores que não batem com o medidor principal. Existem cargas não medidas e perdas; preveja o medidor principal diretamente em vez de somar previsões de submedidores, e use os submedidores para diagnóstico.

Escalando para várias unidades

Um prédio é um script; cinquenta unidades são uma plataforma. Mantenha a estrutura de topics idêntica em todas as unidades, execute um único serviço de previsão que assina com wildcards e armazene os resultados por unidade, seja um prédio comercial em São Paulo ou uma planta em Campinas. As previsões publicadas também podem alimentar um gêmeo digital de cada unidade. Um broker MQTT gerenciado elimina o trabalho operacional de manter a camada de mensageria, e o ConnectMQ oferece clusters dedicados e implantações BYOC quando as unidades exigem isolamento. Para saber mais sobre como combinar modelos com dispositivos conectados, veja o guia de IA e IoT e, para uma visão baseada em modelos dos sistemas de energia, gêmeos digitais para energia.

Comece a usar o ConnectMQ

Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Conecte o gateway dos medidores e o serviço de previsão com YOUR_USERNAME, YOUR_PASSWORD e YOUR_CLIENT_ID gerados e comece a construir o histórico de que o seu modelo de previsão de carga de energia precisa. À medida que adicionar unidades, migre para um plano maior de broker MQTT na nuvem sem alterar os seus topics.

Perguntas frequentes

O que é previsão de carga de energia?

A previsão de carga de energia estima a demanda de eletricidade de um prédio, uma fábrica ou uma área da rede para intervalos futuros, normalmente a partir de dados históricos de medidores, clima e calendário.

Quantos dados preciso para prever a carga de energia?

Algumas semanas de dados em intervalos de 15 minutos podem gerar uma previsão utilizável para o dia seguinte em um prédio com programações estáveis. É preciso um ano ou mais para capturar os padrões sazonais de aquecimento e resfriamento e os feriados.

Devo publicar energia ou potência a partir dos meus medidores?

Publique o contador de energia acumulada para garantir precisão na previsão e no faturamento, porque mensagens perdidas não fazem perder consumo. Publique também a potência instantânea se precisar de dashboards ao vivo.

Qual modelo funciona melhor para previsão de carga?

Gradient boosting com variáveis de calendário, defasagem e clima é um padrão robusto e explicável. Compare-o com uma linha de base do mesmo dia da semana anterior e só troque se outro modelo vencer em um backtest contínuo.