Обмен данными с Центром Интернета вещей с помощью протокола MQTT

В этой статье описывается, как устройства могут использовать поддерживаемые функции MQTT для взаимодействия с Центр Интернета вещей Azure. Центр Интернета вещей позволяет устройствам взаимодействовать с конечными точками устройств Центра Интернета вещей с помощью:

• MQTT версии 3.1.1 на TCP-порте 8883
• MQTT версии 3.1.1 через WebSocket через TCP-порт 443.

Весь обмен данными Центра Интернета вещей с устройствами защищен с помощью протокола TLS/SSL. Поэтому Центр Интернета вещей не поддерживает небезопасные подключения через TCP-порт 1883.

Сравнение поддержки MQTT в Центр Интернета вещей и сетке событий

Центр Интернета вещей не является полнофункциональным брокером MQTT и не поддерживает все функциональные возможности, указанные в стандарте MQTT версии 3.1.1. Если для решения требуется MQTT, мы рекомендуем поддержку MQTT в Сетка событий Azure. Сетка событий обеспечивает двунаправленное взаимодействие между клиентами MQTT в гибких иерархических разделах с помощью модели обмена сообщениями в пабе. Кроме того, он позволяет направлять сообщения MQTT в службы Azure или пользовательские конечные точки для дальнейшей обработки.

В следующей таблице описываются различия в поддержке MQTT между двумя службами:

Подключение к Центру Интернета вещей

Устройство может использовать протокол MQTT для подключения к Центру Интернета вещей с помощью одного из следующих вариантов:

• Пакеты SDK Для Интернета вещей Azure.
• Непосредственно с помощью протокола MQTT.

Порт MQTT (TCP-порт 8883) заблокирован во многих корпоративных и образовательных сетевых средах. Если вы не можете открыть порт 8883 в брандмауэре, рекомендуется использовать MQTT через WebSockets. MQTT через WebSockets взаимодействует через порт 443, который почти всегда открыт в сетевых средах. Сведения о том, как указать MQTT и MQTT через протоколы WebSockets при использовании пакетов SDK Для Интернета вещей Azure, см. в статье "Использование пакетов SDK для устройств".

Использование пакетов SDK для устройств

Доступны пакеты SDK для устройств с поддержкой протокола MQTT для Java, Node.js, C, C# и Python. Для установки подключения к Центру Интернета вещей пакеты SDK для устройств используют выбранный механизм проверки подлинности. Чтобы использовать протокол MQTT, параметр протокола клиента должен быть задан как MQTT. Можно также указать MQTT через WebSockets в параметре протокола клиента. По умолчанию пакеты SDK для устройств подключаются к Центру Интернета вещей, если для флага CleanSession установлено значение 0, и используют качество обслуживания первого уровня для обмена сообщениями с Центром Интернета вещей. Несмотря на возможность настройки параметров QoS 0 для ускорения обмена сообщениями, необходимо помнить, что доставка не гарантируется и не подтверждается. По этой причине QoS 0 часто называют "отправлено и забыто".

Когда устройство подключено к Центру Интернета вещей, пакеты SDK для устройства предоставляют методы, позволяющие устройству осуществлять обмен сообщениями с Центром Интернета вещей.

В следующей таблице содержатся ссылки на примеры кода для каждого поддерживаемого языка и параметр, используемый для установления подключения к Центр Интернета вещей с помощью протокола MQTT или MQTT через протокол WebSockets.

В следующем фрагменте показано, как указать MQTT по протоколу WebSockets при использовании пакета SDK Node.js Azure IoT:

var Client = require('azure-iot-device').Client;
var Protocol = require('azure-iot-device-mqtt').MqttWs;
var client = Client.fromConnectionString(deviceConnectionString, Protocol);

В следующем фрагменте показано, как указать MQTT по протоколу WebSockets при использовании пакета SDK Для Python Для Интернета вещей Azure:

from azure.iot.device.aio import IoTHubDeviceClient
device_client = IoTHubDeviceClient.create_from_connection_string(deviceConnectionString, websockets=True)

Время ожидания проверки активности по умолчанию

Чтобы обеспечить постоянную активность подключения клиента c Центром Интернета вещей, служба и клиент регулярно отправляют друг другу проверки связи. Клиент, использующий пакет SDK для IoT, отправляет пакет проверки активности с интервалом, указанным в следующей таблице:

*Пакет SDK для C# определяет значение по умолчанию свойства MQTT KeepAliveInSeconds как 300 секунд. В действительности пакет SDK отправляет запрос проверки связи четыре раза за период хранения в режиме реального времени. Другими словами, пакет SDK отправляет связь с отслеживанием активности каждые 75 секунд.

В соответствии со спецификацией MQTT версии 3.1.1 интервал запроса проверки на активность в Центре Интернета вещей в 1,5 раза превышает значение запроса проверки на активность клиента, однако Центр Интернета вещей ограничивает максимальное время ожидания на стороне сервера до 29,45 минуты (1767 секунд). Это ограничение связано с тем, что все службы Azure привязаны к времени ожидания простоя TCP подсистемы балансировки нагрузки Azure, которое составляет 29,45 минуты.

Например, устройство, использующее Java SDK отправляет запрос проверки на активность и теряет подключение к сети. Через 230 секунд устройство не отвечает на проверку связи, так как она находится в автономном режиме. Но Центр Интернета вещей не закрывает подключение немедленно — он ожидает еще (230 * 1.5) - 230 = 115 секунд, прежде чем отключить устройство с ошибкой 404104 DeviceConnectionClosedRemotely.

Максимальное значение интервала проверки активности клиента, которое можно задать, — 1767 / 1.5 = 1177 секунд. Любой трафик сбрасывает отсчет интервала проверки на активность. Например, успешное обновление маркера SAS сбрасывает интервал проверки на активность.

Переход от AMQP на MQTT в приложении устройства

Если вы используете SDK устройства, то переключение от использования AMQP на MQTT требует изменения параметра протокола в исходных данных клиента, как указано ранее.

При этом обязательно проверьте следующее:

• AMQP возвращает ошибки для многих условий, а MQTT завершает подключение. В результате может потребоваться изменить логику обработки исключений.

• MQTT не поддерживает операции отклонения при получении сообщений из облака на устройство. Если нужно, чтобы внутреннее приложение получало ответы от приложения для устройства, стоит использовать прямые методы.

• AMQP не поддерживается в Python SDK.

Непосредственное использование протокола MQTT (как устройство)

Если устройство не может использовать пакеты SDK для устройств, оно может подключаться к общедоступным конечным точкам устройства по протоколу MQTT через порт 8883.

В пакете CONNECT устройство должно использовать следующие значения.

• В поле Идентификатор клиента укажите значение идентификатор устройства.

• В поле "Имя пользователя" используйте {iotHub-hostname}/{device-id}/?api-version=2021-04-12, где {iotHub-hostname} находится полный CName центр Интернета вещей.

  Например, если имя Центра Интернета вещей — contoso.azure-devices.net, а имя устройства — MyDevice01, то полное поле Username (Имя пользователя) должно содержать:

  contoso.azure-devices.net/MyDevice01/?api-version=2021-04-12

  Рекомендуем в поле указать api-версию. В противном случае может иметь место непредусмотренное поведение.

