Otimização de HVAC com IA: Setpoints e Horários Mais Inteligentes com Dados MQTT

A otimização de HVAC com IA usa dados do sistema de aquecimento, ventilação e ar-condicionado de um edifício para aprender como cada zona realmente se comporta e, em seguida, escolhe horários de partida, setpoints e programações que mantêm os ocupantes confortáveis com menos energia. Neste caso de uso, você vai ver quais dados coletar via MQTT, como aprender a resposta térmica de uma zona a partir desses dados, como calcular um horário de partida ideal e como enviar recomendações de volta ao edifício com segurança.

Onde o controle convencional de HVAC desperdiça energia

A maioria dos sistemas de automação predial roda com programações e setpoints fixos configurados no comissionamento. A unidade de tratamento de ar de um prédio corporativo em São Paulo ou de um shopping em Manaus liga às 06:00 todos os dias úteis porque alguém um dia decidiu que esse horário era cedo o bastante, independentemente de a noite ter sido amena ou fria. Os setpoints continuam no mesmo valor durante uma tarde de sexta-feira meio vazia. Aquecimento e resfriamento simultâneos em zonas vizinhas passam despercebidos por meses.

Nada disso é uma falha dos controladores, que cumprem bem o seu papel de manter um setpoint. A lacuna está no nível supervisório: decidir quais devem ser os setpoints e as programações, considerando o clima, a ocupação e o comportamento térmico do edifício. É aí que os modelos orientados a dados ajudam, e é por isso que a otimização de HVAC com IA geralmente fica acima do sistema de automação predial existente, em vez de substituí-lo.

Dados a coletar para a otimização de HVAC com IA

Sistemas de automação predial geralmente falam BACnet ou Modbus. Um gateway lê os pontos relevantes e os publica em um broker MQTT sob uma hierarquia consistente, para que o serviço de otimização nunca precise conhecer os nomes de pontos de cada fabricante:

connectmq/hq/floor3/zone-east/temperature     {"ts":..., "value": 23.8, "unit":"degC"}
connectmq/hq/floor3/zone-east/setpoint        {"ts":..., "value": 22.0, "unit":"degC"}
connectmq/hq/floor3/ahu2/supply_temp          {"ts":..., "value": 14.2, "unit":"degC"}
connectmq/hq/weather/outdoor_temp             {"ts":..., "value": 31.5, "unit":"degC"}
connectmq/hq/floor3/zone-east/recommendation  {"ts":..., "start_at":"06:40", "reason":"..."}

Se você está escolhendo entre protocolos prediais no gateway, BACnet vs Modbus compara os dois.

Três oportunidades de otimização

1. Partida e parada otimizadas. Comece a climatizar cada zona apenas com a antecedência necessária para atingir a faixa de conforto quando a ocupação começar, e desligue antes quando a massa térmica do edifício for capaz de manter a temperatura até as pessoas saírem.
2. Otimização de setpoints. Flexibilize os setpoints dentro da faixa de conforto quando as zonas estiverem desocupadas ou pouco ocupadas e faça pré-resfriamento ou pré-aquecimento em horários de baixa demanda ou de preço mais baixo.
3. Detecção de falhas e desperdícios. Encontre zonas que aquecem e resfriam ao mesmo tempo, válvulas que nunca fecham ou sensores com deriva. Essas costumam ser as economias mais rápidas.

A partida otimizada é o melhor primeiro projeto: é fácil de explicar, a economia é mensurável e o seu modo de falha (uma zona um pouco quente na abertura) é brando.

Aprendendo a resposta térmica de uma zona

Muitos edifícios se comportam razoavelmente como um sistema térmico de primeira ordem em horizontes curtos. A variação da temperatura da zona a cada passo de tempo depende da diferença em relação à temperatura externa (ganho de calor pela envoltória) e do resfriamento ou aquecimento entregue pelo HVAC:

T[k+1] - T[k] = a * (T_out[k] - T[k]) + b * u[k] + c

