Comunique-se com um hub IoT usando o protocolo MQTT

Este artigo descreve como os dispositivos podem usar o protocolo MQTT para comunicar com o Hub IoT do Azure. Os endpoints dos dispositivos do Hub IoT suportam a conectividade dos dispositivos utilizando:

• MQTT v3.1.1 na porta 8883
• MQTT v3.1.1 sobre WebSocket na porta 443

Toda a comunicação do dispositivo com o Hub IoT deve ser assegurada usando TLS. Portanto, o Hub IoT não suporta ligações MQTT inseguras na porta 1883.

Compare o suporte MQTT no Hub IoT e no Event Grid

O Hub IoT não é um corretor MQTT completo e não suporta todos os comportamentos especificados na norma MQTT v3.1.1. Se a sua solução precisar de um broker MQTT alojado na cloud, use Azure Event Grid em vez disso. O Event Grid permite a comunicação bidirecional entre clientes MQTT em tópicos hierárquicos flexíveis usando um modelo de mensagens de publicação-assinatura. Também permite encaminhar mensagens MQTT para outros serviços Azure ou endpoints personalizados para processamento adicional.

A tabela a seguir resume as diferenças atuais no suporte MQTT entre os dois serviços:

Ligue-se ao Hub IoT

Um dispositivo pode usar o protocolo MQTT para se conectar a um hub IoT usando uma das seguintes opções:

• Os SDKs de dispositivos IoT do Azure.
• O protocolo MQTT diretamente.

Muitos firewalls corporativos e educacionais bloqueiam a porta MQTT (porta TCP 8883). Se não conseguir abrir a porta 8883 no firewall, use MQTT sobre WebSockets. O MQTT sobre WebSockets se comunica pela porta 443, que quase sempre está aberta. Para aprender a especificar os protocolos MQTT e MQTT sobre WebSockets ao usar os SDKs Azure IoT, consulte Using the device SDKs.

Usar os SDKs do dispositivo

SDKs de dispositivo Azure IoT que suportam o protocolo MQTT estão disponíveis para Java, Node.js, C, C# e Python. Os SDKs de dispositivo usam o mecanismo de autenticação escolhido para estabelecer uma conexão com um hub IoT. Para usar o protocolo MQTT, o parâmetro do protocolo cliente deve ser definido como MQTT. Você também pode especificar MQTT sobre WebSockets no parâmetro de protocolo do cliente. Por defeito, os SDKs dos dispositivos ligam-se a um Hub IoT com a flag CleanSession definida para 0 e usam QoS 1 para troca de mensagens com o IoT hub. Embora seja possível configurar a QoS 0 para uma troca de mensagens mais rápida, você deve observar que a entrega não é garantida e não é reconhecida. Por esta razão, QoS 0 é frequentemente referido como "lançar e esquecer".

Quando um dispositivo se conecta a um hub IoT, os SDKs de dispositivo fornecem métodos que permitem que o dispositivo troque mensagens com um hub IoT.

A tabela seguinte contém ligações para exemplos de código para cada linguagem suportada e especifica o parâmetro a usar para estabelecer uma ligação ao Hub IoT usando o protocolo MQTT ou MQTT over WebSockets.

O seguinte fragmento mostra como especificar o MQTT sobre o protocolo WebSockets quando se usa o 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);

O fragmento seguinte mostra como especificar o protocolo MQTT sobre WebSockets quando se usa o SDK Azure IoT Python:

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

Tempo de expiração padrão para keep-alive

Para garantir que uma conexão de cliente com uma conexão de hub IoT permaneça ativa, tanto o serviço quanto o cliente enviam regularmente um ping keep-alive um para o outro. Se você usar um dos SDKs de dispositivo, o cliente enviará uma mensagem keep-alive no intervalo definido na tabela a seguir:

*O SDK C# define o valor padrão da propriedade MQTT KeepAliveInSeconds como 300 segundos. Na realidade, o SDK envia um pedido de ping quatro vezes durante a duração de keep-alive definida. Em outras palavras, o SDK envia um ping keep-alive uma vez a cada 75 segundos.

De acordo com a especificação MQTT v3.1.1, o intervalo de ping keep-alive do Hub IoT é 1,5 vezes o valor keep-alive do cliente; no entanto, o Hub IoT limita o tempo máximo de espera do lado do servidor a 29,45 minutos (1.767 segundos).

