Cette page a été traduite par l'API Cloud Translation.

Dépannage

Application exemple

Si vous rencontrez des problèmes lors de l'utilisation des API Home, vous pouvez collecter des journaux pour un débogage plus approfondi. La collecte des journaux de l'appareil mobile nécessite Android Debug Bridge (adb). Si vous avez besoin de l'aide de Google, collectez les journaux des appareils Android et du hub, puis ouvrez une demande dans le suivi des problèmes en y joignant les informations et les journaux pertinents.

Collecter les journaux Android

Votre appareil mobile doit être connecté à votre ordinateur local pour toutes les étapes impliquant adb.

Installer adb

Si ce n'est pas déjà fait, configurez Android Debug Bridge sur votre ordinateur local:

Installez "adb" sur votre ordinateur.
Activez les options pour les développeurs et le débogage USB sur votre téléphone Android.

Plug-in Google Home pour Android Studio

Google Home Plugin for Android Studio est un outil utile pour collecter et analyser les journaux. Il a été créé spécifiquement pour les développeurs Google Home platform. Ce plug-in vous permet d'accéder à Google Assistant Simulator, à Cloud Logging et à d'autres outils pour simplifier votre processus de développement smart home.

Utilisez cet outil avec adb pour analyser plus en détail les journaux de l'appareil Matter.

Pour en savoir plus et obtenir l'outil, consultez Google Home Plugin for Android Studio.

Informations sur la version

Nous vous recommandons de collecter toutes les informations de version liées à votre configuration chaque fois que vous décidez de collecter des journaux. Cette étape est obligatoire si vous devez signaler des problèmes à Google.

Obtenez l'ID de votre appareil mobile:

adb devices

List of devices attached
device-id    device

Stockez cette valeur dans une variable appelée phoneid:
```
phoneid=device-id
```

Enregistrez diverses informations sur l'appareil dans des variables:

containerinfo=$(adb -s $phoneid shell dumpsys package com.google.android.gms | grep "versionName" || true);
homemoduleinfo=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.home " || true);
optionalhomemoduleinfo=$(adb -s $phoneid  shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.optional_home " || true);
policyhomemoduleinfo=$(adb -s $phoneid  shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.policy_home" || true);
threadinfo=$(adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "com.google.android.gms.threadnetwork" || true);
ghainfo=$(adb -s $phoneid shell dumpsys package com.google.android.apps.chromecast.app | grep versionName || true);
enabledfeatures=$((adb -s $phoneid shell dumpsys activity provider com.google.android.gms.chimera.container.GmsModuleProvider | grep "Enabled features" | grep -i "home") || true);
androidversion=$(adb -s $phoneid shell getprop ro.build.version.release || true);
androidapiversion=$(adb -s $phoneid shell getprop ro.build.version.sdk || true)

Enregistrez toutes les variables dans un fichier nommé _versions.txt:

Développer pour afficher les commandes permettant d'enregistrer des variables dans un fichier

Vous pouvez copier et coller l'ensemble du bloc dans un terminal à la fois.

versionfile=$logtimestamp"_versions.txt"
echo "Saving version info to $versionfile"

echo "Container version:" >> $versionfile
echo $containerinfo >> $versionfile
echo "" >> $versionfile

echo "Home Module version:" >> $versionfile
echo $homemoduleinfo >> $versionfile
echo "" >> $versionfile

echo "Optional Home Module version:" >> $versionfile
echo $optionalhomemoduleinfo >> $versionfile
echo "" >> $versionfile

echo "Policy Home Module version:" >> $versionfile
echo $policyhomemoduleinfo >> $versionfile
echo "" >> $versionfile

echo "Thread Module version:" >> $versionfile
echo $threadinfo >> $versionfile
echo "" >> $versionfile

echo "GHA version:" >> $versionfile
echo $ghainfo >> $versionfile
echo "" >> $versionfile

echo "Android version: " >> $versionfile
echo $androidversion >> $versionfile
echo "" >> $versionfile

echo "Android API version: " >> $versionfile
echo $androidapiversion >> $versionfile
echo "" >> $versionfile

echo "Found enabled features (blank if missing):" >> $versionfile
echo $enabledfeatures >> $versionfile
echo "" >> $versionfile

Vérifiez le contenu de _versions.txt:

cat _versions.txt

Développer pour afficher l'exemple de sortie de fichier

Container version:
versionName=23.19.12 (190400-530524295) versionName=22.46.17 (190408-491726958)

Home Module version:
com.google.android.gms.home [v230508900]

Optional Home Module version:


Policy Home Module version:
com.google.android.gms.policy_home [230508900] [230508900065.505615668.505615668] [Download:000003be/dl-Home.integ_230508900100400.apk] [download:/Home.integ/230508900100400:Home.integ:230508900100400]

Thread Module version:
com.google.android.gms.threadnetwork [v231912000]

GHA version:
versionName=3.2.32.1

Android version:
13

Android API version:
33

Found enabled features (blank if missing):

Vous pouvez désormais fournir ce fichier à Google si nécessaire pour résoudre les problèmes.

Collecter des journaux

Pour collecter les journaux, fermez toutes les applications exécutées sur l'appareil mobile. Ensuite :

Ouvrez une fenêtre de terminal et effacez les journaux de l'appareil existants:
```
adb logcat -b all -c
```
Démarrez le processus de collecte des journaux:
```
adb logcat >> _logs.txt
```
Laissez ce terminal ouvert. Les journaux de votre appareil seront collectés tant que le processus sera en cours d'exécution.
Exécutez l'application exemple et enregistrez toutes les actions de l'interface utilisateur. Une fois que vous avez terminé, arrêtez le processus logcat exécuté dans le terminal en appuyant sur Ctrl+C (ou Cmd+C sur Mac).
Les journaux de cette session sont enregistrés dans un fichier nommé _logs.txt.

Vous pouvez analyser les informations de ce fichier de différentes manières, y compris en recherchant des mots clés tels que error, exception ou crash.

Scripts de journalisation

Pour votre commodité, l'application exemple fournit des scripts permettant d'obtenir les journaux pertinents et de les compiler dans un fichier texte. Pour offrir la meilleure expérience de débogage possible, ces journaux doivent être joints à tous les bugs signalés afin de faciliter l'analyse de la cause par Google.

Ces journaux se trouvent dans le répertoire scripts de l'arborescence source de l'application exemple. Pour les exécuter, procédez comme suit à partir du répertoire racine du projet:

Obtenez l'ID de votre appareil mobile:

adb devices -l

List of devices attached
device-id device

Exécutez le script get_logs.sh :

 ./scripts/get_logs.sh device-id

Cleared previous logs from device.
Saving version information to home_api_sample_logs_20240605233243.txt...
Saving logs to home_api_sample_logs_20240605233243.txt...
(Press CTRL+C to stop the script)

Reproduisez le problème.
Appuyez sur CTRL+C pour arrêter le script.

Le script génère un fichier journal horodaté contenant toutes les informations pertinentes. Joignez-les à tous les rapports de bugs que vous rencontrez.

Journaux de l'appareil du hub Cast

Pour afficher les journaux d'appareil de votre hub Google, procédez comme suit:

Configurez Android Debug Bridge.
Obtenez l'adresse IP de votre hub:
- Sur le hub, s'il dispose d'un écran :
  1. Balayez l'écran de haut en bas.
  2. Appuyez sur l'icône Paramètres .
  3. Trouver l'adresse IP de l'appareil: sur un Nest Hub (2nd gen), accédez à Informations sur l'appareil > Informations techniques > Adresse IP.
- Depuis GHA sur votre téléphone :
  1. Appuyez sur l'appareil pour afficher sa page d'informations
  2. Appuyez sur l'icône Paramètres pour afficher la page des paramètres.
  3. Recherchez l'adresse IP de l'appareil: accédez à Informations sur l'appareil > Informations techniques > Adresse IP.
Sur un ordinateur connecté au même réseau Wi-Fi que l'appareil:
```
  adb connect ip-address
  adb logcat
```
Pour fournir des journaux à quelqu'un, effectuez l'opération qui échoue et redirigez la sortie vers un fichier texte:
```
  adb logcat -d > platform-logs.txt
```

Automatisations

Détection des bords

Les automatisations de l'écosystème Google Home sont dotées de la détection de bord, une logique qui garantit qu'un déclencheur ne s'active que lorsqu'il y a un changement d'état réel, contrairement à une mise à jour d'état qui ne fait que répéter l'état précédent de l'appareil.

Par exemple, si l'allumage d'une lumière est un déclencheur, la détection de bords garantit que le déclencheur ne s'active que si cet appareil d'éclairage passe de l'état "arrêt" à l'état "marche", et non de l'état "marche" à l'état "marche" (pas de changement).

L'automatisation ne se comporte pas comme prévu

Après avoir pris en compte la détection des bords, si une automatisation ne se comporte pas comme prévu:

Vérifiez chaque appareil pour vous assurer qu'il fonctionne correctement, indépendamment de votre automatisation.
Examinez le graphique d'automatisation de votre automatisation, en le comparant à votre DSL d'automatisation, pour identifier les hypothèses potentiellement incorrectes de votre part.
Observez l'état de l'appareil dans l'application Google Home pendant l'exécution de votre automatisation.
Vérifiez que tous les appareils référencés par l'automatisation sont présents dans la structure où vous vous attendez à les trouver. La suppression d'un appareil sur lequel une automatisation dépend peut avoir des conséquences inattendues. Consultez la section Impact de la suppression d'un appareil sur les automatisations.

L'automatisation s'exécute quand elle ne devrait pas

Si votre automatisation s'exécute alors qu'elle ne devrait pas, examinez les critères de déclenchement. Il peut être nécessaire d'ajouter une logique supplémentaire pour s'assurer qu'un changement d'état n'est capturé qu'une seule fois et ne déclenche l'automatisation qu'une seule fois.

L'automatisation ne se compile pas

Assurez-vous que votre application contient toutes les importations nécessaires, y compris chaque classe correspondant aux différents types de nœuds, ainsi que les traits que vous référencez.

Échec de la validation de la création d'une automatisation

Si la création d'une automatisation ne passe pas la validation, un message d'avertissement ou d'erreur fournit des informations sur le problème. Pour en savoir plus, consultez la documentation de référence sur ValidationIssueType.

La fonction de liste génère des exceptions

Lorsque vous appelez la fonction de liste de l'API Automation, les gestionnaires de lecture peuvent générer des exceptions en raison de fonctionnalités d'API manquantes. Pour y remédier, supprimez l'automatisation concernée.

Pour ce faire :

Assurez-vous d'avoir installé adb. Consultez Installer adb.

Récupérez l'ID de l'automatisation dans les journaux Android en appelant:

adb logcat -s GhpNative

Exemples de journaux :

adb logcat -s GhpNative level:debug | grep -A 10 -B 10 AutomationManagerTrait\.ListResponse

INTERACTION RESPONSE -> SendCommandsResponse:
1 {
1: "automation@global"
3 {
  1: "home.internal.traits.automation.AutomationManagerTrait.ListResponse"
  2:
  5 {
    1: "type.googleapis.com/home.internal.traits.automation.AutomationManagerTrait.ListResponse"
    1 {
        1: "1111-2222-3333-44444-55555" // Automation ID to delete
        2: "structure@2222-3333-4444-5555-6666"
...

Si plusieurs ID d'automatisation doivent être supprimés, vous pouvez utiliser le pager de votre terminal pour contrôler la sortie:

adb logcat -s GhpNative level:debug | less

Supprimez l'automatisation à l'aide de son ID:

structure.deleteAutomation(new object : HasId(id = "1111-2222-3333-44444-55555"))

L'API Discovery enregistre un avertissement lorsqu'un trait n'est pas enregistré

Si l'API Discovery enregistre un avertissement pour Trait not found, cela signifie que l'API tente d'utiliser la caractéristique pour les candidats Discovery, mais qu'elle ne réussira pas, car la caractéristique n'a pas été enregistrée lors de l'initialisation. Exemple :

09-03 17:45:20.578 10646 10646 W AutomationSdk: trait_id: "home.matter.6006.clusters.fc43" and Exception occurred com.google.home.HomeException: 18: Trait not found: home.matter.6006.clusters.fc43
09-03 17:45:20.578 10646 10646 W AutomationSdk: While converting candidate: # com.google.home.platform.traits.AutomationCandidateNode@76f0b582

L'identifiant de trait est home.matter.6006.clusters.fc43, qui correspond à RelativeHumidityControl. Pour déterminer le nom du trait à partir d'un ID, consultez l'index des traits.

Dans cet exemple, RelativeHumidityControl doit être enregistré lors de l'initialisation de l'application. Consultez Enregistrer des traits pour ajouter votre trait au registre.

OAuth

Si vous disposez déjà d'un client OAuth

Si vous disposez déjà d'un client OAuth validé pour une application publiée, vous pouvez utiliser votre client OAuth existant pour tester les API Home.

L'enregistrement Google Home Developer Console n'est pas obligatoire pour tester et utiliser les API Home. Toutefois, vous aurez toujours besoin d'un enregistrement Developer Console approuvé pour publier votre application, même si vous disposez d'un client OAuth validé à partir d'une autre intégration.

Les considérations suivantes s'appliquent :

Une limite de 100 utilisateurs s'applique lorsque vous utilisez un client OAuth existant. Pour savoir comment ajouter des utilisateurs de test, consultez la section Configurer l'écran de consentement OAuth. Indépendamment de la validation OAuth, les API Home imposent une limite de 100 utilisateurs pouvant accorder des autorisations à votre application. Cette limitation est levée une fois l'enregistrement de Developer Console terminé.
L'Developer Consoleenregistrement doit être envoyé pour approbation lorsque vous êtes prêt à restreindre les autorisations de type d'appareil via OAuth en vue de mettre à jour votre application avec les API Home.

Important:L'enregistrement dans la Google Home Developer Console n'est pas encore possible.

Pour les applications Google Cloud dont la validation OAuth est toujours en attente, les utilisateurs ne peuvent pas terminer le flux OAuth tant que la validation n'est pas terminée. Les tentatives d'octroi d'autorisations échouent et renvoient l'erreur suivante:

Access blocked: <Project Name> has not completed the Google verification process.

Gestion des exceptions

API Commissioning