Aqui u é a saída do HVAC (por exemplo, resfriamento ligado ou desligado, ou a posição da válvula), e c captura os ganhos internos e solares médios. Ajustar a, b e c por zona com regressão linear sobre algumas semanas de dados gera um modelo gray-box: simples o bastante para ser confiável e orientado a dados o bastante para refletir o comportamento real de cada zona. Projetos mais avançados usam gradient boosting ou modelos neurais com variáveis de ocupação e radiação solar, mas o modelo gray-box é um ponto de partida sólido e explicável. Na prática, esse conjunto de modelos por zona é o núcleo térmico de um gêmeo digital do edifício.

Exemplo: partida otimizada a partir de dados MQTT

O script abaixo ajusta o modelo térmico de uma zona e depois procura o horário mais tardio de início do resfriamento que ainda leve a zona à faixa de conforto até o início da ocupação. Ele usa histórico simulado para rodar em qualquer lugar e publica a recomendação no servidor MQTT público (gratuito), que serve apenas para testes e protótipos, nunca para dados reais do edifício. Em uma implantação real, o histórico viria do seu assinante historiador e a previsão do tempo, de um serviço meteorológico.

import json
import random
import time
import uuid

import numpy as np
import paho.mqtt.client as mqtt
from sklearn.linear_model import LinearRegression

STEP_MIN = 5
COMFORT_MAX = 24.0
OCCUPANCY_START = "08:00"

# --- 1. Simulated history (replace with historian data) --------------------
rng = np.random.default_rng(1)
true_a, true_b, true_c = 0.004, -0.06, 0.004
T, rows = 25.0, []
for k in range(14 * 24 * 12):  # two weeks at 5-minute steps
    hour = (k * STEP_MIN / 60) % 24
    t_out = 24 + 7 * np.sin((hour - 9) / 24 * 2 * np.pi)
    u = 1.0 if 7 <= hour < 18 else 0.0
    T_next = T + true_a * (t_out - T) + true_b * u + true_c + rng.normal(0, 0.03)
    rows.append((T, t_out, u, T_next - T))
    T = T_next

data = np.array(rows)
X = np.column_stack([data[:, 1] - data[:, 0], data[:, 2]])
model = LinearRegression().fit(X, data[:, 3])
a, b = model.coef_
c = model.intercept_
print(f"learned a={a:.4f} b={b:.4f} c={c:.4f}")

# --- 2. Optimal start search ----------------------------------------------
def simulate(start_index, T0, t_out_forecast, occ_index):
    T = T0
    for k in range(occ_index):
        u = 1.0 if k >= start_index else 0.0
        T = T + a * (t_out_forecast[k] - T) + b * u + c
    return T

T_now = 25.2                                     # zone temperature at 05:00
steps_until_occ = (8 - 5) * 60 // STEP_MIN       # 05:00 -> 08:00
t_out_fc = [22 + 0.08 * k for k in range(steps_until_occ)]  # warming morning forecast

best = 0
for start in range(steps_until_occ, -1, -1):     # latest start first
    if simulate(start, T_now, t_out_fc, steps_until_occ) <= COMFORT_MAX - 0.3:  # small safety margin
        best = start
        break
start_minutes = 5 * 60 + best * STEP_MIN
start_at = f"{start_minutes // 60:02d}:{start_minutes % 60:02d}"
print("recommended cooling start:", start_at)

