MQTT en sistemas de seguridad: cuando los eventos empiezan a hablar el mismo idioma

Durante años, muchas integraciones en seguridad electrónica han girado alrededor de APIs REST, SDKs propietarios, conexiones TCP específicas, ficheros, bases de datos intermedias o consultas periódicas para comprobar si había algo nuevo.

Todas esas opciones pueden tener sentido según el caso, pero también tienen una limitación bastante clara: muchas veces obligan a que un sistema pregunte constantemente a otro si ha ocurrido algo.

Y en seguridad, lo habitual no es querer preguntar. Lo habitual es querer enterarse cuando ocurre algo.

Ahí es donde MQTT está empezando a ganar terreno.

No es una tecnología nueva ni exclusiva del sector de la seguridad. Viene del mundo IoT y se utiliza desde hace años para comunicar dispositivos, sensores y plataformas con poco consumo de red. Pero cada vez aparece más en cámaras, sistemas de vídeo analítico, plataformas de IA, centrales de intrusión, sistemas de incendios y soluciones que necesitan enviar eventos de forma rápida y sencilla.

Qué es MQTT, explicado sin demasiada teoría

MQTT es un protocolo de mensajería ligero basado en un modelo de publicación y suscripción.

Dicho de forma sencilla: en lugar de que un sistema llame directamente a otro, todos se comunican a través de un punto intermedio llamado broker.

Un sistema publica un mensaje en un tema concreto, por ejemplo:

seguridad/camara/entrada/persona-detectada

Y cualquier otro sistema interesado en ese tipo de mensajes puede suscribirse a ese tema para recibirlos.

Los elementos básicos son estos:

• Cliente MQTT: cualquier aplicación, dispositivo o servicio que se conecta al broker.
• Broker: el intermediario que recibe mensajes y los entrega a quienes estén suscritos.
• Topic: la ruta o canal donde se publica un mensaje.
• Payload: el contenido del mensaje. Muchas veces será JSON, aunque MQTT no obliga a un formato concreto.
• QoS: el nivel de garantía de entrega. Permite ajustar si un mensaje se envía una vez, al menos una vez o exactamente una vez, según la necesidad.

La idea es simple, pero muy potente: desacoplar a quien genera el evento de quien lo consume.

Una cámara no tiene por qué conocer todos los sistemas que van a usar su información. Una central no tiene que llamar a diez APIs distintas cada vez que cambia un estado. Publica un evento, y el broker se encarga de distribuirlo.

Por qué encaja tan bien en seguridad electrónica

En seguridad trabajamos cada vez más con eventos.

Una analítica de vídeo detecta una persona en una zona concreta. Un sistema de reconocimiento facial genera una coincidencia. Una central de intrusión cambia de estado. Un panel de incendios informa de una alarma, avería o prealarma. Un control de accesos registra una apertura, una denegación o un evento técnico.

Todo eso son señales que, bien integradas, tienen mucho valor.

El reto no está solo en recibirlas. Está en recibirlas de forma ordenada, fiable y fácil de mantener.

MQTT encaja especialmente bien cuando hay varios sistemas generando información y otros tantos consumiéndola: plataformas de gestión, software de seguridad, servicios en la nube, cuadros de mando, motores de reglas o integraciones con terceros.

En lugar de construir una integración punto a punto para cada combinación posible, se puede trabajar con un modelo más flexible:

• los dispositivos o sistemas publican eventos;
• el broker los organiza por topics;
• las aplicaciones interesadas se suscriben a lo que necesitan;
• cada consumidor procesa solo la información que le corresponde.

Esto no elimina el trabajo de integración, claro. Hay que definir bien los topics, validar payloads, gestionar seguridad, controlar reconexiones y pensar qué pasa si un sistema está temporalmente desconectado. Pero la base de comunicación es limpia y escalable.

Metadata de vídeo IA: enviar datos, no vídeo

Uno de los usos más interesantes está en la analítica de vídeo con IA.

No siempre hace falta mover vídeo. De hecho, muchas veces lo importante no es transmitir la imagen completa, sino el resultado del análisis:

• se ha detectado una persona;
• hay un vehículo en una zona;
• se ha superado un umbral de ocupación;
• se ha generado una alarma de lista;
• se ha identificado un objeto o comportamiento;
• el evento pertenece a una cámara, zona, hora y tipo concreto.

Eso es metadata: información que describe lo que ha ocurrido.

Enviar esa metadata por MQTT permite que otros sistemas reaccionen sin tener que procesar el vídeo completo. Es más ligero, reduce dependencias y facilita integraciones donde cada pieza hace su trabajo: la cámara o la plataforma de analítica detecta, y el sistema de gestión decide qué hacer con el evento.