• В поле Пароль укажите маркер SAS. Формат маркера SAS аналогичен описанному для протоколов HTTPS и AMQP:

  SharedAccessSignature sig={signature-string}&se={expiry}&sr={URL-encoded-resourceURI}

  Примечание.

  При использовании аутентификации с помощью сертификата X.509 пароли маркеров SAS не требуются. Дополнительные сведения см. в руководстве . Создание и отправка сертификатов для тестирования и выполнения инструкций по коду в разделе конфигурации TLS/SSL.

  Дополнительные сведения о создании маркеров SAS см. в разделе "Использование маркеров SAS в качестве раздела управления доступом к Центр Интернета вещей с помощью подписанных URL-адресов".

  Вы также можете использовать кроссплатформенное расширение Центр Интернета вещей Azure для Visual Studio Code или команду расширения CLI az iot hub generate-sas-token для быстрого создания маркера SAS. Затем можно скопировать и вставить маркер SAS в собственный код для тестирования.

Руководство по использованию MQTT напрямую см. в разделе "Использование MQTT" для разработки клиента устройства Интернета вещей без использования пакета SDK для устройств.

Использование расширения Центр Интернета вещей Azure для Visual Studio Code

1. На боковой панели разверните узел "Устройства" в разделе Центр Интернета вещей Azure.

2. Щелкните правой кнопкой мыши устройство Интернета вещей и выберите "Создать маркер SAS для устройства " в контекстном меню.

3. Введите время окончания срока действия маркера SAS в поле ввода и нажмите клавишу ВВОД.

4. Маркер SAS создается и копируется в буфер обмена.

   Созданный маркер SAS имеет следующую структуру.

   HostName={iotHub-hostname};DeviceId=javadevice;SharedAccessSignature=SharedAccessSignature sr={iotHub-hostname}%2Fdevices%2FMyDevice01%2Fapi-version%3D2016-11-14&sig=vSgHBMUG.....Ntg%3d&se=1456481802

   Его часть используется в поле Пароль для подключения с использованием MQTT:

   SharedAccessSignature sr={iotHub-hostname}%2Fdevices%2FMyDevice01%2Fapi-version%3D2016-11-14&sig=vSgHBMUG.....Ntg%3d&se=1456481802

Приложение устройства может указать сообщение Will в пакете CONNECT. Приложение для устройства должно использовать devices/{device-id}/messages/events/ или devices/{device-id}/messages/events/{property-bag} в качестве значения параметра Will topic name (Будущее имя раздела) для определения будущих сообщений, которые будут пересылаться в качестве сообщения телеметрии. В этом случае, если сетевое соединение закрыто, но пакет DISCONNECT ранее не был получен с устройства, то Центр Интернета вещей отправляет сообщение Will, содержащееся в пакете CONNECT, в канал телеметрии. Канал телеметрии может быть либо конечной точкой События по умолчанию, либо настраиваемой конечной точкой, определяемой маршрутизацией Центра Интернета вещей. Сообщение имеет свойство iothub-MessageType со значением Will, назначенным ему.

Непосредственное использование протокола MQTT (как модуль)

Вы можете подключиться к Центр Интернета вещей через MQTT с помощью удостоверения модуля, аналогично подключению к Центр Интернета вещей как устройство. Дополнительные сведения о подключении к Центр Интернета вещей через MQTT в качестве устройства см. в разделе "Использование протокола MQTT напрямую (как устройство)". Однако необходимо использовать следующие значения:

• Задайте идентификатор клиента {device-id}/{module-id}.

• При аутентификации с использованием имени пользователя и пароля задайте для имени пользователя значение <hubname>.azure-devices.net/{device_id}/{module_id}/?api-version=2021-04-12 и используйте в качестве пароля маркер SAS, связанный с удостоверением модуля.

• Используйте devices/{device-id}/modules/{module-id}/messages/events/ в качестве раздела для публикации телеметрии.

• Используйте devices/{device-id}/modules/{module-id}/messages/events/ как раздел WILL.

• Используйте devices/{device-id}/modules/{module-id}/# в качестве раздела для получения сообщений.

• Разделы двойников GET и PATCH идентичны для модулей и устройств.

• Раздел состояния двойников идентичны для модулей и устройств.

