Superviser l’état de connexion d’un appareil
Azure IoT Hub prend en charge plusieurs méthodes de surveillance de l’état de vos appareils. Cet article présente les différentes méthodes de surveillance et fournit des conseils pour vous aider à choisir la meilleure option pour votre solution IoT.
Le tableau suivant présente trois façons de surveiller l’état de la connexion de votre appareil :
| Méthode | Fréquence d’état | Coût | Effort de génération |
|---|---|---|---|
| Propriété ConnectionState du jumeau d’appareil | De façon intermittente | Faible | Faible |
| Event Grid | 60 secondes | Faible | Faible |
| Modèle de pulsation d’appareil personnalisé | Custom | Élevé | Élevé |
En raison de sa fiabilité, de son faible coût et de sa facilité d’utilisation, nous recommandons Event Grid comme solution de supervision par défaut pour la plupart des clients.
Toutefois, la surveillance avec Event Grid présente certaines limitations qui peuvent le disqualifier pour certaines solutions IoT. Utilisez cet article pour comprendre les avantages et les limitations de chaque option.
connectionState du jumeau d’appareil
Chaque identité d’appareil IoT Hub contient une propriété appelée connectionState qui signale l’état connecté ou déconnecté. Cette propriété représente la compréhension de l’état de connexion d’un appareil d’IoT Hub.
La propriété d’état de connexion présente plusieurs limitations :
- L’état de la connexion est mis à jour uniquement pour les appareils utilisant les protocoles AMQP ou MQTT.
- Les mises à jour à cette propriété s’appuient sur des tests ping au niveau du protocole et peuvent être retardées de jusqu’à cinq minutes.
Pour ces raisons, nous vous recommandons d’utiliser uniquement le champ connectionState pendant le développement et le débogage. Les solutions IoT ne doivent pas interroger le champ au moment de l’exécution. Par exemple, n’interrogez pas le champ connectionState pour vérifier si un appareil est connecté avant d’envoyer un message cloud vers appareil ou un SMS.
Event Grid
Nous recommandons Event Grid comme solution de supervision par défaut pour la plupart des clients.
Abonnez-vous aux événements deviceConnected et deviceDisconnected sur Event Grid pour obtenir des alertes et surveiller l’état de connexion des appareils.
Utilisez les articles suivants pour apprendre à intégrer des événements d’appareil connecté/déconnecté à votre solution IoT :
- Réagir aux événements IoT Hub à l'aide d'Event Grid
- Commander des événements de connexion d’appareil en utilisant Cosmos DB
Les événements d’état de connexion de l’appareil sont disponibles pour les appareils qui se connectent à l’aide du protocole MQTT ou AMQP, ou à l’aide de l’un de ces protocoles sur WebSockets. Les requêtes effectuées uniquement avec HTTPS ne déclenchent pas de notifications d’état de connexion de l’appareil.
- Pour les appareils qui se connectent à l’aide des kits SDK Azure IoT pour Java, Node ou Python :
- MQTT : les événements d’état de connexion sont envoyés automatiquement.
- AMQP : une liaison cloud-à-appareil doit être créée pour réduire les retards dans le signalement des états de connexion.
- Pour les appareils qui se connectent à l’aide des SDK Azure IoT pour .NET ou C, les événements d’état de connexion ne seront pas signalés tant qu’un message appareil-à-cloud initial n’est pas envoyé ou qu’un message cloud-à-appareil n’est pas reçu.
En dehors des Kits de développement logiciel (SDK) Azure IoT, dans MQTT, ces opérations sont équivalentes à S’ABONNER à des publications ou à les PUBLIER dans les rubriquesde messagerie appropriées. Sur AMQP, ces opérations correspondent à joindre ou transférer un message sur les chemins de liens appropriés.
Limitations d’Event Grid
L’utilisation d’Event Grid pour surveiller l’état de votre appareil présente les limitations suivantes :
- Event Grid ne signale pas chaque événement de connexion et de déconnexion d’appareil individuel. Au lieu de cela, il interroge l’état de l’appareil toutes les 60 secondes et publie l’état de connexion le plus récent en cas de changement d’état. Pour cette raison, les rapports de changement d’état peuvent être retardés de jusqu’à une minute, et des changements d’état individuels peuvent ne pas être signalés si plusieurs événements se produisent dans la fenêtre de 60 secondes.
- Les appareils qui utilisent AMQP ont besoin d’un lien cloud-à-appareil avant de pouvoir signaler l’état de l’appareil.
- Event Grid expose un point de terminaison public qui ne peut pas être masqué.
Si l’une de ces limitations affecte votre capacité à utiliser Event Grid pour la surveillance de l’état des appareils, vous devez plutôt envisager de créer un modèle de pulsation d’appareil personnalisé.
Modèle de pulsation de l’appareil
Si vous avez besoin de connaître l’état de connexion de vos appareils, mais que les limitations d’Event Grid sont trop restrictives pour votre solution, vous pouvez implémenter le modèle de pulsation. Dans le modèle par pulsations, l’appareil envoie des messages appareil-à-cloud au moins une fois par durée fixe (par exemple, au moins une fois par heure). Même si un appareil n’a pas de données à envoyer, il envoie toujours un message appareil-à-cloud vide, généralement avec une propriété qui l’identifie comme pulsation. Côté service, la solution gère un mappage avec la dernière pulsation reçue pour chaque appareil. Si la solution ne reçoit pas de message de pulsation dans le temps imparti de la part de l’appareil, elle suppose qu’il y a un problème avec l’appareil.
Limitations des pulsations d’appareil
Étant donné que les messages de pulsation sont implémentés en tant que messages appareil-à-cloud, ils sont comptabilisés dans votre quota de messages IoT Hub et dans les limites de la limitation.
Modèle de délai d’expiration court
Si une solution IoT utilise uniquement l’état de la connexion de l’appareil pour déterminer si elle doit envoyer des messages cloud-à-appareil à un appareil, et que ces messages ne sont pas diffusés à de larges groupes d’appareils, envisagez d’utiliser un modèle de délai d’expiration court comme alternative plus simple que le modèle de pulsation. Le modèle de délai d’expiration court permet de déterminer s’il faut envoyer des messages cloud-à-appareil en envoyant des messages avec un délai d’expiration de message court et en demandant des accusés de réception de message à partir des appareils.
Pour plus d’informations, consultez Expiration des messages (durée de vie).
Autres options de surveillance
Une implémentation plus complexe peut inclure les informations d’Azure Monitor et d’Azure Resource Health pour identifier les appareils qui ne parviennent pas à se connecter ou à communiquer. Les tableaux de bord Azure Monitor sont utiles pour voir l’intégrité globale de vos appareils, tandis qu’Event Grid et les modèles de pulsation facilitent la réponse aux pannes d’appareil individuelles.
Pour en savoir plus sur l’utilisation de ces services avec IoT Hub, consultez Surveiller IOT Hub et Vérifier l’intégrité des ressources IOT Hub. Pour plus d’informations sur l’utilisation de Azure Monitor ou Event Grid pour surveiller la connectivité des appareils, consultez Surveiller, diagnostiquer et résoudre les problèmes de connectivité des appareils.