Connexion à MQTT à l'aide des SDK du AWS IoT périphérique Options de qualité de service (QoS) MQTT Sessions permanentes MQTT MQTT a retenu les messages Messages MQTT Last Will and Testament (LWT)Utilisation de ConnectAttributes Fonctionnalités prises en charge par MQTT 5 Propriétés MQTT 5 Codes de motif MQTT AWS IoT différences par rapport aux spécifications MQTT

MQTT

Le MQTT (Message Queuing Telemetry Transport) est un protocole de messagerie léger et largement adopté, conçu pour les appareils restreints. AWS IoT Core le soutient pour MQTT est basé sur les spécifications MQTT v3.1.1 et MQTT v5.0, avec quelques différences, comme indiqué dans. AWS IoT différences par rapport aux spécifications MQTT En tant que dernière version de la norme, MQTT 5 introduit plusieurs fonctionnalités clés qui renforcent la robustesse d’un système basé sur MQTT, notamment de nouvelles améliorations en termes de capacité de mise à l’échelle, un meilleur signalement des erreurs avec les réponses au code de motif, les délais d’expiration des messages et des sessions, et des en-têtes de message utilisateur personnalisés. Pour plus d'informations sur les fonctionnalités prises en charge par MQTT 5, voir Fonctionnalités prises AWS IoT Core en charge par MQTT 5. AWS IoT Core prend également en charge la communication entre les versions MQTT (MQTT 3 et MQTT 5). Un diffuseur de publication MQTT 3 peut envoyer un message MQTT 3 à un abonné MQTT 5 qui recevra un message de publication MQTT 5, et vice versa.

AWS IoT Core prend en charge les connexions de périphériques qui utilisent le protocole MQTT et le protocole MQTT over WSS et qui sont identifiées par un identifiant client. Les AWS IoT SDK pour appareils prennent en charge les deux protocoles et sont les méthodes recommandées pour connecter les appareils AWS IoT Core. Les SDK pour AWS IoT appareils prennent en charge les fonctions nécessaires aux appareils et aux clients pour se connecter aux AWS IoT services et y accéder. Les SDK pour appareils prennent en charge les protocoles d'authentification requis par les AWS IoT services et les exigences en matière d'ID de connexion requises par le protocole MQTT et les protocoles MQTT over WSS. Pour plus d'informations sur la façon de se connecter à AWS IoT l'aide des kits SDK du AWS périphérique et pour obtenir des liens vers des exemples de AWS IoT langues prises en charge, consultezConnexion à MQTT à l'aide des SDK du AWS IoT périphérique. Pour plus d’informations sur les méthodes d’authentification et de mappage de ports pour les messages MQTT, consultez Protocols, port mappings, and authentication (Protocoles, mappages de ports et authentification).

Bien que nous vous recommandions d'utiliser les SDK de l' AWS IoT appareil pour vous y connecter AWS IoT, ils ne sont pas obligatoires. Si vous n'utilisez pas les SDK de l' AWS IoT appareil, vous devez toutefois fournir la sécurité de connexion et de communication nécessaire. Les clients doivent envoyer l’extension TLS SNI (Server Name Indication) dans la demande de connexion. Les tentatives de connexion qui n’incluent pas le SNI sont refusées. Pour plus d'informations, consultez la section Sécurité du transport dans AWS IoT. Les clients qui utilisent des utilisateurs et des AWS informations d'identification IAM pour authentifier les clients doivent fournir l'authentification Signature Version 4 correcte.

Dans cette rubrique :

Connexion à MQTT à l'aide des SDK du AWS IoT périphérique
Options de qualité de service (QoS) MQTT
Sessions permanentes MQTT
MQTT a retenu les messages
Messages MQTT Last Will and Testament (LWT)
Utilisation de ConnectAttributes
Fonctionnalités prises en charge par MQTT 5
Propriétés MQTT 5
Codes de motif MQTT
AWS IoT différences par rapport aux spécifications MQTT

Connexion à MQTT à l'aide des SDK du AWS IoT périphérique

Cette section contient des liens vers les kits SDK du AWS IoT périphérique et vers le code source d'exemples de programmes illustrant comment connecter un appareil à AWS IoT. Les exemples d'applications liés ici montrent comment se connecter à AWS IoT l'aide du protocole MQTT et de MQTT via WSS.

Note

Les SDK du AWS IoT périphérique ont publié un client MQTT 5.

Options de qualité de service (QoS) MQTT

AWS IoT et les SDK pour AWS IoT appareils prennent en charge les niveaux de qualité de service (QoS) MQTT et. 0 1 Le protocole MQTT définit un troisième niveau de QoS, le 2 niveau, AWS IoT mais ne le supporte pas. Seul le protocole MQTT prend en charge la fonctionnalité QoS. HTTPS prend en charge la QoS en transmettant un paramètre de chaîne de requête ?qos=qos dont la valeur peut être 0 ou 1.

Ce tableau décrit comment chaque niveau de QoS affecte les messages publiés par et vers l’agent de messages.

Avec un niveau de QoS de...	Le message est…	Commentaires
QoS niveau 0	Envoyé zéro fois ou plus	Ce niveau doit être utilisé pour les messages envoyés via des liens de communication fiables ou qui peuvent être manqués sans problème.
QoS niveau 1	Envoyé au moins une fois, puis à plusieurs reprises jusqu’à ce qu’une réponse `PUBACK` soit reçue	Le message n’est pas considéré comme complet tant que l’expéditeur n’a pas reçu de réponse `PUBACK` indiquant que la livraison a été réussie.

Sessions permanentes MQTT

Les sessions permanentes stockent les abonnements et les messages d’un client, avec une qualité de service (QoS) de 1, qui n’ont pas été reconnus par le client. Lorsque l’appareil se reconnecte à une session permanente, la session reprend, les abonnements sont rétablis et les messages d’abonnement reçus et stockés sans accusé de réception avant la reconnexion sont envoyés au client.

Le traitement des messages enregistrés est enregistré dans CloudWatch et CloudWatch Logs. Pour plus d'informations sur les entrées écrites dans CloudWatch et les CloudWatch journaux, reportez-vous aux Métriques d'agent de messages sections etEntrée de journal en file d'attente.

Création d’une session permanente

Dans MQTT 3, vous créez une session permanente MQTT en envoyant un message CONNECT et en définissant l’indicateur cleanSession sur 0. Si aucune session n’existe pour le client qui envoie le message CONNECT, une nouvelle session permanente est créée. Si une session existe déjà pour le client, celui-ci la reprend. Pour créer une session propre, vous envoyez un message CONNECT et vous définissez l’indicateur cleanSession sur 1, et l’agent ne stockera aucun état de session lorsque le client se déconnecte.

Dans MQTT 5, vous gérez les sessions permanentes en définissant l’indicateur Clean Start et Session Expiry Interval. Le démarrage propre contrôle le début de la session de connexion et la fin de la session précédente. Lorsque vous définissez Clean Start =1, une nouvelle session est créée et une session précédente est interrompue si elle existe. Lorsque vous définissez Clean Start =0, la session de connexion reprend une session précédente si elle existe. L’intervalle d’expiration de session contrôle la fin de la session de connexion. L’intervalle d’expiration de session indique le temps, en secondes (entier de 4 octets), pendant lequel une session persistera après la déconnexion. Le paramètre Session Expiry interval = 0 entraîne la fin de la session immédiatement après la déconnexion. Si l’intervalle d’expiration de session n’est pas spécifié dans le message CONNECT, la valeur par défaut est 0.

