AWS IoT Guide de dépannage de Device Advisor

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 connexion TLS avait été refusée par Device Advisor. Cela est-il prévu ?

A : Oui. Device Advisor refuse la connexion TLS avant et après chaque essai. 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 connect, MQTT connect et MQTT publish, 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 un historique des appels API de Device Advisor effectués sur mon compte à des fins d'analyse de la sécurité et de dépannage opérationnel ?

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

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. Les événements sont envoyés depuis des appareils et AWS IoT Core seront enregistrés dans 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 permet AWS IoT Core de 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 en votre AWS IoT Core 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 le protocole MQTT pris en charge par Device Advisor ?

R : Device Advisor prend en charge la version 3.1.1 de MQTT 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 rôle IAM à utiliser comme rôle sur votre appareil. Si le test échoue toujours, il se peut que l'appareil n'envoie pas l'extension SNI (Server Name Indication) correcte, requise pour que Device Advisor fonctionne. La valeur SNI 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 SNI (Server Name Indication) au protocole TLS (Transport Layer Security). Pour plus d'informations, consultez la section Sécurité du transport dans AWS IoT.

Q : Ma connexion MQTT échoue avec une erreur « libaws-c-mqtt : AWS_ERROR_MQTT_UNEXPECTED_HANGUP » (ou) la connexion MQTT 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 autorisations IAM minimales requises pour exécuter les tests. Device Advisor utilisera le rôle de périphérique attaché pour effectuer des actions AWS IoT MQTT au nom du périphérique 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 MQTT Publish, 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 des appareils accorde ou refuse l'accès aux AWS IoT ressources et aux opérations du plan de AWS IoT Core 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.