Por exemplo, um dispositivo que usa o SDK Java envia o ping de keep-alive e depois perde a conectividade da rede. 230 segundos depois, o dispositivo perde o ping keep-alive porque está offline. No entanto, Hub IoT não fecha a ligação imediatamente – espera mais (230 * 1.5) - 230 = 115 segundos antes de desligar o dispositivo com o erro 404104 DeviceConnectionClosedRemotely.

O valor máximo de keep-alive do cliente que você pode definir é 1767 / 1.5 = 1177 segundos. Qualquer tráfego redefine o keep-alive. Por exemplo, uma atualização bem-sucedida do token de assinatura de acesso partilhado (SAS) redefine o keep-alive.

Migrar um aplicativo de dispositivo do AMQP para o MQTT

Se estiveres a usar os SDKs device, para mudar de AMQP para MQTT é necessário alterar o parâmetro do protocolo na inicialização do cliente.

Quando você mudar de AMQP para MQTT, verifique os seguintes itens:

• AMQP retorna erros para muitas condições, enquanto MQTT encerra a conexão. Como resultado, talvez seja necessário alterar a lógica de tratamento de exceções.

• O MQTT não suporta a operação de rejeição quando recebe mensagens da nuvem para o dispositivo. Se seu aplicativo back-end precisar receber uma resposta do aplicativo do dispositivo, considere o uso de métodos diretos.

• O AMQP não é suportado no SDK Python.

Use o protocolo MQTT diretamente de um dispositivo

Se um dispositivo não puder usar os SDKs do dispositivo IoT, ele ainda poderá se conectar aos pontos de extremidade do dispositivo público usando o protocolo MQTT na porta 8883.

No pacote CONNECT, o dispositivo deve usar os seguintes valores:

• Para o campo ClientId, use o deviceId.

• Para o campo Nome de usuário, use {iotHub-hostname}/{device-id}/?api-version=2021-04-12, onde {iotHub-hostname} é o nome completo do IoT Hub.

  Por exemplo, se o nome do seu hub IoT for contoso.azure-devices.net e se o nome do seu dispositivo for MyDevice01, o campo Nome de usuário conterá:

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

  Para evitar comportamentos inesperados, inclua a versão da API no campo.

• Para o campo Palavra-passe, use um token SAS. O trecho a seguir mostra o formato do token SAS:

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

  Observação

  Se você usar a autenticação de certificado X.509, as senhas do token SAS não serão necessárias. Para obter mais informações, consulte Tutorial: Criar e carregar certificados para teste e siga as instruções de código na seção de configuração TLS.

  Para mais informações sobre como gerar tokens SAS, consulte a secção Utilizar tokens SAS como um dispositivo da secção Controlar acesso ao Hub IoT usando Assinaturas de Acesso Partilhado.

  Também pode usar a extensão Hub IoT do Azure para Visual Studio Code ou o comando de extensão CLI az iot hub generate-sas-token para gerar um token SAS. Em seguida, você pode copiar e colar o token SAS em seu próprio código para fins de teste.

  A extensão gera um token SAS com a seguinte estrutura:

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

  A parte deste token a ser usada como o campo Senha para se conectar usando MQTT é:

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

O aplicativo de dispositivo pode especificar uma mensagem Will no pacote CONNECT . O aplicativo de dispositivo deve usar devices/{device-id}/messages/events/ ou devices/{device-id}/messages/events/{property-bag} como o nome do tópico Will para definir as mensagens Will a serem encaminhadas como uma mensagem de telemetria. Neste caso, se a ligação à rede estiver fechada, mas um pacote DISCONNECT não tiver sido previamente recebido do dispositivo, então Hub IoT envia a mensagem Will fornecida no pacote CONNECT para o canal de telemetria. O canal de telemetria pode ser o endpoint Events padrão ou um endpoint personalizado definido pelo encaminhamento do Hub IoT. A mensagem tem a propriedade iothub-MessageType com um valor de Will atribuído a ela.

Use o protocolo MQTT diretamente de um módulo

Também pode ligar-se ao Hub IoT através do MQTT usando uma identidade de módulo. Essa abordagem é semelhante à conexão como um dispositivo, mas é necessário usar os seguintes valores:

• Defina o ID do cliente como {device-id}/{module-id}.

• Se estiver autenticando com nome de usuário e senha, defina o nome de usuário como <hubname>.azure-devices.net/{device_id}/{module_id}/?api-version=2021-04-12. Se você estiver usando SAS, use o token SAS associado à identidade do módulo como sua senha.

• Use devices/{device-id}/modules/{module-id}/messages/events/ como um tópico para publicar telemetria.

• Use devices/{device-id}/modules/{module-id}/messages/events/ como o tópico Will.