Démarrage propre MQTT 5 et expiration de session
Valeur de la propriété	Description
`Clean Start`= `1`	Crée une nouvelle session et met fin à une session précédente s’il en existe une.
`Clean Start`= `0`	Reprend une session s’il en existe une précédente.
`Session Expiry Interval`> `0`	Maintient une session.
`Session Expiry interval`= `0`	Ne fait pas perdurer une session.

Dans MQTT 5, si vous définissez Clean Start = 1 et Session Expiry Interval =0, cela équivaut à une session propre de MQTT 3. Si vous définissez Clean Start = 0 et Session Expiry Interval >0, cela équivaut à une session permanente MQTT 3.

Note

Les sessions permanentes de plusieurs versions MQTT (MQTT 3 et MQTT 5) ne sont pas prises en charge. Une session permanente MQTT 3 ne peut pas être reprise en tant que session MQTT 5, et vice versa.

Opérations au cours d’une session permanente

Les clients utilisent l’attribut sessionPresent dans le message de connexion reconnue (CONNACK), afin de déterminer si une session permanente est présente. Si sessionPresent est 1, une session permanente est présente et tous les messages stockés pour le client sont remis au client une fois que celui-ci a reçu CONNACK, comme décrit dans Trafic de messages après reconnexion à une session permanente. Si sessionPresent est 1, le client n’a pas besoin de se réabonner. Toutefois, si sessionPresent est défini sur 0, aucune session permanente n’est présente et le client doit se réabonner à ses filtres de rubrique.

Une fois que le client rejoint la session permanente, il peut publier des messages et à s’abonner aux filtres de rubrique sans aucun indicateur supplémentaire sur chaque opération.

Trafic de messages après reconnexion à une session permanente

Une session permanente représente une connexion continue entre un client et un agent de messages MQTT. Lorsqu’un client se connecte à l’agent de messages à l’aide d’une session permanente, ce dernier enregistre tous les abonnements souscrits par le client pendant la connexion. Lorsque le client se déconnecte, le courtier de messages conserve les messages d'une QoS 1 et les nouveaux messages d'une QoS 1 publiés sur les rubriques auxquelles le client s'est abonné. Les messages sont stockés conformément à la limite du compte. Les messages dépassant cette limite seront supprimés. Pour plus d’informations sur les limites de messages permanents, veuilelz consulter AWS IoT Core quotas de point de terminaison. Lorsque le client se reconnecte à sa session permanente, tous les abonnements sont réactivés et tous les messages stockés sont envoyés au client à un rythme maximum de 10 messages par seconde. Dans MQTT 5, si un QoS1 sortant avec l’intervalle d’expiration des messages expire alors qu’un client est hors ligne, une fois la connexion rétablie, le client ne recevra pas le message expiré.

Après la reconnexion, les messages stockés sont envoyés au client, à un débit limité à 10 messages stockés par seconde, ainsi que tout le trafic de messages en cours jusqu’à ce que la limite Publish requests per second per connection soit atteinte. Le taux de livraison des messages stockés étant limité, la remise de tous les messages stockés prendra plusieurs secondes si une session comporte plus de 10 messages stockés à remettre après la reconnexion.

Fin d’une session permanente

Les sessions permanentes peuvent prendre fin de différentes manières :

Le délai d’expiration de la session permanente est expiré. Le délai d’expiration de session permanente démarre lorsque l’agent de messages détecte qu’un client s’est déconnecté, soit en raison de la déconnexion du client, soit en raison de l’expiration du délai de connexion.
Le client envoie un message CONNECT qui définit l’indicateur cleanSession sur 1.

Dans MQTT 3, la valeur par défaut du délai d’expiration des sessions permanentes est d’une heure, et cela s’applique à toutes les sessions du compte.

Dans MQTT 5, vous pouvez définir l’intervalle d’expiration de session pour chaque session sur les paquets CONNECT et DISCONNECT.

Pour l’intervalle d’expiration de session sur le paquet DISCONNECT :

Si la session en cours a un intervalle d’expiration de session de 0, vous ne pouvez pas définir un intervalle d’expiration de session supérieur à 0 sur le paquet DISCONNECT.
Si la session en cours a un intervalle d’expiration de session supérieur à 0 et que vous définissez l’intervalle d’expiration de session sur 0 sur le paquet DISCONNECT, la session sera terminée sur DISCONNECT.
Sinon, l’intervalle d’expiration de session sur le paquet DISCONNECT mettra à jour l’intervalle d’expiration de session de la session en cours.

Note

Les messages stockés en attente d’être envoyés au client à la fin d’une session sont supprimés ; cependant, ils sont toujours facturés au tarif de messagerie standard, même s’ils n’ont pas pu être envoyés. Pour plus d’informations sur la tarification des messages, consultez AWS IoT Core Tarification. Vous pouvez configurer l’intervalle d’expiration.

Reconnexion après expiration d’une session permanente

Si un client ne se reconnecte pas à sa session permanente avant son expiration, celle-ci se termine et les messages enregistrés sont supprimés. Lorsqu’un client se reconnecte après l’expiration de la session et définit un indicateur cleanSession sur 0, le service crée une nouvelle session persistante. Les abonnements ou messages de la session précédente ne sont pas disponibles pour cette session car ils ont été supprimés à l’expiration de la session précédente.

Frais liés aux messages de session persistants

Les messages vous sont facturés Compte AWS lorsque le courtier de messages envoie un message à un client ou lors d'une session permanente hors ligne. Lorsqu’un appareil hors ligne doté d’une session permanente se reconnecte et reprend sa session, les messages enregistrés sont transmis à l’appareil et débités de nouveau sur votre compte. Pour plus d’informations sur la tarification des messages, consultez la section AWS IoT Core Tarification - Messagerie.

Le délai d’expiration des sessions permanentes par défaut d’une heure peut être augmenté en utilisant le processus d’augmentation de limite standard. Notez que l’augmentation du délai d’expiration de la session peut augmenter le coût de vos messages, car ce délai supplémentaire pourrait permettre de stocker davantage de messages sur l’appareil hors ligne et ces messages supplémentaires seraient débités de votre compte au tarif de messagerie standard. L’heure d’expiration de la session est approximative et une session peut persister jusqu’à 30 minutes de plus que la limite du compte ; toutefois, une session ne sera pas inférieure à la limite du compte. Pour de plus amples informations sur les limites de sessions, veuillez consulter AWS Service Quotas.

MQTT a retenu les messages

AWS IoT Core supporte l'indicateur RETAIN décrit dans le protocole MQTT. Lorsqu'un client définit l'indicateur RETAIN sur un message MQTT qu'il publie, il AWS IoT Core enregistre le message. Il peut ensuite être envoyé aux nouveaux abonnés, récupéré en appelant l’opération GetRetainedMessage et visualisé dans la AWS IoT console.