# --- 3. Publish the recommendation ----------------------------------------
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/hq/floor3/zone-east"
rec = {
    "ts": int(time.time() * 1000),
    "start_at": start_at,
    "occupancy_start": OCCUPANCY_START,
    "comfort_max": COMFORT_MAX,
    "model": {"a": round(a, 5), "b": round(b, 5), "c": round(c, 5)},
    "reason": "latest start meeting comfort band with forecast outdoor temperature",
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="hvac-opt-" + uuid.uuid4().hex[:8])
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
client.publish(f"{BASE}/recommendation", json.dumps(rec), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print("published to", f"{BASE}/recommendation")

Instale com pip install paho-mqtt numpy scikit-learn. Os coeficientes ajustados ficam próximos dos valores simulados, e a recomendação é visivelmente mais tardia do que seria uma partida fixa e antecipada. Em um edifício real, compare o horário recomendado com a programação fixa por várias semanas antes de deixá-lo atuar; a diferença no tempo de operação das AHUs é a economia esperada.

Aplicando as recomendações com segurança

Enviar setpoints a equipamentos reais exige mais cuidado do que publicar um gráfico. Uma progressão prática:

1. Modo consultivo. Publique apenas recomendações; a equipe de facilities as analisa em um dashboard ao lado dos resultados reais.
2. Automação com limites. Um gateway ou uma integração com o BMS aceita recomendações apenas dentro de limites rígidos, como partida nunca antes das 05:00 e setpoints somente entre 21 e 25 degC, e ignora mensagens com mais de alguns minutos. A expiração de mensagens do MQTT 5 é útil aqui, pois comandos desatualizados são descartados pelo broker.
3. Fallback. Se as recomendações pararem de chegar, o BMS volta automaticamente à programação normal.
4. Intervenção humana. Comandos locais sempre prevalecem, e cada intervenção é registrada como evento para que o modelo aprenda com ela.

Esses limites devem ficar na integração do lado do equipamento, e não apenas no serviço de IA, para que um bug no modelo não consiga levar os equipamentos para fora das faixas seguras. O artigo sobre controle seguro de dispositivos IoT por IA aborda essas salvaguardas em profundidade.

Medindo os resultados

Alegações de economia são fáceis de fazer e difíceis de provar. Compare situações equivalentes: dias úteis com temperatura externa e ocupação semelhantes, antes e depois, ou dias alternados entre a programação antiga e a nova. Acompanhe o conforto com o mesmo cuidado que a energia, usando os minutos fora da faixa de conforto por zona. Publique ambos como topics para que apareçam ao lado dos dados operacionais. Um modelo de previsão de carga de energia ajuda aqui como linha de base: a diferença entre a demanda prevista sob a estratégia antiga e a demanda medida sob a nova é uma estimativa justa do efeito.

A camada de dados no ConnectMQ

O ConnectMQ fornece o broker MQTT gerenciado que transporta pontos do BMS, dados meteorológicos, recomendações e resultados entre o seu gateway e o seu serviço de otimização. O explorador de topics ao vivo mostra as recomendações ao lado das temperaturas das zonas que elas afetam, e regras de alerta por limite podem sinalizar zonas que saem da faixa de conforto. Os modelos em si rodam nos seus próprios clientes, por exemplo um serviço Python ou um fluxo Node-RED. Para o panorama completo de IA com dispositivos conectados, veja o guia de IA e IoT e, para técnicas de previsão que você pode reaproveitar, previsão de séries temporais em IoT.

Comece a usar o ConnectMQ

Crie um broker no plano Serverless (Free) em app.connectmq.com, sem cartão de crédito. Conecte o gateway do seu BMS com YOUR_USERNAME, YOUR_PASSWORD e YOUR_CLIENT_ID gerados, colete algumas semanas de dados das zonas e rode o exemplo de partida otimizada no seu próprio edifício. Quando adicionar mais edifícios, um plano de broker MQTT na nuvem amplia o número de conexões sem alterar os seus topics.

Perguntas frequentes

O que é otimização de HVAC com IA?

A otimização de HVAC com IA usa dados e modelos do edifício para escolher horários de partida, setpoints e programações de HVAC melhores do que as configurações fixas, reduzindo o consumo de energia e mantendo as zonas dentro da faixa de conforto.

A otimização de HVAC com IA substitui o sistema de gestão predial?

Não. Ela geralmente atua como uma camada supervisória que recomenda ou envia setpoints e programações, enquanto os controladores do BMS existente continuam operando os equipamentos e garantindo a segurança local.

Quantos dados são necessários para começar?

Algumas semanas de temperatura das zonas, status do HVAC e temperatura externa em intervalos de 5 a 15 minutos bastam para ajustar um modelo térmico simples para partida otimizada. Efeitos sazonais exigem um histórico mais longo.

Como manter seguras as mudanças automáticas de setpoint?

Imponha limites rígidos e verificações de idade das mensagens na integração do lado do equipamento, volte à programação normal quando as recomendações pararem e deixe que os comandos locais sempre tenham prioridade.