• Use devices/{device-id}/modules/{module-id}/# como um tópico para receber mensagens.

• Os tópicos gémeos GET e PATCH são os mesmos para módulos e dispositivos.

• O tópico de status duplo é o mesmo para módulos e dispositivos.

Para mais informações sobre o uso do MQTT com módulos, consulte IoT Edge hub MQTT endpoint.

Exemplos usando MQTT sem um SDK de dispositivo Azure IoT

O repositório de exemplos IoT MQTT contém exemplos de C/C++, Python e CLI que mostram como enviar mensagens de telemetria, receber mensagens cloud para dispositivo e usar dispositivos gémeos sem usar os SDKs Azure dispositivos.

Os exemplos C/C++ usam a biblioteca Eclipse Mosquitto, o exemplo Python usa Eclipse Paho, e os samples CLI usam mosquitto_pub.

Para saber mais, consulte Tutorial - Usar MQTT para desenvolver um cliente de dispositivo IoT sem usar um SDK de dispositivo.

Configuração do TLS

Para usar o protocolo MQTT diretamente, seu cliente deve se conectar por TLS 1.2. Qualquer tentativa de pular esta etapa falhará com erros de conexão.

Para estabelecer uma ligação TLS, pode ser necessário descarregar e referenciar o certificado raiz DigiCert Global Root G2 que o Azure utiliza. Para obter mais informações sobre este certificado, consulte o site da Digicert.

O exemplo seguinte demonstra como implementar esta configuração, utilizando a versão Python da biblioteca MQTT Paho.

Primeiro, instale a biblioteca Paho a partir do seu ambiente de linha de comando:

pip install paho-mqtt

Depois, implementa o cliente num script Python. Substitua esses marcadores no seguinte trecho de código:

• <local path to digicert.cer> é o caminho para um arquivo local que contém o certificado raiz DigiCert. Pode criar este ficheiro copiando a informação do certificado de certs.c no Azure IoT SDK para C. Inclua as linhas -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----, remova as marcas " no início e fim de cada linha, e remova os caracteres \r\n no final de cada linha.

• <device id from device registry> é a ID de um dispositivo que você adicionou ao seu hub IoT.

• <generated SAS token> é um token SAS para o dispositivo criado conforme descrito anteriormente neste artigo.

• <iot hub name> o nome do seu hub IoT.

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()

Para autenticar usando um certificado de dispositivo, atualize o trecho de código anterior com as alterações especificadas no trecho de código a seguir. Para obter mais informações sobre como se preparar para a autenticação baseada em certificados, consulte a seção Obter um certificado de autoridade de certificação X.509 de Autenticar identidades com certificados 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)

Enviar mensagens do dispositivo para a nuvem

Depois de um dispositivo se ligar, pode enviar mensagens para Hub IoT usando devices/{device-id}/messages/events/ ou devices/{device-id}/messages/events/{property-bag} como Nome do Tópico. O {property-bag} elemento permite que o dispositivo envie mensagens com outras propriedades em um formato codificado por url. Por exemplo:

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

Este {property_bag} elemento usa a mesma codificação que cadeias de caracteres de consulta no protocolo HTTPS.

Se estiver a encaminhar mensagens D2C para uma conta Armazenamento do Azure e quiser usar codificação JSON, deve especificar o Tipo de Conteúdo e a informação de Codificação de Conteúdo, incluindo $.ct=application%2Fjson&$.ce=utf-8, como parte do {property_bag} mencionado na nota anterior.

A lista seguinte resume os comportamentos específicos da implementação do Hub IoT MQTT:

• O Hub IoT não suporta mensagens QoS 2. Se uma aplicação de dispositivo publicar uma mensagem com QoS 2, Hub IoT fecha a ligação de rede.

• Hub IoT não persiste Retain mensagens. Se um dispositivo enviar uma mensagem com a flag RETAIN definida para 1, Hub IoT adiciona a propriedade de aplicação mqtt-retain à mensagem. Neste caso, em vez de persistir a mensagem retida, o Hub IoT passa-a para a aplicação backend.

• O Hub IoT suporta apenas uma ligação MQTT ativa por dispositivo. Qualquer nova ligação MQTT em nome do mesmo ID de dispositivo faz com que Hub IoT desligue a ligação existente e escreva 400027 ConnectionForcefullyClosedOnNewConnection nos registos de Hub IoT