Дополнительные сведения об использовании MQTT с модулями см. в статье Публикация сообщений и создание подписки на них с помощью IoT Edge и дополнительные сведения о конечной точке MQTT центра IoT Edge.

Примеры с помощью MQTT без пакета SDK Для Интернета вещей Azure

Репозиторий примеров MQTT Интернета вещей содержит примеры C/C++, Python и CLI, показывающие, как отправлять сообщения телеметрии, получать сообщения телеметрии и использовать двойники устройств без использования пакетов SDK для устройств Azure.

Примеры C/C++ используют библиотеку Eclipse Mosquitto, пример Python использует Eclipse Paho, а примеры CLI используютсяmosquitto_pub.

Дополнительные сведения см. в руководстве . Использование MQTT для разработки клиента устройства Интернета вещей.

конфигурация протокола TLS/SSL

Чтобы напрямую использовать протокол MQTT, ваш клиент должен подключиться по протоколу TLS/SSL. Попытки пропустить этот шаг будут завершаться ошибками соединения.

Чтобы установить подключение TLS, может потребоваться скачать и ссылаться на корневой сертификат DigiCert, который использует Azure. В период с 15 февраля по 15 октября 2023 г. Центр Интернета вещей Azure переносит корневой сертификат TLS из корневого сертификата DigiCert Baltimore в глобальный корневой каталог DigiCert G2. В течение периода миграции на устройствах должны быть оба сертификата, чтобы обеспечить подключение. Дополнительные сведения о миграции см. в статье "Перенос ресурсов Интернета вещей" в новый корневой каталог сертификата TLS. Дополнительные сведения об этих сертификатах см. на веб-сайте Digicert.

В следующем примере показано, как реализовать эту конфигурацию с помощью версии Python библиотеки Paho MQTT в Eclipse Foundation.

Сначала установите библиотеку Paho из командной строки:

pip install paho-mqtt

Затем запустите клиент в сценарии Python. Замените эти заполнители в следующем фрагменте кода:

• <local path to digicert.cer> — это путь к локальному файлу, который содержит корневой сертификат DigiCert. Этот файл можно создать путем копирования сведений о сертификате из certs.c в пакете Центра Интернета вещей Azure для C. Укажите строки -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----, удалите метки " в начале и в конце каждой строки, а также удалите знаки \r\n в конце каждой строки.

• <device id from device registry> — идентификатор устройства, добавленного в Центр Интернета вещей.

• <generated SAS token> — маркер SAS для устройства, созданного как описано ранее в этой статье.

• <iot hub name> — имя Центра Интернета вещей.

from paho.mqtt import client as mqtt
import ssl

path_to_root_cert = "<local path to digicert.cer file>"
device_id = "<device id from device registry>"
sas_token = "<generated SAS token>"
iot_hub_name = "<iot hub name>"


def on_connect(client, userdata, flags, rc):
    print("Device connected with result code: " + str(rc))


def on_disconnect(client, userdata, rc):
    print("Device disconnected with result code: " + str(rc))


def on_publish(client, userdata, mid):
    print("Device sent message")


client = mqtt.Client(client_id=device_id, protocol=mqtt.MQTTv311)

client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_publish = on_publish

client.username_pw_set(username=iot_hub_name+".azure-devices.net/" +
                       device_id + "/?api-version=2021-04-12", password=sas_token)

client.tls_set(ca_certs=path_to_root_cert, certfile=None, keyfile=None,
               cert_reqs=ssl.CERT_REQUIRED, tls_version=ssl.PROTOCOL_TLSv1_2, ciphers=None)
client.tls_insecure_set(False)

client.connect(iot_hub_name+".azure-devices.net", port=8883)

client.publish("devices/" + device_id + "/messages/events/", '{"id":123}', qos=1)
client.loop_forever()

Чтобы выполнить проверку подлинности с помощью сертификата устройства, обновите предыдущий фрагмент кода с изменениями, указанными в следующем фрагменте кода. Дополнительные сведения о подготовке к проверке подлинности на основе сертификатов см. в разделе "Получение сертификата ЦС X.509" для устройств проверки подлинности с помощью сертификатов ЦС X.509.

