Ta strona została przetłumaczona przez Cloud Translation API.

Rozwiązywanie problemów

Przykładowa aplikacja

Jeśli podczas korzystania z interfejsów API Home napotkasz jakiekolwiek problemy, możesz zebrać dzienniki w celu dalszego debugowania. Do zbierania logów z urządzenia mobilnego wymagany jest Android Debug Bridge (adb). Jeśli potrzebujesz pomocy od Google, zbierz logi zarówno z urządzeń z Androidem, jak i z koncentratora, a następnie zgłoś zgłoszenie w systemie śledzenia problemów, podając odpowiednie informacje i powiązane z nim logi.

Zbieranie logów z Androida

Urządzenie mobilne musi być połączone z komputerem lokalnym podczas wszystkich czynności oznaczonych symbolem adb.

Instalowanie adb

Jeśli jeszcze tego nie zrobiłeś, skonfiguruj Android Debug Bridge na swoim komputerze lokalnym:

Zainstaluj „adb” na swoim komputerze.
Włącz Opcje programisty i debugowanie USB na telefonie Android.

Wtyczka Google Home do Android Studio

Google Home Plugin for Android Studio to przydatne narzędzie do zbierania i analizowania logów. Zostało stworzone specjalnie dla programistów Google Home platform. Ta wtyczka zapewnia dostęp do Google Assistant Simulator, Cloud Logging i innych narzędzi, które uproszczą proces rozwoju smart home.

Użyj tego narzędzia w połączeniu z adb, aby dokładniej analizować dzienniki urządzenia Matter.

Aby dowiedzieć się więcej i pobrać narzędzie, zobacz Google Home Plugin for Android Studio.

Informacje o wersji

Zalecamy, aby za każdym razem, gdy zdecydujesz się na zbieranie dzienników, zebrać wszystkie informacje o wersji związane z konfiguracją. Jest to wymagane, jeśli chcesz zgłosić problemy Google.

Uzyskiwanie identyfikatora urządzenia mobilnego:

adb devices

List of devices attached
device-id    device

Zapisz tę wartość w zmiennej o nazwie phoneid:
```
phoneid=device-id
```

Zapisz różne informacje o urządzeniu w zmiennych:

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)

Zapisz wszystkie zmienne w pliku o nazwie _versions.txt:

Rozwiń, aby wyświetlić polecenia zapisywania zmiennych do pliku

Cały blok można skopiować i wkleić do terminala jednocześnie.

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

Sprawdź zawartość _versions.txt:

cat _versions.txt

Rozwiń, aby wyświetlić dane wyjściowe przykładowego pliku

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):

W razie potrzeby możesz teraz udostępnić ten plik Google w celu rozwiązania problemu.

Zbieranie dzienników

Aby zebrać dzienniki, zamknij wszystkie aplikacje uruchomione na urządzeniu mobilnym. Następnie:

Otwórz okno terminala i wyczyść istniejące logi urządzenia:
```
adb logcat -b all -c
```
Rozpocznij proces zbierania logów:
```
adb logcat >> _logs.txt
```
Pozostaw ten terminal otwarty. Spowoduje to zbieranie dzienników z urządzenia, dopóki proces będzie działać.
Uruchom przykładową aplikację i przechwyć wszystkie działania interfejsu użytkownika. Gdy skończysz, zatrzymaj proces logcat działający w terminalu, naciskając Ctrl+C (lub Cmd+C na Macu).
Dzienniki z tej sesji są zapisywane w pliku o nazwie _logs.txt.

Informacje w tym pliku możesz analizować na różne sposoby, np. wyszukując słowa kluczowe takie jak error, exception lub crash.

Skrypty logu

Przykładowa aplikacja zawiera skrypty, które ułatwiają uzyskiwanie odpowiednich logów i kompilowanie ich w plik tekstowy. Aby zapewnić jak najlepsze debugowanie, te dzienniki należy dołączyć do wszystkich zgłaszanych błędów, aby ułatwić Google analizę ich przyczyn.