Este enfoque se está viendo en fabricantes y soluciones de vídeo que ya contemplan MQTT como canal para publicar eventos analíticos. También hay integraciones públicas donde Herta aparece publicando información de alarmas mediante MQTT, y fabricantes como Axis documentan el envío de metadata de escena a través de MQTT.

No lo veo como una moda, sino como una evolución bastante lógica: si los dispositivos son cada vez más inteligentes, tiene sentido que publiquen eventos de forma estructurada y consumible por otros sistemas.

Ventajas frente a enfoques más tradicionales

MQTT no sustituye a todo. No es “mejor” que REST, ONVIF, SDKs o integraciones TCP en cualquier situación. Cada herramienta tiene su sitio.

Pero sí aporta ventajas claras en escenarios orientados a eventos.

La primera es que evita el polling constante. Si un sistema tiene que preguntar cada pocos segundos si ha ocurrido algo, estamos consumiendo recursos aunque no haya novedades. Con MQTT, el evento llega cuando se publica.

La segunda es el desacoplamiento. El productor del evento no necesita saber quién lo va a consumir. Esto simplifica mucho cuando hay varios receptores o cuando se añaden nuevos sistemas con el tiempo.

La tercera es la ligereza. MQTT está pensado para mensajes pequeños y redes donde conviene no desperdiciar ancho de banda.

La cuarta es la escalabilidad funcional. Un mismo evento puede alimentar una plataforma de alarmas, un dashboard, un motor de automatización o una integración externa sin que el dispositivo origen tenga que multiplicar conexiones.

Y la quinta, muy importante en integración, es la claridad operativa. Si los topics están bien diseñados y los mensajes tienen una estructura consistente, resulta mucho más fácil probar, diagnosticar y evolucionar la integración.

Cosas que conviene hacer bien

Como siempre, la tecnología no hace magia por sí sola.

MQTT puede simplificar mucho, pero solo si se usa con criterio. Algunos puntos son especialmente importantes:

• definir una estructura de topics clara y estable;
• usar payloads comprensibles y versionables;
• asegurar la conexión con autenticación, permisos y cifrado cuando corresponda;
• controlar qué sistemas pueden publicar y a qué topics;
• decidir bien el nivel de QoS;
• monitorizar el broker;
• tratar duplicados o reintentos en el consumidor;
• documentar los eventos disponibles.

En seguridad electrónica, además, hay que ser especialmente cuidadoso con la exposición de información. Un evento puede parecer pequeño, pero puede contener datos sensibles: ubicación, horarios, identificadores, estados de alarma o información personal si hablamos de analítica avanzada.

MQTT facilita el transporte del mensaje, pero la responsabilidad sobre qué se envía, cómo se protege y quién puede leerlo sigue siendo nuestra.

Dónde lo veo aplicable

En mi caso, lo veo especialmente interesante para integraciones donde distintos fabricantes empiezan a publicar eventos o metadata de forma más abierta.

Por ejemplo, analíticas de vídeo IA que envían detecciones, sistemas de reconocimiento facial que generan alarmas, centrales que publican cambios de estado o plataformas que necesitan distribuir eventos a otros módulos.

En Dorlet estamos comenzando a desarrollar integraciones con fabricantes que apuestan por MQTT para el envío de metadata, como Herta. Lo comento desde una perspectiva personal y sin entrar en detalles internos, pero me parece un buen ejemplo de hacia dónde se está moviendo una parte del sector: menos integraciones cerradas y más intercambio de eventos estructurados.

Para quienes trabajamos conectando software, dispositivos y sistemas de seguridad, esto abre una vía bastante interesante. No porque MQTT resuelva todos los problemas, sino porque plantea una forma más natural de integrar sistemas que producen eventos continuamente.

Conclusión

MQTT no es una palabra mágica ni una solución universal. Pero encaja muy bien en un escenario cada vez más habitual: muchos dispositivos y plataformas generando eventos que otros sistemas necesitan consumir de forma rápida, ligera y flexible.

En vídeo analítico, intrusión, incendios, control de accesos o plataformas de gestión, el valor está cada vez más en conectar bien la información.

Y cuando hablamos de eventos, metadata y sistemas que deben reaccionar sin estar preguntando todo el tiempo, MQTT tiene mucho sentido.

Quizá lo más interesante no sea el protocolo en sí, sino el cambio de mentalidad que trae consigo: pasar de integraciones rígidas punto a punto a arquitecturas donde los eventos circulan de forma más ordenada, desacoplada y preparada para crecer.

Ahí es donde creo que MQTT puede aportar mucho al sector de la seguridad.