# Create the client as before
# ...

# Set the username but not the password on your client
client.username_pw_set(username=iot_hub_name+".azure-devices.net/" +
                       device_id + "/?api-version=2021-04-12", password=None)

# Set the certificate and key paths on your client
cert_file = "<local path to your certificate file>"
key_file = "<local path to your device key file>"
client.tls_set(ca_certs=path_to_root_cert, certfile=cert_file, keyfile=key_file,
               cert_reqs=ssl.CERT_REQUIRED, tls_version=ssl.PROTOCOL_TLSv1_2, ciphers=None)

# Connect as before
client.connect(iot_hub_name+".azure-devices.net", port=8883)

Отправка сообщений из устройства в облако

После подключения устройства он может отправлять сообщения в Центр Интернета вещей с помощью devices/{device-id}/messages/events/ или devices/{device-id}/messages/events/{property-bag} в качестве имени раздела. Элемент {property-bag} позволяет устройству отправлять сообщения с другими свойствами в формате, закодированном url-адресом. Рассмотрим пример.

RFC 2396-encoded(<PropertyName1>)=RFC 2396-encoded(<PropertyValue1>)&RFC 2396-encoded(<PropertyName2>)=RFC 2396-encoded(<PropertyValue2>)…

В следующем списке описаны Центр Интернета вещей поведения, характерные для реализации.

• Центр Интернета вещей не поддерживает сообщения со вторым уровнем качества обслуживания. Если приложение для устройства публикует сообщение со вторым уровнем качества обслуживания, то Центр Интернета вещей закрывает сетевое подключение.

• Центр Интернета вещей не сохраняет сообщения retain. Если устройство направляет сообщение СОХРАНИТЬ с флажком установленном на 1, Центр Интернета вещей добавляет в сообщение свойство mqtt-retain приложения. В этом случае Центр Интернета вещей не хранит сообщение retain, а передает его во внутреннее приложение.

• Центр Интернета вещей поддерживает только одно активное подключение MQTT на устройство. Любое новое подключение MQTT от имени того же идентификатора устройства приводит к тому, что Центр Интернета вещей удалить существующее подключение и 400027 ConnectionForcefullyClosedOnNewConnection входит в журналы Центр Интернета вещей

• Чтобы маршрутизировать сообщения на основе текста сообщения, необходимо сначала добавить свойство ContentType (ct) в конец раздела MQTT и задать его значение application/json;charset=utf-8 , как показано в следующем примере. Дополнительные сведения о маршрутизации сообщений на основе свойств сообщения или текста сообщения см. в документации по синтаксису запросов маршрутизации сообщений Центр Интернета вещей.

  devices/{device-id}/messages/events/$.ct=application%2Fjson%3Bcharset%3Dutf-8

Дополнительные сведения см. в статье "Отправка сообщений устройства в облако и облако" с помощью Центр Интернета вещей.

Получение сообщений из облака на устройство

Для получения сообщений из Центра Интернета вещей устройство должно подписаться с использованием devices/{device-id}/messages/devicebound/# в качестве значения параметра Topic Filter (Фильтр разделов). Подстановочный знак # в фильтре тем используется только для получения дополнительных свойств в имени раздела устройства. В Центре Интернета вещей запрещено использовать подстановочные знаки # или ? для фильтрации подразделов. Так как Центр Интернета вещей не является брокером общего назначения службы сообщений на основе шаблона "издатель-подписчик", то он поддерживает только задокументированные имена и фильтры разделов. Устройство может подписываться только на пять разделов одновременно.

