> 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/cloud-mqtt.md).
# Cloud MQTT
Aprovisiona un broker Cloud MQTT gestionado en Kilo IoT — endpoint y credenciales dedicados por conector, ideal para pilotos.
Cloud MQTT es la opción de broker gestionado por la plataforma para un conector MQTT. El servidor IoT de Kilo aprovisiona un endpoint de broker dedicado por conector, genera credenciales y asigna un prefijo de tema único que delimita el espacio de nombres del conector dentro del broker gestionado. Los dispositivos y las pasarelas de borde publican en ese endpoint; la plataforma consume los mensajes directamente.
Para implementaciones que no tienen la necesidad operativa de ejecutar su propio broker MQTT — pruebas piloto, sitios remotos, instalaciones recientemente adquiridas, firmware MQTT proporcionado por el proveedor que solo necesita un destino público — Cloud MQTT elimina del alcance de la integración el aprovisionamiento del broker, la gestión de certificados y las preocupaciones de accesibilidad.
## Cuándo Cloud MQTT es la opción adecuada
* **Ingesta en terreno virgen.** No existe un broker; ejecutar uno añadiría alcance de infraestructura sin beneficio operativo.
* **Firmware MQTT proporcionado por el proveedor.** Un dispositivo o pasarela está configurado para publicar MQTT en un endpoint accesible desde Internet, y es preferible un endpoint gestionado a poner en marcha infraestructura.
* **Sitios remotos con operaciones limitadas.** Un sitio tiene enlace ascendente celular o satelital y TI local limitada; apuntar los publicadores a un endpoint gestionado en la nube es operativamente más sencillo que ejecutar un broker local.
* **Implementaciones piloto.** Validar una integración MQTT antes de comprometerse con inversión en infraestructura de broker.
Cuando ya hay un broker existente en su lugar — un clúster de Mosquitto on-premise, AWS IoT Core, una instancia empresarial de HiveMQ u otro producto de broker — consulte [MQTT externo](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) en su lugar.
## Aprovisionamiento del conector
1. Vaya a **Conectores** en la barra lateral.
2. Haz clic en **Añadir conector**.
3. Selecciona **Cloud MQTT** desde el **tipo de conector** menú desplegable.
4. Proporcione un **Nombre** para el conector (etiqueta operativa, p. ej. `Telemetría de la línea A de la planta 3`).
5. Haz clic en **Añade**.
La plataforma aprovisiona el endpoint del broker y muestra cuatro credenciales:
| Campo | Comportamiento |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **URL del broker** | El endpoint gestionado completo, incluido el esquema y el puerto. Usa MQTTS (TLS) en el puerto 1884. Copie textualmente: el esquema y el puerto forman parte de la credencial. |
| **Prefijo del tema** | El prefijo de espacio de nombres único para los mensajes enrutados a este conector. Cada mensaje que publiquen sus dispositivos debe comenzar con este prefijo. El prefijo tiene la forma `iot/{org}/{connection}` — dos segmentos opacos que identifican su organización y este conector. |
| **Nombre de usuario** | Generado por la plataforma. Cópielo exactamente: debe reproducirse byte por byte en el lado publicador. |
| **Contraseña** | Un secreto generado aleatoriamente. Se muestra una sola vez. **Cópielo y guárdelo de forma segura al crearlo.** No es posible recuperarlo; solo rotarlo. |
La contraseña no se almacena en un formato recuperable. Trate la copia posterior al aprovisionamiento como la única oportunidad para capturarla; si se pierde ese momento, será necesario regenerar las credenciales y reconfigurar a todos los publicadores.
## Modelo de integración
Los publicadores de Cloud MQTT se conectan salientemente al broker gestionado. Hay tres detalles importantes:
* **TLS en el puerto 1884.** Configure el cliente MQTT de su publicador para usar el `mqtts://` esquema en el puerto 1884. No asuma el puerto 1883: el broker gestionado no acepta conexiones en texto plano. El certificado del broker está firmado por una CA de confianza pública, por lo que no se requiere un paquete de CA del lado del cliente para las bibliotecas estándar.
* **El prefijo de tema es obligatorio en cada tema publicado.** Un dispositivo que publica lecturas de energía debe publicar en `{Topic prefix}/{your topic}` — por ejemplo, `iot/{org}/{connection}/meters/EM-4492/power`. Los mensajes publicados fuera del prefijo no se entregan a este conector.
* **El prefijo de tema se elimina antes del enrutamiento del dispositivo.** Cuando configura el Device ID Topic de un dispositivo en la subpestaña Topic, especifica solo la parte a nivel de dispositivo (`meters/{{deviceId}}/power` o similar). La plataforma gestiona el prefijo internamente.
Para dispositivos puenteados específicamente con Zigbee2MQTT, el `base_topic` de Z2M en `configuration.yaml` debería ser `{Topic prefix}/zigbee2mqtt`. Luego Z2M publica cada dispositivo bajo `{Topic prefix}/zigbee2mqtt/{friendlyName}`, y el tema a nivel de dispositivo que se ve para el enrutamiento es `zigbee2mqtt/{friendlyName}`.
## Verificación de la ingesta
Después de iniciar el publicador, abra la página de detalles del conector. El campo **Último dato recibido** se actualiza en segundos tras la primera publicación. Para configuraciones puenteadas con Z2M, el propio `bridge/state` anuncio de mensaje retenido es lo primero que acepta el broker; normalmente es cuando **Último dato recibido** aparece por primera vez, antes de que cualquier dispositivo haya informado.
Si **Último dato recibido** no se actualiza después de que el publicador informa una conexión correcta con el broker, las causas más comunes son un puerto incorrecto (1883 frente a 1884), un esquema TLS incorrecto o un desajuste en el prefijo de tema. Consulte [Solución de problemas](/kilo-docs-es/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) para la secuencia completa de diagnóstico.
## Rotación de credenciales
Rote las credenciales de Cloud MQTT cuando:
* La contraseña original se perdió o nunca se capturó.
* Se sospecha de una filtración de credenciales.
* Una transición de equipo o la salida de un contratista justifica la rotación.
* Una política de cumplimiento exige rotación periódica.
Para rotar:
1. Abra la página de detalles del conector.
2. En modo de edición, regenere la contraseña.
3. Capture la nueva contraseña inmediatamente.
4. Actualice todos los clientes publicadores (configuración del firmware, Z2M `configuration.yaml`, ajustes de la pasarela de borde) con la nueva contraseña.
5. Reinicie los publicadores para que tomen la nueva credencial.
El nombre de usuario y el prefijo de tema permanecen estables durante la rotación. Solo cambia la contraseña.
## Límites
Los conectores Cloud MQTT son ilimitados por organización. Use varios conectores para delimitar espacios de nombres por sitio, proveedor o equipo operativo: cada conector tiene su propio prefijo de tema y credenciales, y el acceso se puede gestionar de forma independiente por conector.
---
# 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/cloud-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.