Dzienniki te znajdują się w katalogu scripts w drzewie źródłowym aplikacji przykładowej. Wykonaj te czynności w głównym katalogu projektu:

Uzyskiwanie identyfikatora urządzenia mobilnego:

adb devices -l

List of devices attached
device-id device

Uruchom skrypt 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)

Odtwórz problem.
Aby zatrzymać skrypt, naciśnij CTRL+C.

Skrypt wygeneruje plik dziennika ze znacznikiem czasu, który będzie zawierał wszystkie istotne informacje. Dołącz je do wszystkich raportów dotyczących napotkanych błędów.

Dzienniki urządzenia przesyłającego

Za pomocą tej metody możesz wyświetlać dzienniki urządzeń Google Nest Hub. Jest ona obsługiwana w przypadku tych modeli:

Google Home
Google Nest Audio
Google Nest Hub
Google Nest Mini

Aby włączyć centrum Cast do pobierania logów lokalnych:

Skonfiguruj Android Debug Bridge.
Uzyskaj adres IP huba:
- Na hubie, jeśli ma ekran:
  1. Przesuń palcem z góry ekranu w dół
  2. Kliknij ikonę Ustawienia .
  3. Znajdź adres IP urządzenia: W urządzeniu Nest Hub (2nd gen) przejdź do sekcji Informacje o urządzeniu > Informacje techniczne > Adres IP
- Z GHA na telefonie:
  1. Kliknij urządzenie, aby otworzyć stronę z informacjami o nim.
  2. Kliknij ikonę Ustawienia , aby otworzyć stronę ustawień.
  3. Znajdź adres IP urządzenia: otwórz Informacje o urządzeniu > Informacje techniczne > Adres IP.
Na komputerze połączonym z tą samą siecią Wi-Fi co urządzenie:
```
  adb connect ip-address
  adb logcat
```
Aby udostępnić komuś dzienniki, wykonaj operację, która się nie powiodła, i przekieruj dane wyjściowe do pliku tekstowego:
```
  adb logcat -d > platform-logs.txt
```

Automatyzacja

Wykrywanie krawędzi

Automatyzacje w ekosystemie Google Home mają funkcję wykrywania zmian, która sprawdza, czy starter aktywuje się tylko wtedy, gdy nastąpi rzeczywista zmiana stanu, a nie aktualizacja stanu, która po prostu powtarza poprzedni stan urządzenia.

Jeśli na przykład włączenie światła jest działaniem początkowym, wykrywanie krawędzi sprawdza, czy działanie początkowe jest aktywowane tylko wtedy, gdy urządzenie oświetleniowe przechodzi ze stanu wyłączonego do włączonego, a nie ze stanu włączonego do włączonego (bez zmiany).

Automatyzacja nie działa zgodnie z oczekiwaniami

Jeśli po uwzględnieniu wykrywania krawędzi automatyzacja nie działa zgodnie z oczekiwaniami:

Sprawdź każde urządzenie, aby upewnić się, że działa prawidłowo niezależnie od automatyzacji.
Przyjrzyj się wykresowi automatyzacji dla swojej automatyzacji i porównaj go z wykresem automatyzacji DSL, aby wykryć wszelkie potencjalnie błędne założenia.
Obserwuj stan urządzenia w aplikacji Google Home podczas wykonywania automatyzacji.
Sprawdź, czy wszystkie urządzenia, do których odwołuje się automatyzacja, znajdują się w strukturze, w której powinny być. Usunięcie urządzenia, od którego zależy automatyzacja, może mieć nieprzewidziane konsekwencje. Zobacz Wpływ usunięcia urządzenia na automatyzacje.

Automatyzacja uruchamia się, gdy nie powinna

Jeśli automatyzacja działa w nieodpowiednich momentach, sprawdź kryteria uruchamiania. Może być konieczne dodanie dodatkowej logiki, aby mieć pewność, że zmiana stanu zostanie zarejestrowana tylko raz i tylko raz uruchomi automatyzację.