Устройство не получает сообщения от Центр Интернета вещей до тех пор, пока он не будет успешно подписан на свою конечную точку для конкретного устройства, представленную фильтром devices/{device-id}/messages/devicebound/# раздела. Когда подписка выполнена, устройство получает сообщения, переданные из облака на устройство, только с момента подписки. Если устройство подключается с флагом CleanSession, имеющим значение 0, то подписка будет сохраняться в разных сеансах. В этом случае при следующем подключении с флагом CleanSession 0 устройство получает ожидающие сообщения, отправленные на него, пока оно было отключено. Если устройство использует флаг CleanSession с значением 1, оно не получает сообщения от Центр Интернета вещей, пока не подписывается на конечную точку устройства.

Центр Интернета вещей передает сообщения с именем раздела devices/{device-id}/messages/devicebound/ или devices/{device-id}/messages/devicebound/{property-bag} при наличии свойств сообщения. {property-bag} содержит закодированные в формате URL-адреса пары "ключ-значение" свойств сообщения. В контейнер свойств входят только свойства приложений и задаваемые пользователем системные свойства (такие как messageId или correlationId). Имена системных свойств имеют префикс $, свойства приложений используют исходное имя свойства без префикса. Дополнительные сведения о формате контейнера свойств см. в разделе "Отправка сообщений устройства в облако".

В сообщениях из устройства в облако значения в пакете свойств представлены в следующей таблице:

Следующие примеры демонстрируют пакет свойств, который содержит три свойства приложения: свойство1 со значением null; свойство2, пустая строка (""); и свойство3 со значением "строка".

/?prop1&prop2=&prop3=a%20string

Если приложение для устройства подписывается на раздел со вторым уровнем качества обслуживания, то Центр Интернета вещей присваивает пакету SUBACK уровень качества обслуживания не выше первого. После этого Центр Интернета вещей доставляет сообщения на устройство, используя первый уровень качества обслуживания.

Получение свойств двойника устройства

Сначала устройство подписывается на $iothub/twin/res/#, чтобы получать ответы операций. Затем оно отправляет пустое сообщение в раздел $iothub/twin/GET/?$rid={request id} с заполненным значением request ID (идентификатор запроса). Затем служба отправляет ответное сообщение, содержащее данные двойника устройства в разделе $iothub/twin/res/{status}/?$rid={request-id}, используя то же значение идентификатора запроса, что и в запросе.

Идентификатор запроса может быть любым допустимым значением значения свойства сообщения, а состояние проверяется как целое число. Дополнительные сведения см. в статье "Отправка сообщений устройства в облако и облако" с помощью Центр Интернета вещей.

Текст ответа содержит раздел properties двойника устройства, как показано в следующем примере ответа:

{
    "desired": {
        "telemetrySendFrequency": "5m",
        "$version": 12
    },
    "reported": {
        "telemetrySendFrequency": "5m",
        "batteryLevel": 55,
        "$version": 123
    }
}

Возможны следующие коды состояний:

См. общие сведения о двойниках устройств и их использовании в Центре Интернета вещей.

Обновление сообщаемых свойств двойника устройства

Чтобы обновить сообщаемые свойства, устройство отправляет запрос в Центр Интернета вещей с помощью публикации в указанном разделе MQTT. После Центр Интернета вещей обработки запроса он отвечает на состояние успешной или неудачной операции обновления через публикацию в другой раздел. Устройство может подписаться на этот раздел, чтобы уведомить его о результатах запроса на обновление двойника. Чтобы реализовать этот тип взаимодействия "запрос — ответ" в MQTT, мы используем понятие идентификатора запроса ($rid), изначально предоставленное устройством в запросе на обновление. Этот идентификатор запроса также включается в ответ Центра Интернета вещей, чтобы позволить устройству сопоставить ответ с конкретным более ранним запросом.

Следующая последовательность действий описывает, как устройство обновляет сообщаемые свойства в двойнике устройства в Центре Интернета вещей:

1. Сначала устройство должно подписаться на раздел $iothub/twin/res/#, чтобы получать ответы операций из Центра Интернета вещей.

