AWS IoT Guide de dépannage de Device Advisor

Aidez-nous à améliorer ce sujet

Dites-nous ce qui pourrait contribuer à l'améliorer

Général

Q : Puis-je exécuter plusieurs suites de tests en parallèle ?

A : Oui. Device Advisor prend désormais en charge l'exécution de plusieurs suites de tests sur différents appareils à l'aide d'un point de terminaison au niveau de l'appareil. Si vous utilisez le point de terminaison au niveau du compte, vous pouvez exécuter une suite à la fois car un point de terminaison Device Advisor est disponible par compte. Pour de plus amples informations, veuillez consulter configuration de votre appareil

Q : J'ai vu sur mon appareil que la TLS connexion avait été refusée par Device Advisor. Cela est-il prévu ?

A : Oui. Device Advisor refuse la TLS connexion avant et après chaque test. Nous recommandons aux utilisateurs de mettre en œuvre un mécanisme de nouvelle tentative sur l'appareil afin de bénéficier d'une expérience de test entièrement automatisée avec Device Advisor. Si vous exécutez une suite de tests comportant plusieurs scénarios de test, par exemple TLS MQTT connecter, connecter et MQTT publier, nous vous recommandons de créer un mécanisme adapté à votre appareil. Le mécanisme peut essayer de se connecter à notre point de terminaison de test toutes les 5 secondes pendant une minute à deux. De cette manière, vous pouvez exécuter plusieurs cas de test en séquence de manière automatisée.

Q : Puis-je obtenir l'historique des API appels effectués par Device Advisor sur mon compte à des fins d'analyse de sécurité et de résolution des problèmes opérationnels ?

A : Oui. Pour recevoir l'historique des API appels effectués avec Device Advisor sur votre compte, il vous suffit CloudTrail d'activer le AWS IoT Console de gestion et filtrez la source d'événement à êtreiotdeviceadvisor.amazonaws.com.

Q : Comment puis-je consulter les connexions à Device Advisor CloudWatch ?

R : Les journaux générés lors de l'exécution d'une suite de tests sont téléchargés CloudWatch si vous ajoutez la politique requise (par exemple, CloudWatchFullAccess) à votre rôle de service (voirConfiguration). S'il existe au moins un cas de test dans la suite de tests, un groupe de journaux « testSuiteId aws/iot/deviceadvisor/$ » est créé avec deux flux de journaux. L'un des flux est le « $ testRunId » et inclut les journaux des actions effectuées avant et après l'exécution des scénarios de test dans votre suite de tests, telles que les étapes de configuration et de nettoyage. L'autre flux de log est « $ suiteRunId _$ »testRunId, qui est spécifique à une suite de tests exécutée. Événements envoyés depuis des appareils et AWS IoT Core sera connecté à ce flux de journal.

Q : Quel est l'objectif du rôle d'autorisation de l'appareil ?

R : Device Advisor se trouve entre votre appareil de test et AWS IoT Core pour simuler des scénarios de test. Il accepte les connexions et les messages de vos appareils de test et les transmet à AWS IoT Core en assumant le rôle d'autorisation de votre appareil et en établissant une connexion en votre nom. Il est important de vous assurer que les autorisations relatives aux rôles de l'appareil sont les mêmes que celles du certificat que vous utilisez pour exécuter des tests. AWS IoT les politiques de certification ne sont pas appliquées lorsque Device Advisor établit une connexion à AWS IoT Core en votre nom en utilisant le rôle d'autorisation de l'appareil. Toutefois, les autorisations associées au rôle d'autorisation de l'appareil que vous avez défini sont appliquées.

Q : Dans quelles régions Device Advisor est-il pris en charge ?

Device Advisor est pris en charge dans les régions us-west-2 et eu-west-1.

Q : Pourquoi est-ce que je constate des résultats incohérents ?

R : L'une des principales causes d'incohérence des résultats est la définition d'un test EXECUTION_TIMEOUT à une valeur trop faible. Pour plus d'informations sur les EXECUTION_TIMEOUT valeurs recommandées et par défaut, consultez les scénarios de test de Device Advisor.

Q : Quel est MQTT le protocole pris en charge par Device Advisor ?

R : Device Advisor prend en charge MQTT la version 3.1.1 avec les certificats clients X509.

Q : Et si mon scénario de test a échoué avec un message d'expiration du délai d'exécution alors que j'ai essayé de connecter mon appareil au point de terminaison du test ?

R : Validez toutes les étapes de la section Créer un IAM rôle à utiliser comme rôle sur votre appareil. Si le test échoue toujours, il se peut que l'appareil n'envoie pas l'extension d'indication de nom de serveur (SNI) correcte, requise pour que Device Advisor fonctionne. La SNI valeur correcte est l'adresse du point de terminaison renvoyée lorsque vous suivez la section Configurer votre appareil. AWS IoT exige également que les appareils envoient l'extension Server Name Indication (SNI) au protocole Transport Layer Security (TLS). Pour plus d'informations, voir Sécurité des transports dans AWS IoT.

Q : Ma MQTT connexion échoue avec une erreur « libaws-c-mqtt : AWS_ERROR _ MQTT _ UNEXPECTED _ HANGUP » (ou) la MQTT connexion de mon appareil est automatiquement déconnectée du point de terminaison Device Advisor. Comment résoudre cette erreur ?

R : Ce code d'erreur particulier et les déconnexions inattendues peuvent être provoqués par de nombreux facteurs différents, mais ils sont probablement liés au rôle de l'appareil attaché à l'appareil. Les points de contrôle ci-dessous (par ordre de priorité) permettront de résoudre ce problème.

• Le rôle de périphérique attaché à l'appareil doit disposer des IAM autorisations minimales requises pour exécuter les tests. Device Advisor utilisera le rôle d'appareil connecté pour effectuer AWS IoT MQTTactions au nom de l'appareil de test. Si les autorisations requises sont absentes, l'AWS_ERROR_MQTT_UNEXPECTED_HANGUPerreur s'affichera ou des déconnexions inattendues se produiront pendant que l'appareil tente de se connecter au point de terminaison Device Advisor. Par exemple, si vous avez choisi d'exécuter le scénario de test MQTTPublish, les actions Connect et Publish doivent être incluses dans le rôle avec le sujet correspondant ClientId (vous pouvez fournir plusieurs valeurs en utilisant des virgules pour séparer les valeurs, et vous pouvez fournir des valeurs de préfixe à l'aide d'un caractère générique (*). Par exemple, pour accorder l'autorisation de publier sur n'importe quel sujet commençant par TestTopic, vous pouvez fournir « TestTopic* » comme valeur de ressource. Voici quelques exemples de politiques.

• Incompatibilité entre les valeurs définies dans le rôle de l'appareil pour vos types de ressources et les valeurs réelles utilisées dans le code. Par exemple : une incompatibilité est ClientId définie dans le rôle et le code réellement ClientId utilisé dans le code de votre appareil. Les valeurs telles que ClientId Topic et le code TopicFilter doivent être identiques dans le rôle et le code de l'appareil.

• Le certificat d'appareil associé à votre appareil doit être actif et être associé à une politique comportant les autorisations d'action requises pour les ressources. Notez que la politique de certification de l'appareil accorde ou refuse l'accès à AWS IoT ressources et AWS IoT Core opérations sur le plan de données. Device Advisor exige que vous disposiez d'un certificat d'appareil actif attaché à votre appareil qui accorde les autorisations d'action utilisées lors d'un scénario de test.