Modifier

Share via


Commandes application-à-appareil IoT

Azure IoT Hub

Les applications utilisent deux mécanismes principaux pour envoyer des commandes aux appareils IoT, une messagerie cloud-à-appareil et des méthodes directes.

  • Les applications envoient des messages cloud-à-appareil à des files d’attente de messages spécifiques de l’appareil sur la plateforme IoT pour que les appareils puissent les lire quand ils sont connectés. Les appareils décident quand lire les messages.

  • Les applications appellent des méthodes directes directement sur les appareils connectés, en utilisant un modèle requête-réponse sur des points de terminaison d’appareil IoT dédiés.

Cet article décrit des caractéristiques de messagerie cloud-à-appareil et des méthodes directes. L’article explique également comment utiliser des méthodes directes avec des passerelles de protocole et des appareils en attente connectés.

Messages de cloud-à-appareil

Les applications envoient des messages de commande cloud-à-appareil pour des appareils spécifiques à Azure IoT Hub, qui stocke les messages dans des files d’attente spécifiques de l’appareil. Le service IoT Hub remet les messages aux files d’attente spécifiques de l’appareil, que les appareils soient connectés ou non.

Diagramme montrant comment le service IoT Hub stocke des messages dans une file d’attente de messages interne pour chaque appareil, et les appareils qui interrogent ces messages.

Les considérations suivantes s’appliquent lors de l’utilisation d’une messagerie cloud-à-appareil :

  • Les files d’attente de messages agissent efficacement en tant que boîtes aux lettres pour des appareils, et les appareils sont responsables de l’interrogation de leurs files d’attente de messages à la recherche de nouveaux messages quand ils sont connectés.
  • Les appareils reçoivent des messages en mode premier entré, premier sorti, ce qui rend la messagerie cloud-à-appareil idéale pour la lecture et l’action sur les messages de façon séquentielle.
  • Les messages ont une expiration configurable, de sorte que les messages non lus peuvent finalement être supprimés de la file d’attente des messages de l’appareil.
  • Pour les communications avec état, les applications peuvent utiliser un récepteur de commentaires pour surveiller la remise et l’accusé de réception des messages. L’application peut utiliser un récepteur de commentaires unique pour surveiller toutes les files d’attente de messages pour tous les appareils.

Méthodes directes

Les applications appellent directement des méthodes directes sur des appareils IoT connectés, et s’attendent à ce que les appareils exécutent les méthodes et les inscrivent auprès du service IoT Hub. Le service IoT Hub appelle les méthodes directes sur des appareils connectés via des canaux directs, et les appareils sont responsables de l’exécution des fonctions et du retour de résultats immédiats.

Diagramme montrant comment le service IoT Hub appelle du code directement sur un appareil individuel à l’aide de méthodes directes.

Les considérations suivantes s’appliquent lors de l’utilisation de méthodes directes :

  • Les méthodes directes échouent si la connexion est interrompue entre le service IoT Hub et l’appareil avant la fin de l’exécution de la méthode. Les applications peuvent intercepter et gérer les échecs des commandes de nouvelle tentative.
  • Étant donné qu’il n’y a pas de file d’attente, les applications qui requièrent un séquencement de méthodes directes doivent gérer le séquencement des appels de méthode, de sorte que l’exécution d’une méthode appelle la méthode suivante.
  • L’appel de méthodes directes permet à une application de définir deux délais d’expiration. Un délai d’expiration spécifie la durée pendant laquelle le service IoT Hub doit attendre qu’un appareil se connecte avant d’abandonner, et l’autre délai d’expiration spécifie la durée pendant laquelle l’appelant doit attendre la fin de l’exécution de la méthode et répondre avant d’abandonner.

Méthodes directes avec passerelles de protocole

Les applications IoT qui utilisent des passerelles de protocole peuvent tirer parti de l’application de la connectivité et du modèle de requête-réponse des méthodes directes. Les passerelles de cloud ou de protocole permettent de connecter des appareils préexistants et divers au service IoT Hub en agissant pour le compte des appareils afin de répartir des communications de protocole personnalisées. Les passerelles de protocole peuvent également faire abstraction du modèle de méthodes directes en sérialisant des méthodes dans des messages de protocole compatibles avec l’appareil.

