> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/what-is-mqtt.md).
# Qué es MQTT
¿Qué es MQTT? Un protocolo IoT ligero de publicación y suscripción — brokers, topics, QoS — y cómo se asigna al conector de Kilo.
MQTT es un protocolo ligero de mensajería publicación-suscripción diseñado para redes y dispositivos con recursos limitados, especificado originalmente por IBM en 1999 para SCADA sobre enlaces satelitales y ahora estandarizado como ISO/IEC 20922. Tres propiedades hacen que hoy sea el protocolo dominante del IoT industrial: un pequeño sobrecoste de formato en la red adecuado para endpoints celulares y alimentados por batería, productores y consumidores desacoplados mediante un broker central, y garantías de entrega bien definidas (QoS 0/1/2) que permiten a los integradores intercambiar rendimiento por fiabilidad según el topic.
Si está integrando un sistema existente que produce MQTT — un sistema de gestión de edificios, una flota de medidores conectados a la red celular, una flota de PLC puenteados con MQTT — en Kilo IoT Server, la orientación a continuación cubre el modelo que la plataforma asume. Si ya opera MQTT en producción y quiere saltar adelante, [MQTT en la nube](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) y [MQTT externo](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) describa directamente la configuración del conector.
## Roles arquitectónicos
Tres roles participan en cualquier intercambio MQTT:
* **Broker** — la infraestructura de enrutamiento. Los dispositivos y las aplicaciones se conectan al broker; el broker empareja a los publicadores con los suscriptores según patrones de topic y gestiona la entrega conforme al nivel de QoS solicitado. El broker es el único punto de conexión para cada participante de MQTT; no existe una alternativa punto a punto.
* **Publicadores** — producen mensajes para topics. Entre los publicadores industriales en la práctica se incluyen PLC con firmware MQTT, pasarelas de borde que traducen Modbus / BACnet / OPC-UA a MQTT, puentes específicos del proveedor (Zigbee2MQTT, ESPHome) y firmware embebido personalizado en dispositivos de campo.
* **Suscriptores** — consumen mensajes. El conector MQTT de Kilo IoT Server es un suscriptor. Varios suscriptores pueden consumir los mismos topics de forma independiente — su panel de control existente, el historiador local y la plataforma pueden recibir todos los mismos datos sin coordinación.
```
Dispositivos de campo ──┐
PLC ───────────┤
Puentes ────────┼──> Broker ──> Suscriptores (Kilo, historiador, paneles de control, ...)
Pasarelas de borde ──┘
```
Los dispositivos suelen ser tanto publicadores (informando telemetría) como suscriptores (recibiendo puntos de ajuste, configuración, enlaces descendentes). El broker es el intermediario siempre presente.
## Topics: la clave de enrutamiento
Cada mensaje MQTT lleva un **topic** — una cadena UTF-8 separada por barras. El broker usa topics para emparejar publicadores y suscriptores; los suscriptores registran interés en patrones usando `+` (comodín de un solo nivel) y `#` (comodín multinivel al final). Los topics no están predefinidos; la parte que publica elige el topic, y un catálogo de topics se establece por convención o acuerdo del proveedor.
Convenciones comunes en implementaciones industriales:
* **Estructura jerárquica de topic por sitio/activo/métrica** — por ejemplo, `plant-3/line-a/extruder-04/temperature` o `building-12/floor-2/ahu-1/setpoint`. Esto hace naturales las suscripciones con comodines para la agregación de todo el sitio.
* **Esquemas con prefijo del proveedor** para puentes de protocolo — p. ej., `zigbee2mqtt/{friendlyName}`, `tasmota/{deviceName}/SENSOR`, `mosquitto/+/state`. El Kilo IoT Server admite cualquier forma de topic mediante el **Tema de ID de dispositivo** campo de patrón — vea [Temas y enrutamiento de dispositivos](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md).
* **espacios de nombres de Sparkplug B** para jerarquías al estilo OPC-UA — p. ej., `spBv1.0/{group}/DDATA/{node}/{device}`. La plataforma consume estos como topics MQTT ordinarios; la decodificación específica de Sparkplug la gestiona la pasarela de borde que publica.
La configuración del conector de la plataforma trata los topics como patrones: en cada dispositivo se construye el topic a partir de segmentos y se marca el que lleva el identificador del dispositivo, y la plataforma extrae el identificador de esa posición cuando llega cada mensaje.
## Cargas útiles: JSON estructurado en la práctica
El propio protocolo MQTT es agnóstico respecto a la carga útil — entran bytes, salen bytes. En las implementaciones de producción, JSON es con mucho el formato preferido para los sistemas nuevos, con Sparkplug B ocasional (Protocol Buffers) y formatos binarios propietarios para puentes heredados. El conector MQTT de Kilo IoT Server analiza automáticamente cargas útiles JSON — objetos planos, objetos anidados (aplanados a rutas con notación de puntos) y valores primitivos son todos compatibles.
Una carga útil típica de telemetría industrial:
```json
{
"timestamp": "2026-01-15T14:32:18Z",
"temperature": 78.4,
"pressure": 4.21,
"vibration": {"rms": 0.42, "peak": 1.8},
"status": "running"
}
```
Cuando se asignan a métricas de la plataforma, `temperatura`, `pressure`, `vibration.rms`, `vibration.peak`, y `estado` cada uno se convierte en una Clave del Conector direccionable. La pestaña Mapping vincula cada Clave del Conector con una métrica normalizada, que es lo que luego fluye al Gemelo Digital, al motor de reglas y al almacenamiento histórico.
Para esquemas de una métrica por topic (puentes heredados, patrones de aliasing OPC-UA), las **topics de telemetría** filas de la subpestaña Topic permiten mapear explícitamente cada topic a una Clave del Conector con nombre.
## QoS, mensajes retenidos, last-will
Tres características del protocolo aparecen con suficiente frecuencia en implementaciones industriales como para merecer ser mencionadas explícitamente:
* **Niveles de QoS** — 0 (como mucho una vez), 1 (al menos una vez), 2 (exactamente una vez). El conector de la plataforma gestiona el QoS que use el publicador; elija el nivel que coincida con su tolerancia operativa a duplicados frente a pérdidas. QoS 2 tiene el mayor sobrecoste de broker y normalmente se reserva para comandos de control o cambios de estado críticos.
* **Mensajes retenidos** — mensajes marcados que el broker almacena y vuelve a enviar a los nuevos suscriptores al conectarse. Útiles para anunciar el estado actual (p. ej., anuncios de "en línea/fuera de línea"). Si el broker entrega mensajes retenidos a la plataforma como publicaciones suscritas estándar, pueden mapearse como cualquier otra carga útil — verifíquelo según el comportamiento de su broker.
* **Última voluntad y testamento (LWT)** — un mensaje que el broker publica en nombre del publicador si se desconecta inesperadamente. Patrón común: la LWT de un dispositivo publica `"offline"` en su topic de estado, de modo que los suscriptores vean los cambios de estado de desconexión sin hacer consultas periódicas. Si su broker entrega los mensajes LWT al conector como publicaciones MQTT estándar, pueden mapearse como cualquier otra carga útil.
Estas características las configura la parte que publica, no el conector. El conector acepta lo que entregue el broker.
## Por qué MQTT para el IoT industrial
La adopción del protocolo en implementaciones comerciales está impulsada por tres propiedades que se alinean claramente con los requisitos operativos:
* **Eficiencia de ancho de banda.** El sobrecoste del formato en la red es lo bastante pequeño para dispositivos de campo conectados por red celular y despliegues inalámbricos de alta densidad. Los keep-alives y pings son configurables para ajustarse a las ventanas de conectividad disponibles.
* **Productores y consumidores desacoplados.** Añadir un nuevo suscriptor (un historiador, una plataforma analítica de terceros, Kilo IoT Server) no requiere reconfigurar a los publicadores. Los equipos de operaciones pueden desplegar nuevos consumidores sin tocar el campo.
* **Ecosistema maduro.** Existen Mosquitto, HiveMQ, AWS IoT Core, Azure IoT Hub y muchos otros brokers. La mayoría de los puentes de protocolo industriales modernos (Modbus-to-MQTT, BACnet-to-MQTT, pasarelas de borde Sparkplug B) incluyen publicación MQTT de primera clase.
Para la configuración específica del despliegue, continúe con [MQTT en la nube](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) para brokers gestionados por la plataforma, o [MQTT externo](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) para conectar un broker existente.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.kiloiot.io/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/what-is-mqtt.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
