Comment un hub Azure IoT interagit-il avec les appareils Embedded / IoT?

Je travaille sur la plate-forme Azure IoT et je comprends comment les appareils envoient des données au hub IoT (si je ne me trompe pas, il s'agit simplement d'un appel de service Web ou de quelque chose de similaire).

Mais je me demande comment le hub IoT envoie des données / commandes / entrées aux appareils, car nous ne travaillons pas sur le hub IoT pour la communication entre appareils (nous n'avons aucune obligation de pousser les données vers les appareils). Le hub IoT peut-il interagir directement avec les appareils? (En utilisant l'identifiant unique de l'appareil ou en utilisant une identité unique comme IP, adresse Mac, etc.).

Quelque part, j'ai lu que les appareils continuent de demander au hub IoT si le hub IoT a une entrée pour eux, et le hub IoT envoie ensuite des données / commandes / entrées aux appareils en réponse. Est-ce vrai? Sinon, veuillez expliquer.

Le modèle utilisé par les appareils connectés IoT Hub est qu'ils n'accepteront jamais les connexions entrantes. Les appareils IoT Hub n'agissent jamais comme un `` serveur '', et c'est une partie cruciale du modèle de sécurité dans Azure IoT. Le modèle définitif à ce sujet est résumé dans la communication assistée par service de Clemens Vasters .

Par conséquent, les appareils «interrogent» toujours un service externe afin d'envoyer des données ou de recevoir des commandes. Les API donnent l'impression que des données sont envoyées à un appareil, mais c'est toujours l'appareil qui établit la connexion sortante.

Le hub IoT le fait de deux manières:

1. En envoyant des données au terminal de l'appareil /devices/{deviceId}/messages/devicebound. Il s'agit d'un point de terminaison de messagerie AMQP, semblable à un abonnement de file d'attente ou de rubrique. L'appareil, lors de la lecture des commandes, doit accuser réception si nécessaire, ce qui fait partie du protocole AMQP sous-jacent. Cela fonctionne de la même manière avec MQTT, et https est une solution de rechange valide. L'API résume tout cela pour vous. Il existe des concepts supplémentaires, tels que les «méthodes directes» qui sont un wrapper API autour essentiellement du même protocole de message sous-jacent
2. En utilisant le jumeau d'appareil côté serveur, qui est un moyen de maintenir logiquement les propriétés synchronisées entre l'appareil et le serveur. Vous définissez une propriété sur le jumeau d'appareil, et lorsque l'appareil se synchronise, cette propriété sera synchronisée avec l'appareil. Ceci est moins basé sur les messages et construit sur le protocole de gestion des périphériques LWM2M.

Une grande partie de l'interrogation, de la connexion, du partage des connexions, des reçus, etc. devrait être prise en charge dans le cadre du protocole AMQP (ou MQTT), qui à son tour est intégré au SDK IoT Hub. Donc, ce qui précède est très simplifié, mais pour réitérer, IoT Hub ne peut pas et n'essaiera (jamais) d'envoyer des données à une adresse / port IP sur votre appareil.