For the complete documentation index, see llms.txt. This page is also available as Markdown.

Cloud MQTT

Provisionnez un broker Cloud MQTT géré dans Kilo IoT — point de terminaison et identifiants dédiés par connecteur, idéal pour les pilotes.

Cloud MQTT est l’option de broker gérée par la plateforme pour un connecteur MQTT. Le serveur IoT Kilo provisionne un endpoint de broker dédié par connecteur, génère les identifiants et attribue un préfixe de topic unique qui délimite l’espace de noms du connecteur au sein du broker géré. Les appareils et les passerelles edge publient vers cet endpoint ; la plateforme consomme les messages directement.

Pour les déploiements qui n’ont pas de besoin opérationnel d’exécuter leur propre broker MQTT — pilotes, sites distants, sites récemment acquis, firmware MQTT fourni par un fournisseur qui a seulement besoin d’une destination publique — Cloud MQTT élimine du périmètre d’intégration le provisionnement du broker, la gestion des certificats et les problèmes d’accessibilité.

Quand Cloud MQTT est le bon choix

  • Ingestion greenfield. Aucun broker existant ; en faire fonctionner un ajouterait du périmètre d’infrastructure sans bénéfice opérationnel.

  • Firmware MQTT fourni par un fournisseur. Un appareil ou une passerelle est configuré pour publier en MQTT vers un endpoint accessible depuis Internet, et un endpoint géré est préférable à la mise en place d’une infrastructure.

  • Sites distants avec des opérations contraintes. Un site dispose d’une liaison montante cellulaire ou satellite et d’un support informatique limité sur place ; orienter les éditeurs vers un endpoint cloud géré est opérationnellement plus simple que d’exécuter un broker local.

  • Déploiements pilotes. Valider une intégration MQTT avant d’engager un investissement dans une infrastructure de broker.

Lorsqu’un broker existant est déjà en place — un cluster Mosquitto sur site, AWS IoT Core, une instance HiveMQ d’entreprise ou un autre produit de broker — voir External MQTT à la place.

Provisionnement du connecteur

  1. Accédez à Connecteurs dans la barre latérale.

  2. Cliquez sur Ajouter un connecteur.

  3. Sélectionner Cloud MQTT depuis le type de connecteur menu déroulant.

  4. Fournissez un Nom pour le connecteur (libellé opérationnel, par ex. Télémétrie ligne A usine 3).

  5. Cliquez sur Ajouter.

La plateforme provisionne l’endpoint du broker et affiche quatre identifiants :

Champ
Comportement

URL du broker

L’endpoint géré complet, y compris le schéma et le port. Utilise MQTTS (TLS) sur le port 1884. À copier tel quel — le schéma et le port font partie de l’identifiant.

Préfixe de topic

Le préfixe d’espace de noms unique pour les messages routés vers ce connecteur. Chaque message publié par vos appareils doit commencer par ce préfixe. Le préfixe a la forme iot/{org}/{connection} — deux segments opaques identifiant votre organisation et ce connecteur.

Nom d’utilisateur

Généré par la plateforme. À copier exactement — il doit être reproduit à l’identique côté publication.

Mot de passe

Un secret généré aléatoirement. Affiché une seule fois. À copier et à conserver en lieu sûr lors de la création. Aucune récupération n’est possible — uniquement une rotation.

Le mot de passe n’est pas stocké sous une forme récupérable. Considérez la copie effectuée après le provisionnement comme la seule occasion de le capturer ; si vous manquez ce moment, il faut régénérer les identifiants et reconfigurer tous les éditeurs.

A newly provisioned Cloud MQTT connector showing the broker URL, topic prefix, username and one-time password with copy buttons

Modèle d’intégration

Les éditeurs Cloud MQTT se connectent en sortie vers le broker géré. Trois points sont importants :

  • TLS sur le port 1884. Configurez le client MQTT de votre éditeur pour utiliser le mqtts:// schéma sur le port 1884. N’assumez pas le port 1883 — le broker géré n’accepte pas les connexions en clair. Le certificat du broker est signé par une autorité de certification approuvée publiquement, donc aucun bundle de CA côté client n’est requis pour les bibliothèques standard.

  • Le préfixe de topic est obligatoire sur chaque topic publié. Un appareil publiant des relevés d’énergie doit publier vers {Topic prefix}/{your topic} — par exemple, iot/{org}/{connection}/meters/EM-4492/power. Les messages publiés en dehors du préfixe ne sont pas livrés à ce connecteur.

  • Le préfixe de topic est supprimé avant le routage vers l’appareil. Lorsque vous configurez le topic d’ID de périphérique d’un appareil dans le sous-onglet Topic, vous ne spécifiez que la partie au niveau de l’appareil (meters/{{deviceId}}/power ou similaire). La plateforme gère le préfixe en interne.

Pour les appareils reliés via Zigbee2MQTT en particulier, le Z2M base_topic paramètre dans configuration.yaml doit être {Topic prefix}/zigbee2mqtt. Z2M publie ensuite chaque appareil sous {Topic prefix}/zigbee2mqtt/{friendlyName}, et le topic de niveau appareil vu pour le routage est zigbee2mqtt/{friendlyName}.

Vérification de l’ingestion

Après le démarrage de l’éditeur, ouvrez la page de détail du connecteur. Le Dernières données reçues champ se met à jour dans les secondes qui suivent la première publication. Pour les configurations reliées par Z2M, le propre bridge/state l’annonce de message retenu bridge/state est la première chose que le broker accepte — c’est généralement à ce moment que Dernières données reçues apparaît pour la première fois, avant qu’aucun appareil n’ait signalé quoi que ce soit.

Si Dernières données reçues ne se met pas à jour après que l’éditeur a signalé une connexion réussie au broker, les causes les plus courantes sont un mauvais port (1883 au lieu de 1884), un mauvais schéma TLS ou un décalage du préfixe de topic. Voir Dépannage pour la séquence de diagnostic complète.

Rotation des identifiants

Faites tourner les identifiants Cloud MQTT lorsque :

  • Le mot de passe d’origine a été perdu ou n’a jamais été capturé.

  • Une fuite d’identifiants est suspectée.

  • Une transition d’équipe ou le départ d’un prestataire justifie une rotation.

  • Une politique de conformité exige une rotation périodique.

Pour faire la rotation :

  1. Ouvrez la page de détail du connecteur.

  2. En mode édition, régénérez le mot de passe.

  3. Capturez immédiatement le nouveau mot de passe.

  4. Mettez à jour tous les clients émetteurs (configuration du firmware, Z2M configuration.yaml, paramètres de passerelle edge) avec le nouveau mot de passe.

  5. Redémarrez les éditeurs pour prendre en compte le nouvel identifiant.

Le nom d’utilisateur et le préfixe de topic restent stables lors de la rotation. Seul le mot de passe change.

The Settings tab of a Cloud MQTT connector, with the password masked and a regenerate button beside it

les limites

Les connecteurs Cloud MQTT sont illimités par organisation. Utilisez plusieurs connecteurs pour segmenter les espaces de noms par site, fournisseur ou équipe opérationnelle — chaque connecteur dispose de son propre préfixe de topic et de ses propres identifiants, et l’accès peut être géré indépendamment pour chaque connecteur.

Mis à jour