Compartilhar via

Suporte ao MQTT 5 para IoT Hub (preterido)

  • Artigo

Versão: 2.0 versão da api: 2020-10-01-versão prévia

Este documento define a API do plano de dados do Hub IoT sobre o protocolo MQTT versão 5.0. Confira a Referência da API para obter definições completas nesta API.

Observação

O suporte ao MQTT 5 no Hub IoT foi preterido e o Hub IoT tem suporte limitado de recursos para MQTT. Se a sua solução precisar de suporte para MQTT v3.1.1 ou v5, recomendamos o suporte ao MQTT na Grade de Eventos do Azure. Para obter mais informações, confira Comparar o suporte ao MQTT no Hub IoT e na Grade de Eventos.

Pré-requisitos

  • Crie um novo hub IoT com o modo de pré-visualização habilitado. O MQTT 5 só está disponível no modo de pré-visualização e você não pode alternar um hub IoT existente para o modo de pré-visualização. Para obter mais informações, confira Habilitar o modo de pré-visualização
  • Conhecimento prévio sobre a especificação MQTT 5.

Nível de suporte e limitações

O suporte do Hub IoT ao MQTT 5 está em versão prévia e é limitado das seguintes maneiras (comunicado ao cliente por meio de propriedades CONNACK, a menos que explicitamente indicado de outra forma):

  • Ainda não há suporte oficial para SDKs do dispositivo IoT do Azure.
  • Não há suporte para identificadores de assinatura.
  • Não há suporte para assinaturas compartilhadas.
  • Não há suporte para RETAIN.
  • Maximum QoS é 1.
  • Maximum Packet Size é 256 KiB (sujeito a restrições adicionais por operação).
  • Não há suporte às IDs de cliente atribuídas.
  • Keep Alive é limitado a 19 min (atraso máximo para verificação de atividade – 28.5 min ).
  • Topic Alias Maximum é 10.
  • Não há suporte para Response Information; CONNACK não retorna a propriedade Response Information, mesmo que CONNECT contenha a propriedade Request Response Information.
  • Receive Maximum (número máximo permitido de pacotes PUBLISH não confirmados pendentes (na direção cliente-servidor com QoS: 1) é 16.
  • Um cliente único não pode ter mais do que 50 assinaturas. Se um cliente atingir o limite de assinatura, SUBACK retornará o código de motivo 0x97 (cota excedida) para assinaturas.

Ciclo de vida da conexão

Conexão

Para conectar um cliente ao Hub IoT usando essa API, estabeleça conexão de acordo com a especificação MQTT 5. O cliente deverá enviar o pacote CONNECT dentro de 30 segundos após um handshake de TLS bem-sucedido; caso contrário, o servidor fechará a conexão. Este é um exemplo de pacote CONNECT:

-> CONNECT
    Protocol_Version: 5
    Clean_Start: 0
    Client_Id: D1
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    api-version: 2020-10-10
    host: abc.azure-devices.net
    sas-at: 1600987795320
    sas-expiry: 1600987195320
    client-agent: artisan;Linux
  • A propriedade Authentication Method é necessária e identifica qual método de autenticação é usado. Para obter mais informações sobre métodos de autenticação, confira Autenticação.
  • A manipulação da propriedade Authentication Data depende de Authentication Method. Se Authentication Method estiver definido como SAS, Authentication Data será obrigatório e deverá conter uma assinatura válida. Para obter mais informações sobre dados de autenticação, confira Autenticação.
  • A propriedade api-version é necessária e deve ser definida como o valor de versão da API fornecido no cabeçalho desta especificação para que ela seja aplicada.
  • A propriedade host define o nome do host do locatário. É necessária, a menos que a extensão SNI tenha sido apresentada no registro de saudação do cliente durante o handshake de TLS
  • sas-at define a hora da conexão.
  • sas-expiry define a hora de expiração para a SAS fornecida.
  • Opcionalmente, client-agent comunica informações sobre o cliente que está criando a conexão.

Observação

Authentication Method e outras propriedades em toda a especificação com nomes em letras maiúsculas são propriedades de primeira classe no MQTT 5 (elas são descritas em detalhes na especificação MQTT 5). api-version e outras propriedades com nomes separados por hifens são propriedades do usuário específicas para a API do Hub IoT.

O Hub IoT responde com o pacote CONNACK quando termina de autenticar e busca dados para viabilizar a conexão. Se a conexão for estabelecida com sucesso, CONNACK será semelhante a:

<- CONNACK
    Session_Present: 1
    Reason_Code: 0x00
    Session_Expiry_Interval: 0xFFFFFFFF # included only if CONNECT specified value less than 0xFFFFFFFF and more than 0x00
    Receive_Maximum: 16
    Maximum_QoS: 1
    Retain_Available: 0
    Maximum_Packet_Size: 262144
    Topic_Alias_Maximum: 10
    Subscription_Identifiers_Available: 0
    Shared_Subscriptions_Available: 0
    Server_Keep_Alive: 1140 # included only if client did not specify Keep Alive or if it specified a bigger value

As propriedades de pacote CONNACK seguem a especificação MQTT 5. Elas refletem os recursos do Hub IoT.

Autenticação

A propriedade Authentication Method no cliente CONNECT define o tipo de autenticação que será usada para esta conexão:

  • SAS - a assinatura de acesso compartilhado é fornecida na propriedade Authentication Data de CONNECT.
  • X509 - o cliente depende da autenticação de certificado do cliente.

A autenticação falhará se o método de autenticação não corresponder ao método configurado pelo cliente no Hub IoT.

Observação

Essa API exige que a propriedade Authentication Method seja definida no pacote CONNECT. Se a propriedade Authentication Method não for fornecida, a conexão falhará com a resposta Bad Request.

Não há suporte para a autenticação de nome de usuário/senha usada em versões anteriores da API.

SAS

Com a autenticação baseada em SAS, um cliente deve fornecer a assinatura do contexto de conexão. A assinatura comprova a autenticidade da conexão do MQTT. A assinatura deve ser baseada em uma das duas chaves de autenticação na configuração do cliente no Hub IoT. Ou deve ser baseado em uma das duas chaves de acesso compartilhado de uma política de acesso compartilhado.

A cadeia de caracteres a ser assinada deve ser formada da seguinte maneira:

{host name}\n
{Client Id}\n
{sas-policy}\n
{sas-at}\n
{sas-expiry}\n
  • host name é derivado de uma extensão SNI (apresentada pelo cliente no registro de saudação do cliente durante o handshake de TLS) ou da propriedade host do usuário no pacote CONNECT.
  • Client Id é o identificador do cliente no pacote CONNECT.
  • sas-policy - se presente, define a política de acesso do Hub IoT usada na autenticação. É codificado como uma propriedade de usuário no pacote CONNECT. Opcional: omitir isso significa que as configurações de autenticação no registro do dispositivo são usadas em seu lugar.
  • sas-at - se presente, especifica a hora da conexão (hora atual). É codificado como a propriedade de usuário de tipo time no pacote CONNECT.
  • sas-expiry define a hora de expiração para a autenticação. É uma propriedade de usuário com tipo time no pacote CONNECT. Esta propriedade é necessária.

Para parâmetros opcionais, se omitida, uma cadeia de caracteres vazia DEVERÁ ser usada no lugar de uma cadeia de caracteres para entrar.

HMAC-SHA256 é usado para aplicar o hash à cadeia de caracteres com base em uma das chaves simétricas do dispositivo. O valor de hash é então definido como o valor da propriedade Authentication Data.

X509

Se a propriedade Authentication Method for definida como X509, o Hub IoT autenticará a conexão com base no certificado de cliente fornecido.

Reautenticação

Se a autenticação baseada em SAS for usada, recomendamos o uso de tokens de autenticação de curta duração. Para manter a conexão autenticada e impedir a desconexão devido à expiração, o cliente deve autenticar novamente enviando um pacote AUTH com Reason Code: 0x19 (reautenticação):

-> AUTH
    Reason_Code: 0x19
    Authentication_Method: SAS
    Authentication_Data: {SAS bytes}
    sas-at: {current time}
    sas-expiry: {SAS expiry time}

Regras:

  • Authentication Method deve ser o mesmo usado para a autenticação inicial
  • se a conexão foi autenticada originalmente usando SAS com base na política de acesso compartilhado, a assinatura usada na reautenticação deverá ser baseada nessa mesma política.

Se a reautenticação for bem-sucedida, o Hub IoT enviará um pacote AUTH com Reason Code: 0x00 (sucesso). Caso contrário, o Hub IoT enviará um pacote DISCONNECTcom Reason Code: 0x87 (não autorizado) e fechará a conexão.

Desconexão

O servidor pode desconectar o cliente por alguns motivos, incluindo:

  • o cliente demostra comportamento inadequado de modo que é impossível responder diretamente com a confirmação (ou resposta) negativa,
  • o servidor falha ao manter o estado da conexão atualizado,
  • outro cliente se conecta com a mesma identidade.

O servidor pode se desconectar com qualquer código de motivo definido na especificação MQTT 5.0. Menção notáveis:

  • 135 (não autorizado) quando a reautenticação falha, o token SAS atual expira ou as credenciais do dispositivo mudam.
  • 142 (sessão capturada) quando uma nova conexão com a mesma identidade do cliente for aberta.
  • 159 (taxa de conexão excedida) quando a taxa de conexão do hub IoT excede o limite.
  • 131 (erro específico da implementação) é usado para erros personalizados definidos nesta API. As propriedades status e reason são usadas para comunicar mais detalhes sobre a causa da desconexão (confira Resposta para obter detalhes).

Operations

Todas as funcionalidades desta API são expressas como operações. Este é um exemplo de operação de envio de telemetria:

-> PUBLISH
    QoS: 1
    Packet_Id: 3
    Topic: $iothub/telemetry
    Payload: Hello

<- PUBACK
    Packet_Id: 3
    Reason_Code: 0

Para obter a especificação completa das operações nesta API, consulte a Referência da API MQTT 5 do plano de dados do Hub IoT.

Observação

Todas as amostras nesta especificação são mostradas a partir da perspectiva do cliente. Entrar em -> significa que o cliente está enviando o pacote e que <- está recebendo.

Tópicos e assinaturas da mensagem

Os tópicos usados nas mensagens das operações nesta API começam com $iothub/. A semântica do agente MQTT não se aplica a essas operações (confira "Tópicos que começam com $" para obter detalhes). Não há suporte para tópicos que começam com $iothub/ e que não estão definidos nesta API:

  • Enviar mensagens para resultados indefinidos do tópico na resposta Not Found (confira Resposta para obter detalhes),
  • Assinar resultados indefinidos do tópico no SUBACK com Reason Code: 0x8F (filtro de tópico inválido).

Nomes de tópico e nomes de propriedade diferenciam maiúsculas de minúsculas e devem ser correspondências exatas. Por exemplo, $iothub/telemetry/ não é suportado, mas $iothub/telemetry é.

Observação

Curingas em assinaturas em $iothub/.. não são suportados. Ou seja, um cliente não pode assinar $iothub/+ ou $iothub/#. A tentativa de fazer isso resulta em SUBACK com Reason Code: 0xA2 (sem suporte a assinaturas curinga). Somente curingas de segmento único (+) têm suporte em vez de parâmetros de caminho no nome do tópico para operações que os incluem.

Tipos de interação

Todas as operações nessa API se baseiam em um de dois tipos de interação:

  • Mensagem com confirmação opcional (MessageAck)
  • Solicitação-resposta (ReqRep)

As operações também variam de acordo com a direção (determinada pela direção da mensagem inicial que está sendo trocada):

  • Cliente para servidor (c2s)
  • Servidor para cliente (s2c)

Por exemplo, a telemetria de envio é uma operação de Cliente para servidor do tipo "Mensagem com confirmação", enquanto que Lidar com método direto é uma operação de Servidor para cliente do tipo Solicitação-resposta.

Interações de confirmação de mensagem

A interação de mensagem com confirmação opcional (MessageAck) é expressa como uma troca dos pacotes PUBLISH e PUBACK no MQTT. A confirmação é opcional e o remetente pode optar por não solicitá-la, enviando um pacote PUBLISH com QoS: 0.

Observação

Se as propriedades no pacote PUBACK precisarem ser truncadas devido a um Maximum Packet Size declarado pelo cliente, o Hub IoT manterá o máximo de propriedades do usuário dentro do limite fornecido. As propriedades do usuário listadas primeiro têm maior chance de serem enviadas do que aquelas listadas posteriormente; a propriedade Reason String tem a menor prioridade.

Exemplo de uma interação MessageAck simples

Mensagem:

PUBLISH
    QoS: 1
    Packet_Id: 34
    Topic: $iothub/{request.path}
    Payload: <any>

Confirmação (sucesso):

PUBACK
    Packet_Id: 34
    Reason_Code: 0

Interações de solicitação-resposta

Em interações de Solicitação-resposta (ReqRep), tanto a solicitação quanto a resposta são traduzidas em pacotes PUBLISH com QoS: 0.

A propriedade Correlation Data deve ser definida em ambos e é usada para corresponder o pacote Resposta ao pacote Solicitação.

Esta API usa o tópico de resposta única $iothub/responses para todas as operações de ReqRep. A assinatura/cancelamento da assinatura deste tópico para operações de cliente para servidor não é necessária; o servidor assume que todos os clientes tenham assinado.

Exemplo de interação ReqRep simples

Solicitação:

PUBLISH
    QoS: 0
    Topic: $iothub/{request.path}
    Correlation_Data: 0x01 0xFA
    Payload: ...

Resposta (sucesso):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: ...

As interações de ReqRep não dão suporte a pacotes PUBLISH com QoS: 1 como mensagens de solicitação ou resposta. Enviar uma Solicitação PUBLISH resulta na resposta Bad Request.

O comprimento máximo suportado pela propriedade Correlation Data é 16 bytes. Se a propriedade Correlation Data no pacote PUBLISH for definida com um valor maior que 16 bytes, o Hub IoT enviará DISCONNECT com resultado Bad Request e fechará a conexão. Esse comportamento se aplica somente a pacotes trocados nessa API.

Observação

Os dados de correlação são uma sequência de bytes arbitrária, por exemplo, não é garantido que seja uma cadeia de caracteres UTF-8.

ReqRep usa tópicos predefinidos para resposta; a propriedade Tópico de resposta no pacote de Solicitação PUBLISH (se definida pelo remetente) é ignorada.

O Hub IoT assina automaticamente os tópicos de resposta do cliente para todas as operações de ReqRep de cliente para servidor. Mesmo que o cliente cancele a assinatura do tópico de resposta, o Hub IoT restabelece a assinatura automaticamente. Para interações de ReqRep de servidor para cliente, ainda é necessário que o dispositivo assine.

Propriedades da Mensagem

Propriedades da operação (definidas pelo sistema ou pelo usuário) são expressas como propriedades do pacote no MQTT 5.

Os nomes de propriedade do usuário diferenciam maiúsculas de minúsculas e devem ser escritos exatamente conforme foram definidos. Por exemplo, Trace-ID não é suportado, mas trace-id sim.

As solicitações com propriedades do usuário fora da especificação e sem o prefixo @ resultam em erro.

As propriedades do sistema são codificadas como propriedades de primeira classe (por exemplo, Content Type) ou como propriedades do usuário. A especificação fornece uma lista completa de propriedades de sistema com suporte. Todas as propriedades de primeira classe são ignoradas, a menos que o suporte a elas seja explicitamente declarado na especificação.

Quando propriedades definidas pelo usuário são permitidas, seus nomes devem seguir o formato @{property name}. As propriedades definidas pelo usuário dão suporte apenas a valores de cadeia de caracteres UTF-8 válidos. por exemplo, a propriedade MyProperty1 com valor 15 deve ser codificada como propriedade do usuário com o nome @MyProperty e o valor 15.

Se o Hub IoT não reconhecer a propriedade Usuário, ela será considerada um erro e o Hub IoT responderá com PUBACK com Reason Code: 0x83 (Erro específico da implementação) e status: 0100 (Solicitação inválida). Se a confirmação não foi solicitada (QoS: 0), um pacote DISCONNECT com o mesmo erro é retornado e a conexão será encerrada.

Essa API define os seguintes tipos de dados, além do string:

  • time: número de milissegundos desde 1970-01-01T00:00:00.000Z. por exemplo, 1600987195320 para 2020-09-24T22:39:55.320Z,
  • u32: número inteiro não assinado de 32 bits.
  • u64: número inteiro não assinado de 64 bits.
  • i32: número inteiro assinado de 32 bits.

Resposta

As interações podem ter resultados diferentes: Success, Bad Request, Not Found etc. Os resultados são diferenciados uns dos outros pela propriedade do usuário status. Reason Code em pacotes PUBACK (para interações de MessageAck) corresponde ao status quando possível.

Observação

Se o cliente especificar Request Problem Information: 0 no pacote CONNECT, nenhuma propriedade do usuário será enviada nos pacotes PUBACK para cumprir a especificação MQTT 5, incluindo a propriedade status. Nesse caso, o cliente ainda pode confiar no Reason Code para determinar se a confirmação é positiva ou negativa.

Cada interação tem um padrão (ou sucesso). Tem Reason Code das propriedades 0 e status "não definidas". Caso contrário:

  • Para interações de MessageAck, PUBACK obtém Reason Code diferente de 0x0 (sucesso). A propriedade status pode estar presente para esclarecer ainda mais o resultado.
  • Para interações ReqRep, a Resposta PUBLISH obtém o conjunto de propriedades status.
  • Como não há como responder diretamente a interações de MessageAck com QoS: 0, o pacote DISCONNECT é enviado em vez das informações de resposta, seguido da desconexão.

Exemplos:

Solicitação inválida (MessageAck):

PUBACK
    Reason_Code: 131
    status: 0100
    reason: Unknown property `test`

Não autorizado (MessageAck):

PUBACK
    Reason_Code: 135
    status: 0101

Não autorizado (ReqRep):

PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: ...
    status: 0101

Quando necessário, o Hub IoT define as seguintes propriedades do usuário:

  • status - Código estendido do Hub IoT para o status da operação. Esse código pode ser usado para diferenciar os resultados.
  • trace-id – ID de rastreamento da operação; o Hub IoT pode manter mais diagnósticos relativos à operação que poderia ser usada para investigação interna.
  • reason - A mensagem legível que fornece mais informações sobre por que a operação foi encerrada no estado indicado pela propriedade status.

Observação

Se o cliente definir a propriedade Maximum Packet Size no pacote CONNECT com um valor muito pequeno, nem todas as propriedades do usuário poderão ser adequadas e não aparecerão no pacote.

reason destina-se apenas a pessoas e não deve ser usado em lógicas de cliente. Essa API permite que as mensagens sejam alteradas em um ponto sem aviso ou sem alteração de versão.

Se o cliente enviar RequestProblemInformation: 0 no pacote CONNECT, as propriedades do usuário não serão incluídas nas confirmações de acordo com a especificação MQTT 5.

Código de status

A propriedade status carrega o código de status para a operação. Ela é otimizada para eficiência de leitura do computador. Consiste em um número inteiro não assinado de dois bytes codificado como um hexadecimal em uma cadeia de caracteres como 0501. Estrutura do código (mapa de bits):

7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
0 0 0 0 0 R T T | C C C C C C C C

O primeiro byte é usado para sinalizadores:

  • bits 0 e 1 indicam o tipo de resultado:
    • 00 - sucesso
    • 01 - erro de cliente
    • 10 - erro de servidor
  • bit 2: 1 indica que o erro pode sofrer nova tentativa
  • Os bits 3 a 7 são reservados e devem ser definidos como 0

O segundo byte contém o código de resposta distinto. Códigos de erro com sinalizadores diferentes podem ter o mesmo valor de segundo byte. Por exemplo, pode haver os códigos de erro 0001, 01010201, 0301 com significados distintos.

Por exemplo, Too Many Requests é um erro de cliente com nova tentativa com o próprio código 1. O valor é 0000 0101 0000 0001 ou 0x0501.

Os clientes podem usar o bits de tipo para identificar se a operação foi concluída com sucesso. Os clientes também podem usar um bit com nova tentativa para decidir se é sensato tentar novamente a operação.

Recomendações

Gerenciamento da sessão

O pacote CONNACK transporta a propriedade Session Present para indicar que o servidor restaurou a sessão criada anteriormente. Use essa propriedade para descobrir se deseja assinar tópicos ou ignorar a assinatura, desde que tenha sido feita anteriormente.

Para contar com o Session Present, o cliente deve manter o controle das assinaturas feitas (ou seja, enviar o pacote SUBSCRIBE e receber SUBACK com o código de motivo bem-sucedido), ou certifique-se de assinar todos os tópicos em uma única troca SUBSCRIBE/SUBACK. Caso contrário, se o cliente enviar dois pacotes SUBSCRIBE e o servidor processar apenas um deles com sucesso, o servidor comunica Session Present: 1 em CONNACK, enquanto tem apenas parte das assinaturas do cliente aceitas.

Para evitar o caso em que uma versão mais antiga do cliente não assinou todos os tópicos, é melhor assinar incondicionalmente quando o comportamento do cliente for alterado (por exemplo, como parte da atualização do firmware). Além disso, para garantir que nenhuma assinatura obsoleta seja deixada para trás (assumindo o número máximo permitido de assinaturas), cancele explicitamente as assinaturas que não estão mais em uso.

Separação em lotes

Não há nenhum formato especial para enviar um lote de mensagens. Para reduzir a sobrecarga de operações que fazem uso intensivo de recursos no TLS e na rede, agrupe os pacotes (PUBLISH, PUBACK, SUBSCRIBE e assim por diante) antes de entregá-los à pilha TLS/TCP subjacente. Além disso, o cliente pode facilitar o alias do tópico dentro do "lote":

  • Coloque o nome completo do tópico no primeiro pacote PUBLISH para a conexão e associe o alias do tópico a ele.
  • Deixe os próximos pacotes do mesmo tópico com nome e propriedade de alias em branco.

Migração

Esta seção lista as alterações na API em relação ao suporte anterior do MQTT.

  • O protocolo de transporte é o MQTT 5. Anteriormente, MQTT 3.1.1.
  • As informações de contexto para autenticação SAS estão contidas diretamente no pacote CONNECT, em vez de serem codificadas junto com a assinatura.
  • O método de autenticação é usado para indicar o método de autenticação usado.
  • A assinatura de acesso compartilhado é colocada na propriedade de dados de autenticação. O campo Senha anterior foi usado.
  • Os tópicos para operações são diferentes:
    • Telemetria: $iothub/telemetry em vez de devices/{Client Id}/messages/events.
    • Comandos: $iothub/commands em vez de devices/{Client Id}/messages/devicebound.
    • Patch do gêmeo reportado: $iothub/twin/patch/reported em vez de $iothub/twin/PATCH/properties/reported.
    • Notificar o estado desejado do gêmeo alterado: $iothub/twin/patch/desired em vez de $iothub/twin/PATCH/properties/desired.
  • A assinatura do tópico de resposta para as operações de solicitação-resposta entre cliente e servidor não é necessária.
  • As propriedades do usuário são usadas em vez das propriedades de codificação no segmento do nome do tópico.
  • Os nomes de propriedade são escritos de acordo com a convenção de nomenclatura separada por hifens em vez de abreviações com prefixos especiais. Agora, as propriedades definidas pelo usuário exigem prefixos. Por exemplo, $.mid agora é message-id, enquanto myProperty1 se torna @myProperty1.
  • A propriedade de Dados de correlação é usada para correlacionar mensagens de solicitação e resposta para operações de solicitação-resposta em vez da propriedade $rid codificada no tópico.
  • A propriedade iothub-connection-auth-method não está mais marcada nos eventos de telemetria.
  • Os comandos C2D não são limpos na ausência de uma inscrição do dispositivo. Eles permanecem na fila até que o dispositivo se inscreva ou expire.

Exemplos

Enviar telemetria

Mensagem:

-> PUBLISH
    QoS: 1
    Packet_Id: 31
    Topic: $iothub/telemetry
    @myProperty1: My String Value # optional
    creation-time: 1600987195320 # optional
    @ No_Rules-ForUser-PROPERTIES: Any UTF-8 string value # optional
    Payload: <data>

Confirmação:

<- PUBACK
    Packet_Id: 31
    Reason_Code: 0

Confirmação alternativa (limitada):

<- PUBACK
    Packet_Id: 31
    Reason_Code: 151
    status: 0501

Enviar solicitação de estado do gêmeo

Solicitação:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/get
    Correlation_Data: 0x01 0xFA
    Payload: <empty>

Resposta (sucesso):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    Payload: <twin/desired state>

Resposta (não permitido):

<- PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x01 0xFA
    status: 0102
    reason: Operation not allowed for `B2` SKU
    Payload: <empty>

Lidar com chamada de método direto

Solicitação:

<- PUBLISH
    QoS: 0
    Topic: $iothub/methods/abc
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Resposta (sucesso):

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    response-code: 200 # user defined response code
    Payload: <data>

Observação

status não está definido; é uma resposta de sucesso.

Resposta do dispositivo não disponível:

-> PUBLISH
    QoS: 0
    Topic: $iothub/responses
    Correlation_Data: 0x0A 0x10
    status: 0603

Erro ao usar o QoS 0, parte 1

Solicitação:

-> PUBLISH
    QoS: 0
    Topic: $iothub/twin/gett # misspelled topic name - server won't recognize it as Request-Response interaction
    Correlation_Data: 0x0A 0x10
    Payload: <data>

Resposta:

<- DISCONNECT
    Reason_Code: 144
    reason: "Unsupported topic: `$iothub/twin/gett`"

Erro ao usar o QoS 0, parte 2

Solicitação:

-> PUBLISH # missing Correlation Data
    QoS: 0
    Topic: $iothub/twin/get
    Payload: <data>

Resposta:

<- DISCONNECT
    Reason_Code: 131
    status: 0100
    reason: "`Correlation Data` property is missing"

Próximas etapas