> 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/gateways/mqtt-edge-gateways.md). # Pasarelas perimetrales MQTT Pasarelas perimetrales MQTT para Kilo IoT — puentes de Modbus, BACnet, OPC-UA, Sparkplug B y Zigbee2MQTT hacia MQTT. En implementaciones comerciales, el conector MQTT suele ser la interfaz de integración para **pasarelas perimetrales** — pequeños ordenadores o dispositivos industriales que traducen protocolos que no son MQTT en publicaciones MQTT. Los PLC Modbus, los sistemas de gestión de edificios BACnet, los sistemas de control expuestos por OPC-UA, la automatización equipada con Sparkplug B y las mallas Zigbee no hablan MQTT de forma nativa, pero un software de pasarela bien compatible puede conectar cada uno de ellos con el conector de la plataforma mediante un modelo uniforme de tema y carga útil. Esta página cubre los patrones arquitectónicos para pasarelas perimetrales MQTT y las decisiones de diseño que afectan a la limpieza con que se integran. No es una guía de configuración paso a paso para un producto de pasarela concreto — la documentación del proveedor se encarga de la instalación; esta página es la referencia de integración. ## Qué hace una pasarela perimetral MQTT La pasarela perimetral se sitúa entre el equipo de campo que no usa MQTT y el broker MQTT. Sus responsabilidades: 1. **Leer del protocolo de origen** — ciclos de sondeo Modbus RTU/TCP, suscripciones COV de BACnet, suscripciones OPC-UA, sesiones de nodos Sparkplug B, participación en mallas Zigbee. 2. **Normalizar valores** — aplicar factores de escala, convertir unidades a un conjunto coherente, decodificar campos de bits y enumeraciones en valores legibles para humanos. 3. **Publicar en MQTT** — emitir cargas útiles JSON a una estructura de temas consumible por los suscriptores posteriores. (Los Protocol Buffers de Sparkplug B deben traducirse a JSON antes de publicarlos en los temas que consume el conector MQTT de la plataforma — consulte «Categorías comunes de pasarela» más abajo.) 4. **Aceptar comandos opcionalmente** — suscribirse a temas de control (`/set`, `/cmd`", específicos del proveedor) y escribir de vuelta en el protocolo de origen. (El conector de la plataforma consume telemetría; los flujos de control se manejan en la pasarela.) La pasarela suele ser un pequeño dispositivo Linux cerca del equipo de campo — un PC industrial, un ordenador para carril DIN, un Raspberry Pi o un dispositivo del proveedor. En operación, funciona como un servicio del sistema con semántica de reinicio ante fallos. ## Categorías comunes de pasarela | Categoría | Software/dispositivos típicos | Estructura del tema | Formato de carga útil | | -------------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Modbus → MQTT** | Modbus2MQTT, pasarelas proporcionadas por proveedores (Advantech, Moxa), flujos personalizados de Node-RED | `{site}/{plc}/{deviceId}/data` o temas por registro | Objeto JSON o un valor por tema | | **BACnet → MQTT** | Puentes BMS del proveedor, EasyIO, plataformas de integración personalizadas | `building/{floor}/{ahu-id}/{point}` | JSON con mapeo de punto a valor | | **OPC-UA → MQTT** | OPC Router, FactoryStudio, nodos perimetrales Sparkplug B | Sparkplug `spBv1.0/{group}/DDATA/{node}/{device}` o personalizado | **Debe ser JSON para que el conector de la plataforma lo ingiera.** Los Protocol Buffers de Sparkplug B deben ser traducidos a JSON por la pasarela perimetral antes de publicarlos. | | **Sparkplug B nativo** | Ignition Edge de Inductive Automation, pasarelas perimetrales de Cirrus Link | `spBv1.0/{group}/DDATA/{node}/{device}` | **Debe traducirse a JSON por la pasarela perimetral antes de que el conector MQTT lo ingiera.** El conector MQTT de la plataforma no decodifica los Protocol Buffers de Sparkplug B. | | **Zigbee → MQTT** | Zigbee2MQTT (código abierto, común en pilotos y pequeñas implementaciones comerciales) | `zigbee2mqtt/{friendlyName}` | JSON plano | | **Puentes personalizados** | Puentes hechos a medida en Python/Node.js sobre las API del proveedor | Lo que haya elegido el autor del puente | Normalmente JSON | La plataforma consume cualquiera de estos — el conector es agnóstico al protocolo. Lo importante en el momento de la integración es que la estructura del tema de la pasarela coincida en el campo Device ID Topic y que la estructura de la carga útil de la pasarela coincida en la pestaña Mapping. Consulte [Temas y enrutamiento de dispositivos](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md) para los detalles de enrutamiento. ## Consideraciones de diseño para nuevas integraciones de pasarelas perimetrales Al elegir o configurar una pasarela perimetral para una nueva integración comercial, cuatro decisiones de diseño afectan la calidad de la ingestión: ### Estructura del tema Una estructura de temas jerárquica y predecible simplifica el registro de dispositivos y hace que los patrones de temas sean reutilizables entre dispositivos similares. Recomendado: ``` {site}/{system}/{deviceId}/{metric-or-data} ``` Por ejemplo, `plant-3/line-a/extruder-04/data` para un objeto de estado JSON plano, o `plant-3/line-a/extruder-04/temperature` para un valor por tema. Las estructuras compatibles con patrones permiten que un solo patrón de Device ID Topic cubra muchos dispositivos de la misma familia — `plant-3/line-a/{{deviceId}}/data` funciona para todos los dispositivos de la Línea A. Evite: * Espacios en blanco en cualquier segmento, especialmente en el segmento del identificador del dispositivo. El campo de entrada Device ID elimina los espacios en blanco. * Mezclar convenciones de identificadores dentro de una sola integración. Si algunos dispositivos usan guiones y otros guiones bajos, documente la elección y aplíquela de forma coherente. * Incrustar metadatos de forma libre en el tema (nombres de operarios, fechas, números de orden de trabajo). Los temas son claves de enrutamiento, no anotaciones — coloque los metadatos en la carga útil. ### Formato de carga útil El JSON plano o poco anidado simplifica la pestaña Mapping. La plataforma aplana automáticamente los objetos anidados a rutas con notación de puntos, así que `{"vibration": {"rms": 0.42, "peak": 1.8}}` se convierte en `vibration.rms` y `vibration.peak` como posibles candidatos a Connector Key. Las jerarquías muy anidadas siguen funcionando, pero resultan menos ergonómicas para los operadores que revisan los mapeos. **Sparkplug B requiere traducción a JSON en el borde.** El conector MQTT de la plataforma consume cargas útiles JSON — no decodifica de forma nativa los Protocol Buffers de Sparkplug B. Las pasarelas perimetrales que usan Sparkplug B (Ignition Edge de Inductive Automation, módulos MQTT de Cirrus Link, OPC Router con salida Sparkplug) deben configurarse para traducir Protocol Buffers a JSON antes de publicar en los temas a los que se suscribe el conector. La mayoría de las pasarelas perimetrales comerciales compatibles con Sparkplug incluyen esta traducción como una opción de configuración estándar. ### Cadencia de publicación La cadencia de publicación es una decisión específica de la implementación impulsada por los objetivos de tiempo de respuesta del motor de reglas, la capacidad del broker y la capacidad del firmware del dispositivo. La configuración COV / dead-band de la pasarela perimetral es la palanca para reducir publicaciones redundantes una vez elegida una cadencia base para una clase de dispositivo determinada. Verifique la cadencia que la pasarela perimetral puede sostener frente a las reglas y paneles que consumen los datos, y ajústela a medida que la implementación madure. ### Fiabilidad y comportamiento ante desconexiones Para la telemetría relevante para la misión, configure la pasarela con: * **MQTT QoS 1** para temas de telemetría — entrega al menos una vez; la pasarela reintenta al reconectarse al broker. * **Última voluntad y testamento de MQTT (LWT)** — el anuncio de la pasarela de «me desconecté inesperadamente», normalmente publicado como mensaje retenido en un tema de estado. Si su broker entrega el mensaje LWT al conector como una publicación suscrita estándar, un `estado` campo puede asignarse para reflejar la conectividad de la pasarela — valide la ruta con una prueba deliberada de desconexión antes de confiar en ella operativamente. * **Mensajes «online» retenidos** — publicados al conectarse, reemplazados por el LWT al desconectarse. Los suscriptores (incluidos los nuevos que se conecten más tarde) ven el estado de conectividad actual de inmediato. * **Almacenamiento local persistente** — la pasarela almacena temporalmente la telemetría mientras está desconectada del broker y la reproduce al reconectarse. La mayoría de las pasarelas perimetrales comerciales admiten esto; verifique el tamaño del búfer frente a las ventanas de desconexión previstas. ## En esta sección * [**Hubs Zigbee2MQTT**](/kilo-docs-es/kilo-iot-server/gateways/mqtt-edge-gateways/zigbee2mqtt-hubs.md) — Zigbee2MQTT como un patrón de pasarela perimetral MQTT: topología de hub, adecuación al despliegue, orientación para validar la capacidad y cómo el flujo MQTT resultante alimenta el flujo estándar de enrutamiento de dispositivos. ## A dónde ir a continuación * [Temas y enrutamiento de dispositivos](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md) — registrar dispositivos detrás de cualquiera de estas pasarelas. * [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) — elegir la parte del broker. * [Solución de problemas](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) — diagnosticar problemas de ingestión. --- # 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/gateways/mqtt-edge-gateways.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.