La monitorización HVAC con sensores IoT te ofrece una visión continua de cómo se comportan realmente las climatizadoras, los fancoils y los equipos de cubierta, no solo de si están encendidos. Este caso de uso muestra qué mediciones detectan los fallos más habituales, cómo publicarlas por MQTT y cómo convertirlas en alertas e informes de horas de funcionamiento con un broker en la nube.
Qué falla en los equipos de climatización
La mayoría de los problemas de climatización no se anuncian con una alarma. Aparecen como derivas lentas: un filtro se colmata y cae el caudal de aire, una válvula se atasca y baja el rendimiento de la batería, un compresor arranca y para continuamente por la mala ubicación de un termostato, o un equipo funciona todo el fin de semana porque se anuló un horario y nadie lo restableció. Los ocupantes solo lo notan cuando el confort se resiente, y para entonces se ha desperdiciado energía durante semanas.
Un sistema de gestión de edificios puede detectar parte de esto, pero muchas sedes no tienen BMS o tienen uno al que solo puede acceder un contratista. Instalar a posteriori unos cuantos sensores IoT y publicar en MQTT cubre el vacío rápidamente y funciona igual en toda una cartera, tanto si el equipo es una unidad compacta de cubierta en una tienda como una climatizadora en una torre de oficinas.
Las señales que importan
No necesitas decenas de puntos por equipo. Las mediciones siguientes cubren la mayor parte de la detección de fallos práctica:
| Señal | Sensor | Qué revela |
|---|---|---|
| Temperatura del aire de impulsión | Sonda de conducto (DS18B20, PT1000 con transmisor) | Si el equipo está realmente calentando o enfriando |
| Temperatura del aire de retorno | Sonda de conducto | La carga del equipo; junto con la impulsión da el delta-T |
| Presión diferencial del filtro | Sensor de presión diferencial de bajo rango, de 0 a 500 Pa | Colmatación del filtro, filtro ausente, rotura de correa |
| Corriente del ventilador o del compresor | Transformador de corriente de núcleo partido | Horas de funcionamiento, ciclos cortos, cambios de carga mecánica |
| Temperatura exterior | Sonda con protección o fuente meteorológica | Contexto para la demanda de calefacción y refrigeración |
| Temperatura de zona | Sensor de pared | Si el espacio es confortable |
El valor derivado más útil es el delta-T, la diferencia entre el aire de retorno y el de impulsión. Cuando un equipo de refrigeración funciona con un delta-T muy pequeño, o la batería no recibe agua fría o refrigerante, o el caudal de aire es demasiado alto, o un sensor está mal colocado. Una presión de filtro que sube de forma constante durante semanas es normal; una que cae de repente hacia cero significa que el filtro se ha roto o no está.
Arquitectura
Hay dos formas habituales de llevar estas señales a MQTT:
- Controladores existentes. Si los equipos ya tienen controladores BACnet, un gateway lee los puntos y los publica, como se muestra en nuestro tutorial de BACnet a MQTT.
- Nodos de sensores añadidos. Un ESP32 o un pequeño módulo IoT industrial por equipo lee las sondas directamente y publica por Wi-Fi o Ethernet. El tutorial de ESP32 con MQTT cubre los fundamentos de la conexión.
En ambos casos, el nodo publica hacia fuera en un broker y cada consumidor se suscribe: el explorador de topics del portal para la puesta en marcha, un script de analítica para los valores derivados y un panel para el personal de mantenimiento. La estructura de topics sigue la jerarquía del edificio:
acme/ist01/tower-a/roof/ahu-2/telemetry
acme/ist01/tower-a/roof/ahu-2/derived
acme/ist01/tower-a/roof/ahu-2/status
Un único mensaje de telemetría por intervalo mantiene el tráfico reducido y facilita la alineación 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"
}
Calcular el delta-T y las horas de funcionamiento desde MQTT
Los valores derivados se calculan mejor en un solo lugar que en cada nodo de sensores. El script siguiente se suscribe a la telemetría de todos los equipos, calcula el delta-T, acumula las horas de funcionamiento del ventilador y del compresor, cuenta los arranques del compresor por hora para detectar ciclos cortos y publica los resultados de vuelta en MQTT. Pruébalo en el servidor MQTT público gratuito con el prefijo de demostración, solo con datos de prueba, y después cambia a credenciales privadas.
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 # una corriente por encima de esto significa que el ventilador funciona
COMP_ON_A = 3.0 # una corriente por encima de esto significa que el compresor funciona
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 los huecos para que los cortes no inflen las horas
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()
Simula un equipo desde la línea de comandos para verlo en acción:
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}'
Aquí los contadores de horas de funcionamiento viven en memoria, así que se reinician cuando el script se reinicia. Para unas horas de funcionamiento aptas para facturación, escribe los valores derivados en una base de datos de series temporales desde el mismo suscriptor, o deja que una herramienta como Telegraf se suscriba a los topics y los almacene.
Alertas por umbral para fallos de climatización
ConnectMQ te permite definir en el portal reglas de alerta por umbral sobre los valores entrantes, y cada alerta disparada se guarda en el registro de alertas. Reglas iniciales prácticas para una climatizadora de refrigeración:
| Regla | Condición | Causa probable |
|---|---|---|
| Delta-T bajo en refrigeración | delta_t_c por debajo de 4 durante 30 minutos |
Sin agua fría, válvula atascada, caudal de aire excesivo |
| Filtro colmatado | filter_dp_pa por encima de la pérdida de carga final del filtro |
Toca sustituir el filtro |
| Filtro ausente o correa rota | filter_dp_pa por debajo de 20 con el ventilador en marcha |
Filtro roto, correa que patina |
| Aire de impulsión demasiado caliente | supply_c por encima de 18 en modo refrigeración |
Fallo del compresor, pérdida de refrigerante |
| Ciclos cortos | comp_starts_last_hour por encima de 6 |
Equipo sobredimensionado, ubicación del termostato, fallo de control |
| Funcionamiento fuera de horario | corriente del ventilador por encima del umbral fuera del horario | Horario anulado |
Ajusta los umbrales por equipo tras una semana de observación. Los equipos, el clima y la clase de filtro varían demasiado para usar cifras universales, y la ficha técnica del fabricante indica los límites correctos de presión del filtro.
Almacenar el histórico y generar informes
Los valores en vivo detectan fallos; el histórico demuestra los ahorros y orienta el mantenimiento. Como cada consumidor es simplemente otro cliente MQTT, añadir almacenamiento no afecta a los nodos de sensores. Las opciones habituales son una instancia de Telegraf con su entrada de consumidor MQTT escribiendo en InfluxDB, un flujo de Node-RED que inserta en PostgreSQL o un pequeño suscriptor en Python que escribe en la base de datos que ya use tu organización. Guarda la telemetría en bruto al intervalo nativo durante unos meses y conserva agregados horarios durante años.
Entre los informes mensuales útiles para los equipos de mantenimiento están las horas de funcionamiento por equipo comparadas con las horas programadas, el número de horas que cada equipo pasó con un delta-T bajo, la fecha en que cada filtro alcanzó su presión de sustitución y los equipos ordenados por arranques del compresor. Estas cifras convierten quejas vagas como "en la tercera planta siempre hace calor" en órdenes de trabajo concretas.
Lista de comprobación del despliegue
- Elige de tres a cinco equipos representativos, no toda la cartera.
- Monta las sondas de impulsión lo bastante aguas abajo de la batería para medir aire mezclado, y las de retorno antes de la caja de mezcla.
- Coloca los transformadores de corriente sobre un único conductor, no sobre todo el cable.
- Pon en marcha cada sensor observando los valores en vivo en el explorador de topics mientras el equipo completa sus ciclos.
- Ejecuta el suscriptor de analítica y observa durante una semana antes de activar las alertas.
- Redacta un breve procedimiento para cada alerta para que los técnicos sepan qué revisar.
- Amplía al resto de los equipos cuando las falsas alarmas estén bajo control.
Escalar
Un nodo añadido por equipo y un servicio de analítica caben con holgura en el plan Serverless gratuito para un piloto. A medida que añades edificios, el número de conexiones crece linealmente con los equipos, y el nivel Serverless de pago admite hasta 1.000 conexiones con suscripciones compartidas, de modo que puedes ejecutar varios procesos de analítica que se repartan la carga. Como el broker es un broker MQTT gestionado y un broker MQTT en la nube, no instalas nada en cada edificio salvo los nodos de sensores.
La calidad del aire y la ocupación añaden un contexto valioso a los datos de climatización: consulta la monitorización de la calidad del aire interior y los sensores de ocupación de oficinas. Para carteras de edificios inteligentes, de torres de oficinas en Bogotá a centros comerciales en Barcelona, los mismos topics derived pueden alimentar un gemelo digital 3D que marque cada equipo con fallo sobre el modelo del edificio. La visión de conjunto se trata en sistema de automatización de edificios con MQTT y en la guía de automatización IoT.
Empieza a monitorizar tu climatización con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Conecta un nodo de sensores, observa los valores en el explorador de topics en vivo y después añade reglas de alerta por umbral para el delta-T y la presión de los filtros. ConnectMQ gestiona el broker para que tu equipo pueda centrarse en las instalaciones.
Preguntas frecuentes
¿Cuál es la medición de climatización más útil?
Las temperaturas del aire de impulsión y de retorno juntas, porque el delta-T muestra si el equipo está transfiriendo calor de verdad. Después, añade la presión diferencial del filtro.
¿Necesito un BMS para la monitorización HVAC con sensores IoT?
No. Los nodos de sensores añadidos pueden publicar directamente en MQTT. Si existe un BMS, un gateway puede reutilizar sus puntos en lugar de instalar sensores nuevos.
¿Con qué frecuencia debe enviarse la telemetría de climatización?
Cada 30 a 60 segundos basta para temperaturas y presiones. Las mediciones de corriente para las horas de funcionamiento y los ciclos cortos se benefician de intervalos de 10 a 15 segundos.
¿Pueden enviarse alertas desde el propio broker?
ConnectMQ evalúa las reglas de alerta por umbral y las registra en el registro de alertas. Para SMS, correo electrónico o tickets, ejecuta un suscriptor como Node-RED que reaccione a los topics correspondientes.
