Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Utilisation des shadows dans les applications et les services
Cette section décrit la manière dont une application ou un service interagit avec le service AWS IoT Device Shadow. Cet exemple suppose que l'application ou le service interagit uniquement avec le shadow et, via le shadow, avec l'appareil. Cet exemple n'inclut aucune action de gestion, telle que la création ou la suppression de shadows.
Cet exemple utilise l'API REST du service AWS IoT Device Shadow pour interagir avec les ombres. Contrairement à l'exemple utilisé dansUtilisation des shadows sur les appareils, qui utilise un modèle de publish/subscribe communication, cet exemple utilise le modèle de request/response communication de l'API REST. Cela signifie que l'application ou le service doit faire une demande avant de pouvoir recevoir une réponse de AWS IoT. Un inconvénient de ce modèle, toutefois, est qu'il ne prend pas en charge les notifications. Si votre application ou service nécessite des notifications rapides concernant les changements d'état de l'appareil, pensez aux protocoles MQTT ou MQTT over WSS, qui prennent en charge le modèle de publish/subscribe communication, comme décrit dans. Utilisation des shadows sur les appareils
Important
Assurez-vous que l'utilisation des shadows par votre application ou service est cohérente et prise en charge par les implémentations correspondantes sur vos appareils. Prenez en compte, par exemple, la façon dont les shadows sont créés, mis à jour et supprimés, et la manière dont les mises à jour sont gérées sur l'appareil et dans les applications ou services qui accèdent au shadow. Votre conception doit indiquer clairement comment l'état de l'appareil est mis à jour et rapporté, et comment vos applications et services interagissent avec l'appareil et ses shadows.
L'URL de l'API REST pour un shadow nommé est :
https://endpoint/things/thingName/shadow?name=shadowName
et pour un shadow non nommé :
https://endpoint/things/thingName/shadow
où :
- point de terminaison
-
Point de terminaison renvoyé par la commande CLI :
aws iot describe-endpoint --endpoint-type IOT:Data-ATS - thingName
-
Nom de l'objet d'objet auquel le shadow appartient
- shadowName
-
Nom du shadow nommé. Ce paramètre n'est pas utilisé avec des shadows non nommés.
Initialisation de l'application ou du service lors de la connexion à AWS IoT
Lorsque l'application se connecte pour la première fois AWS IoT, elle doit envoyer une requête HTTP GET aux URL des ombres qu'elle utilise pour obtenir l'état actuel des ombres qu'elle utilise. Cela lui permet de synchroniser l'application ou le service avec le shadow.
L'état du traitement change lorsque l'application ou le service est connecté à AWS IoT
Lorsque l'application ou le service est connecté AWS IoT, il peut interroger périodiquement l'état actuel en envoyant une requête HTTP GET sur les URL des ombres qu'il utilise.
Lorsqu'un utilisateur final interagit avec l'application ou le service pour modifier l'état de l'appareil, l'application ou le service peuvent envoyer une demande HTTP POST aux URL des shadows qu'ils utilisent pour mettre à jour l'état desired du shadow. Cette demande renvoie la modification qui a été acceptée, mais vous devrez peut-être interroger le shadow en effectuant des demandes HTTP GET jusqu'à ce que l'appareil ait mis à jour le shadow avec son nouvel état.
Détecter si un appareil est connecté
Pour déterminer si un appareil est actuellement connecté, incluez une propriété connected dans le document shadow et utilisez un message MQTT Last Will and Testament (LWT) pour définir la propriété connected sur false si un appareil est déconnecté en raison d'une erreur.
Note
Les messages MQTT LWT envoyés à des sujets AWS IoT réservés (sujets commençant par $) sont ignorés par le service AWS IoT Device Shadow. Cependant, ils sont traités par les clients abonnés et par le moteur de AWS IoT règles. Vous devrez donc créer un message LWT envoyé à une rubrique non réservée et une règle republiant le message MQTT LWT en tant que message de mise à jour fictif vers la rubrique de mise à jour réservée de l'ombre. ShadowTopicPrefix/update
Pour envoyer un message LWT au service Device Shadow
-
Créez une règle qui republie le message MQTT LWT sur la rubrique réservée. L'exemple suivant est une règle à l'écoute d'un message sur la
my/things/myLightBulb/updaterubrique et qui le republie dans$aws/things/myLightBulb/shadow/update.{ "rule": { "ruleDisabled": false, "sql": "SELECT * FROM 'my/things/myLightBulb/update'", "description": "Turn my/things/ into $aws/things/", "actions": [ { "republish": { "topic": "$$aws/things/myLightBulb/shadow/update", "roleArn": "arn:aws:iam:123456789012:role/aws_iot_republish" } } ] } } -
Lorsque l'appareil se connecte AWS IoT, il enregistre un message LWT dans une rubrique non réservée pour que la règle de republication le reconnaisse. Dans cet exemple, cette rubrique est
my/things/myLightBulb/updateet elle définit la propriété connectée surfalse.{ "state": { "reported": { "connected":"false" } } } -
Après la connexion, l'appareil publie un message sur sa rubrique de mise à jour de shadow,
$aws/things/myLightBulb/shadow/update, pour rapporter son état actuel, ce qui inclut la définition de sa propriétéconnectedsurtrue.{ "state": { "reported": { "connected":"true" } } } -
Avant que l'appareil ne se déconnecte gracieusement, il publie un message sur sa rubrique de mise à jour de shadow,
$aws/things/myLightBulb/shadow/update, pour rapporter son état le plus récent, ce qui inclut la définition de sa propriétéconnectedsurfalse.{ "state": { "reported": { "connected":"false" } } } -
Si l'appareil se déconnecte en raison d'une erreur, le gestionnaire de AWS IoT messages publie le message LWT de l'appareil pour le compte de l'appareil. La règle de republication détecte ce message et publie le message de mise à jour de shadow pour mettre à jour la propriété
connecteddu shadow de l'appareil.
Note
En raison de la nature asynchrone du traitement des déconnexions, il n'est pas garanti que les messages LWT soient envoyés dans l'ordre lors de la reconnexion. Nous vous recommandons d'utiliser les événements du cycle de vie pour améliorer la précision de la détection de l'état de connectivité, car ces événements fournissent des attributs permettant de gérer les événements hors service.