Sistema de automatización de edificios MQTT: BACnet y KNX

Una capa MQTT en un sistema de automatización de edificios te permite sacar los datos encerrados en controladores BACnet, líneas KNX y contadores Modbus y publicarlos en un único lugar donde los paneles, la analítica y las herramientas de alertas puedan usarlos. Esta guía explica dónde encaja MQTT en un sistema de gestión de edificios (BMS), qué debe sustituir y qué no, y cómo diseñar los topics, los gateways y la seguridad para que decenas de edificios puedan compartir un único broker.

Por qué los edificios necesitan otro protocolo más

La mayoría de los edificios comerciales ya funcionan con un protocolo de campo maduro. BACnet domina la climatización y la central de producción, KNX es habitual en Europa para iluminación, persianas y control de estancias, y Modbus RTU o TCP aparece en contadores de energía, enfriadoras y variadores de velocidad. Estos protocolos son buenos en aquello para lo que se diseñaron: control determinista en una red local, con modelos de objetos que los ingenieros de climatización entienden.

En lo que flojean es en salir del edificio. BACnet/IP depende de broadcasts UDP y presupone una LAN plana y de confianza. El enrutamiento KNX/IP usa multicast. Ninguno atraviesa un cortafuegos con soltura, ninguno se diseñó para miles de suscriptores remotos y exponerlos a internet es un error de seguridad bien conocido. Los equipos de mantenimiento que quieren una visión de cartera del consumo energético, las quejas de confort o las averías de los equipos acaban con un front-end por sede, cada uno con su propio inicio de sesión y formato de exportación.

MQTT resuelve justamente ese vacío. Es un protocolo ligero de publicación/suscripción en el que cada dispositivo y aplicación establece una conexión TCP o TLS saliente con un broker MQTT central. Los gateways de cada edificio traducen los puntos locales a topics, y todo lo que necesite los datos se suscribe, sin saber dónde está el gateway ni cuántas sedes existen.

Dónde se sitúa MQTT en un sistema de automatización de edificios

Piensa en un edificio en tres capas:

Nivel de campo: sensores, actuadores, cajas VAV, pulsadores KNX, contadores. La comunicación es BACnet MS/TP, KNX TP, Modbus RTU, DALI o buses propietarios.
Nivel de automatización: controladores y estaciones de supervisión que ejecutan lazos de control, horarios y enclavamientos. Aquí sigue siendo BACnet/IP, KNX/IP o Modbus TCP.
Nivel de integración: el lugar donde los datos se normalizan y se comparten con el resto de la organización. Aquí es donde encaja MQTT.

La regla importante es que los lazos de control permanecen en local. Un lazo PID de temperatura de impulsión debe seguir funcionando si se cae la conexión a internet, así que reside en el controlador, no en la nube. MQTT lleva la telemetría hacia arriba y, con cuidado, los cambios de consigna o las anulaciones de horario hacia abajo. En la práctica, la capa MQTT del sistema de automatización de edificios es una interfaz hacia el norte, no un sustituto de la red de campo.

Comparativa de funciones de los protocolos

Protocolo	Función típica en un edificio	Transporte	Bueno en	Débil en
BACnet/IP	Controladores de climatización, central de producción, supervisión	UDP 47808, broadcasts	Modelo de objetos rico, interoperabilidad entre fabricantes	Atravesar NAT y cortafuegos, muchos clientes remotos
BACnet MS/TP	Controladores de campo, cajas VAV	RS-485	Cableado barato, determinista	Ancho de banda, acceso remoto
KNX	Iluminación, persianas, control de estancias	Par trenzado, multicast o tunneling KNX/IP	Automatización de estancias descentralizada y robusta	Integración fuera del edificio
Modbus RTU/TCP	Contadores, variadores, enfriadoras	RS-485 o TCP 502	Sencillez, omnipresencia	Sin metadatos, solo sondeo
MQTT	Integración, nube, analítica	TCP/TLS hacia un broker	Muchas sedes, muchos consumidores, conexiones solo salientes	Control en tiempo real estricto

Gateways: convertir puntos en topics

Cada edificio necesita al menos un gateway. Lee los puntos del protocolo de campo y los publica como mensajes MQTT. Tienes tres opciones realistas:

MQTT integrado en el controlador o el supervisor. Muchos controladores BMS y sistemas operativos de edificios recientes pueden publicar MQTT directamente. Comprueba si admiten TLS y autenticación con usuario y contraseña antes de confiar en ellos.
Un pequeño gateway Linux. Un dispositivo de la clase Raspberry Pi o un PC industrial que ejecute un script o un flujo de Node-RED. Nuestros tutoriales de BACnet a MQTT y KNX a MQTT muestran puentes completos de código abierto.
Un gateway de protocolos comercial. Útil cuando necesitas un comportamiento BACnet certificado o tienes cientos de puntos por dispositivo.

Elijas lo que elijas, el gateway debe sondear o suscribirse en local (suscripciones COV de BACnet, telegramas de grupo KNX), aplicar bandas muertas para no inundar el broker de ruido y publicar JSON con marca de tiempo, valor, unidad e indicador de calidad.

{
  "ts": "2026-10-16T08:15:02Z",
  "value": 13.4,
  "unit": "degC",
  "quality": "good",
  "source": "bacnet:1201/analogInput:3"
}

Incluir la referencia al objeto original en source facilita mucho el diagnóstico cuando alguien pregunta por qué un valor del panel difiere del front-end del BMS.

Diseño de topics para edificios multisede

El diseño de topics es la decisión con la que convivirás más tiempo. Una jerarquía basada en la ubicación física funciona bien en edificios porque la gente piensa en esos términos:

<org>/<site>/<building>/<floor>/<zone>/<equipment>/<point>
acme/ist01/tower-a/f12/zone-east/ahu-2/supply-air-temp
acme/ist01/tower-a/f12/zone-east/ahu-2/filter-dp
acme/ank02/hq/f03/meeting-301/occupancy/present

Esto refleja el estilo ISA-95 que se usa en las fábricas (empresa, sede, área, línea, célula), lo cual importa porque ConnectMQ reconoce las estructuras de topics ISA-95 y Unified Namespace y puede mostrar los dispositivos agrupados por esos niveles en su vista de dispositivos. Así, los responsables de mantenimiento pueden recorrer una cartera por sede y planta en lugar de buscar en listas planas de topics.

Algunas reglas prácticas:

Usa minúsculas, guiones en lugar de espacios y ningún nombre personal en los topics.
Deja el nombre del punto al final para que los comodines sigan siendo útiles: acme/+/+/+/+/+/supply-air-temp devuelve todas las temperaturas de impulsión de la cartera.
Publica los metadatos que cambian poco (unidades, consignas, modelo del equipo) como mensajes retenidos para que los nuevos suscriptores conozcan de inmediato el estado actual.
Separa las órdenes de la telemetría, por ejemplo .../ahu-2/cmd/setpoint frente a .../ahu-2/supply-air-temp, y deja que solo los clientes autorizados publiquen en los topics de órdenes.

Si ya gestionas plantas industriales, el mismo razonamiento aparece en nuestro artículo sobre Sparkplug B y el Unified Namespace.

Escribir de vuelta en el edificio de forma segura

Leer datos tiene poco riesgo. Escribir consignas desde la nube, no. Antes de que cualquier mensaje MQTT pueda cambiar un valor en un dispositivo BACnet o KNX, pon barreras de protección en el gateway:

Mantén una lista explícita de puntos escribibles. Nunca expongas un topic genérico de "escribir cualquier objeto".
Valida los rangos en el gateway (por ejemplo, una consigna de zona entre 18 y 26 grados Celsius).
En BACnet, escribe con una prioridad definida y libérala cuando termine la anulación, para que los horarios locales vuelvan a tomar el control.
Devuelve el valor aceptado en un topic de estado y registra quién lo solicitó.
Usa QoS 1 para las órdenes y haz que el manejador sea idempotente, porque un mensaje QoS 1 puede llegar dos veces. Nuestra guía de niveles de QoS de MQTT explica por qué.

Centralizar muchos edificios en un broker

Una vez que cada gateway publica hacia fuera, centralizar una cartera se convierte en una decisión de alojamiento. Puedes ejecutar un broker en tu propio centro de datos, pero entonces asumes los parches, los certificados, la monitorización y la planificación de capacidad de un sistema que los equipos de mantenimiento esperan que funcione las 24 horas.