Exemples d’utilisation de messages retenus au format MQTT

En tant que message de configuration initiale

Les messages retenus au format MQTT sont envoyés à un client une fois que celui-ci s’est abonné à une rubrique. Si vous souhaitez que tous les clients abonnés à un sujet reçoivent le message MQTT conservé juste après leur inscription, vous pouvez publier un message de configuration avec l'indicateur RETAIN activé. Les clients abonnés reçoivent également des mises à jour de cette configuration chaque fois qu’un nouveau message de configuration est publié.
En tant que dernier message d’état connu

Les appareils peuvent définir l’indicateur RETAIN sur les messages d’état actuel afin que AWS IoT Core les enregistre. Lorsque les applications se connectent ou se reconnectent, elles peuvent s'abonner à cette rubrique et obtenir le dernier état signalé juste après s'être abonnées à la rubrique de message conservée. De cette façon, ils peuvent éviter d’avoir à attendre le prochain message de l’appareil pour voir l’état actuel.

Dans cette section :

Tâches courantes avec des messages retenus au format MQTT dans AWS IoT Core
Facturation et messages retenus
Comparaison des messages MQTT retenus et des sessions permanentes MQTT
MQTT a conservé les messages et AWS IoT Device Shadows

Tâches courantes avec des messages retenus au format MQTT dans AWS IoT Core

AWS IoT Core enregistre les messages MQTT avec l'indicateur RETAIN activé. Ces messages retenus sont envoyés à tous les clients abonnés au sujet, sous la forme d’un message MQTT normal, et ils sont également stockés pour être envoyés aux nouveaux abonnés à la rubrique.

Les messages retenus au format MQTT nécessitent des actions politiques spécifiques pour autoriser les clients à y accéder. Pour des exemples d’utilisation des politiques relatives aux messages retenus, consultez Exemples de stratégies de messages conservés.

Cette section décrit les opérations courantes impliquant les messages retenus.

Création d’un message retenu

Le client détermine si un message est retenu lorsqu’il publie un message MQTT. Les clients peuvent définir l’indicateur RETAIN lorsqu’ils publient un message à l’aide d’un SDK des appareils. Les applications et les services peuvent définir l’indicateur RETAIN lorsqu’ils utilisent l’Publishaction pour publier un message MQTT.

Un seul message par nom de rubrique est retenu. Un nouveau message dont l’indicateur RETAIN est défini et publié dans une rubrique remplace tout message retenu existant qui a été envoyé au sujet précédemment.

REMARQUE : Vous ne pouvez pas publier dans une rubrique réservée lorsque l’indicateur RETAIN est activé.
Abonnement à un sujet de message retenu

Les clients s’abonnent aux rubriques de message retenus comme ils le feraient pour n’importe quel autre rubrique de message MQTT. L’indicateur RETAIN est activé pour les messages retenus reçus en vous abonnant à un sujet de message retenu.

Les messages conservés sont supprimés AWS IoT Core lorsqu'un client publie un message conservé avec une charge utile de 0 octet dans le sujet du message conservé. Les clients qui se sont abonnés à la rubrique du message retenu recevront également le message de 0 octet.

L’abonnement à un filtre de rubrique générique qui inclut un sujet de message retenu permet au client de recevoir les messages suivants publiés dans le sujet du message retenu, mais il ne transmet pas le message retenu lors de l’abonnement.

REMARQUE : Pour recevoir un message retenu lors de l’abonnement, le filtre de rubrique de la demande d’abonnement doit correspondre exactement à la rubrique du message retenu.

L’indicateur RETAIN est activé pour les messages retenus reçus lors de l’abonnement à une rubrique de message retenu. Les messages retenus qui sont reçus par un client abonné après son abonnement ne le sont pas.
Récupération d’un message retenu

Les messages retenus sont remis automatiquement aux clients lorsqu’ils s’abonnent à la rubrique contenant le message retenu. Pour qu’un client reçoive le message retenu lors de son abonnement, il doit s’abonner au nom exact de rubrique du message retenu. L’abonnement à un filtre de rubrique générique qui inclut une rubrique de message retenu permet au client de recevoir les messages suivants publiés dans la rubrique du message retenu, mais il ne transmet pas le message retenu lors de l’abonnement.

Les services et applications peuvent répertorier et récupérer les messages retenus en appelant ListRetainedMessages et GetRetainedMessage.

Aucun client n’est empêché de publier des messages dans une rubrique de message retenu sans définir l’indicateur RETAIN. Cela peut entraîner des résultats inattendus, tels que le message retenu ne correspondant pas au message reçu en vous abonnant à la rubrique.

Avec MQTT 5, si l’intervalle d’expiration d’un message retenu est défini et que le message retenu expire, un nouvel abonné qui s’abonne à cette rubrique ne recevra pas le message retenu une fois son abonnement réussi.
Répertorier les sujets des messages retenus

Vous pouvez répertorier les messages retenus en appelant ListRetainedMessages et les messages retenus peuvent être consultés dans la AWS IoT console.
Obtenir les détails des messages retenus

Vous pouvez obtenir les détails des messages retenus en appelant GetRetainedMessage et ils peuvent être consultés dans la AWS IoT console.
Retenir un message volontaire

Les messages MQTT Will créés lorsqu’un appareil se connecte peuvent être retenus en définissant l’indicateur Will Retain dans le champ Connect Flag bits.
Supprimer un message retenu

Les appareils, les applications et les services peuvent supprimer un message retenu en publiant un message avec l’indicateur RETAIN activé et une charge utile de message vide (0 octet) dans le nom du sujet du message retenu à supprimer. Ces messages suppriment le message conservé de AWS IoT Core, sont envoyés aux clients abonnés au sujet, mais ils ne sont pas conservés par AWS IoT Core.

Les messages retenus peuvent également être supprimés de manière interactive en accédant au message retenu dans la AWS IoT console. Les messages retenus supprimés à l’aide de la AWS IoT console envoient également un message de 0 octet aux clients abonnés au sujet du message retenu.

Les messages retenus ne peuvent pas être restaurés après leur suppression. Un client devra publier un nouveau message retenu pour remplacer le message supprimé.
Débogage et résolution des problèmes liés aux messages retenus

La AWS IoT console fournit plusieurs outils pour vous aider à résoudre les problèmes liés aux messages retenus :
- La page des messages retenus
  
  La page Messages retenus de la console AWS IoT fournit une liste paginée des messages retenus qui ont été stockés par votre compte dans la région actuelle. À partir de cette page, vous pouvez :
  - Consultez les détails de chaque message retenu, tels que la charge utile du message, la QoS, l’heure à laquelle il a été reçu.
  - Mettez à jour le contenu d’un message retenu.
  - Supprimez un message retenu.
- Le client de test MQTT
  
  La page du client de test MQTT de la console AWS IoT permet de s’abonner et de publier sur des sujets MQTT. L’option de publication vous permet de définir l’indicateur RETAIN sur les messages que vous publiez afin de simuler le comportement de vos appareils.
