‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות

אפליקציה לדוגמה

אם נתקלים בבעיות במהלך השימוש בממשקי ה-API של Home, אפשר לאסוף יומנים כדי לבצע ניפוי באגים נוסף. כדי לאסוף יומנים מהמכשיר הנייד, צריך להשתמש ב-Android Debug Bridge ‏ (adb). אם אתם צריכים עזרה מ-Google, עליכם לאסוף את היומנים ממכשירי Android וממרכז הבקרה, ולפתוח כרטיס במעקב הבעיות עם המידע הרלוונטי והיומנים שקשורים אליו.

איסוף יומנים של Android

המכשיר הנייד צריך להיות מחובר למחשב המקומי בכל השלבים שקשורים ל-adb.

התקנת adb

אם עדיין לא עשיתם זאת, צריך להגדיר את Android Debug Bridge במחשב המקומי:

מתקינים את adb במחשב.
מפעילים את האפשרויות למפתחים ואת ניפוי הבאגים ב-USB בטלפון Android.

איך מקבלים מזהה מכשיר נייד

כך מוצאים את המזהה של המכשיר הנייד:
```
adb devices
```
```
List of devices attached
device-id    device
```
אחסון הערך הזה במשתנה שנקרא phoneid:
```
phoneid=device-id
```

פרטי הגרסה

מומלץ לאסוף את כל פרטי הגרסה שקשורים להגדרה בכל פעם שמחליטים לאסוף יומנים. הפעולה הזו נדרשת אם אתם צריכים לשתף בעיות עם Google.

שמירת מידע שונה על המכשיר במשתנים:

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

שמירת כל המשתנים בקובץ בשם _versions.txt:

הרחבה להצגת פקודות לשמירת משתנים בקובץ

אפשר להעתיק את כל הבלוק ולהדביק אותו במסוף בבת אחת.

versionfile="_versions.txt"
echo "Saving version info to $versionfile"
echo "Container version: $containerinfo" > $versionfile
echo "Home Module version: $homemoduleinfo" >> $versionfile
echo "Optional Home Module version: $optionalhomemoduleinfo" >> $versionfile
echo "Thread Module version: $threadinfo" >> $versionfile
echo "GHA version: $ghainfo" >> $versionfile
echo "Android version: $androidversion" >> $versionfile
echo "Android API version: $androidapiversion" >> $versionfile
echo "Found enabled features: $enabledfeatures" >> $versionfile

מאמתים את התוכן של _versions.txt:

cat _versions.txt

הרחבה להצגת פלט של קובץ לדוגמה

Container version:     versionName=26.26.34 (190400-945364269)
Home Module version:             com.google.android.gms.home [v262634001]
Optional Home Module version:         com.google.android.gms.optional_home [262634025] ...
Thread Module version:             com.google.android.gms.threadnetwork [v262634001]
GHA version:     versionName=4.22.28.0
Android version: 14
Android API version: 34
Found enabled features:             Enabled features: appsearch_impl, brella_dynamite, dck_management...

עכשיו אפשר לספק את הקובץ הזה ל-Google לפי הצורך לצורך פתרון בעיות.

הפעלת דגלים מפורטים לניפוי באגים

לפני שמתחילים לאסוף יומנים של מכשירי Android או להריץ דוח באגים, צריך להגדיר את גודל המאגר של כלי הרישום ולאפשר תגי ניפוי באגים מפורטים לרכיבי Google Home ו-GMS:

# Clear existing device logs and expand logger buffer size
adb -s $phoneid logcat -b all -c
adb -s $phoneid logcat -G 8M

# Enable GMS Service ID verbose flags
adb -s $phoneid shell setprop log.tag.gms_svc_id:168 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:304 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:305 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:319 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:336 VERBOSE
adb -s $phoneid shell setprop log.tag.gms_svc_id:360 VERBOSE

# Enable GHP and Matter log tags
adb -s $phoneid shell setprop log.tag.CameraCommissioningPlugin VERBOSE
adb -s $phoneid shell setprop log.tag.HomeSdk VERBOSE
adb -s $phoneid shell setprop log.tag.HomeClient VERBOSE
adb -s $phoneid shell setprop log.tag.InteractionApiChimeraService VERBOSE
adb -s $phoneid shell setprop log.tag.MatterCommissioner VERBOSE
adb -s $phoneid shell setprop log.tag.SampleApp VERBOSE

איסוף יומנים של Android באמצעות סקריפטים

כדי לצלם יומני מכשיר Android בזמן אמת במהלך סשן ניפוי באגים:

