W jaki sposób Azure IoT Hub współdziała z urządzeniami Embedded / IoT?

Pracuję na platformie Azure IoT i rozumiem, w jaki sposób urządzenia wysyłają dane do centrum IoT (jeśli się nie mylę, to tylko wywołanie usługi internetowej lub coś podobnego).

Zastanawiam się jednak, w jaki sposób hub IoT wysyła dane / polecenia / dane wejściowe do urządzeń, ponieważ nie pracujemy na hubie IoT do komunikacji z urządzeniami (nie mamy żadnych wymagań dotyczących przekazywania danych do urządzeń). Czy centrum IoT może bezpośrednio współpracować z urządzeniami? (Użycie unikalnego identyfikatora urządzenia lub użycie dowolnej unikalnej tożsamości, takiej jak adres IP, adres Mac itp.).

Gdzieś czytałem, że urządzenia ciągle wysyłają żądania do koncentratora IoT, jeśli koncentrator IoT ma dla nich jakieś dane wejściowe, a następnie koncentrator IoT wysyła dane / polecenia / dane wejściowe do urządzeń w odpowiedzi. Czy to prawda? Jeśli nie, proszę wyjaśnić.

Modelem używanym przez urządzenia IoT Hub jest to, że nigdy nie będą przyjmować połączeń przychodzących. Urządzenia Centrum IoT nigdy nie działają jako „serwer”, co stanowi kluczową część modelu zabezpieczeń w usłudze Azure IoT. Ostateczny model na ten temat znajduje się w Clemens Vasters „Service Assisted Communication” .

Dlatego urządzenia zawsze „odpytują” zewnętrzną usługę w celu wysyłania danych lub odbierania poleceń. Interfejsy API sprawiają, że wygląda na to, że dane są wysyłane do urządzenia, ale zawsze jest to urządzenie nawiązujące połączenie wychodzące.

Centrum IoT robi to na dwa sposoby:

1. Wysyłając dane do punktu końcowego urządzenia /devices/{deviceId}/messages/devicebound. Jest to punkt końcowy przesyłania komunikatów AMQP, podobny do kolejki lub subskrypcji tematu. Podczas odczytywania poleceń urządzenie musi w razie potrzeby potwierdzić odbiór, który jest częścią podstawowego protokołu AMQP. Działa to tak samo z MQTT, a https jest prawidłową rezerwą. Interfejs API to wszystko dla Ciebie. Istnieją dodatkowe koncepcje, takie jak „metody bezpośrednie”, które są opakowaniem interfejsu API w zasadzie w oparciu o ten sam podstawowy protokół komunikatów
2. Korzystając z bliźniaczego urządzenia po stronie serwera, jest to sposób na logiczne utrzymanie synchronizacji właściwości między urządzeniem a serwerem. Ustawiasz właściwość na urządzeniu bliźniaczym, a kiedy urządzenie synchronizuje się, ta właściwość zostanie zsynchronizowana z urządzeniem. Jest to mniej oparte na komunikatach i oparte na protokole zarządzania urządzeniami LWM2M.

Wiele „odpytywania”, łączenia, współdzielenia połączeń, potwierdzeń itp. Należy załatwić jako część protokołu AMQP (lub MQTT), który z kolei jest zawarty w pakiecie IoT Hub SDK. Tak więc powyższe jest bardzo uproszczone, ale aby powtórzyć, IoT Hub nie może i nie będzie (nigdy) próbował wysyłać danych na adres IP / port urządzenia.