Certains résultats inattendus peuvent être le résultat de ces aspects de la manière dont les messages conservés sont implémentés dans AWS IoT Core.
- Limit es de messages retenues
  
  Lorsqu'un compte a stocké le nombre maximum de messages conservés, AWS IoT Core renvoie une réponse limitée aux messages publiés avec l'option RETAIN définie et à des charges utiles supérieures à 0 octet jusqu'à ce que certains messages conservés soient supprimés et que le nombre de messages conservés tombe en dessous de la limite.
- Ordre de distribution des messages retenus
  
  La séquence d’envoi des messages retenus et des messages souscrits n’est pas garantie.

Facturation et messages retenus

La publication de messages avec l’indicateur RETAIN activé par un client, à l’aide de la console AWS IoT ou par appel Publish entraîne des frais de messagerie supplémentaires décrits dans la section AWS IoT Core Tarification - Messagerie.

La récupération des messages conservés par un client, à l'aide de AWS IoT la console ou par appel GetRetainedMessageentraîne des frais de messagerie en plus des frais d'utilisation habituels de l'API. Les frais supplémentaires sont décrits dans la section AWS IoT Core Tarification - Messagerie.

Les messages MQTT Will publiés lorsqu’un appareil se déconnecte de façon inattendue entraînent des frais de messagerie décrits dans la section AWS IoT Core Tarification- Messagerie.

Pour plus d’informations sur les coûts de messagerie, consultez la section AWS IoT Core Tarification - Messagerie.

Comparaison des messages MQTT retenus et des sessions permanentes MQTT

Les messages retenus et les sessions permanentes sont des fonctionnalités standard de MQTT qui permettent aux appareils de recevoir des messages publiés alors qu’ils étaient hors ligne. Les messages retenus peuvent être publiés à partir de sessions permanentes. Cette section décrit les principaux aspects de ces fonctionnalités et explique comment elles fonctionnent ensemble.

	Messages retenus	Sessions persistantes
Fonctions principales	Les messages retenus peuvent être utilisés pour configurer ou notifier de grands groupes d’appareils après leur connexion. Les messages retenus peuvent également être utilisés lorsque vous souhaitez que les appareils ne reçoivent que le dernier message publié dans une rubrique après une reconnexion.	Les sessions permanentes sont utiles pour les appareils dotés d’une connectivité intermittente et susceptibles de manquer plusieurs messages importants. Les appareils peuvent se connecter à une session permanente pour recevoir les messages envoyés lorsqu’ils sont hors ligne.
Exemples	Les messages retenus peuvent fournir aux appareils des informations de configuration relatives à leur environnement lorsqu’ils se connectent. La configuration initiale peut inclure une liste d’autres rubriques de message auxquels il doit s’abonner ou des informations sur la façon dont il doit configurer son fuseau horaire local.	Les appareils qui se connectent via un réseau cellulaire à connectivité intermittente peuvent utiliser des sessions permanentes pour éviter de manquer des messages importants envoyés alors qu’un appareil n’est pas couvert par le réseau ou doit éteindre sa radio cellulaire.
Messages reçus lors de l’inscription initiale à une rubrique	Une fois que vous vous êtes abonné à une rubrique contenant un message retenu, le message retenu le plus récent est reçu.	Une fois que vous vous êtes abonné à une rubrique sans qu’un message soit retenu, aucun message n’est reçu tant qu’un message n’est pas publié dans la rubrique.
Rubriques souscrites après reconnexion	En l’absence de session permanente, le client doit s’abonner aux rubriques après s’être reconnecté.	Les rubriques auxquelles vous êtes abonné sont restaurées après la reconnexion.
Messages reçus après la reconnexion	Une fois que vous vous êtes abonné à une rubrique contenant un message retenu, le message retenu le plus récent est reçu.	Tous les messages publiés avec un QOS = 1 et auxquels vous êtes abonné avec un QOS =1 alors que l’appareil était déconnecté sont envoyés après la reconnexion de l’appareil.
Expiration de session/données	Dans MQTT 3, les messages retenus n’expirent pas. Ils sont stockés jusqu’à ce qu’ils soient remplacés ou supprimés. Dans MQTT 5, les messages retenus expirent après l’intervalle d’expiration des messages que vous avez défini. Pour plus d’informations, consultez Expiration de messages.	Les sessions permanentes expirent si le client ne se reconnecte pas dans le délai imparti. Après l’expiration d’une session permanente, les abonnements du client et les messages enregistrés publiés avec un QOS = 1 et auxquels vous avez souscrit avec un QOS =1 alors que l’appareil était déconnecté sont supprimés. Les messages expirés ne seront pas remis. Pour de amples informations sur l’expiration des sessions permanentes, veuillez consulter Sessions permanentes MQTT.

Pour plus d'informations sur les sessions permanentes, consultez Sessions permanentes MQTT.

Avec les messages retenus, le client de publication détermine si un message doit être retenu et remis à un appareil après sa connexion, qu’il ait déjà eu une session ou non. Le choix de stocker un message est fait par le diffuseur de publication et le message stocké est remis à tous les clients actuels et futurs qui s’abonnent avec un abonnement QoS 0 ou QoS 1. Les messages retenus ne contiennent qu’un seul message à la fois sur une rubrique donnée.

Lorsqu’un compte a stocké le nombre maximum de messages retenus, AWS IoT Core renvoie une réponse limitée aux messages publiés avec l’option RETAIN définie et à des charges utiles supérieures à 0 octet jusqu’à ce que certains messages retenus soient supprimés et que le nombre de messages retenus tombe en dessous de la limite.

MQTT a conservé les messages et AWS IoT Device Shadows

Les messages retenus et les Device Shadows retiennent les données d’un appareil, mais ils se comportent différemment et répondent à des objectifs différents. Cette section décrit leurs similitudes et leurs différences.

	Messages retenus	Device Shadows
La charge utile des messages possède une structure ou un schéma prédéfini	Tel que défini par l’implémentation. MQTT ne spécifie pas de structure ou de schéma pour la charge utile de ses messages.	AWS IoT prend en charge une structure de données spécifique.
La mise à jour de la charge utile des messages génère des messages d’événement	La publication d’un message retenu envoie le message aux clients abonnés, mais ne génère pas de messages de mise à jour supplémentaires.	La mise à jour d’un Device Shadow génère des messages de mise à jour décrivant le changement.
Les mises à jour des messages sont numérotées	Les messages retenus ne sont pas numérotés automatiquement.	Les documents Device Shadow sont dotés de numéros de version et d’horodatage automatiques.
La charge utile du message est attachée à une ressource d’objet	Les messages retenus ne sont pas attachés à une ressource d’objet.	Les Device Shadows sont attachés à une ressource d’objets.
Mise à jour des éléments individuels de la charge utile du message	Les éléments individuels du message ne peuvent pas être modifiés sans mettre à jour l’intégralité de la charge utile du message.	Les éléments individuels d’un document Device Shadow peuvent être mis à jour sans qu’il soit nécessaire de mettre à jour l’intégralité du document Device Shadow.
Le client reçoit les données des messages lors de l’abonnement	Le client reçoit automatiquement un message retenu après s’être abonné à une rubrique contenant un message retenu.	Les clients peuvent s’abonner aux mises à jour de Device Shadow, mais ils doivent demander délibérément l’état actuel.
Indexation et consultabilité	Les messages retenus ne sont pas indexés pour la recherche.	L’indexation de flotte indexe les données Device Shadow à des fins de recherche et d’agrégation.

