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

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

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

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

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

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

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

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

Устройство может использовать протокол MQTT для подключения к IoT-хабу, используя один из следующих вариантов:

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

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

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

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

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

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

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

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

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

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

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

Чтобы поддерживать соединение клиента с центром IoT, и служба, и клиент регулярно отправляют друг другу проверочный сигнал keep-alive. Если вы используете один из пакетов SDK устройства, клиент отправляет сообщение о сохранении активности через интервал, определенный в следующей таблице:

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

Согласно спецификации MQTT v3.1.1, интервал проверки активности в Центр Интернета вещей в 1,5 раза превышает значение keep-alive клиента. Однако Центр Интернета вещей ограничивает максимальный тайм-аут на серверной стороне до 29,45 минут (1 767 секунд).

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

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

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

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

При переходе с AMQP на MQTT проверьте следующие элементы:

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

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

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

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

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

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

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

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

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

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

  Чтобы избежать непредвиденного поведения, включите версию API в поле.

• В поле Пароль укажите маркер SAS. В следующем фрагменте кода показан формат маркера SAS:

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

  Замечание

  Если вы используете аутентификацию сертификатов X.509, вам не нужны пароли от токенов SAS. Дополнительные сведения см. в руководстве по созданию и отправке сертификатов для тестирования и выполнения инструкций по коду в разделе конфигурации TLS.

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

  Можно также использовать расширение Центр Интернета вещей Azure для Visual Studio Code или команды расширения CLI az iot hub generate-sas-token для создания маркера SAS. Затем можно скопировать и вставить маркер 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} в качестве имени топика Уилл для определения сообщений Уилл, которые должны быть пересланы как сообщения телеметрии. В этом случае, если сетевое соединение закрыто, но пакет DISCONNECT ранее не был получен от устройства, Центр Интернета вещей отправляет сообщение Will, поданное в пакете CONNECT, на телеметрический канал. Канал телеметрии может быть либо конечной точкой по умолчанию Events, либо пользовательской конечной точкой, определенной Центр Интернета вещей маршрутизацией. Сообщение имеет свойство iothub-MessageType со значением Will, назначенным ему.

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

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

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

• При проверке подлинности с помощью имени пользователя и пароля задайте для имени пользователя значение <hubname>.azure-devices.net/{device_id}/{module_id}/?api-version=2021-04-12. Если вы используете SAS, используйте маркер 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 с модулями см. в разделе конечная точка MQTT концентратора IoT Edge.

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

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

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

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

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

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

Чтобы установить TLS-соединение, возможно, потребуется скачать и ссылаться на корневый сертификат DigiCert Global Root G2, который использует Azure. Дополнительные сведения об этом сертификате см. на веб-сайте компании Digicert.

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

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

pip install paho-mqtt

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

• <local path to digicert.cer> — это путь к локальному файлу, который содержит корневой сертификат DigiCert. Этот файл можно создать, скопировав сведения о сертификате из certs.c в Azure IoT SDK для 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>)…

В этом элементе {property_bag} используется та же кодировка символов, что и для строк запросов в протоколе HTTPS.

Если вы направляете сообщения D2C в учетную запись служба хранилища Azure и хотите использовать кодировку JSON, необходимо указать сведения о типе контента и кодировке контента, включая $.ct=application%2Fjson&$.ce=utf-8, в рамках {property_bag}, упомянутых в предыдущем примечание.

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

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

• Центр Интернета вещей не сохраняет сообщения Retain. Если устройство отправляет сообщение с флагом RETAIN, установленным в 1, Центр Интернета вещей добавляет в сообщение свойство приложения mqtt-retain. В этом случае вместо сохранения сохраненного сообщения Центр Интернета вещей передает его в серверное приложение.

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

• Чтобы маршрутизировать сообщения на основе текста сообщения, сначала добавьте свойство 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, он не получает сообщения от Центр Интернета вещей, пока он не подписывается на конечную точку устройства.

Центр Интернета вещей отправляет сообщения с помощью Topic Namedevices/{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

Когда приложение устройства подписывается на раздел с QoS 2 Центр Интернета вещей предоставляет максимальный уровень качества обслуживания 1 в пакете SUBACK. После этого Центр Интернета вещей отправляет сообщения на устройство с помощью QoS 1.

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

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

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

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

{
    "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 должно быть указано целое число.

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

Продление сертификата устройства (операционный сертификат)

1. Во-первых, устройство подписывается на $iothub/credential/#, чтобы получать ответ операции.

2. Затем он публикует сообщение в разделе $iothub/credentials/POST/issueCertificate/?$rid={request_id}, где сообщение содержит значение идентификатора запроса. Текст запроса содержит идентификатор устройства, запрашивающего сертификат, и запрос на подпись сертификата (CSR).

{       
    "id": "device1", // Required. The ID for the device requesting the certificate. This ID is the active authenticated device.
    "csr": "MIICYTCCAUkCAQAwHDEaMBgGA1wRZGAw...yM1X8USCtPz/1nRYDOtA==", // Required. The base64 encoded PKCS#10 CSR, without PEM header or footers or new lines.
    "replace": "*", // Optional. Default null. "*" is accepted to replace any active request.
  } 

1. Устройство получает ответ, подтверждающий получение. Это статус 202.

2. Затем служба отправляет ответное сообщение, содержащее данные сертификата устройства в теме $iothub/credential/res/{status}/?$rid={request-id}, используя тот же идентификатор запроса , что и запрос. Это статус 200.

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

Текст ответа содержит полную цепочку для обновленного сертификата устройства, как показано в следующем примере ответа:

{
  "certificates": [
    "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",  // Device cert
    "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",  // Intermediate CA
    "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"   // Root CA
  ]
}

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

**Дополнительные сведения см. в разделе Продление сертификата Device в управлении сертификатами Центр Интернета вещей Azure**

Дальнейшие действия

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

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