Comunicar-se com um hub IoT usando o protocolo MQTT

Este artigo descreve como os dispositivos podem usar o protocolo MQTT para se comunicar com Azure IoT Hub. Os pontos de extremidade do dispositivo IoT Hub dão suporte à conectividade do dispositivo usando:

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

Toda a comunicação do dispositivo com IoT Hub deve ser protegida usando TLS. Portanto, IoT Hub não dá suporte a conexões MQTT inseguras pela porta 1883.

Comparar o suporte ao MQTT no IoT Hub e na Grade de Eventos

IoT Hub não é um agente MQTT completo e não dá suporte a todos os comportamentos especificados no padrão MQTT v3.1.1. Se sua solução precisar de um agente MQTT hospedado na nuvem, use Azure Event Grid em vez disso. Event Grid permite comunicações bidirecionais entre clientes MQTT em tópicos hierárquicos flexíveis usando um modelo de mensagens de publicação-assinatura. Ele também permite rotear mensagens MQTT para outros serviços Azure ou pontos de extremidade personalizados para processamento adicional.

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

Conectar-se ao IoT Hub

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

• Os SDKs do dispositivo Azure IoT.
• Protocolo MQTT diretamente.

Muitos firewalls corporativos e educacionais bloqueiam a porta MQTT (porta TCP 8883). Se você não conseguir abrir a porta 8883 no firewall, use MQTT via WebSockets. O MQTT via WebSockets se comunica pela porta 443, que está quase sempre aberta. Para saber como especificar os protocolos MQTT e MQTT sobre WebSockets ao usar os SDKs de Azure IoT, consulte Utilizando os SDKs do dispositivo.

Usar os SDKs do dispositivo

Azure IoT SDKs de dispositivo que dão suporte ao protocolo MQTT estão disponíveis para Java, Node.js, C, C#e Python. Os SDKs do 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 do cliente deve ser definido como MQTT. Você também pode especificar MQTT por WebSockets no parâmetro de protocolo do cliente. Por padrão, os SDKs do dispositivo se conectam a um IoT Hub com o sinalizador CleanSession definido como 0 e usam QoS 1 para troca de mensagens com o IoT hub. Embora seja possível configurar o QoS 0 para uma troca de mensagens mais rápida, observe que a entrega não é garantida e não é confirmada. Por esse motivo, o QoS 0 é geralmente chamado de "fire and forget".

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

A tabela a seguir contém links para exemplos de código para cada idioma com suporte e especifica o parâmetro a ser usado para estabelecer uma conexão com IoT Hub usando o protocolo MQTT ou MQTT sobre WebSockets.

O fragmento a seguir mostra como especificar o protocolo MQTT sobre WebSockets ao usar o SDK do 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 a seguir mostra como especificar o protocolo MQTT sobre WebSockets ao usar o SDK do Azure IoT Python:

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

Tempo limite padrão de keep-alive

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

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

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

Por exemplo, um dispositivo que usa o SDK de Java envia o ping keep-alive e, em seguida, perde a conectividade de rede. Depois de 230 segundos, o dispositivo perde o ping de Keep Alive porque está offline. No entanto, IoT Hub não fecha a conexão imediatamente - ela aguarda mais (230 * 1.5) - 230 = 115 segundos antes de desconectar 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 SAS (assinatura de acesso compartilhado) redefine o keep-alive.

Migrar um aplicativo de dispositivo do AMQP para o MQTT

Se você estiver usando os SDKs device, para mudar de usar AMQP para MQTT exigirá que você altere o parâmetro de protocolo na inicialização do cliente.

Ao alterar de AMQP para MQTT, verifique os seguintes itens:

• AMQP retorna erros para várias 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 dá suporte à operação de rejeição quando recebe mensagens de nuvem para dispositivo. Se o aplicativo de back-end precisar receber uma resposta do aplicativo de dispositivo, considere usar métodos diretos.

• O AMQP não tem suporte no SDK do Python.

Usar 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:

• No campo ClientId, use o deviceId.

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

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

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

  Para evitar um comportamento inesperado, inclua a versão da API no campo.

• No campo de senha Senha insira um token SAS. O snippet 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 de token SAS não serão necessárias. Para obter mais informações, consulte Tutorial: Criar e carregar certificados para teste e seguir instruções de código na seção de configuração do TLS.

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

  Você também pode usar a extensão Azure IoT Hub para Visual Studio Code ou o comando de extensão da CLI az iot hub generate-sas-token para gerar um token SAS. Em seguida, você pode copiar e colar o token SAS em seu 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 desse token para usar como o campo Senha para conectar usando MQTT é:

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

