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

פתרון בעיות

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

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

איסוף יומנים של 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 או מפעילים דוח איתור באגים, צריך להגדיר את שטח האחסון הזמני של ה-logger ולהפעיל תגי ניפוי באגים מפורטים של 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 displaying seconds on the screen
adb -s $phoneid shell settings put secure clock_seconds 1

# 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
```
מתחילים את תהליך איסוף היומנים בחלון הטרמינל:
```
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

כדי לשתף מידע מפורט על אבחון שכולל בעיות ברמת המערכת, קובצי 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 Hub לאחזור יומנים מקומיים:

מגדירים את Android Debug Bridge.
מאתרים את כתובת ה-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 מותקנת. איך מתקינים את 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 מתעד אזהרה כשתכונה לא רשומה

אם ב-Discovery API נרשמת אזהרה לגבי 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 משתמשים שיכולים לתת הרשאות לאפליקציה שלכם, שנקבעת על ידי ממשקי ה-API של Home. ההגבלה הזו תוסר אחרי השלמת הרישום של Developer Console.
Developer Console registration צריך לשלוח לאישור כשמוכנים להגביל את ההרשאות של סוגי המכשירים באמצעות OAuth כהכנה לעדכון האפליקציה באמצעות ממשקי ה-API של Home.

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

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

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