Messages MQTT Last Will and Testament (LWT)

Last Will and Testament (LWT) est une fonctionnalité de MQTT. Grâce LWT, les clients peuvent spécifier un message que l’agent publiera sur un rubrique défini par le client et enverra à tous les clients abonnés au rubrique en cas de déconnexion non initiée. Le message spécifié par les clients est appelé message LWT ou message Will, et la rubrique définie par les clients est appelé rubrique Will. Vous pouvez spécifier un message LWT lorsqu’un appareil se connecte à l’agent. Ces messages peuvent être retenus en plaçant l’indicateur Will Retain dans le champ Connect Flag bits pendant la connexion. Par exemple, si l’indicateur Will Retain est défini sur 1, un message Will sera stocké dans l’agent dans le rubrique Will associée. Pour plus d’informations, consultez Messages volontaires.

L’agent retiendra les messages Will jusqu’à ce qu’une déconnexion non initiée se produise. Lorsque cela se produit, le courtier publiera les messages à tous les clients abonnés à la rubrique Will pour notifier la déconnexion. Si le client se déconnecte de l’agent avec une déconnexion initiée par le client à l’aide du message MQTT DISCONNECT, l’agent ne publiera pas les messages LWT enregistrés. Dans tous les autres cas, les messages LWT seront envoyés. Pour une liste complète des scénarios de déconnexion dans lesquels l’agent enverra les messages LWT, consultez la section Événements de connexion/déconnexion.

Utilisation de ConnectAttributes

ConnectAttributes vous permettent de spécifier les attributs que vous souhaitez utiliser dans votre message de connexion dans vos politiques IAM telles que PersistentConnect et LastWill. Grâce à ConnectAttributes, vous pouvez ainsi créer des politiques qui n’autorisent pas les appareils à accéder aux nouvelles fonctionnalités par défaut, ce qui peut être utile si un appareil est compromis.

connectAttributes prend en charge les fonctions suivantes :

PersistentConnect: Utilisez la fonctionnalité PersistentConnect pour enregistrer tous les abonnements effectués par le client pendant la connexion lorsque la connexion entre le client et le courtier est interrompue.
LastWill: Utilisez la fonctionnalité LastWill pour publier un message LastWillTopic lorsqu’un client se déconnecte de manière inattendue.

Par défaut, votre politique prévoit une connexion non permanente et aucun attribut n’est transmis pour cette connexion. Vous devez spécifier une connexion permanente dans votre politique IAM si vous souhaitez en avoir une.

Pour des exemples ConnectAttributes, consultez la section Exemples de politiques de connexion.

Fonctionnalités prises en charge par MQTT 5

AWS IoT Core le support de MQTT 5 est basé sur la spécification MQTT v5.0 avec quelques différences, comme indiqué dans. AWS IoT différences par rapport aux spécifications MQTT

AWS IoT Core prend en charge les fonctionnalités MQTT 5 suivantes :

Abonnements partagés
Démarrage correct et expiration de session
Code de motif sur tous les ACK
Alias de rubrique
Expiration du message
Autres fonctionnalités de MQTT 5

Abonnements partagés

AWS IoT Core prend en charge les abonnements partagés pour MQTT 3 et MQTT 5. Les abonnements partagés permettent à plusieurs clients de partager un abonnement à une rubrique et un seul client recevra les messages publiés sur cette rubrique selon une distribution aléatoire. Les abonnements partagés peuvent équilibrer efficacement la charge des messages MQTT entre un certain nombre d’abonnés. Supposons, par exemple, que 1000 appareils publient sur le même rubrique et que 10 applications principales traitent ces messages. Dans ce cas, les applications principales peuvent s’abonner à la même rubrique et chacune recevra aléatoirement des messages publiés par les appareils sur le rubrique partagé. Cela revient à « partager » efficacement la charge de ces messages. Les abonnements partagés permettent également une meilleure résilience. Lorsqu’une application principale se déconnecte, l’agent répartit la charge entre les abonnés restants du groupe.

Pour utiliser les abonnements partagés, les clients s’abonnent au filtre de rubrique d’un abonnement partagé comme suit :


$share/{ShareName}/{TopicFilter}

$share est une chaîne littérale indiquant le filtre de rubrique d’un abonnement partagé, qui doit commencer par $share.
{ShareName} est une chaîne de caractères qui indique le nom partagé utilisé par un groupe d’abonnés. Le filtre de rubrique d’un abonnement partagé doit contenir un ShareName et être suivi du caractère /. Le {ShareName} ne doit pas inclure les caractères suivants : /, +, ou#. La taille maximale de {ShareName} est de 128 octets.
{TopicFilter} suit la même syntaxe de filtre de rubrique qu’un abonnement non partagé. La taille maximale de {TopicFilter} est de 256 octets.
Les deux barres obliques requises (/) car les $share/{ShareName}/{TopicFilter} ne sont pas incluses dans le nombre maximum de barres obliques dans la rubrique et dans la limite du filtre de rubrique.

Les abonnements identiques {ShareName}/{TopicFilter} appartiennent au même groupe d’abonnements partagés. Vous pouvez créer plusieurs groupes d’abonnements partagés et ne pas dépasser la limite d’abonnements partagés par groupe. Pour plus d’informations, veuillez consulter la rubrique Points de terminaison et quotas AWS IoT Core depuis la Référence générale AWS .

Les tableaux suivants comparent les abonnements non partagés et les abonnements partagés :

Abonnement	Description	Exemples de filtres de rubrique
Abonnements non partagés	Chaque client crée un abonnement distinct pour recevoir les messages publiés. Lorsqu’un message est publié dans une rubrique, tous les abonnés à ce rubrique reçoivent une copie du message.	`sports/tennis sports/#`
Abonnements partagés	Plusieurs clients peuvent partager un abonnement à un rubrique et un seul client recevra les messages publiés sur ce rubrique de manière aléatoire.	`$share/consumer/sports/tennis $share/consumer/sports/#`

Flux d’abonnements non partagés	Flux d’abonnements partagés

Remarques importantes concernant l’utilisation des abonnements partagés