2. Устройство отправляет сообщение, содержащее обновление двойника устройства, в раздел $iothub/twin/PATCH/properties/reported/?$rid={request-id}. Это сообщение содержит значение request ID (идентификатор запроса).

3. Затем служба отправляет ответное сообщение, содержащее новое значение ETag для коллекции сообщаемых свойств в разделе $iothub/twin/res/{status}/?$rid={request-id}. В этом ответном сообщении используется то же значение request ID, что и в запросе.

Текст запроса содержит документ JSON, в котором имеются новые значения для переданных свойств. Каждый элемент документа JSON обновляет или добавляет соответствующий компонент в документе двойника устройства. Элемент, установленный на null, удаляет элемент из содержащего объекта. Например:

{
    "telemetrySendFrequency": "35m",
    "batteryLevel": 60
}

Возможны следующие коды состояний:

Следующий фрагмент кода Python демонстрирует процесс обновления свойств двойника через MQTT с помощью клиента Paho MQTT:

from paho.mqtt import client as mqtt

# authenticate the client with IoT Hub (not shown here)

client.subscribe("$iothub/twin/res/#")
rid = "1"
twin_reported_property_patch = "{\"firmware_version\": \"v1.1\"}"
client.publish("$iothub/twin/PATCH/properties/reported/?$rid=" +
               rid, twin_reported_property_patch, qos=0)

При успешном выполнении процесса обновления свойств двойника в предыдущем фрагменте кода сообщение публикации из Центр Интернета вещей имеет следующий раздел: $iothub/twin/res/204/?$rid=1&$version=6где 204 код состояния, указывающий на успешность, $rid=1 соответствует идентификатору запроса, предоставленному устройством в коде, и $version соответствует версии раздела сообщаемых свойств двойников устройств после обновления.

См. общие сведения о двойниках устройств и их использовании в Центре Интернета вещей.

Получение уведомлений об обновлении требуемых свойств

При подключении устройства Центр Интернета вещей отправляет уведомления в раздел $iothub/twin/PATCH/properties/desired/?$version={new-version}, в котором находится содержимое обновления, выполненного серверной частью решения. Например:

{
    "telemetrySendFrequency": "5m",
    "route": null,
    "$version": 8
}

В обновлениях свойств значение null означает, что элемент объекта JSON удаляется. Кроме того, $version указывает новую версию раздела с требуемыми свойствами двойника.

См. общие сведения о двойниках устройств и их использовании в Центре Интернета вещей.

Ответ на прямой метод

Сначала устройство должно подписаться на $iothub/methods/POST/#. Центр Интернета вещей отправляет запросы метода в раздел $iothub/methods/POST/{method-name}/?$rid={request-id} с допустимым документом JSON или без текста.

В качестве ответа устройство отправляет сообщение без текста или с допустимой строкой JSON в раздел $iothub/methods/res/{status}/?$rid={request-id}. В этом сообщении значение request ID должно совпадать с идентификатором в сообщении запроса, а в качестве status должно быть указано целое число.

Дополнительные сведения см. в статье Общие сведения о прямых методах и информация о вызове этих методов из Центра Интернета вещей.

Следующие шаги

Дополнительные сведения об использовании MQTT см. в следующей статье:

• Документация по MQTT
• Использование MQTT для разработки клиента устройства Интернета вещей без использования пакета SDK для устройств
• Примеры приложений MQTT

Дополнительные сведения об использовании пакетов SDK для устройств Интернета вещей см. в следующих статье:

• IoT Hub SDKs (Пакеты SDK для Центра Интернета вещей)

Дополнительные сведения о планировании развертывания Центра Интернета вещей см. в следующих руководствах:

• Использование устройства IoT Edge в качестве шлюза
• Подключение устройств Интернета вещей к Azure: Центр Интернета вещей и Центров событий
• Выбор правильного уровня Центра Интернета вещей для решения