פועלים לפי ההוראות בהפעלת דגלים מפורטים של ניפוי באגים כדי לנקות יומנים קיימים, להרחיב את שטח האחסון הזמני ולהגדיר תגי רישום מפורטים.
סוגרים את כל האפליקציות שפועלות במכשיר הנייד.
לפני שמתחילים את הבדיקה, מנקים את הרעשים במאגר היומנים הקיים:
```
adb -s $phoneid logcat -c
```
מתחילים את תהליך איסוף היומנים בחלון Terminal:
```
adb -s $phoneid logcat | tee android-logs_$(date +%Y%m%d%H%M%S).txt
```
משאירים את חלון הטרמינל הזה פתוח. הפעולה הזו תתעד יומנים מהמכשיר כל עוד התהליך פועל.
מריצים את האפליקציה ומבצעים את כל הפעולות בממשק המשתמש שנדרשות לשחזור הבעיה.
בסיום, עוצרים את התהליך logcat במסוף על ידי הקשה על Ctrl+C (או על Cmd+C ב-Mac).
היומנים מהסשן הזה נשמרים בתיקייה android-logs_YYYYMMDDmmss.txt. מצרפים את android-logs_YYYYMMDDmmss.txt ואת _versions.txt לדוחות על באגים.

איסוף יומנים של Android באמצעות adb bugreport

כדי לשתף מידע מפורט לצורך אבחון בעיות ברמת המערכת, קובצי dump של קריסות או ניפוי באגים ברמה נמוכה ברשת וב-Bluetooth, אפשר לתעד דוח מלא על באג ב-Android:

הפעלת Matter BLE: כשמדווחים על בעיה בהפעלת Matter BLE, צריך להפעיל את יומן ה-Snoop של Bluetooth HCI באפשרויות למפתחים (הגדרות > אפשרויות למפתחים > הפעלת יומן ה-Snoop של Bluetooth HCI) לפני שמשחזרים את הבעיה.
הגדרות לפני הבדיקה: לפני שמריצים את הבדיקה, צריך לפעול לפי השלבים במאמר הפעלת דגלים מפורטים לניפוי באגים כדי להפעיל את מאפייני ניפוי הבאגים המפורטים במכשיר.
יצירת דוח על באג: אחרי שמריצים את הבדיקה ומשחזרים את הבעיה, מריצים את הפקודה הבאה כדי ליצור ארכיון מלא של דוח על באג:
```
adb -s $phoneid bugreport ./android-bugreport_$(date +%Y%m%d%H%M%S).zip
```
מידע מתקדם לניפוי באגים: קובץ android-bugreport_YYYYMMDDmmss.zip שנוצר מכיל נתוני אבחון מקיפים ברמת המערכת – כולל קבצים מלאים של dump מהמערכת, נתונים סטטיסטיים של הזיכרון, אבחון של הסוללה ועקבות של מערכות משנה ברמה נמוכה – ומספק מידע מתקדם יותר לניפוי באגים.

יומנים של מכשירי Cast Hub

אפשר להשתמש בשיטה הזו כדי לראות את יומני המכשירים של Google Nest Hub. השיטה הזו נתמכת בדגמים הבאים:

Google Home
Google Nest Audio
Google Nest Hub
Google Nest Mini

כדי להפעיל מרכז Cast לאחזור יומנים מקומיים:

הגדרת ממשק הגישור של Android‏ (ADB)
כדי לראות את כתובת ה-IP של הרכזת:
- במרכז השליטה, אם יש לו מסך:
  1. מחליקים למטה מהחלק העליון של המסך.
  2. מקישים על סמל ההגדרות
  3. כדי למצוא את כתובת ה-IP של המכשיר: ב-Nest Hub (2nd gen), עוברים אל פרטי המכשיר > מידע טכני > כתובת IP.
- מתוך GHA בטלפון:
  1. מקישים על המכשיר כדי לפתוח את דף הפרטים שלו.
  2. מקישים על סמל ההגדרות כדי לפתוח את דף ההגדרות.
  3. כדי למצוא את כתובת ה-IP של המכשיר: עוברים אל פרטי המכשיר > מידע טכני > כתובת IP
במחשב שמחובר לאותה רשת Wi-Fi שאליה מחובר המכשיר:
```
  adb connect ip-address
  adb logcat
```
כדי לספק יומנים למישהו, מבצעים את הפעולה שנכשלה ומעבירים את הפלט לקובץ טקסט:
```
  adb logcat -d > platform-logs.txt
```

פעולות אוטומטיות

זיהוי קצוות

באוטומציות במערכת האקולוגית של Google Home יש זיהוי קצה, שהוא לוגיקה שמוודאת שטריגר לפעולה מופעל רק כשחל שינוי בפועל במצב, ולא כשחל עדכון במצב שפשוט חוזר על המצב הקודם של המכשיר.

לדוגמה, אם הפעלת אור היא טריגר לפעולה, זיהוי קצה מוודא שהטריגר לפעולה מופעל רק אם מכשיר האור עובר ממצב כבוי למצב דלוק, ולא ממצב דלוק למצב דלוק (ללא שינוי).

הפעולה האוטומטית לא מתבצעת כמו שציפיתי

אחרי שמתחשבים בזיהוי הקצוות, אם האוטומציה לא מתנהגת כמצופה:

בודקים כל מכשיר כדי לוודא שהוא פועל בצורה תקינה ללא קשר לאוטומציה.
כדאי לעיין בתרשים האוטומציה של האוטומציה שלכם ולהשוות אותו ל-DSL של האוטומציה, כדי לגלות הנחות שגויות פוטנציאליות מצדכם.
אפשר לעקוב אחרי מצב המכשיר באפליקציית Google Home במהלך ההפעלה של האוטומציה.
בודקים שכל המכשירים שהאוטומציה מתייחסת אליהם נמצאים במבנה שבו אתם מצפים שהם יהיו. למחיקה של מכשיר שפעולה אוטומטית מסתמכת עליו יכולות להיות השלכות לא רצויות. השפעת מחיקת מכשיר על אוטומציות

הפעולה האוטומטית מופעלת כשהיא לא אמורה לפעול

אם הפעולות האוטומטיות פועלות כשהן לא אמורות לפעול, צריך לבדוק את טריגר הפעולה. יכול להיות שיהיה צורך להוסיף לוגיקה נוספת כדי לוודא ששינוי במצב יתועד רק פעם אחת ויפעיל את האוטומציה רק פעם אחת.

הפעולה האוטומטית לא עוברת קומפילציה

חשוב לוודא שהאפליקציה מכילה את כל הייבוא הנדרש, כולל כל מחלקה שמתאימה לסוגי הצמתים השונים, וגם את התכונות שאתם מפנים אליהן.

יצירת האוטומציה נכשלת באימות

אם יצירת האוטומציה לא עוברת אימות, תוצג אזהרה או הודעת שגיאה עם מידע על הבעיה. מידע נוסף זמין במאמר בנושא ValidationIssueType.

פונקציית List מחזירה חריגים

כשקוראים לפונקציית הרשימה של Automation API, יכול להיות שמטפלי קריאה יזרקו חריגים בגלל תכונות API חסרות. כדי לפתור את הבעיה, צריך למחוק את האוטומציה המושפעת.

לשם כך:

בודקים שadb installed מותקן. ראו התקנת adb.

כדי לאחזר את המזהה של האוטומציה מיומני Android, מפעילים את הפקודה:

adb logcat -s GhpNative

יומנים לדוגמה:

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

אם צריך למחוק כמה מזהי אוטומציה, אפשר להשתמש בכלי להצגת פלט בטרמינל כדי לשלוט בפלט:

adb logcat -s GhpNative level:debug | less

מחיקת הפעולה האוטומטית באמצעות המזהה שלה:

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

‫Discovery API מתעד אזהרה כשמאפיין לא רשום

אם ה-API של Discovery מתעד אזהרה לגבי Trait not found, המשמעות היא שה-API מנסה להשתמש במאפיין למועמדים ל-Discovery, אבל הוא לא יצליח כי המאפיין לא נרשם במהלך האתחול. לדוגמה:

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

מזהה המאפיין הוא home.matter.6006.clusters.fc43, שמתאים ל-RelativeHumidityControl. כדי לדעת מה שם המאפיין לפי המזהה, אפשר לעיין באינדקס המאפיינים.

בדוגמה הזו, צריך לרשום את RelativeHumidityControl במהלך אתחול האפליקציה. כדי להוסיף את המאפיין למרשם, אפשר להיעזר במאמר בנושא רישום מאפיינים.

OAuth

אם יש לכם לקוח OAuth קיים

אם כבר יש לכם לקוח OAuth מאומת לאפליקציה שפורסמה, אתם יכולים להשתמש בלקוח ה-OAuth הקיים כדי לבדוק את ממשקי ה-API של Home.

אין צורך ברישום Google Home Developer Console כדי לבדוק את ממשקי ה-API של Home ולהשתמש בהם. עם זאת, עדיין תצטרכו רישום מאושר של Developer Console כדי לפרסם את האפליקציה, גם אם יש לכם לקוח OAuth מאומת משילוב אחר.

השיקולים הבאים רלוונטיים:

קיימת מגבלה של 100 משתמשים כשמשתמשים בלקוח OAuth קיים. מידע על הוספת משתמשים למטרות בדיקה זמין במאמרמגדירים את מסך ההסכמה ל-OAuth. בנוסף לאימות OAuth, יש מגבלה של 100 משתמשים שיכולים להעניק הרשאות לאפליקציה שלכם דרך Home APIs. המגבלה הזו תוסר לאחר השלמת הרישום של Developer Console.
Developer Console registration צריך לשלוח לאישור כשמוכנים להגביל הרשאות לפי סוג המכשיר באמצעות OAuth, כהכנה לעדכון האפליקציה באמצעות Home APIs.

חשוב לדעת: עדיין אי אפשר להירשם ל-Google Home Developer Console.

בGoogle Cloud אפליקציות שעדיין ממתינות לאימות OAuth, משתמשים לא יכולים להשלים את תהליך OAuth עד שהאימות יושלם. ניסיונות להעניק הרשאות ייכשלו עם השגיאה הבאה:

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