Un broker MQTT gestionado elimina ese trabajo. Con ConnectMQ, cada gateway de edificio se conecta al mismo broker mediante TLS en el puerto 8883 con sus propias credenciales generadas, y el portal te ofrece un explorador de topics en vivo para inspeccionar lo que publica cada sede. Las reglas de alerta por umbral pueden señalar condiciones como una temperatura de impulsión que se mantiene fuera de rango, y el registro de alertas guarda un historial de cuándo se dispararon. Los paneles, los flujos de Node-RED, los recolectores Telegraf o los servicios Python que escriben en tu base de datos se conectan como clientes MQTT normales y se suscriben con comodines.

Lista de comprobación del dimensionamiento

Cuenta los gateways por sede más cada aplicación consumidora; cada uno es una conexión.
Estima los mensajes por segundo después de aplicar bandas muertas, no las tasas de sondeo en bruto.
Comprueba el mensaje más grande que necesitas (una instantánea completa de un equipo puede ser mayor que un único punto).
Decide si necesitas QoS 2 o suscripciones compartidas para consumidores con balanceo de carga.
Planifica el aislamiento: una cartera con una separación estricta entre inquilinos puede justificar un clúster dedicado.

Los pilotos pequeños caben en el plan Serverless gratuito (hasta 25 conexiones, QoS 0 y 1, mensajes de 256 KB). Las carteras más grandes pasan al nivel Serverless de pago (hasta 1.000 conexiones, QoS 2, suscripciones compartidas) o a un clúster Dedicated.

Consideraciones de seguridad específicas de los edificios

Las redes de los edificios suelen ser planas, antiguas y compartidas con contratistas. MQTT ayuda porque los gateways solo necesitan conexiones salientes, de modo que nunca abres puertos entrantes en el cortafuegos para BACnet o KNX. Además:

Usa siempre TLS (puerto 8883, u 8084 para paneles con WebSocket seguro).
Da a cada gateway sus propias credenciales para poder revocar un dispositivo comprometido sin tocar los demás. ConnectMQ vincula los client ID a las credenciales emitidas y bloquea las IP tras varios inicios de sesión fallidos.
Mantén el gateway en una VLAN separada de la red de campo, solo con los puertos que necesita.
Nunca publiques datos personales, como los ID de las tarjetas de acceso, en topics que muchas aplicaciones puedan leer.

La lista más amplia de buenas prácticas de seguridad MQTT se aplica a los edificios tanto como a las fábricas.

Un plan de despliegue realista

Empieza con un edificio y un pequeño conjunto de puntos de alto valor: temperaturas de impulsión y retorno, presión diferencial de filtros, contador de energía principal y algunas temperaturas de zona. Publícalos en el servidor MQTT público gratuito solo si los datos no son sensibles y únicamente quieres validar los payloads; pasa a un broker privado en cuanto intervengan direcciones reales o datos de ocupación. Añade después las alertas, luego los paneles (incluido, si aporta valor, un gemelo digital 3D del edificio) y luego una segunda sede. Al tercer edificio sabrás si tu esquema de topics escala. Para más casos de uso consulta nuestra guía de automatización IoT, y para aplicaciones concretas lee monitorización HVAC con sensores IoT.

Conecta tus edificios a ConnectMQ

Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. En minutos obtienes un usuario, una contraseña y un client ID para tu primer gateway, y el explorador de topics muestra los datos de tu edificio en cuanto llegan. Cuando crezca la cartera, cambia de plan sin modificar tu diseño de topics.

Preguntas frecuentes

¿Sustituye MQTT a BACnet en un sistema de automatización de edificios?

No. BACnet y KNX siguen siendo las redes de control dentro del edificio. MQTT es la capa de integración que lleva los puntos seleccionados a los paneles, a la analítica y a otras sedes.

¿Puedo controlar equipos de climatización por MQTT?

Sí, a través de un gateway que escriba en el controlador, pero limítalo a una lista de puntos permitidos, valida los rangos y mantén los lazos de control en local para que el edificio siga funcionando si se cae la conexión.

¿Qué QoS debe usar la telemetría de un edificio?

QoS 0 está bien para lecturas frecuentes en las que el siguiente valor llega enseguida. Usa QoS 1 para alarmas y órdenes, y haz que los manejadores de órdenes sean idempotentes.

¿Cuántas conexiones necesita un edificio?

Normalmente una por gateway más una por cada aplicación consumidora. Un edificio piloto típico con un solo gateway y un panel necesita solo un puñado de conexiones.

Sistema de automatización de edificios con MQTT: cómo encaja MQTT junto a BACnet y KNX