O aplicativo do 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. Nesse caso, se a conexão de rede for fechada, mas um pacote DISCONNECT não foi recebido anteriormente do dispositivo e IoT Hub envia a mensagem Will fornecida no pacote CONNECT para o canal de telemetria. O canal de telemetria pode ser o ponto de extremidade padrão Events ou um ponto de extremidade personalizado definido pelo roteamento IoT Hub. A mensagem tem a propriedade iothub-MessageType com um valor de Will atribuído a ele.

Usar o protocolo MQTT diretamente de um módulo

Você também pode se conectar a IoT Hub por MQTT usando uma identidade de módulo. Essa abordagem é semelhante à conexão como um dispositivo, mas você precisa usar os seguintes valores:

• Defina a 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 tópico para a publicação de 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 o recebimento de mensagens.

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

• O tópico de status do gêmeo é o mesmo para módulos e dispositivos.

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

Exemplos usando MQTT sem um SDK do dispositivo Azure IoT

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

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

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

Configuração TLS

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

Para estabelecer uma conexão TLS, talvez seja necessário baixar e referenciar o certificado raiz DigiCert Global Root G2 que Azure usa. Para obter mais informações sobre esse certificado, consulte o site da Digicert.

O exemplo a seguir demonstra como implementar essa configuração usando a versão Python da biblioteca Paho MQTT.

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

pip install paho-mqtt

Em seguida, implemente o cliente em um script Python. Substitua estes espaços reservados no seguinte snippet de código:

• <local path to digicert.cer> é o caminho para um arquivo local que contém o certificado raiz DigiCert. Você pode criar esse arquivo copiando as informações 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 no final 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 de 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 snippet de código anterior com as alterações especificadas no snippet de código a seguir. Para obter mais informações sobre como se preparar para autenticação baseada em certificado, consulte a seção Obter um certificado de AC 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 que um dispositivo se conecta, ele pode enviar mensagens para IoT Hub usando devices/{device-id}/messages/events/ ou devices/{device-id}/messages/events/{property-bag} como um Topic Name. O elemento {property-bag} habilita o dispositivo a enviar mensagens com outras propriedades em um formato codificado de URL. Por exemplo:

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

Esse elemento {property_bag} usa a mesma codificação de cadeias de caracteres de consulta do protocolo HTTPS.

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

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

• IoT Hub não dá suporte a mensagens QoS 2. Se um aplicativo de dispositivo publicar uma mensagem com QoS 2, IoT Hub fechará a conexão de rede.

• IoT Hub não persiste Retain mensagens. Se um dispositivo enviar uma mensagem com o sinalizador RETAIN definido como 1, IoT Hub adicionará a propriedade do aplicativo mqtt-retain à mensagem. Nesse caso, em vez de persistir a mensagem retida, IoT Hub passa-a para o aplicativo de back-end.

• IoT Hub dá suporte apenas a uma conexão MQTT ativa por dispositivo. Qualquer nova conexão MQTT em nome da mesma ID do dispositivo faz com que IoT Hub solte a conexão existente e escreva 400027 ConnectionForcefullyClosedOnNewConnection nos logs de IoT Hub

• 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 obter mais informações sobre o roteamento de mensagens com base nas propriedades da mensagem ou no corpo da mensagem, consulte a documentação da sintaxe de consulta de roteamento de mensagens IoT Hub.

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

Para obter mais informações, consulte Send e receba mensagens com IoT Hub.

Receber mensagens da nuvem para o dispositivo

Para receber mensagens de IoT Hub, um dispositivo deve assinar usando devices/{device-id}/messages/devicebound/# como um Filtro de Tópico. O curinga # de vários níveis no filtro de tópico permite que o dispositivo receba mais propriedades no nome do tópico. IoT Hub não permite o uso dos caracteres curingas # ou ? para filtrar subtópicos. O IoT Hub não é um broker de mensagens de publicação/assinatura de uso geral; ele suporta apenas os nomes de tópicos e filtros de tópicos documentados. Um dispositivo só pode assinar cinco tópicos por vez.

O dispositivo não recebe nenhuma mensagem do Hub IoT até assinar com êxito seu ponto de extremidade específico do dispositivo, representado pelo filtro de tópico devices/{device-id}/messages/devicebound/#. Depois que uma assinatura é estabelecida, o dispositivo recebe mensagens de nuvem para dispositivo que foram enviadas a ela após o momento da assinatura. Se o dispositivo se conectar com o sinalizador CleanSession definido como 0, a assinatura será persistida entre as diferentes sessões. Neste caso, a próxima vez que o dispositivo conectar-se com CleanSession 0, ele receberá todas as mensagens pendentes enviadas a ele enquanto estava desconectado. Se o dispositivo usar o sinalizador CleanSession definido como 1, ele não receberá mensagens do Hub IoT até que assine o ponto de extremidade do dispositivo.

