> 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-pt/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md).
# Cloud MQTT
Provisione um broker Cloud MQTT gerido no Kilo IoT — endpoint dedicado e credenciais por conector, ideal para pilotos.
Cloud MQTT é a opção de broker gerida pela plataforma para um conector MQTT. O Kilo IoT Server provisiona um endpoint de broker dedicado por conector, gera credenciais e atribui um prefixo de tópico único que delimita o namespace do conector dentro do broker gerido. Os dispositivos e gateways de edge publicam nesse endpoint; a plataforma consome as mensagens diretamente.
Para implementações que não têm necessidade operacional de executar o seu próprio broker MQTT — pilotos, locais remotos, instalações recentemente adquiridas, firmware MQTT fornecido pelo fabricante que apenas precisa de um destino público — o Cloud MQTT remove do âmbito da integração o provisionamento do broker, a gestão de certificados e as preocupações de conectividade.
## Quando o Cloud MQTT é a escolha certa
* **Ingestão greenfield.** Não existe broker; executar um acrescentaria âmbito de infraestrutura sem benefício operacional.
* **Firmware MQTT fornecido pelo fabricante.** Um dispositivo ou gateway está configurado para publicar MQTT para um endpoint acessível pela Internet, e é preferível um endpoint gerido a criar infraestrutura de raiz.
* **Locais remotos com operações limitadas.** Um local tem uplink celular ou por satélite e TI local limitada; apontar os publishers para um endpoint cloud gerido é operacionalmente mais simples do que executar um broker local.
* **Implementações piloto.** Validar uma integração MQTT antes de se comprometer com investimento em infraestrutura de broker.
Quando já existe um broker em vigor — um cluster Mosquitto on-premise, AWS IoT Core, uma instância empresarial do HiveMQ ou outro produto de broker — consulte [External MQTT](/kilo-docs-pt/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) em vez disso.
## Provisionamento do conector
1. Navegue para **Conectores** na barra lateral.
2. Clica em **Adicionar conector**.
3. Seleciona **Cloud MQTT** a partir do **Tipo de conector** menu suspenso.
4. Forneça um **Nome** para o conector (rótulo operacional, por ex. `Telemetria da Linha A da Fábrica 3`).
5. Clica em **Adicione**.
A plataforma provisiona o endpoint do broker e apresenta quatro credenciais:
| Campo | Comportamento |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **URL do broker** | O endpoint gerido completo, incluindo esquema e porta. Usa MQTTS (TLS) na porta 1884. Copie literalmente — o esquema e a porta fazem parte da credencial. |
| **Prefixo do tópico** | O prefixo de namespace único para as mensagens encaminhadas para este conector. Todas as mensagens que os seus dispositivos publicam têm de começar com este prefixo. O prefixo tem a forma `iot/{org}/{connection}` — dois segmentos opacos que identificam a sua organização e este conector. |
| **Nome de utilizador** | Gerado pela plataforma. Copie exatamente — tem de ser reproduzido byte a byte no lado da publicação. |
| **campo Palavra-passe** | Um segredo gerado aleatoriamente. Mostrado uma vez. **Copie e guarde em segurança aquando da criação.** Não é possível recuperar — apenas girar. |
A palavra-passe não é armazenada de forma recuperável. Trate a cópia pós-provisionamento como a única oportunidade para a capturar; se falhar esse momento, será necessário regenerar as credenciais e reconfigurar todos os publishers.
## Modelo de integração
Os publishers do Cloud MQTT ligam-se de saída ao broker gerido. Três detalhes importam:
* **TLS na porta 1884.** Configure o cliente MQTT do seu publisher para usar o `mqtts://` esquema na porta 1884. Não assuma a porta 1883 — o broker gerido não aceita ligações em texto simples. O certificado do broker é assinado por uma CA publicamente confiável, por isso não é necessário um bundle de CA do lado do cliente para bibliotecas standard.
* **O prefixo de tópico é obrigatório em todos os tópicos publicados.** Um dispositivo que publica leituras de energia tem de publicar para `{Prefixo de tópico}/{seu tópico}` — por exemplo, `iot/{org}/{connection}/meters/EM-4492/power`. As mensagens publicadas fora do prefixo não são entregues a este conector.
* **O prefixo de tópico é removido antes do encaminhamento do dispositivo.** Quando configura o Device ID Topic de um dispositivo no separador Topic, especifica apenas a parte ao nível do dispositivo (`meters/{{deviceId}}/power` ou semelhante). A plataforma trata do prefixo internamente.
Para dispositivos ligados via Zigbee2MQTT especificamente, a configuração Z2M `base_topic` em `configuration.yaml` deve ser `{Prefixo de tópico}/zigbee2mqtt`. O Z2M publica então cada dispositivo em `{Prefixo de tópico}/zigbee2mqtt/{friendlyName}`, e o tópico ao nível do dispositivo visto para encaminhamento é `zigbee2mqtt/{friendlyName}`.
## Verificação da ingestão
Depois de iniciar o publisher, abra a página de detalhes do conector. O campo **Últimos dados recebidos** atualiza-se em segundos após a primeira publicação. Para configurações ligadas via Z2M, o próprio anúncio de mensagem retida do `bridge/state` bridge/state **Últimos dados recebidos** é a primeira coisa que o broker aceita — é normalmente nessa altura que
Se **Últimos dados recebidos** aparece pela primeira vez, antes de qualquer dispositivo ter reportado. Se não atualizar depois de o publisher indicar uma ligação bem-sucedida ao broker, as causas mais comuns são porta errada (1883 vs 1884), esquema TLS errado ou incompatibilidade do prefixo de tópico. Consulte [Resolução de problemas](/kilo-docs-pt/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) para a sequência de diagnóstico completa.
## Rotação de credenciais
Rode as credenciais do Cloud MQTT quando:
* A palavra-passe original foi perdida ou nunca foi capturada.
* É suspeitada uma fuga de credenciais.
* Uma transição de equipa ou saída de um contractor justifica a rotação.
* Uma política de conformidade exige rotação periódica.
Para rodar:
1. Abra a página de detalhes do conector.
2. Em modo de edição, regenere a palavra-passe.
3. Capture a nova palavra-passe imediatamente.
4. Atualize todos os clientes de publicação (configuração de firmware, Z2M `configuration.yaml`, definições do gateway de edge) com a nova palavra-passe.
5. Reinicie os publishers para adotarem a nova credencial.
O nome de utilizador e o prefixo de tópico permanecem estáveis durante a rotação. Apenas a palavra-passe muda.
## Limites
Os conectores Cloud MQTT são ilimitados por organização. Use vários conectores para delimitar namespaces por local, fornecedor ou equipa operacional — cada conector tem o seu próprio prefixo de tópico e credenciais, e o acesso pode ser gerido de forma independente 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-pt/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.