Lorsqu’une tentative de publication auprès d’un abonné QoS0 échoue, aucune nouvelle tentative n’a lieu et le message est supprimé.
Lorsqu’une tentative de publication à destination d’un abonné QoS1 avec une session propre échoue, le message est envoyé à un autre abonné du groupe pour plusieurs tentatives de nouvelle tentative. Les messages qui ne parviennent pas à être remis après toutes les tentatives seront supprimés.
Lorsqu’une tentative de publication auprès d’un abonné QoS1 avec des sessions permanentes échoue parce que l’abonné est hors ligne, les messages ne sont pas mis en file d’attente et sont envoyés à un autre abonné du groupe. Les messages qui ne parviennent pas à être remis après toutes les tentatives seront supprimés.
Les abonnements partagés ne reçoivent pas de messages retenus.
Lorsque les abonnements partagés contiennent des caractères génériques (# ou +), plusieurs abonnements partagés peuvent correspondre à un rubrique. Dans ce cas, l’agent de messages copie le message de publication et l’envoie à un client aléatoire dans chaque abonnement partagé correspondant. Le comportement des caractères génériques des abonnements partagés peut être expliqué dans le schéma suivant.

Dans cet exemple, trois abonnements partagés correspondent à la rubrique MQTT de publication sports/tennis. L’agent de messages copie le message publié et l’envoie à un client aléatoire dans chaque groupe correspondant.

Le client 1 et le client 2 partagent l’abonnement : $share/consumer1/sports/tennis

Le client 3 et le client 4 partagent l’abonnement : $share/consumer1/sports/#

Le client 5 et le client 6 partagent l’abonnement : $share/consumer2/sports/tennis

Pour plus d’informations sur les limites des abonnements partagés, consultez la section AWS IoT Core Points de terminaison et quotas de la AWS référence générale. Pour tester les abonnements partagés à l'aide du client AWS IoT MQTT dans la AWS IoT console, consultezTest des abonnements partagés dans le client MQTT. Pour plus d’informations sur les abonnements partagés, consultez la section Abonnements partagés de la spécification MQTTV5.0.

Démarrage correct et expiration de session

Vous pouvez utiliser Clean Start et Session Expiration pour gérer vos sessions permanentes avec plus de flexibilité. Un indicateur Clean Start indique si la session doit démarrer sans utiliser une session existante. Un intervalle d’expiration de session indique la durée pendant laquelle la session doit être retenue après une déconnexion. L’intervalle d’expiration des sessions peut être modifié lors de la déconnexion. Pour plus d’informations, consultez Sessions permanentes MQTT.

Code de motif sur tous les ACK

Vous pouvez déboguer ou traiter les messages d’erreur plus facilement à l’aide des codes de motif. Les codes de motif sont renvoyés par l’agent de messages en fonction du type d’interaction avec l’agent (s’abonner, publier, accuser réception). Pour plus d’informations, consultez Codes de motif MQTT. Pour une liste complète des codes de motif MQTT, consultez la spécification MQTT v5.

Alias de rubrique

Vous pouvez remplacer le nom d’une rubrique par un alias de rubrique, qui est un entier de deux octets. L'utilisation d'alias de rubrique permet d'optimiser la transmission des noms de rubriques afin de réduire potentiellement les coûts de données sur les services de données mesurés. AWS IoT Core a une limite par défaut de 8 alias de rubrique. Pour plus d’informations, veuillez consulter la rubrique Points de terminaison et quotas AWS IoT Core depuis la Référence générale AWS .

Expiration du message

Vous pouvez ajouter des valeurs d’expiration aux messages publiés. Ces valeurs représentent l’intervalle d’expiration des messages en secondes. Si un message n’a pas été envoyé aux abonnés dans cet intervalle, il expirera et sera supprimé. Si vous ne définissez pas la valeur d’expiration du message, celui-ci n’expirera pas.

À l’aller, l’abonné recevra un message indiquant le temps restant dans l’intervalle d’expiration. Par exemple, si un message de publication entrant expire 30 secondes et qu’il est acheminé vers l’abonné au bout de 20 secondes, le champ d’expiration du message sera mis à jour à 10. Il est possible que le message reçu par l’abonné ait un MEI mis à jour de 0. En effet, dès que le temps restant est inférieur ou égal à 999 ms, il sera mis à jour à 0.

Dans AWS IoT Core, l'intervalle d'expiration minimal des messages est de 1. Si l’intervalle est défini sur 0 du côté client, il sera ajusté à 1. L’intervalle d’expiration maximal des messages est de 604 800 (7 jours). Toute valeur supérieure à cette valeur sera ajustée à la valeur maximale.

Dans la communication entre versions, le comportement d’expiration du message est déterminé par la version MQTT du message de publication entrant. Par exemple, un message d’expiration envoyé par une session connectée via MQTT5 peut expirer pour les appareils abonnés à des sessions MQTT3. Le tableau ci-dessous indique comment l’expiration des messages prend en charge les types de messages de publication suivants :

Publier un type de message	Intervalle d’expiration des messages
Publier régulièrement	Si un serveur ne parvient pas à délivrer le message dans le délai spécifié, le message expiré sera supprimé et l’abonné ne le recevra pas. Cela inclut les situations telles que lorsqu’un appareil ne publie pas ses messages QoS 1.
Conserver	Si un message retenu expire et qu’un nouveau client s’abonne à la rubrique, le client ne recevra pas le message lors de son inscription.
Dernier testament	L’intervalle entre les derniers messages testamentaires commence une fois que le client se déconnecte et que le serveur tente de transmettre le dernier testament à ses abonnés.
Messages mis en file d’attente	Si un QoS1 sortant avec intervalle d’expiration des messages expire lorsqu’un client est hors ligne, le client ne recevra pas le message expiré après la reprise de la session permanente.

Autres fonctionnalités de MQTT 5

Déconnexion du serveur

Lorsqu’une déconnexion se produit, le serveur peut envoyer au client de manière proactive un message DISCONNECT pour notifier la fermeture de la connexion avec un code de motif de déconnexion.

Requête/réponse

Les éditeurs peuvent demander qu’une réponse soit envoyée par le destinataire à un rubrique spécifié par le diffuseur de publication lors de la réception.

Taille maximale du paquet

Le client et le serveur peuvent spécifier indépendamment la taille de paquet maximale qu’ils prennent en charge.

Format de charge utile et type de contenu

Vous pouvez spécifier le format de charge utile (binaire, texte) et le type de contenu lorsqu’un message est publié. Ils sont transmis au destinataire du message.

Propriétés MQTT 5

Les propriétés MQTT 5 sont des ajouts importants à la norme MQTT pour prendre en charge les nouvelles fonctionnalités de MQTT 5 telles que l’expiration de session et le modèle de requête/réponse. Dans AWS IoT Core, vous pouvez créer des règles qui peuvent transférer les propriétés des messages sortants ou utiliser HTTP Publish pour publier des messages MQTT avec certaines des nouvelles propriétés.

Le tableau suivant répertorie toutes les propriétés MQTT 5 prises AWS IoT Core en charge.

Propriété	Description	Type d’entrée	Paquets
Indicateur de format de charge utile	Valeur booléenne indiquant si la charge utile est formatée en UTF-8.	Octet	PUBLIER, CONNECTER
Type de contenu	Chaîne UTF-8 qui décrit le contenu de la charge utile.	Chaîne UTF-8	PUBLIER, CONNECTER
Rubrique de réponse	Chaîne UTF-8 qui décrit la rubrique dans laquelle le récepteur doit effectuer la publication dans le cadre du flux demande-réponse. La rubrique ne doit pas avoir de caractères génériques.	Chaîne UTF-8	PUBLIER, CONNECTER
Données de corrélation	Données binaires utilisées par l’expéditeur du message de demande pour identifier la demande à laquelle correspond le message de réponse.	Binaire	PUBLIER, CONNECTER
Propriétés de l’utilisateur	Une paire de chaînes UTF-8. Cette propriété peut apparaître plusieurs fois dans un même paquet. Les destinataires recevront les paires clé-valeur dans l’ordre dans lequel elles sont envoyées.	Paire de chaînes UTF-8	CONNECTER, PUBLIER, Will Properties, S’ABONNER, SE DÉCONNECTER, SE DÉSABONNER
Intervalle d’expiration des messages	Entier de 4 octets qui représente l’intervalle d’expiration des messages en secondes. S’il est absent, le message n’expire jamais.	Entier de 4 octets	PUBLIER, CONNECTER
Intervalle d’expiration des sessions	Un entier de 4 octets qui représente l'intervalle d'expiration de la session en secondes. AWS IoT Core prend en charge un maximum de 7 jours, avec un maximum d'une heure par défaut. Si la valeur que vous avez définie dépasse le maximum de votre compte, la valeur ajustée AWS IoT Core sera renvoyée dans le CONNACK.	Entier de 4 octets	CONNECTER, CONNECTER, DÉCONNECTER
Identifiant client attribué	Un identifiant client aléatoire généré AWS IoT Core lorsqu'aucun identifiant client n'est spécifié par les appareils. L’identifiant client aléatoire doit être un nouvel identifiant client qui n’est utilisé par aucune autre session actuellement gérée par le courtier.	Chaîne UTF-8	CONNACK
Serveur Keep Alive	Un entier de 2 octets qui représente la durée de rétention attribuée par le serveur. Le serveur déconnecte le client s’il est inactif pendant une durée supérieure à la durée de conservation.	Entier de 2 octets	CONNACK
Demander des informations sur le problème	Valeur booléenne qui indique si la chaîne de motif ou les propriétés utilisateur sont envoyées en cas d’échec.	Octet	CONNECT
Recevoir maximum	Un entier de 2 octets qui représente le nombre maximum de paquets PUBLISH QOS > 0 qui peuvent être envoyés sans recevoir de PUBACK.	Entier de 2 octets	CONNECTER, CONNECTER
Alias maximal du rubrique	Cette valeur indique la valeur la plus élevée qui sera acceptée comme alias de rubrique. La valeur par défaut est 0.	Entier de 2 octets	CONNECTER, CONNECTER
QoS maximale	La valeur maximale de QoS prise en charge. AWS IoT Core La valeur par défaut est 1. AWS IoT Core ne prend pas en charge QoS2.	Octet	CONNACK
Retenir disponible	Valeur booléenne qui indique si le courtier de AWS IoT Core messages prend en charge les messages conservés. La valeur par défaut est 1.	Octet	CONNACK
Taille maximale du paquet	Taille maximale des paquets qui AWS IoT Core acceptent et envoient. Ne peut pas dépasser 128 Ko.	Entier de 4 octets	CONNECTER, CONNECTER
Abonnement Wildcard disponible	Valeur booléenne qui indique si le courtier de AWS IoT Core messages prend en charge Wildcard Subscription Available. La valeur par défaut est 1.	Octet	CONNACK
Identifiant d’abonnement disponible	Valeur booléenne qui indique si le courtier de AWS IoT Core messages prend en charge l'identifiant d'abonnement disponible. La valeur par défaut est 0.	Octet	CONNACK

Codes de motif MQTT

MQTT 5 introduit un meilleur signalement des erreurs avec les réponses au code de raison. AWS IoT Core peut renvoyer des codes de motif, y compris, mais sans s'y limiter, les suivants regroupés par paquets. Pour une liste complète des codes de motif pris en charge par MQTT 5, consultez les spécifications du MQTT 5.

Codes de motif CONNACK
Valeur	Hex	Nom du code de motif	Description
0	0x00	Réussite	La connexion est acceptée.
128	0x80	Erreur non spécifiée	Le serveur ne souhaite pas révéler le motif de l’échec, sinon aucun des autres codes de motif ne s’applique.
133	0x85	Identifiant du client non valide	L’identifiant du client est une chaîne valide mais n’est pas autorisé par le serveur.
134	0x86	Nom d’utilisateur ou mot de passe incorrect	Le serveur n’accepte pas le nom d’utilisateur ou le mot de passe spécifiés par le client.
135	0x87	Non autorisé	Le client n’est pas autorisé à se connecter.
144	0x90	Nom de la rubrique non valide	Le nom de la rubrique testamentaire est correctement formé mais n’est pas accepté par le serveur.
151	0x97	Quota dépassé	Une limite de mise en œuvre ou imposée par l’administration a été dépassée.
155	0 x 9 B	QoS n’est pas pris en charge.	Le serveur ne prend pas en charge la QoS définie dans Will QoS.

Codes de motif PUBACK
Valeur	Hex	Nom du code de motif	Description
0	0x00	Réussite	Le message est accepté. La publication du message QoS 1 se poursuit.
128	0x80	Erreur non spécifiée	Le destinataire n’accepte pas la publication, mais soit ne souhaite pas en révéler la raison, soit elle ne correspond pas à l’une des autres valeurs.
135	0x87	Non autorisé	Le PUBLISH n’est pas autorisé.
144	0x90	Nom de la rubrique non valide	Le nom de la rubrique n’est pas mal formé, mais il n’est pas accepté par le client ou le serveur.
145	0x91	Identifiant de paquet en cours d’utilisation	L’identifiant du paquet est déjà utilisé. Cela peut indiquer une incompatibilité de l’état de session entre le client et le serveur.
151	0x97	Quota dépassé	Une limite de mise en œuvre ou imposée par l’administration a été dépassée.

Code de motif de déconnexion
Valeur	Hex	Nom du code de motif	Description
129	0x81	Paquet incorrect	Le paquet reçu n’est pas conforme à cette spécification.
130	0x82	Erreur de protocole	Un paquet inattendu ou en panne a été reçu.
135	0x87	Non autorisé	La demande n'est pas autorisée.
139	0 x 8 B	Arrêt du serveur	Le serveur est en train de s’arrêter.
141	0 x 8D	Délai d’expiration de Keep Alive	La connexion est fermée car aucun paquet n’a été reçu pendant 1,5 fois la durée de Keep Alive.
142	0 x 8E	Session prise en charge	Une autre connexion utilisant le même ClientID s’est connectée, ce qui a entraîné la fermeture de cette connexion.
143	0 x 8 F	Filtre de rubrique invalide	Le filtre de rubrique est correctement formé mais n’est pas accepté par le serveur.
144	0x90	Nom de la rubrique non valide	Le nom de la rubrique est correctement formé mais n’est pas accepté par ce client ou serveur.
147	0x93	Dépassement du maximum de réception	Le client ou le serveur a reçu une publication supérieure à la valeur maximale de réception pour laquelle il n’a pas envoyé de PUBACK ou de PUBCOMP.
148	0x94	Alias de rubrique invalide	Le client ou le serveur a reçu un paquet PUBLISH contenant un alias de rubrique supérieur à l’alias de rubrique maximal qu’il a envoyé dans le paquet CONNECT ou CONNACK.
151	0x97	Quota dépassé	Une limite de mise en œuvre ou imposée par l’administration a été dépassée.
152	0x98	Action administrative	La connexion est interrompue suite à une action administrative.
155	0 x 9 B	QoS n’est pas pris en charge.	Le client a spécifié une QoS supérieure à la QoS spécifiée dans une QoS maximale dans le CONNACK.
161	0 x A1	Identifiants d’abonnement non pris en charge	Le serveur ne prend pas en charge les identifiants d’abonnement ; l’abonnement n’est pas accepté.

Codes de motif SUBACK
Valeur	Hex	Nom du code de motif	Description
0	0x00	QoS 0 accordé	L’abonnement est accepté et la QoS maximale envoyée sera de QoS 0. Il s’agit peut-être d’une QoS inférieure à celle demandée.
1	0x01	QoS 1 accordé	L’abonnement est accepté et la QoS maximale envoyée sera de QoS 1. Il s’agit peut-être d’une QoS inférieure à celle demandée.
128	0x80	Erreur non spécifiée	L’abonnement n’est pas accepté et le serveur ne souhaite pas en révéler le motif ou aucun des autres codes de motif ne s’applique.
135	0x87	Non autorisé	Le client n’est pas autorisé à souscrire cet abonnement.
143	0 x 8 F	Filtre de rubrique invalide	Le filtre de rubrique est correctement formé mais n’est pas autorisé pour ce client.
145	0x91	Identifiant de paquet en cours d’utilisation	L’identifiant de paquet spécifié est déjà utilisé.
151	0x97	Quota dépassé	Une limite de mise en œuvre ou imposée par l’administration a été dépassée.

Codes de motif UNSUBACK
Valeur	Hex	Nom du code de motif	Description
0	0x00	Réussite	L'abonnement est supprimé.
128	0x80	Erreur non spécifiée	Le désabonnement n’a pas pu être effectué et le serveur ne souhaite pas en révéler le motif ou aucun des autres codes de motif ne s’applique.
143	0 x 8 F	Filtre de rubrique invalide	Le filtre de rubrique est correctement formé mais n’est pas autorisé pour ce client.
145	0x91	Identifiant de paquet en cours d’utilisation	L’identifiant de paquet spécifié est déjà utilisé.

AWS IoT différences par rapport aux spécifications MQTT

L’implémentation de l’agent de messages est basée sur les spécifications MQTT v3.1.1 et MQTT v5.0, mais elle diffère des spécifications de la manière suivante :

AWS IoT ne prend pas en charge les paquets suivants pour MQTT 3 : PUBREC, PUBREL et PUBCOMP.
AWS IoT ne prend pas en charge les paquets suivants pour MQTT 5 : PUBREC, PUBREL, PUBCOMP et AUTH.
AWS IoT ne prend pas en charge la redirection du serveur MQTT 5.
AWS IoT prend en charge les niveaux de qualité de service (QoS) MQTT 0 et 1 uniquement. AWS IoT ne prend pas en charge la publication ou l'abonnement avec QoS de niveau 2. Lorsque QoS 2 est requis, l’agent de messages , n’envoie pas de PUBACK ou de SUBACK.
En effet AWS IoT, l'abonnement à une rubrique dont le niveau de QoS est 0 signifie qu'un message est délivré zéro fois ou plus. Un message peut être remis plusieurs fois. Les messages remis plusieurs fois peuvent être envoyés avec un ID de paquet différent. Dans ce cas, l'indicateur DUP n'est pas défini.
Lorsqu'il répond à une demande de connexion, l'agent de messages envoie un message CONNACK. Ce message contient un indicateur précisant si la connexion reprend une session précédente.
Avant d’envoyer des paquets de contrôle supplémentaires ou une demande de déconnexion, le client doit attendre que le message CONNACK soit reçu sur son appareil par l’agent de messages AWS IoT .
Lorsqu'un client s'abonne à une rubrique, il peut y avoir un délai entre le moment où l'agent de messages envoie un SUBACK et le moment où le client commence à recevoir de nouveaux messages correspondants.
Lorsqu’un client utilise le caractère générique # dans le filtre de rubrique pour s’abonner à une rubrique, toutes les chaînes situées à son niveau ou inférieur dans la hiérarchie des rubriques sont mises en correspondance. Cependant, la rubrique parent ne correspond pas. Par exemple, un abonnement à la rubrique sensor/# reçoit les messages publiés dans les rubriques sensor/, sensor/temperature, sensor/temperature/room1, mais pas les messages publiés dans sensor. Pour plus d’informations sur les caractères génériques, consultez Filtres de rubrique.
L'agent de messages utilise l'ID de client pour identifier chaque client. L'ID de client est transmis depuis le client à l'agent de messages dans le cadre de la charge utile MQTT. Deux clients possédant le même ID de client ne peuvent pas être connectés simultanément à l’agent de messages. Lorsqu'un client se connecte à l'agent de messages à l'aide d'un ID de client qu'un autre client utilise, la nouvelle connexion client est acceptée et le client connecté précédemment est déconnecté.
À de rares occasions, l'agent de messages peut renvoyer le même message PUBLISH logique avec un ID de paquet différent.
L’abonnement aux filtres de rubrique contenant un caractère générique ne permet pas de recevoir les messages retenus. Pour recevoir un message retenu, la demande d’abonnement doit contenir un filtre de rubrique correspondant exactement à la rubrique du message retenu.
L’agent de messages ne garantit pas l’ordre dans lequel les messages et les ACK sont reçus.
AWS IoT peut avoir des limites différentes des spécifications. Pour plus d’informations veuillez consulter AWS IoT Core Limites et quotas de l’agent de messages et des protocoles dans le AWS IoT Guide de référence.
L'indicateur MQTT DUP n'est pas pris en charge.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Protocoles de communication des appareils

HTTPS

MQTT

Dans cette rubrique :

Connexion à MQTT à l'aide des SDK du AWS IoT périphérique

Note

Note

Important

Options de qualité de service (QoS) MQTT

Sessions permanentes MQTT

Création d’une session permanente

Note

Opérations au cours d’une session permanente

Trafic de messages après reconnexion à une session permanente

Fin d’une session permanente

Note

Reconnexion après expiration d’une session permanente

Frais liés aux messages de session persistants

MQTT a retenu les messages

Exemples d’utilisation de messages retenus au format MQTT

En tant que message de configuration initiale

En tant que dernier message d’état connu

Dans cette section :

Tâches courantes avec des messages retenus au format MQTT dans AWS IoT Core

Création d’un message retenu

Abonnement à un sujet de message retenu

Récupération d’un message retenu

Répertorier les sujets des messages retenus

Obtenir les détails des messages retenus

Retenir un message volontaire

Supprimer un message retenu

Débogage et résolution des problèmes liés aux messages retenus

La page des messages retenus

Le client de test MQTT

Limit es de messages retenues

Ordre de distribution des messages retenus

Facturation et messages retenus

Comparaison des messages MQTT retenus et des sessions permanentes MQTT

MQTT a conservé les messages et AWS IoT Device Shadows

Messages MQTT Last Will and Testament (LWT)

Utilisation de ConnectAttributes

Fonctionnalités prises en charge par MQTT 5

AWS IoT Core prend en charge les fonctionnalités MQTT 5 suivantes :

Abonnements partagés

Démarrage correct et expiration de session

Code de motif sur tous les ACK

Alias de rubrique

Expiration du message

Autres fonctionnalités de MQTT 5

Propriétés MQTT 5

Codes de motif MQTT

AWS IoT différences par rapport aux spécifications MQTT