IoT Hub entrega mensagens com o Topic Namedevices/{device-id}/messages/devicebound/ ou devices/{device-id}/messages/devicebound/{property-bag} quando há propriedades de mensagem. {property-bag} contém pares de chave/valor codificados de URL das propriedades da mensagem. Somente propriedades de aplicativo e propriedades do sistema definível pelo usuário (como messageId ou correlationId) estão incluídas no recipiente 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 recipiente de propriedades, confira Enviando mensagens do dispositivo para nuvem.

Em mensagens da nuvem para dispositivo, os valores no recipiente de propriedades são representados como na seguinte tabela:

O seguinte exemplo mostra um recipiente de propriedades que contém três propriedades de aplicativo: prop1 com o valor null; prop2, uma cadeia de caracteres vazia (""); e prop3 com o valor "uma cadeia de caracteres".

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

Quando um aplicativo de dispositivo se inscreve em um tópico com QoS 2, o IoT Hub concede o nível máximo permitido de QoS, que é 1, no pacote SUBACK. Depois disso, IoT Hub entrega mensagens ao dispositivo usando o QoS 1.

Recuperar propriedades do dispositivo gêmeo

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

A 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 obter mais informações, consulte Send e receba mensagens com IoT Hub.

O corpo de resposta contém a seção de propriedades do dispositivo gêmeo, como no seguinte exemplo de resposta:

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

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

Para obter mais informações, consulte Compreender e usar dispositivos gêmeos em IoT Hub.

Atualizar as propriedades relatadas do dispositivo gêmeo

Para atualizar as propriedades relatadas, o dispositivo emite uma solicitação para IoT Hub publicando em um tópico MQTT designado. Depois que IoT Hub processa a solicitação, ela responde com o status de êxito ou falha da operação de atualização publicando em outro tópico. O dispositivo pode assinar este tópico para receber notificações sobre o resultado da solicitação de atualização do gêmeo. Para implementar esse tipo de interação de solicitação/resposta no MQTT, o dispositivo fornece uma ID de solicitação ($rid) em sua solicitação de atualização inicial. Essa ID de solicitação é incluída na resposta de IoT Hub para habilitar o dispositivo a correlacionar a resposta à solicitação correta.

A sequência a seguir descreve como um dispositivo atualiza as propriedades relatadas no dispositivo gêmeo em IoT Hub:

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

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

3. Em seguida, o serviço envia uma mensagem de resposta que contém o novo valor de 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 da 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 dispositivo gêmeo. Um membro definido como null exclui 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 trecho de código Python demonstra o processo de atualização das propriedades gêmeas relatadas por 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 relatadas do gêmeo for bem-sucedido, IoT Hub publicará uma mensagem no seguinte tópico: $iothub/twin/res/204/?$rid=1&$version=6, em que 204 é o código de status que indica êxito, $rid=1 corresponde à ID da solicitação fornecida pelo dispositivo no código e $version corresponde à versão da seção de propriedades relatadas dos dispositivos gêmeos após a atualização.

Para obter mais informações, consulte Compreender e usar dispositivos gêmeos em IoT Hub.

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

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

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

Em relação às atualizações de propriedade, valores null 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 desejada do gêmeo.

Para obter mais informações, consulte Compreender e usar dispositivos gêmeos em IoT Hub.

Responder a um método direto

Primeiro, um dispositivo assina $iothub/methods/POST/#. IoT Hub envia solicitações 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 um corpo vazio para o tópico $iothub/methods/res/{status}/?$rid={request-id}. Nessa mensagem, a ID da Solicitação deve corresponder com o da mensagem de solicitação e o status deve ser um número inteiro.

Para obter mais informações, consulte Compreender e invocar métodos diretos do IoT Hub.

Renovar um certificado do dispositivo (certificado operacional)

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

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

{       
	"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. Em seguida, o serviço envia uma mensagem de resposta que contém os dados do certificado do dispositivo no tópico $iothub/credential/res/{status}/?$rid={request-id}, usando a mesma ID de solicitação que a solicitação.

A 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 obter mais informações, consulte Send e receba mensagens com IoT Hub.

O corpo da resposta contém a cadeia completa do certificado de dispositivo renovado, conforme mostrado no exemplo de resposta a seguir:

{
  "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 obter mais informações, consulte Renovação de certificado de dispositivo no gerenciamento de certificados do Azure IoT Hub

Próximas Etapas 

Para saber mais sobre como usar o MQTT, confira:

• Documentação do MQTT
• Tutorial - Usar o MQTT para desenvolver um cliente do dispositivo IoT sem usar um SDK do dispositivo
• exemplos de aplicativo MQTT
• SDKs de IoT do Azure