O monitoramento de HVAC com sensores IoT oferece uma visão contínua de como unidades de tratamento de ar, fan coils e unidades de telhado realmente se comportam, e não apenas se estão ligadas. Este caso de uso mostra quais medições detectam as falhas mais comuns, como publicá-las via MQTT e como transformá-las em alertas e relatórios de tempo de operação com um broker MQTT gerenciado.
O Que Dá Errado em Equipamentos de HVAC
A maioria dos problemas de HVAC não se anuncia com um alarme. Eles aparecem como desvios lentos: um filtro satura e o fluxo de ar cai, uma válvula trava e o desempenho da serpentina diminui, um compressor faz ciclos curtos por causa de um termostato mal posicionado, ou uma unidade funciona o fim de semana inteiro porque uma agenda foi sobreposta e nunca restaurada. Os ocupantes só percebem quando o conforto é afetado, e a essa altura a energia já foi desperdiçada por semanas.
Um sistema de gerenciamento predial pode detectar parte disso, mas muitos locais não têm BMS nenhum, ou têm um que só uma empresa terceirizada consegue acessar. Instalar alguns sensores IoT e publicar via MQTT preenche essa lacuna rapidamente e funciona da mesma forma em todo o portfólio, seja a unidade um equipamento compacto de telhado em uma loja em Campinas, uma unidade de tratamento de ar em uma torre de escritórios em São Paulo ou o sistema de climatização de uma planta em Manaus.
Os Sinais Que Importam
Você não precisa de dezenas de pontos por unidade. As medições abaixo cobrem a maior parte da detecção prática de falhas:
| Sinal | Sensor | O que revela |
|---|---|---|
| Temperatura do ar de insuflamento | Sonda de duto (DS18B20, PT1000 com transmissor) | Se a unidade está de fato aquecendo ou resfriando |
| Temperatura do ar de retorno | Sonda de duto | A carga sobre a unidade; com o insuflamento, dá o delta-T |
| Pressão diferencial do filtro | Sensor de pressão diferencial de baixa faixa, 0 a 500 Pa | Saturação do filtro, filtro ausente, correia rompida |
| Corrente do ventilador ou do compressor | Transformador de corrente de núcleo bipartido | Tempo de operação, ciclos curtos, mudanças de carga mecânica |
| Temperatura do ar externo | Sonda protegida ou dados meteorológicos | Contexto para a demanda de aquecimento e resfriamento |
| Temperatura da zona | Sensor de parede | Se o ambiente está confortável |
O valor derivado mais útil é o delta-T, a diferença entre o ar de retorno e o de insuflamento. Quando uma unidade de resfriamento opera com delta-T muito pequeno, ou a serpentina não está recebendo água gelada ou refrigerante, ou o fluxo de ar está alto demais, ou um sensor está no lugar errado. Uma pressão de filtro que sobe gradualmente ao longo de semanas é normal; uma que cai de repente para perto de zero significa que o filtro colapsou ou não está lá.
Arquitetura
Há duas formas comuns de levar esses sinais ao MQTT:
- Controladores existentes. Se as unidades já têm controladores BACnet, um gateway lê os pontos e os publica, como mostrado em nosso tutorial de BACnet para MQTT.
- Nós de sensores instalados em retrofit. Um ESP32 ou um pequeno módulo IoT industrial por unidade lê as sondas diretamente e publica via Wi-Fi ou Ethernet. O tutorial de MQTT com ESP32 cobre o básico da conexão.
Em ambos os casos o nó publica em uma conexão de saída para um broker, e cada consumidor assina: o explorador de topics do portal para o comissionamento, um script de análise para os valores derivados e um dashboard para a equipe de facilities. A estrutura de topics segue a hierarquia do edifício:
acme/ist01/tower-a/roof/ahu-2/telemetry
acme/ist01/tower-a/roof/ahu-2/derived
acme/ist01/tower-a/roof/ahu-2/status
Uma única mensagem de telemetria por intervalo mantém o tráfego pequeno e facilita o alinhamento temporal:
{
"ts": "2026-10-16T10:30:00Z",
"supply_c": 13.6,
"return_c": 23.1,
"outdoor_c": 27.4,
"filter_dp_pa": 182,
"fan_a": 6.8,
"comp_a": 14.2,
"mode": "cooling"
}
Calculando Delta-T e Tempo de Operação a Partir do MQTT
Os valores derivados devem ser calculados em um único lugar, e não em cada nó de sensor. O script abaixo assina a telemetria de todas as unidades, calcula o delta-T, acumula o tempo de operação do ventilador e do compressor, conta as partidas do compressor por hora para detectar ciclos curtos e publica os resultados de volta no MQTT. Teste-o no servidor MQTT público (gratuito) com o prefixo de demonstração e depois troque para credenciais privadas; o servidor público pode ser lido por qualquer pessoa e serve apenas para testes e protótipos, não para dados de produção.
import json
import time
import uuid
from collections import defaultdict, deque
import paho.mqtt.client as mqtt
BROKER, PORT = "broker.connectmq.com", 1883
PREFIX = "connectmq/demo/hvac-q81z"
FAN_ON_A = 1.0 # corrente acima disto significa ventilador ligado
COMP_ON_A = 3.0 # corrente acima disto significa compressor ligado
MAX_STARTS_PER_HOUR = 6
state = defaultdict(lambda: {"last_ts": None, "fan_s": 0.0, "comp_s": 0.0,
"comp_on": False, "starts": deque()})
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe(f"{PREFIX}/+/telemetry", qos=0)
def on_message(client, userdata, msg):
unit = msg.topic.split("/")[-2]
try:
t = json.loads(msg.payload)
except json.JSONDecodeError:
return
s = state[unit]
now = time.time()
if s["last_ts"] is not None:
dt = min(now - s["last_ts"], 120) # limita lacunas para que quedas não inflem o tempo de operação
if t.get("fan_a", 0) > FAN_ON_A:
s["fan_s"] += dt
if s["comp_on"]:
s["comp_s"] += dt
s["last_ts"] = now
comp_on = t.get("comp_a", 0) > COMP_ON_A
if comp_on and not s["comp_on"]:
s["starts"].append(now)
s["comp_on"] = comp_on
while s["starts"] and now - s["starts"][0] > 3600:
s["starts"].popleft()
delta_t = None
if "return_c" in t and "supply_c" in t:
delta_t = round(t["return_c"] - t["supply_c"], 2)
derived = {
"ts": t.get("ts"),
"delta_t_c": delta_t,
"fan_runtime_h": round(s["fan_s"] / 3600, 2),
"comp_runtime_h": round(s["comp_s"] / 3600, 2),
"comp_starts_last_hour": len(s["starts"]),
"short_cycling": len(s["starts"]) > MAX_STARTS_PER_HOUR,
}
client.publish(f"{PREFIX}/{unit}/derived", json.dumps(derived), qos=1, retain=True)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"hvac-analytics-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()
Simule uma unidade pela linha de comando para vê-lo funcionar:
mosquitto_pub -h broker.connectmq.com -p 1883 -i hvac-sim-q81z \
-t "connectmq/demo/hvac-q81z/ahu-2/telemetry" \
-m '{"ts":"2026-10-16T10:30:00Z","supply_c":13.6,"return_c":23.1,"filter_dp_pa":182,"fan_a":6.8,"comp_a":14.2}'
Os contadores de tempo de operação aqui ficam em memória, então são zerados quando o script reinicia. Para um tempo de operação com precisão de faturamento, grave os valores derivados em um banco de dados de séries temporais a partir do mesmo subscriber, ou deixe uma ferramenta como o Telegraf assinar os topics e armazená-los.
Alertas por Limite para Falhas de HVAC
O ConnectMQ permite definir regras de alerta por limite sobre os valores recebidos no portal, e cada alerta disparado fica registrado no log de alertas. Regras práticas para começar com uma unidade de tratamento de ar em modo de resfriamento:
| Regra | Condição | Causa provável |
|---|---|---|
| Delta-T baixo em resfriamento | delta_t_c abaixo de 4 por 30 minutos |
Sem água gelada, válvula travada, fluxo de ar excessivo |
| Filtro saturado | filter_dp_pa acima da perda de carga final do filtro |
Hora de trocar o filtro |
| Filtro ausente ou correia rompida | filter_dp_pa abaixo de 20 com o ventilador ligado |
Filtro colapsado, correia escorregando |
| Ar de insuflamento quente demais | supply_c acima de 18 em modo de resfriamento |
Falha no compressor, perda de refrigerante |
| Ciclos curtos | comp_starts_last_hour acima de 6 |
Unidade superdimensionada, posição do termostato, falha de controle |
| Operação fora do horário | Corrente do ventilador acima do limite fora da agenda | Agenda sobreposta |
Ajuste os limites por unidade depois de uma semana de observação. Equipamentos, clima e classe de filtro variam demais para números universais, e a folha de dados do fabricante informa os limites corretos de pressão do filtro.
Armazenando o Histórico e Gerando Relatórios
Os valores ao vivo detectam falhas; o histórico comprova economias e orienta a manutenção. Como cada consumidor é apenas mais um cliente MQTT, adicionar armazenamento não mexe nos nós de sensores. As escolhas comuns são uma instância do Telegraf com seu input de consumidor MQTT gravando no InfluxDB, um fluxo Node-RED inserindo no PostgreSQL ou um pequeno subscriber Python gravando no banco de dados que sua organização já usa. Armazene a telemetria bruta no intervalo nativo por alguns meses e mantenha agregados horários por anos.
Relatórios mensais úteis para as equipes de facilities incluem as horas de operação por unidade comparadas com as horas programadas, o número de horas que cada unidade passou com delta-T baixo, a data em que cada filtro atingiu a pressão de troca e as unidades classificadas por partidas do compressor. Esses números transformam reclamações vagas, como "o terceiro andar está sempre quente", em ordens de serviço específicas. Telemetria ao vivo, valores derivados e histórico por unidade também são a matéria-prima de um gêmeo digital do edifício.
Checklist de Implantação
- Escolha de três a cinco unidades representativas, não o portfólio inteiro.
- Instale as sondas de insuflamento longe o suficiente da serpentina para captar ar misturado, e as de retorno antes da caixa de mistura.
- Instale os transformadores de corrente em um único condutor, não no cabo inteiro.
- Comissione cada sensor acompanhando os valores ao vivo no explorador de topics enquanto a unidade cicla.
- Rode o subscriber de análise e observe por uma semana antes de ativar os alertas.
- Escreva um pequeno procedimento para cada alerta, para que os técnicos saibam o que verificar.
- Expanda para as demais unidades quando os alarmes falsos estiverem sob controle.
Escalando
Um nó de retrofit por unidade e um serviço de análise cabem facilmente no plano Serverless gratuito para um piloto. À medida que você adiciona edifícios, o número de conexões cresce linearmente com as unidades, e o nível Serverless pago suporta até 1.000 conexões com shared subscriptions, para que você possa rodar vários workers de análise dividindo a carga. Como o broker é um broker MQTT na nuvem, você não instala nada em cada edifício além dos nós de sensores.
A qualidade do ar e a ocupação acrescentam um contexto valioso aos dados de HVAC: veja monitoramento da qualidade do ar interno e sensores de ocupação de escritório. O panorama mais amplo é tratado em automação predial com MQTT e no guia de automação IoT.
Comece a Monitorar Seu HVAC com o ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito. Conecte um nó de sensor, acompanhe os valores no explorador de topics ao vivo e depois adicione regras de alerta por limite para delta-T e pressão do filtro. Como broker MQTT gerenciado, o ConnectMQ opera o broker para que sua equipe possa se concentrar nos equipamentos.
Perguntas frequentes
Qual é a medição de HVAC mais útil?
As temperaturas do ar de insuflamento e de retorno juntas, porque o delta-T mostra se a unidade está de fato transferindo calor. Em seguida, adicione a pressão diferencial do filtro.
Preciso de um BMS para monitorar HVAC com sensores IoT?
Não. Nós de sensores instalados em retrofit podem publicar diretamente no MQTT. Se houver um BMS, um gateway pode reaproveitar seus pontos em vez de instalar novos sensores.
Com que frequência a telemetria de HVAC deve ser enviada?
A cada 30 a 60 segundos é suficiente para temperaturas e pressões. As medições de corrente para tempo de operação e ciclos curtos se beneficiam de intervalos de 10 a 15 segundos.
Os alertas podem ser enviados pelo próprio broker?
O ConnectMQ avalia as regras de alerta por limite e as registra no log de alertas. Para SMS, e-mail ou abertura de chamados, rode um subscriber como o Node-RED que reaja aos topics relevantes.