• Para rotear mensagens com base no corpo da mensagem, primeiro adicione a propriedade ct ao final do tópico MQTT e defina seu valor como application/json;charset=utf-8 mostrado no exemplo a seguir. Para mais informações sobre encaminhamento de mensagens, seja com base nas propriedades ou no corpo da mensagem, consulte a documentação da sintaxe de encaminhamento de mensagens Hub IoT.

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

Para mais informações, consulte Enviar e receber mensagens com Hub IoT.

Receba mensagens da nuvem para o dispositivo

Para receber mensagens de Hub IoT, o dispositivo deve subscrever usando devices/{device-id}/messages/devicebound/# como Topic Filter. O curinga de vários níveis no filtro de tópico permite que o dispositivo receba mais propriedades no nome do tópico. O Hub IoT não permite o uso dos carateres curinga # ou ? para filtrar tópicos secundários. O Hub IoT não é um intermediário de mensagens de publicação-subscrição de uso geral, apenas suporta os nomes e filtros de tópicos documentados. Um dispositivo só pode subscrever cinco tópicos de cada vez.

O dispositivo não recebe nenhumas mensagens do Hub IoT até subscrever com sucesso ao seu endpoint específico do dispositivo, representado pelo filtro de tópico devices/{device-id}/messages/devicebound/#. Depois que uma assinatura é estabelecida, o dispositivo recebe mensagens da nuvem para o dispositivo que foram enviadas para ele após o tempo da assinatura. Se o dispositivo se conectar com a flag CleanSession definida como 0, a assinatura será persistida em sessões diferentes. Nesse caso, da próxima vez que o dispositivo se conectar com o CleanSession 0 , ele receberá todas as mensagens pendentes enviadas a ele enquanto estiver desconectado. Se o dispositivo usar a flag CleanSession definida para 1, no entanto, não recebe nenhuma mensagem de Hub IoT até subscrever o endpoint do dispositivo.

Hub IoT entrega mensagens com o Nome do Tópicodevices/{device-id}/messages/devicebound/, ou devices/{device-id}/messages/devicebound/{property-bag} quando existem propriedades de mensagem. {property-bag} Contém pares chave/valor das propriedades de mensagem codificados por URL. Somente as propriedades do aplicativo e as propriedades do sistema configuráveis pelo usuário (como messageId ou correlationId) são incluídas no pacote de propriedades. Os nomes de propriedade do sistema têm o prefixo $, as propriedades do aplicativo usam o nome da propriedade original sem prefixo. Para obter mais informações sobre o formato do pacote de propriedades, consulte Envio de mensagens do dispositivo para a nuvem.

Em mensagens de nuvem para dispositivo, os valores no pacote de propriedades são representados como na tabela a seguir:

O exemplo a seguir mostra um conjunto de propriedades que contém três propriedades de aplicativo: prop1 com um valor de null; prop2, uma corda vazia (""); e prop3 com um valor de "uma corda".

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

Quando uma aplicação de dispositivo subscreve um tópico com QoS 2, Hub IoT concede o nível máximo de QoS 1 no pacote SUBACK. Depois disso, o Hub IoT entrega mensagens ao dispositivo usando QoS 1.

Recuperar propriedades gêmeas do dispositivo

Primeiro, um dispositivo assina $iothub/twin/res/#, para receber as respostas da operação. Em seguida, ele envia uma mensagem vazia para o tópico $iothub/twin/GET/?$rid={request id}, com um valor preenchido para ID de solicitação. Em seguida, o serviço envia uma mensagem de resposta contendo os dados do gémeo do dispositivo no tópico $iothub/twin/res/{status}/?$rid={request-id}, usando o mesmo ID de pedido.

O ID da solicitação pode ser qualquer valor válido para um valor de propriedade de mensagem e o status é validado como um inteiro. Para mais informações, consulte Enviar e receber mensagens com Hub IoT.

O corpo da resposta contém a seção de propriedades do gêmeo do dispositivo, conforme mostrado no exemplo de resposta a seguir:

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

Os códigos de status possíveis são:

Para mais informações, veja Compreenda e use os gémeos de dispositivos em Hub IoT.

Atualizar propriedades relatadas do gêmeo do dispositivo

Para atualizar as propriedades reportadas, o dispositivo faz uma solicitação ao Hub IoT, publicando para um tópico MQTT designado. Depois de o Hub IoT processar o pedido, responde com o estado de sucesso ou falha da operação de atualização ao publicar noutro tópico. O dispositivo pode subscrever este tópico para receber notificações sobre o resultado do pedido de atualização gémea. Para implementar esse tipo de interação solicitação/resposta no MQTT, o dispositivo fornece um ID de solicitação ($rid) em sua solicitação de atualização inicial. Este ID de pedido é então incluído na resposta do Hub IoT para permitir que o dispositivo correlacione a resposta com o pedido correto.

