> 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/external-mqtt.md).
# External MQTT
Conecta Kilo IoT Server a tu propio broker MQTT — Mosquitto, AWS IoT Core, HiveMQ — con autenticación TLS y enrutamiento de topics.
External MQTT conecta Kilo IoT Server a un broker MQTT que ya opera usted. La plataforma se conecta al broker, se suscribe a los temas relevantes y consume los mensajes dentro del mismo canal de enrutamiento que los datos de Cloud MQTT. Elija esta opción cuando el broker ya forme parte de su infraestructura — un clúster Mosquitto local, AWS IoT Core, una implementación empresarial de HiveMQ o un broker gestionado por un proveedor compartido entre sitios.
## Cuándo MQTT externo es la opción adecuada
* **Ya existe un broker que forma parte de las operaciones.** Los dispositivos ya publican en él; varios suscriptores (historiadores, paneles, plataformas de integración) ya consumen de él. Añadir la plataforma como un suscriptor más es operacionalmente más sencillo que reencaminar a los publicadores.
* **Requisitos de cumplimiento o residencia de datos** especifican que la telemetría debe pasar por su propio broker antes de llegar a consumidores SaaS.
* **Arquitecturas híbridas** en las que el procesamiento perimetral local ocurre antes de que un subconjunto de la telemetría se reenvíe a la plataforma.
Para despliegues sin un broker existente, [Cloud MQTT](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) es la vía con menor sobrecarga.
## Requisito de accesibilidad
Kilo IoT Server se conecta a su broker, por lo que el broker debe ser accesible desde Internet pública mediante DDNS, reenvío de puertos o una IP pública dedicada. Un broker accesible solo en una VLAN privada no es alcanzable desde el plano de control en la nube de la plataforma.
El patrón estándar de producción es una IP pública o un nombre de host DDNS para el broker, con reglas de firewall que controlan qué orígenes pueden conectarse.
Para implementaciones de desarrollo o piloto, un túnel de exposición como ngrok funciona para pruebas de corta duración — pero tenga en cuenta que ejecutar una herramienta de exposición no confirma por sí mismo que Kilo pueda الوصول al broker. Después de guardar el conector, **publique un mensaje de prueba y confirme que Último dato recibido se actualiza** en la página de detalles del conector. Esta es la única manera de verificar la accesibilidad de extremo a extremo.
## Opciones de autenticación
El conector admite cuatro métodos de autenticación, seleccionables al crearla:
| Método | Cuándo usarlo | Campos de configuración |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Anónimo** | Solo para brokers de desarrollo. **No lo use para brokers expuestos en producción** — cualquiera en Internet que encuentre el broker puede publicar o suscribirse. | Ninguno |
| **Básica** | Autenticación mediante nombre de usuario y contraseña. La configuración más común para despliegues de producción en los que TLS protege las credenciales en tránsito. | Nombre de usuario, contraseña |
| **Certificado** | Autenticación TLS mutua mediante certificados de cliente. Máxima garantía; estándar para despliegues regulados. | Archivo del certificado de CA, archivo del certificado del cliente, archivo de la clave privada (cargados como archivos; no pegue contenido PEM) |
| **Token JWT** | Autenticación basada en token compatible con brokers que validan JWT (por ejemplo, AWS IoT Core con autorizadores personalizados, u otros brokers con complementos JWT). | Token |
Para Certificado, los tres archivos cargados forman el lado cliente de un intercambio mTLS; el broker debe configurarse para confiar en la CA y validar el certificado del cliente contra ella. La clave privada debe estar sin cifrar en el momento de la carga.
## Aprovisionamiento del conector
1. Vaya a **Conectores** en la barra lateral.
2. Haz clic en **Añadir conector**.
3. Selecciona **MQTT externo** desde el **tipo de conector** menú desplegable.
4. Complete:
| Campo | Obligatorio | Detalles |
| ------------------ | ----------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Nombre** | Sí | Etiqueta operativa, por ejemplo `Mosquitto de la planta 3` o `Clúster de broker de Norteamérica`. |
| **URL del broker** | Sí | URL completa con esquema y puerto. Ejemplos: `mqtts://broker.facility.example.com:8883`, `ssl://broker.example.com:8883`. |
5. Elija el método de autenticación y complete sus campos.
6. Haz clic en **Añade**.
El conector aparece en la tabla de conectores. Haga clic en la página de detalles para encontrar el **Último dato recibido** indicador.
## Paso de verificación
La accesibilidad de extremo a extremo solo se confirma cuando una publicación real llega a la plataforma. Después de guardar el conector:
1. Publique un mensaje de prueba en su broker sobre cualquier tema al que el conector se suscriba.
2. Abra la página de detalles del conector en Kilo.
3. Confirme **Último dato recibido** que se actualiza en unos pocos segundos.
Una prueba sencilla de una sola ejecución desde un host que pueda الوصول al broker:
```bash
mosquitto_pub \
-h broker.facility.example.com -p 8883 \
--cafile /path/to/ca.crt \
-u {username} -P {password} \
-t "test/connectivity" \
-m '{"hello":"world"}'
```
(Sustituya el esquema/puerto y las credenciales por el método de autenticación de su broker.)
Si **Último dato recibido** no se actualiza después de una publicación local exitosa, consulte [Solución de problemas](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md). Las causas más comunes son reglas de firewall entre la salida de la plataforma y su broker, discrepancias en la lista de IP permitidas, sesiones de túnel caducadas cuando se usa ngrok para pruebas o una configuración TLS incorrecta en el lado del broker.
## Implementación de referencia de Mosquitto autogestionado
Para despliegues que necesiten una referencia rápida para configurar un broker Mosquitto autogestionado con fines de prueba o piloto, el Docker Compose mínimo se ve así:
```yaml
services:
mosquitto:
image: eclipse-mosquitto:2
container_name: mosquitto
restart: unless-stopped
ports:
- "1883:1883"
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/data:/mosquitto/data
```
`mosquitto.conf`:
```
listener 1883
allow_anonymous false
password_file /mosquitto/config/passwd
persistence true
persistence_location /mosquitto/data/
log_dest stdout
```
Dos notas operativas:
* **`log_dest stdout`** stdout se prefiere frente al registro basado en archivos en implementaciones contenerizadas. Los directorios de registros montados con bind a menudo fallan bajo SELinux/AppArmor o debido a discrepancias de propiedad; stdout del contenedor es recopilado por el controlador de registros de Docker.
* **El puerto 1883 entra en conflicto.** En infraestructura de desarrollo o compartida, el puerto 1883 ya puede estar en uso (por ejemplo, un kubectl port-forward, otro broker local). `ss -tlnp \| grep 1883` identifica el proceso que lo está usando. Reasigne el puerto del lado del host (por ejemplo, `"1885:1883"`) y reenvíe en su lugar el nuevo puerto del host — el puerto interno del contenedor puede permanecer en 1883 para publicadores dentro de la red.
Para la terminación TLS, antes de la exposición pública se requiere un proxy inverso separado o la configuración TLS nativa de Mosquitto (fuera del alcance aquí — consulte la documentación de Mosquitto).
## Límites
Los conectores MQTT externos están limitados a 10 por organización. Para despliegues que necesiten integraciones de broker adicionales más allá de este límite, contacte al equipo de ingeniería de la plataforma durante la planificación del despliegue.
---
# 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/external-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.