Diagramme illustrant la séquence d’appels de méthode directe permettant d’utiliser une passerelle de protocole pour répartir une communication de protocole personnalisé d’un appareil vers le service IoT Hub.

  1. L’application appelle la méthode directe pour le compte de l’appareil dans la passerelle de protocole.
  2. Pour l’implémentation de la méthode, la passerelle traduit la méthode en un protocole spécifique de l’appareil et envoie le message à l’appareil. L’appareil n’a pas connaissance des modifications apportées à l’implémentation du cloud.
  3. Lorsque l’appareil termine le message et répond, la passerelle traduit l’état spécifique de l’appareil en réponse de la méthode.
  4. Le service IoT Hub accomplit la méthode directe en remplissant un résultat de la méthode pour l’appelant.

Le projet open source de Passerelle de protocole Azure traduisant les méthodes directes en messages de protocole MQTT en mode natif, il est facilement extensible et illustre ce modèle de programmation pour d’autres adaptateurs de protocole.

Appareils en veille connectés

Les scénarios de commande IoT peuvent impliquer des appareils en veille connectés qui sont en état de faible consommation d’énergie quand ils sont inactifs. Des mécanismes tels que le SMS mobile peuvent envoyer des signaux de réveil pour faire passer ces appareils en état de fonctionnement entièrement opérationnel.

Diagramme illustrant la façon dont les messages ou commandes SMS envoyés via des API Azure IoT peuvent réveiller un appareil et le connecter au service IoT Hub pour recevoir des commandes.

  1. L’application envoie des commandes aux appareils à l’aide de l’API ServiceClient. Une instance de ServiceClient peut envoyer des messages et appeler des méthodes pour plusieurs appareils.
  2. L’application envoie également des appels SMS de réveil aux appareils en veille via la passerelle SMS du fournisseur mobile.
  3. Au réveil, les appareils en veille utilisent l’API DeviceClient pour se connecter à IoT Hub et recevoir des commandes. Une instance de DeviceClient représente un appareil unique connecté au service IoT Hub.

Utiliser des méthodes directes pour déterminer l’état de connexion de l’appareil

L’envoi de messages de réveil inutiles via des passerelles SMS est coûteux. Avant d’envoyer des commandes réelles à un appareil, utilisez les délais d’expiration de connexion et de méthode pour déterminer si l’appareil est connecté, et envoyez un réveil si nécessaire.

    TimeSpan connTimeOut = FromSeconds(0); // Period to wait for device to connect.
    TimeSpan funcTimeOut = FromSeconds(30); // Period to wait for method to execute.

    while (true) {
        // Send the command via direct method. Initially use a timeout of zero
        // for the connection, which determines whether the device is connected to
        // IoT Hub or needs an SMS wakeup sent to it.

        var method = new CloudToDeviceMethod("RemoteCommand", funcTimeOut, connTimeOut);
        methodInvocation1.SetPayloadJson(CommandPayload);

        var response = await serviceClient.InvokeDeviceMethodAsync(deviceId, method);

        // [DeviceNotConnected] represents a return value from the CloudToDeviceMethod
        // method. That method is not implemented in this sample.
        if (response == [DeviceNotConnected] && connTimeOut == 0) {
            // The device is not currently connected and needs an SMS wakeup. This
            // device should wake up within a period of < 30 seconds. Send the wakeup
            // and retry the method request with a 30 second timeout on waiting for
            // the device to connect.

            connTimeOut = FromSeconds(30); // Set a 30 second connection timeout.
            SendAsyncSMSWakeUpToDevice(); // Send SMS wakeup through mobile gateway.
            continue; // Retry with new connection timeout.
        } else {
            // The method either succeeded or failed.
            ActOnMethodResult(var);
            break;
        }
    }

Pour simplement vérifier la connectivité, utilisez une méthode vide avec un délai d’expiration de connexion égal à zéro pour implémenter un simple test ping. Par exemple :

var method = new CloudToDeviceMethod("Ping", 0, 0);

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Étapes suivantes