A sequência seguinte descreve como um dispositivo atualiza as propriedades reportadas no dispositivo gémeo no Hub IoT:

1. Um dispositivo subscreve primeiro o tópico $iothub/twin/res/# para permitir que receba respostas de Hub IoT.

2. Um dispositivo envia uma mensagem que contém a atualização gêmea do dispositivo para o $iothub/twin/PATCH/properties/reported/?$rid={request-id} tópico. Esta mensagem inclui um valor de ID de solicitação.

3. Em seguida, o serviço envia uma mensagem de resposta que contém o novo valor ETag para a coleção de propriedades relatadas no tópico $iothub/twin/res/{status}/?$rid={request-id}. Essa mensagem de resposta usa a mesma ID de solicitação que a solicitação.

O corpo da mensagem de solicitação contém um documento JSON que contém novos valores para propriedades relatadas. Cada membro no documento JSON atualiza ou adiciona o membro correspondente no documento do gêmeo do dispositivo. Um membro, quando configurado para null, apaga o membro do objeto que o contém. Por exemplo:

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

Os códigos de status possíveis são:

O seguinte excerto de código Python demonstra o processo de atualização das propriedades reportadas gêmeas sobre MQTT usando o cliente 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)

Quando o processo de atualização de propriedades reportadas do gémeo digital tem sucesso, o Hub IoT publica uma mensagem para o seguinte tópico: $iothub/twin/res/204/?$rid=1&$version=6, onde 204 é o código de estado que indica sucesso, $rid=1 corresponde ao ID do pedido fornecido pelo dispositivo no código, e $version corresponde à versão da secção das propriedades reportadas do gémeo digital após a atualização.

Para mais informações, veja Compreenda e use os gémeos de dispositivos em Hub IoT.

Receber notificações de atualização de propriedades desejadas

Quando um dispositivo está ligado, Hub IoT envia notificações para o tópico $iothub/twin/PATCH/properties/desired/?$version={new-version}, que contêm o conteúdo da atualização realizada pelo backend da solução. Por exemplo:

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

Quanto às atualizações de propriedade, null os valores significam que o membro do objeto JSON está sendo excluído. Além disso, $version indica a nova versão da seção de propriedades desejadas do gêmeo.

Para mais informações, veja Compreenda e use os gémeos de dispositivos em Hub IoT.

Responder a um método direto

Primeiro, um dispositivo subscreve o $iothub/methods/POST/#. Hub IoT envia pedidos de método para o tópico $iothub/methods/POST/{method-name}/?$rid={request-id}, com um JSON válido ou um corpo vazio.

Para responder, o dispositivo envia uma mensagem com um JSON válido ou corpo vazio para o tópico $iothub/methods/res/{status}/?$rid={request-id}. Nesta mensagem, o ID da solicitação deve corresponder ao da mensagem de solicitação, e o status deve ser um inteiro.

Para mais informações, veja Compreender e invocar métodos diretos de Hub IoT.

Renovar um certificado de dispositivo (certificado operacional)

1. Primeiro, um dispositivo subscreve a $iothub/credential/#, para permitir que receba a resposta da operação.

2. Depois, publica uma mensagem para o tópico $iothub/credentials/POST/issueCertificate/?$rid={request_id}, onde a mensagem inclui um valor de ID de pedido. O corpo do pedido contém o ID do dispositivo que solicita o certificado e um pedido de assinatura de certificado (CSR).

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

3. O serviço envia então uma mensagem de resposta contendo os dados do certificado do dispositivo no tópico $iothub/credential/res/{status}/?$rid={request-id}, usando o mesmo ID de solicitação do pedido original.

O ID da solicitação pode ser qualquer valor válido para um valor de propriedade de mensagem e o status é validado como um inteiro. Para mais informações, consulte Enviar e receber mensagens com Hub IoT.

O corpo da resposta contém a cadeia completa para o certificado de dispositivo renovado, como mostra o seguinte exemplo de resposta:

{
  "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
  ]
}

Os códigos de status possíveis são:

**Para mais informações, veja Renovação de certificados de dispositivo em Hub IoT do Azure gestão de certificados

Passos seguintes

Para saber mais sobre como usar o MQTT, consulte:

• Documentação MQTT
• Tutorial - Use o MQTT para desenvolver um cliente de dispositivo IoT sem usar um SDK de dispositivo
• Exemplos de aplicações MQTT
• Azure IoT SDKs