Examine o guia de solução de problemas de comunicações do dispositivo

  • 4 minutos

As listas de verificação de solução de problemas a seguir fornecem algumas coisas para tentar antes de enviar um tíquete de suporte.

Não é possível conectar-se ao seu hub IoT do Azure

Se o seu dispositivo não conseguir se conectar ao seu hub IoT do Azure, aqui estão algumas coisas para verificar:

  1. Suas credenciais estão corretas?
    • Se você estiver usando certificados X.509, as impressões digitais devem corresponder. Certifique-se de que a impressão digital no registo corresponde à impressão digital do certificado que está a tentar utilizar.
    • Se estiver a utilizar uma cadeia de ligação com uma chave de acesso partilhada, certifique-se de que corresponde ao dispositivo ou a uma política com a funcionalidade DeviceConnect.
    • Se estiver a utilizar uma assinatura de acesso partilhado, certifique-se de que a expiração está correta e que está a utilizar a chave de acesso partilhada correta para a assinar.
  2. Reveja o registo do dispositivo (utilizando o portal do Azure) e certifique-se de que o dispositivo está ativado.
  3. Você consegue passar pelo firewall?
    • A coisa mais fácil de tentar é executar a ferramenta iothub-diagnostics e ver se ela consegue se conectar ao seu hub IoT do Azure com as credenciais do seu dispositivo. Ele tenta todos os protocolos suportados e WebSockets e exibe seus resultados de teste.
    • Se não for possível executar o iothub-diagnostics, você pode tentar executar as mesmas etapas manualmente:
      • Executar ping em um site conhecido para verificar a resolução de nomes e o tráfego de saída funciona.
      • Altere o transporte usado para instanciar o cliente (AMQP, AMQPWS, MQTT, MQTTWS e HTTP).
  4. Tente executar os exemplos padrão.
    • Se os exemplos puderem se conectar, tente encontrar diferenças entre como o programa e os exemplos instanciam o cliente. O problema pode ser tão simples quanto um erro de digitação.
    • Se as amostras não puderem se conectar e nem o iothub-diagnostics, o problema provavelmente será um problema com as credenciais ou sua rede.

Não detetando desconexões

O difícil das desconexões é que elas muitas vezes parecem aleatórias. Se o SDK não estiver disparando um erro, não há como saber o que está acontecendo. Ou há?

  1. A lógica da repetição pode estar atrasando as coisas?
    • Seja padrão, a lógica de repetição continua por quatro minutos. Esperou tanto tempo?
    • Se não quiser esperar, tente desativar a lógica de repetição chamando client.setRetryPolicy(new NoRetry())
  2. Precisa de registos detalhados? O SDK usa a biblioteca de depuração para registro:
    • Defina a DEBUG variável de ambiente e execute seu aplicativo novamente. Aqui estão alguns bons valores para a DEBUG variável de ambiente para você começar:
      • O azure* parâmetro registra a atividade do SDK, mas não a biblioteca de transporte subjacente.
      • O amqp10* parâmetro registra a atividade da biblioteca AMQP de baixo nível.
      • O * parâmetro registra tudo.
    • O debug parâmetro registra em stderr log por padrão e pode ser detalhado, especialmente se definido como *.
    • Se você estiver salvando esses logs para publicá-los em um problema, tenha cuidado para raspar informações confidenciais!

Falha ao enviar algumas mensagens

As falhas de mensagem são outra complicada. Parece que algumas mensagens estão sendo enviadas, mas não todas. O que dá? A primeira pergunta a fazer é: "Como você sabe que algumas mensagens não estão sendo enviadas?"

  1. Se for porque o retorno de chamada é chamado com um erro, o objeto de erro pode fornecer mais pistas do que apenas uma mensagem. Preste atenção ao tipo de erro em si:
    • Se for um tipo de SDK personalizado, deve ser explícito. Se a digitação explícita não for suficiente, observe as propriedades do erro e tente ver se há um erro específico do protocolo lá.
    • Se for um genérico Error, significa que o SDK não conseguiu traduzir esse erro. Quando você receber um erro genérico, registre um problema e nos forneça o maior número de detalhes possível, incluindo os valores das propriedades de erro e a pilha de erros.
  2. Se for porque não está a ver as mensagens na sua aplicação na nuvem, tente verificar:
    • No lado do dispositivo, os argumentos passaram para o retorno de chamada da send operação.
    • Tente usar a extensão do Azure IoT para CLI do Azure com o monitor-events subcomando para verificar se as mensagens aparecem no ponto de extremidade compatível com hubs de eventos do seu Hub IoT. Se o fizerem, pelo menos você sabe que o dispositivo está funcionando corretamente. Se isso não acontecer, é improvável que seja um problema de serviço e você pode rastrear problemas do lado do dispositivo.