Automatyzacja nie kompiluje się

Upewnij się, że aplikacja zawiera wszystkie niezbędne importy, w tym każdą klasę odpowiadającą różnym typom węzłów, a także cechy, do których się odwołujesz.

Tworzenie automatyzacji nie przechodzi weryfikacji

Jeśli tworzenie automatyzacji nie przejdzie weryfikacji, pojawi się komunikat z ostrzeżeniem lub błędem, który będzie zawierał informacje o problemie. Więcej informacji znajdziesz w ValidationIssueType.

Funkcja listy zgłasza wyjątki

Podczas wywoływania funkcji listy API automatyzacji procedury odczytu mogą zgłaszać wyjątki z powodu brakujących funkcji API. Aby temu zapobiec, usuń automatyzację, której to dotyczy.

Aby to zrobić:

Sprawdź, czy zainstalowano adb. Zobacz Instalowanie adb.

Pobierz identyfikator automatyzacji z logów Androida, wywołując:

adb logcat -s GhpNative

Przykładowe logi:

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"
...

Jeśli chcesz usunąć wiele identyfikatorów automatyzacji, możesz użyć pagera terminala, aby kontrolować dane wyjściowe:

adb logcat -s GhpNative level:debug | less

Usuń automatyzację za pomocą jej identyfikatora:

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

Interfejs Discovery API rejestruje ostrzeżenie, gdy cecha zostanie wyrejestrowana

Jeśli interfejs Discovery API rejestruje ostrzeżenie dotyczące Trait not found, oznacza to, że interfejs API próbuje użyć cechy w przypadku kandydatów do odkrywania, ale nie uda mu się to, ponieważ cecha nie została zarejestrowana podczas inicjowania. Na przykład:

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

Identyfikator cechy to home.matter.6006.clusters.fc43, co odpowiada RelativeHumidityControl. Aby określić nazwę cechy na podstawie identyfikatora, zapoznaj się z indeksem cech.

Z tego przykładu wynika, że RelativeHumidityControl musi zostać zarejestrowany podczas inicjowania aplikacji. Aby dodać cechę do rejestru, zapoznaj się z sekcją Rejestrowanie cech.

OAuth

Jeśli masz już klienta OAuth

Jeśli masz już zweryfikowanego klienta OAuth dla opublikowanej aplikacji, możesz go użyć do testowania interfejsów Home API.

Google Home Developer Console nie jest wymagana do testowania i korzystania z interfejsów Home API. Aby opublikować aplikację, musisz jednak mieć zatwierdzoną Developer Consolerejestrację, nawet jeśli masz zweryfikowanego klienta OAuth z innej integracji.

Obowiązują te zasady:

Jeśli używasz istniejącego klienta OAuth, obowiązuje limit 100 użytkowników. Informacje o dodawaniu użytkowników testowych znajdziesz w artykuleSkonfiguruj ekran zgody OAuth. Niezależnie od weryfikacji OAuth interfejsy Home API mają limit 100 użytkowników, którzy mogą przyznawać uprawnienia Twojej aplikacji. To ograniczenie zostanie zniesione po zakończeniu rejestracji w usłudze Developer Console.
Developer Console registration należy przesłać do zatwierdzenia, gdy chcesz ograniczyć przyznawanie uprawnień do typów urządzeń za pomocą OAuth w ramach przygotowań do zaktualizowania aplikacji za pomocą interfejsów Home API.

Ważne: rejestracja w konsoli deweloperskiej Google Home nie jest jeszcze możliwa.

W przypadku Google Cloud aplikacji, które wciąż czekają na weryfikację OAuth, użytkownicy nie mogą zakończyć procesu OAuth, dopóki weryfikacja nie zostanie ukończona. Próby przyznania uprawnień zakończą się niepowodzeniem i wyświetli się ten błąd:

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