Cette rubrique décrit les problèmes de messagerie courants et leurs solutions pour la communication entre les appareils, IoT Platform et les serveurs.
Gestion des messages en double
Le niveau QoS 1 garantit une livraison au moins une fois ; un appareil peut donc recevoir des messages en double. Ces doublons partagent le même ID de message, que l'appareil peut utiliser pour la déduplication. IoT Platform minimise également l'envoi de messages QoS 1 en double.
Échec de réception des données par un appareil MQTT
Si un appareil ne parvient pas à recevoir des données, vérifiez les points suivants pour identifier la cause :
Vérifiez que l'appareil est abonné au bon topic. Un appareil MQTT ne peut recevoir des messages que des topics auxquels il est abonné.
Si l'appareil manque occasionnellement des messages : Vérifiez la présence d'une logique longue dans le callback de l'application de votre appareil. Le cas échéant, déplacez cette logique vers un thread séparé afin d'éviter de bloquer le callback.
Assurez-vous que l'application s'abonne au topic lors de son initialisation. Les messages envoyés avant la finalisation de l'abonnement risquent d'être perdus.
Pour recevoir les messages QoS 1 envoyés pendant que l'appareil était hors ligne, définissez le paramètre de connexion MQTT cleanSession sur false (c'est-à-dire que cleanSession doit être false).
Stockage des messages
Après la publication d'un message sur un topic, IoT Platform le transfère immédiatement aux appareils abonnés à ce topic.
Message QoS 0 : IoT Platform ne le stocke pas.
Message QoS 1 : IoT Platform le conserve pendant 7 jours.
Durée de rétention des données des appareils
Messages QoS 0 : IoT Platform ne les conserve pas.
Messages QoS 1 : IoT Platform les conserve pendant 7 jours.
Vous pouvez consulter les journaux de communication des 7 derniers jours dans la console IoT Platform sur la page de votre instance. Pour plus d'informations, consultez Log Service.
Livraison lente ou expirée des messages
Une connexion réseau instable constitue une cause fréquente de ce problème.
Pour tester la connectivité réseau de l'appareil :
Connectez-vous à la console IoT Platform.
Sur la page Overview, repérez l'instance et cliquez sur son ID ou son alias.
Dans le volet de navigation de gauche, choisissez Devices > Devices.
Sur la page Devices, recherchez l'appareil par son DeviceName ou son alias.
Dans la colonne Actions de l'appareil, cliquez sur View.
Sous l'onglet Device Information, cliquez sur Test à côté de Real-time Delay.
Cliquez sur OK pour démarrer le test.
Répétez les étapes 6 et 7 pour recueillir davantage de données. Une latence constamment élevée indique une connexion réseau instable.
Prise en charge des messages testament et conservés
Oui. IoT Platform prend en charge les messages testament et conservés avec MQTT 5.0. Pour plus d'informations, consultez Fonctionnalités MQTT 5.0 prises en charge par IoT Platform.
Récupération des messages côté serveur
Un serveur peut récupérer les messages des appareils de deux manières.
-
Abonnement côté serveur : Utilisez l'abonnement côté serveur d'IoT Platform pour vous abonner à un ou plusieurs types de messages. Selon vos paramètres d'abonnement, IoT Platform transfère les messages des types spécifiés de tous les appareils d'un produit vers votre serveur. IoT Platform prend en charge les types d'abonnement côté serveur suivants :
Abonnement côté serveur AMQP : Utilisez un SDK AMQP pour recevoir les messages des appareils transférés par IoT Platform.
Abonnement côté serveur MNS : Utilisez un SDK MNS pour recevoir les messages des appareils que IoT Platform transfère vers une file d'attente Simple Message Queue (formerly MNS) (SMQ).
Transfert de données : Utilisez le transfert de données pour acheminer les données d'appareils spécifiés vers une file d'attente Simple Message Queue (formerly MNS) (SMQ) ou une file d'attente Message Queue for Apache RocketMQ, selon les règles de transfert de données. Votre serveur consomme les messages à l'aide d'un SDK MNS ou d'un SDK Message Queue for Apache RocketMQ. Pour plus d'informations, consultez Présentation du transfert de données.
Les files d'attente SMQ ne reçoivent pas les messages de la console
IoT Platform ne transfère pas vers les files d'attente Simple Message Queue (formerly MNS) (SMQ) les messages envoyés depuis la console ou via une API cloud, car il les considère comme des messages côté serveur. Seuls les messages provenant d'un appareil, tels que les messages montants, les notifications de changement de statut des appareils et les modifications de tags des appareils, sont acheminés vers les files d'attente SMQ.
Comment identifier le topic source
Les messages dans une file d'attente Simple Message Queue (formerly MNS) (SMQ) présentent le format suivant :
{
"messageid": "12345",
"messagetype": "status/upload",
"topic": "null/topic",
"payload": {},
"timestamp": 1469564576
}Le champ topic identifie le topic source.
Envoi de commandes aux appareils
Vous pouvez appeler les API IoT Platform suivantes pour envoyer des messages aux appareils :
|API
|
Description
| | --- | --- | |
[Pub](t7631.dita#doc_api_Iot_Pub)
|
Envoie un message à un appareil spécifié en utilisant un topic personnalisé.
| |
[BatchPub](t1995451.dita#doc_api_Iot_BatchPub)
|
Envoie un message à plusieurs appareils d'un produit spécifié en utilisant un topic personnalisé.
| |
[PubBroadcast](t7632.dita#doc_api_Iot_PubBroadcast)
|
Diffuse des messages aux appareils en ligne d'un produit spécifié.
Vous pouvez cibler tous les appareils en ligne ou uniquement ceux abonnés à un topic spécifique.
| |
[RRpc](t7633.dita#doc_api_Iot_RRpc)
|
Envoie un message de requête à un appareil spécifié et renvoie une réponse de manière synchrone.
| |
[SetDeviceProperty](t7600.dita#doc_api_Iot_SetDeviceProperty)
|
Définit la valeur d'une propriété Thing Specification Language (TSL) pour un appareil spécifié.
| |
[SetDevicesProperty](t41889.dita#doc_api_Iot_SetDevicesProperty)
|
Définit la valeur d'une propriété Thing Specification Language (TSL) pour plusieurs appareils d'un produit spécifié.
| |
[InvokeThingService](t7598.dita#doc_api_Iot_InvokeThingService)
|
Invoque un service Thing Specification Language (TSL) spécifié sur un seul appareil.
| |
[InvokeThingsService](t41888.dita#doc_api_Iot_InvokeThingsService)
|
Invoque un service Thing Specification Language (TSL) spécifié sur plusieurs appareils d'un produit spécifié.
|
Communication entre appareils
Oui, les appareils d'une même instance peuvent communiquer entre eux.
Utilisez la fonctionnalité data forwarding ou message routing pour transférer les messages du topic d'un appareil vers un autre, permettant ainsi la communication entre eux.
Vous pouvez transférer les données d'un topic d'appareil, tel qu'un topic de rapport des données du modèle de thing, vers d'autres topics. Pour plus d'informations, consultez Transférer des données vers d'autres topics.
Pour connecter une lumière intelligente à une application mobile via le transfert de données, consultez Communication M2M entre appareils à l'aide du transfert de données.
Pour connecter une lumière intelligente à une application mobile via le routage des messages, consultez Communication M2M entre appareils à l'aide du routage des messages.
Échec des messages QoS 2
IoT Platform prend en charge QoS 0 et QoS 1, mais ne prend pas en charge QoS 2.
Pour plus de détails, consultez la spécification du protocole MQTT.
Connexion des appareils et synchronisation des statuts
Abonnez-vous aux messages de mise à jour du statut des appareils en utilisant l'abonnement côté serveur afin de maintenir synchronisées les informations de connexion et de statut des appareils.
Pour plus d'informations, consultez Abonnement côté serveur.
Visualisation des données de l'appareil
-
Utilisez l'abonnement côté serveur ou la fonction Data Forwarding pour transférer les données de l'appareil vers votre serveur ou votre base de données. Vous pouvez ensuite développer votre propre solution de visualisation des données.
Pour plus d'informations, consultez les rubriques server-side subscription et Data Forwarding (New Version).
-
Exploitez un SDK côté serveur pour IoT Platform afin d'appeler des API, récupérer les données transmises par les appareils et concevoir votre propre solution de visualisation.
Les API suivantes permettent de récupérer les données des appareils :
|
**API**
|
**Description**
| | --- | --- | |
[QueryDevicePropertyStatus](t7599.dita#)
|
Récupère les instantanés des propriétés d'un appareil spécifié.
| |
[QueryDeviceOriginalPropertyStatus](t1995332.dita#)
|
Interroge les instantanés bruts des propriétés signalées par un appareil, y compris celles ayant réussi ou échoué à la validation du modèle d'objet (Thing Model).
| |
[QueryDeviceOriginalPropertyData](t1995333.dita#)
|
Consulte les enregistrements bruts des propriétés rapportées par un appareil, incluant celles validées ou rejetées par le Thing Model.
| |
[QueryDeviceOriginalEventData](t1995334.dita#)
|
Examine les historiques bruts des événements émis par un appareil, qu'ils aient passé ou non la validation du Thing Model.
| |
[QueryDeviceOriginalServiceData](t1995336.dita#)
|
Recherche les traces brutes des appels de service initiés par un appareil, y compris ceux ayant échoué ou réussi la vérification du Thing Model.
| |
[QueryDeviceDesiredProperty](t124801.dita#)
|
Obtient les valeurs souhaitées des propriétés d'un appareil.
| |
[QueryDevicePropertyData](t7596.dita#)
|
Extrait les données d'une propriété unique d'un appareil sur une période donnée.
| |
[QueryDevicePropertiesData](t77565.dita#)
|
Récupère les données relatives à plusieurs propriétés d'un appareil durant un intervalle de temps défini.
| |
[QueryDeviceEventData](t7595.dita#)
|
Liste les occurrences d'événements générées par un appareil.
| |
[QueryDeviceServiceData](t7597.dita#)
|
Affiche l'historique des appels de service effectués par un appareil.
| |
[QueryDevicesHotStorageData](t2273493.xdita#)
|
Interroge les séries temporelles stockées dans le service de données.
| |
[QueryDevicesHotStorageDataStatus](t2273494.xdita#)
|
Récupère les instantanés des séries temporelles conservées dans le service de données.
|
Publication de messages hexadécimaux via l'API
La console IoT Platform ne permet pas l'envoi de messages hexadécimaux via l'outil online debug, le simulateur d'appareil ou l'onglet liste des topics de la page de détails d'un appareil.
Privilégiez les API Pub, BatchPub ou PubBroadcast pour transmettre ce type de contenu. Le paramètre MessageContent doit contenir le message original encodé en Base64, qu'il s'agisse d'une chaîne de caractères ou d'un tableau d'octets hexadécimal.
Une fois le message envoyé par votre serveur métier via l'API, IoT Platform le décode automatiquement depuis le format Base64 avant de le router vers l'appareil cible.
Exportation des données des appareils
IoT Platform conserve les messages QoS 0 pendant 1 jour maximum et les messages QoS 1 jusqu'à 7 jours.
Le module de stockage du service de données permet d'archiver les données hors ligne des appareils ainsi que les séries temporelles. Les données hors ligne englobent les tables système de la plateforme, les tables de séries temporelles, les tables d'instantanés et les tables de stockage personnalisé. Les séries temporelles des appareils regroupent les données du modèle d'objet (propriétés, services et événements) rapportées par les équipements, ainsi que les données de topics personnalisés configurées selon les règles de stockage temporel. La procédure de configuration est décrite dans la rubrique Configure Data Storage.
-
Pour extraire les données des appareils, interrogez-les via les API appropriées puis poussez les résultats vers votre propre infrastructure.
-
Données de topic personnalisé
Interrogation des séries temporelles : QueryDevicesHotStorageData.
Consultation des instantanés : QueryDevicesHotStorageDataStatus.
-
Données du modèle d'objet (Thing Model)
Instantanés de toutes les propriétés d'un appareil ou d'un nœud jumeau numérique : QueryDevicePropertyStatus.
Instantané des propriétés brutes rapportées par un appareil (incluant celles validées ou rejetées par le Thing Model) : QueryDeviceOriginalPropertyStatus.
Historique des propriétés brutes émises par un appareil (couvrant les validations réussies et échouées du Thing Model) : QueryDeviceOriginalPropertyData.
Journal des événements bruts générés par un appareil (qu'ils aient passé ou non la validation du Thing Model) : QueryDeviceOriginalEventData.
Traces des appels de service bruts initiés par un appareil (validés ou rejetés par le Thing Model) : QueryDeviceOriginalServiceData.
-
Données issues des tables de stockage du service de données
Extraction des données présentes dans les tables système de la plateforme, ainsi que dans les tables de séries temporelles ou d'instantanés : CreateDownloadDataJob et GetDownloadFile.
-
API de données du service de données
Lancez une tâche d'interrogation via une API du service de données pour obtenir des informations spécifiques depuis une source de données : ListAnalyticsData.
-
Si vous souhaitez conserver les données des appareils sur le long terme, réduire les coûts de stockage ou effectuer des traitements avancés (tels que l'analyse SQL, les et l'API de données), activez la sauvegarde des sources de données des appareils. Dès lors que cette option est activée pour un produit, IoT Platform génère automatiquement les time-series/snapshot tables correspondantes dans l'offline storage. Ces structures incluent la product property time-series table, la product property snapshot table et la product event table.
Abonnement AMQP pour les données hexadécimales
Oui.
Suivez cette procédure pour acheminer les données hexadécimales :
Configurez l'appareil pour qu'il transmette les données au format hexadécimal via un topic personnalisé. Reportez-vous à la section Use custom topics to communicate pour les détails techniques.
-
Paramétrez le transfert de messages afin de souscrire aux notifications envoyées par l'appareil sur le topic personnalisé.
Configuration de l'abonnement côté serveur AMQP : Dans Alibaba Cloud IoT Platform, attribuez la valeur Push Message Type au champ Device-reported Messages.
-
Transfert des données vers un groupe de consommateurs côté serveur AMQP : Dans l'analyseur de messages, exploitez la fonction
payload('binary')afin de convertir les données reçues de l'appareil en variable binaire pour un transit transparent.La liste complète des fonctions prises en charge par l'analyseur Data Forwarding est disponible dans la rubrique Function list.
-
Intégrez un SDK client AMQP pour consommer les messages personnalisés provenant de l'appareil.
Alibaba Cloud IoT Platform met à disposition des exemples de code pour les SDK AMQP dans les langages suivants :
Les SDK clients AMQP pour Python 3 et PHP s'appuient sur le protocole STOMP pour dialoguer avec Alibaba Cloud IoT Platform. Lors de leur utilisation, encodez systématiquement la charge utile en Base64 avant sa transmission afin d'éviter toute troncature des données.
Les instructions détaillées d'intégration sont présentées dans la documentation Connexion du client AMQP.
Mappage entre groupe de consommateurs et file d'attente de messages AMQP
Oui.
Un maximum de 128 clients AMQP peuvent consommer simultanément les messages issus d'une même file d'attente AMQP.
Association d'un appareil à une file d'attente AMQP unique
Oui.
Servez-vous du Rule Engine pour orienter les données vers un groupe de consommateurs abonné à un serveur AMQP. Dans le script de l'analyseur de transfert, utilisez des fonctions comme topic(number) ou deviceName() au sein d'une instruction if pour cibler un appareil spécifique et diriger ses messages vers la file d'attente AMQP appropriée.
Voici un exemple de script d'analyse :
// Get the device's message payload and parse it as JSON.
var data = payload("json");
// Get the device name.
var dn = deviceName();
// If the message is from 'device01', forward its data.
if (dn == 'device01') {
writeAmqp(1000, data, "Debug");
}Pour approfondir la syntaxe des scripts d'analyse, consultez la rubrique Syntaxe des scripts. La procédure de configuration de l'analyseur de transfert de messages est expliquée dans Transfert des données vers un groupe de consommateurs abonné à un serveur AMQP.
Notification des applications concernant le statut de connexion des appareils
La fonctionnalité d'abonnement côté serveur d'IoT Platform permet de recevoir des notifications lors des changements d'état des appareils. Pour activer ce mécanisme, déployez et lancez un client AMQP sur le serveur hébergeant votre application ou mini-programme.
La mise en œuvre repose sur les étapes suivantes :
Configuration de l'abonnement côté serveur AMQP : Depuis la console IoT Platform, paramétrez un groupe de consommateurs pour l'abonnement côté serveur afin de pousser les messages de changement d'état des appareils.
-
Intégration du client AMQP : Installez et exécutez un client AMQP sur le serveur supportant votre application ou mini-programme pour établir la connexion avec IoT Platform.
Le format des données relatives aux changements d'état est décrit dans la section État de connexion/déconnexion de l'appareil. Une fois les messages reçus par le client AMQP, implémentez la logique nécessaire pour les afficher dans votre interface applicative.
Connexion de l'appareil : Lorsqu'un appareil se connecte à IoT Platform, la plateforme transmet ses informations d'état au client AMQP pour consommation.
Absence de réception de message après un appel d'API Pub
L'appareil n'est pas abonné au topic indiqué dans l'appel à l'API Pub.
Un appareil doit être explicitement abonné à un topic pour en recevoir les messages. Pour réaliser cet abonnement, invoquez l'API SubscribeTopic.
S'abonner à des topics et les consulter
Un appareil doit s'abonner activement aux topics. Une fois l'abonnement effectué avec succès, les topics apparaissent dans la section Topic List de la page de détails de l'appareil pour votre instance dans la console IoT Platform.
Si un appareil n'est abonné à aucun topic, l'onglet Topic List de sa page de détails reste vide.
S'abonner à des topics
Un appareil peut s'abonner aux topics de plusieurs manières :
-
Si vous utilisez le SDK C Link (versions 3.1, 3.2 et 4.x) ou le SDK Python Link fourni par IoT Platform, votre appareil s'abonne automatiquement aux topics de communication de base et aux topics du modèle d'objet (Thing Model) disposant de l'autorisation subscribe.
Après avoir créé un topic personnalisé avec l'autorisation subscribe, vous pouvez utiliser les API suivantes du SDK pour vous abonner au topic personnalisé :
Pour les versions 3.1 et 3.2 du SDK C Link : IOT_MQTT_Subscribe.
Pour la version 4.x du SDK C Link : aiot_mqtt_sub.
Pour le SDK Python Link : lk.subscribe_topic(topic, qos=1).
Si vous activez l'abonnement par proxy lors de la création d'un topic personnalisé, IoT Platform abonne automatiquement l'appareil à ce topic lorsque celui-ci établit une connexion.
Pour ajouter un topic personnalisé, consultez la rubrique Utiliser des topics personnalisés pour communiquer.
-
Démarrer le simulateur d'appareil : Lorsque vous utilisez la fonctionnalité de simulateur d'appareil fournie par IoT Platform, l'appareil s'abonne automatiquement aux topics de communication de base et aux topics du modèle d'objet.
Après avoir créé un topic personnalisé avec l'autorisation subscribe, vous pouvez utiliser la fonctionnalité de débogage des commandes ascendantes pour vous y abonner.
Utiliser MQTT.fx pour se connecter à IoT Platform : Une fois l'appareil en ligne, utilisez la fonctionnalité Subscribe pour vous abonner aux topics de l'appareil.
-
SubscribeTopic : Une fois qu'un appareil est connecté à IoT Platform, appelez cette API pour vous abonner aux topics de l'appareil.
Après avoir créé un topic personnalisé avec l'autorisation subscribe, vous pouvez appeler l'API SubscribeTopic pour vous abonner au topic.
Consulter les topics abonnés
Choisissez l'une des méthodes suivantes :
Consulter les topics abonnés d'un appareil dans la console IoT Platform.
Appelez l'API QueryDeviceSubTopic pour interroger les topics auxquels l'appareil est abonné.
Pourquoi les abonnements AMQP ne peuvent-ils pas recevoir de messages RRPC ?
La communication RRPC est un processus synchrone : le côté serveur envoie une requête à un appareil et attend une réponse. IoT Platform ne prend pas en charge les abonnements côté serveur AMQP pour les messages de communication RRPC.
Pour plus d'informations sur la communication RRPC, consultez la rubrique Communication synchrone MQTT (RRPC).
Format JSON standard pour les topics personnalisés
IoT Platform n'impose aucun format de données spécifique pour la communication via des topics personnalisés. Vous définissez le format.
Pour obtenir des informations sur les topics et le format Alink JSON requis pour la communication entre les appareils et IoT Platform, consultez la documentation relative au protocole Alink.
Si vous définissez le data format sur passthrough/custom lors de la création d'un produit, vous devez configurer l'analyse des messages. Cette configuration permet d'analyser les charges utiles au format personnalisé, envoyées par les appareils via un topic personnalisé, et de les convertir au format JSON. Pour plus d'informations, consultez la rubrique Analyse des messages de topics personnalisés.
Erreur de communication du modèle d'objet : « 5092 - property not found »
Cette erreur signifie qu'une propriété dans un message ascendant ou descendant n'est pas définie dans le modèle d'objet.
Causes possibles :
La propriété n'est pas définie dans le modèle d'objet. Accédez à la console IoT Platform pour examiner les définitions des propriétés et ajouter la propriété requise. Consultez la rubrique Ajouter un modèle d'objet.
La propriété est définie dans un module personnalisé. Pour la communication ascendante et descendante, vous devez préfixer la propriété avec l'identifiant du module personnalisé selon le format suivant :
{tsl.functionBlockId}:{tsl.properties.identifier}.
Pour plus de détails sur les champs du modèle d'objet, consultez la rubrique Référence des champs TSL du modèle d'objet. Pour plus d'informations sur les codes d'erreur liés aux messages, consultez la rubrique Codes d'erreur dans le journal d'exécution cloud.
Définition de propriété : erreur de réponse 6335 de l'appareil
Le modèle d'objet spécifie une réponse vide pour la méthode de définition de propriété. Par conséquent, lorsque IoT Platform envoie une commande de définition de propriété à un appareil, le champ data du message de réponse de l'appareil doit être vide. Si les données ne sont pas vides, une erreur se produit.
Pour plus d'informations sur les codes d'erreur, consultez la rubrique codes d'erreur dans les journaux d'exécution côté cloud.
Correspondance des topics pour les appareils
Oui. Les topics d'un appareil physique doivent correspondre à ceux de son appareil correspondant dans le produit.
Abonnement croisé entre appareils
Non. Un appareil ne peut s'abonner qu'à ses propres topics.
Recevoir des messages de tous les appareils
Vous pouvez utiliser l'abonnement côté serveur AMQP pour que votre serveur reçoive les messages des appareils. Pour plus d'informations, consultez la rubrique Utiliser l'abonnement côté serveur AMQP.
Échec de l'abonnement avec un certificat d'appareil partagé
Un seul appareil peut utiliser un certificat d'appareil à la fois. L'appareil matériel et le client MQTT doivent utiliser des certificats d'appareil différents pour se connecter à IoT Platform.
Un appareil ne peut s'abonner qu'à ses propres topics et ne peut pas publier de messages sur les topics d'autres appareils.
-
Vous pouvez utiliser Data Forwarding ou le routage des messages basé sur les topics pour transférer les messages d'un topic d'un appareil vers un autre, ce qui permet la communication entre les appareils.
Exemples :
Pour transférer les données d'un appareil depuis un topic utilisé pour signaler les données du modèle d'objet vers d'autres topics, consultez la rubrique Transférer des données vers d'autres topics.
Pour connecter une lampe intelligente à une application mobile à l'aide de Data Forwarding, consultez la rubrique Communication M2M entre appareils basée sur le transfert de messages.
Pour connecter une lampe intelligente à une application mobile à l'aide du routage des messages basé sur les topics, consultez la rubrique Communication M2M entre appareils basée sur le routage des messages Topic.
Autorisations d'opération pour les topics
-
IoT Platform prédéfinit les autorisations d'opération pour les topics de base et du modèle d'objet, et vous ne pouvez pas les modifier. Pour afficher ces autorisations, procédez comme suit :
Connectez-vous à la console IoT Platform.
Dans le coin supérieur gauche de la console, sélectionnez la région où se trouve votre instance.
Dans l'onglet Instance Overview, sous All Environments, recherchez votre instance et cliquez sur sa carte.
Dans le volet de navigation de gauche, choisissez .
Sur la page Product, recherchez votre produit et cliquez sur View dans la colonne Actions.
-
Sur la page Product details, cliquez sur l'onglet Topic category list. Vous pouvez ensuite afficher les listes de topics dans les onglets Basic topic et Thing model topic.
La colonne Operation permission de la liste des topics affiche les autorisations Publish et Subscribe pour chaque topic.
Le tableau de l'onglet Thing model topic contient les colonnes Function, Topic category, Operation permission et Description. Ce tableau répertorie les chemins d'accès aux topics (tels que
/sys/${productKey}/${deviceName}/thing/event/property/post) et leurs autorisations de publication ou d'abonnement correspondantes pour les fonctions telles que report property, set property, report event et invoke service.
Utilisez l'API QueryProductTopic pour interroger les détails des catégories de topics personnalisés d'un produit.
Exporter les journaux d'exécution côté cloud
Non, cela n'est pas possible.
-
Vous pouvez activer Log Service puis activer le transfert des journaux d'exécution côté cloud dans la console IoT Platform. Cela vous permet d'exporter les journaux vers un Logstore dans Log Service pour un stockage à long terme. Pour obtenir des instructions, consultez la rubrique Transférer les journaux d'exécution côté cloud.
Après avoir activé la fonctionnalité de transfert de journaux, Log Service crée automatiquement les ressources suivantes pour stocker vos journaux. Vous pouvez ensuite afficher les journaux d'exécution côté cloud transférés dans Log Service.
Project : iot-log-${uid}-${regionId}. Dans ce format, ${uid} correspond à l'ID de votre compte Alibaba Cloud et ${regionId} à l'ID de la région de votre service IoT Platform.
Logstore : iot-logs.
IoT Platform : Distribuer un message d'un seul appareil à plusieurs serveurs
Pour un abonnement côté serveur AMQP, un groupe de consommateurs est mappé à une seule file d'attente de messages AMQP. Si vous démarrez plusieurs consommateurs et les liez au même groupe de consommateurs, chaque message d'appareil est distribué à l'un d'eux de manière aléatoire. Pour envoyer une copie de chaque message à chaque consommateur, liez chaque consommateur à un groupe de consommateurs différent.
Pour plus d'informations, consultez les rubriques suivantes :
Configurer un groupe de consommateurs côté serveur AMQP : Configurer un abonnement côté serveur AMQP ou Transférer des données vers un groupe de consommateurs.
Démarrer un consommateur AMQP sur votre serveur : Connecter un client AMQP.
Diffuser des messages à plusieurs appareils
L'interface PubBroadcast d'IoT Platform vous permet de publier un message de diffusion vers plusieurs appareils en ligne au sein d'un produit spécifique. Vous pouvez cibler tous les appareils en ligne ou uniquement ceux qui sont abonnés à un topic spécifié.
Erreur d'abonnement côté serveur IoT Platform 9203
Cette erreur se produit parce que le client AMQP ou le client Simple Message Queue (anciennement MNS) (SMQ) pour l'abonnement côté serveur est hors ligne. Pour connecter le client AMQP, consultez la rubrique Connecter un client AMQP. Pour connecter le client MNS, consultez la rubrique Développer un client consommateur MNS.
Fréquence d'abonnement des appareils
Bien qu'un appareil n'ait besoin de s'abonner qu'une seule fois, nous recommandons de s'abonner à chaque démarrage. Cela garantit que le rappel correspondant dans votre code est déclenché.
Envoi de messages avant l'abonnement
Non. Un appareil ne reçoit des messages d'un topic de communication qu'après s'y être abonné. Pour plus de détails, consultez la rubrique Utiliser des topics de communication.
Connecter un client et s'abonner aux modifications de propriété
Configurer un abonnement côté serveur AMQP : Dans IoT Platform, définissez le Message Type sur Device-reported Messages.
-
Utilisez un SDK client AMQP pour vous connecter à IoT Platform et recevoir les Device-reported Messages abonnés contenant les données de propriété de l'appareil.
Alibaba Cloud IoT Platform fournit des exemples de code de SDK client AMQP dans les langages suivants :
Les SDK clients AMQP pour Python 3 et PHP utilisent le protocole STOMP pour communiquer avec IoT Platform. Lors de l'utilisation de ces SDK, vous devez encoder le contenu du message en Base64 avant de le pousser. Sinon, le contenu du message risque d'être tronqué.
Pour des instructions détaillées sur l'utilisation des SDK, consultez la rubrique Instructions de connexion du client AMQP.
Autorisation inter-comptes
Utilisez
device distributionpour distribuer des appareils d'uneinstancesource vers uneinstancecible dans un autreaccount. Leaccountcible peut alors afficher les données de ces appareils. Pour connaître les limites d'utilisation et obtenir des instructions détaillées, consultez la rubrique distribution d'appareils.