Google Home Vitals (Cloud)

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

מרכז הבקרה מחולק לשלושה חלקים, שכל אחד מהם מתייחס לחלק מרכזי שתורם לאיכות הכוללת של השילוב.

1. ‫Google to Partner Metrics – מדד שבודק את תקינות הקריאות מ-Google אל הבק אנד בענן.

2. System Health - Partner to Google Metrics – מדד שבודק את תקינות הקריאות מהמערכת שלכם אל Google.

3. ‫Device Health - State Accuracy – מדד שבודק את הדיוק של המצבים שמאוחסנים במערכות של Google, שמשמשים כדי להחזיר תשובות לשאילתות של משתמשים.

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

אם הכפתור הבא לא מעביר אתכם ישירות ללוח הבקרה, אתם יכולים לעבור לדף Overview, לבחור באפשרות Dashboards ואז לבחור באפשרות לוח הבקרה של Google Home Vitals (Cloud) מהרשימה My Dashboards כדי לראות את לוח הבקרה.

כניסה לדף Dashboard

מדדי Google לשותף

המדד Query/Execute Success Rate >= 99.5%‎ מודד את התדירות שבה הפקודות של המשתמשים מבוצעות בצורה נכונה. המדד הזה עוזר להימנע מתשובות של Assistant כמו "אין לי גישה למכשיר" או מאישור שגוי של פקודה שעדיין לא בוצעה.

המדד שיעור הצלחת הסנכרון >= 99.5% בודק באיזו תדירות בקשות הסנכרון מתבצעות בצורה נכונה, כדי לוודא שהמכשירים שמוצגים ב-Google Home מסונכרנים עם המכשירים שמחוברים לתשתית הענן שלכם.

מה נחשב "הצלחה"?

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

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

מה נחשב "כשל"?

השגיאות שמופיעות בקודי שגיאה נפוצים בפלטפורמה ומסומנות כניתנות לטיפול על ידי השותף נחשבות כ "כשלים" בחישוב שיעורי ההצלחה של QUERY,‏ EXECUTE ו-SYNC. בנוסף, השגיאות שמופיעות בדף Errors and exceptions נחשבות גם הן כ-Failures, חוץ מהמקרים הבאים:

שוויון במצב התגובה להפעלה

כשמחזירים סטטוס SUCCESS בתגובה מסוג EXECUTE, האובייקט states של המטען הייעודי (payload) של התגובה חייב להכיל את כל שדות המצב הפעילים והמעודכנים שמוגדרים על ידי התכונות שאתם מפעילים. אם תשמיטו שדות מצב נדרשים או תחזירו אובייקט states ריק לתכונות מורכבות, פלטפורמת Google Home לא תצליח לנתח את תוצאת הביצוע, ותתעד אותה ככשל מסוג AGENT_ISSUE או INVALID_RESPONSE שיוריד את שיעור ההצלחה של השאילתה והביצוע.

המדד ‎Query/Execute Latency (p90) <= 1000ms מודד את זמן ההמתנה של פעולה שבוקשה ועוזר לוודא שהמשתמשים לא צריכים לחכות יותר מדי זמן, למשל, לחכות כמה שניות עד שהאור ייכבה.

מדדי זמן אחזור

זמן האחזור הוא אינדיקטור קריטי למידת התגובה של השילוב שלכם למשתמש הקצה. בלוח הבקרה מוצג זמן האחזור באחוזון ה-90 (P90), שמייצג את החוויה של המשתמשים "האיטיים" ביותר (לדוגמה, P90 של 800ms פירושו ש-90% מהבקשות מאושרות תוך 800ms או פחות).

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

1. זמן האחזור של שאילתה (שאלה)

המדד הזה בודק את זמן הלוך ושוב של Cloud-to-cloud כש-Google מבקשת את המצב הנוכחי של המכשיר.

• התחלה: Google שולחת בקשת action.devices.QUERY לכתובת ה-URL למילוי הבקשה.
• חלון המדידה: משך הזמן שנדרש לענן לקבל, לעבד ולשלוח את תגובת ה-HTTP המלאה בחזרה ל-Google.
• סיום: Google מקבלת את המטען הייעודי (payload) של התגובה הסופית מהשירות שלכם ומאשרת את קבלתו.

2. ‫EXECUTE Latency (Action)

המדד הזה בודק את זמן אישור הפקודה כש-Google שולחת בקשת בקרה למכשיר.

• התחלה: Google שולחת בקשת action.devices.EXECUTE לכתובת ה-URL למילוי הבקשה.
• חלון המדידה: הזמן שלוקח לענן לקבל את הפקודה ולהחזיר תגובת אישור.
• סיום: Google מקבלת את תגובת הסטטוס SUCCESS,‏ PENDING או OFFLINE.
• היקף טכני: המדד הזה בודק את הזמן של "אישור התגובה" בין הענן של Google לענן שלכם. הוא לא מודד את הזמן שלוקח לחומרה הפיזית (לדוגמה, נורה) להשלים את שינוי המצב הפיזי, כי לעיתים קרובות זה כרוך בזמן אחזור של רשת Mesh מקומית מחוץ לנתיב של הענן לענן.

פירוט ציר הזמן של זמן האחזור של EXECUTE/QUERY

כשמנתחים את חותמות הזמן של זמן האחזור ב-EXECUTE או ב-QUERY, אפשר לחלק את זמן הלוך ושוב הכולל לרצף הבא:

מכיוון שהפירוט הזה משווה בין חותמות הזמן בצד של Google לבין אלה שבצד של השותף, השרתים של השותף חייבים להיות מסונכרנים עם NTP (Network Time Protocol). אפילו סטייה קלה בשעון (50-100 אלפיות השנייה) תעוות את זמני ההעברה המחושבים (t2 - t1 ו-t4 - t3), ועלולה להוביל למדדים בלתי אפשריים מבחינה לוגית, כמו זמני אחזור שליליים.

‫[t1] נשלחה בקשה (Google Outbound): ‏Google יוזמת את בקשת ה-intent. מכיוון ש-t1 לא נחשף ישירות, הוא מחושב בקירוב על ידי הפחתת זמן האחזור הכולל מחותמת הזמן הסופית של הבקשה הנכנסת.

‫Network Transit (t1 to t2): זמן ההמתנה המשוער בתור וזמן המעבר ברשת עד להגעה לנקודת הקצה של מילוי הבקשה.

‫[t2] Request Received (Partner Ingress): חותמת הזמן המדויקת שבה הבקשה מגיעה לשער ה-API או לשרת ה-Ingress של הסביבה שלכם.

עיבוד אצל השותף (t2 עד t3): זמן האחזור של הביצוע הפנימי, הניתוב והטיפול במכשיר, כולו בתוך סביבת הענן שלכם.

[t3] נשלחה תגובה (יציאה מהשותף): חותמת הזמן שבה השירות שלכם שולח את תגובת המילוי בחזרה ל-Google.

זמן מעבר חזרה (מ-t3 אל t4): הזמן שלוקח לנתב את הרשת בחזרה ולהשלים את החיבור אל Google.

‫[t4] השלמת הבקשה (נכנסת ל-Google): Google מקבלת את התשובה הסופית ומעבדת אותה. חותמת הזמן הזו מתועדת ביומני Google Cloud בתור receiveTimestamp.

כדי להמחיש איך המדדים האלה קשורים זה לזה, נבחן בקשה לדוגמה של EXECUTE עם זמן אחזור כולל שנרשם ביומן (latencyMsec) של 1,700 אלפיות השנייה וGoogle Cloud receiveTimestamp (t4) של 2026-05-25T15:25:00.550Z.

אפשרויות להפחתת זמן האחזור

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

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

1. איזון עומסים גלובלי (GLB)

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

   • איך זה עובד: מגדירים נקודת כניסה גלובלית אחת (כתובת URL) שנמצאת בקצה הרשת. מאזן העומסים מזהה באופן אוטומטי את המקור הגיאוגרפי של הבקשה מאשכולות המילוי של Google, ומנתב את התנועה לקצה העורפי התקין הקרוב ביותר באזור.

   • יתרון: הביצועים של Anycast, אבל עם הגדרה הרבה פחות מורכבת ובעלות נמוכה יותר.

2. ‫DNS שמזהה מיקום גיאוגרפי (GeoDNS)

   • איך זה עובד: מגדירים את ספק ה-DNS כך שיפענח את כתובת ה-URL למילוי הבקשה לכתובות IP שונות, בהתאם למיקום הגיאוגרפי של שאילתת ה-DNS.

   • הטמעה: ודאו שספק ה-DNS שלכם מותאם לנקודות היציאה של Google. כששירותי המילוי האזוריים של Google (לדוגמה, בארה"ב, באיחוד האירופי או באסיה) פותרים את הדומיין, הם מקבלים את כתובת ה-IP של מרכז הנתונים באותו אזור ספציפי.

אסטרטגיות אופטימיזציה בשכבת האפליקציה

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

1. שיטת ה-Proxy "טרמפולינה"

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

   1. ‫Google פונה לכתובת ה-URL הגלובלית.

   2. שרת proxy אזורי (לדוגמה, פונקציית Nginx או Lambda קלה) מקבל את הבקשה.

   3. שרת ה-proxy מעביר את המטען הייעודי (payload) דרך רשת הליבה הפנימית המהירה למסד הנתונים הראשי.

   יתרון: הפעולה הזו מקצרת את זמן ה-TCP Handshake, שלרוב הוא הגורם העיקרי לאחזור בבקשות למרחקים ארוכים.

2. רמזים לאזור של טוקן הגישה

   במהלך תהליך קישור החשבון (OAuth), המערכת שלכם יכולה לזהות את אזור הבית של המשתמש.

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

תקינות המערכת – מדדי שותף ל-Google

שמירה על שיעור הצלחה של ‎99.5%‎ ומעלה עוזרת לוודא שהסטטוסים של המכשירים נכונים ב-Google Home, שהמכשירים מתווספים ומוסרים, שהאוטומציות מופעלות ושאירועי ההיסטוריה מופיעים בכרטיסייה "פעילות" של Google Home app (GHA).

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

מה נחשב "הצלחה"?

‫2xx (הצלחה): עדכון המצב התקבל ועובד בהצלחה על ידי Home Graph.

מה נחשב "כשל"?

‫4xx (שגיאת שותף) מייצגות כשלים ומצביעות על בעיה בבקשה שנשלחה מהענן שלכם. הקודים הנפוצים כוללים:

‫400 בקשה לא תקינה

הסיבה: השרת לא הצליח לעבד את הבקשה בגלל תחביר לא תקין. סיבות נפוצות כוללות פורמט JSON שגוי או שימוש ב-null במקום ב-"" לערך מחרוזת.

פתרון: ודאו שגוף הבקשה הוא קובץ JSON תקין (אין מבנה פגום או ערכי null בשדות של מחרוזות), וודאו ש-agentUserId תואם לערך מתגובת ה-SYNC.

שגיאת 404

הסיבה: deviceId או agentUserId לא נמצאו ב-HomeGraph (עדיין לא סונכרנו, הקישור כבר בוטל או שהמזהה לא תואם).

הפתרון:

1. חשוב לוודא שהערך של agentUserId תואם לערך שצוין בתגובת ה-SYNC.
2. משתמשים ב-Home Graph SYNC API כדי לבדוק אם שגיאת 404 נגרמת בגלל מכשיר או משתמש שחסרים ב-HomeGraph.
3. חשוב להפעיל את requestSync אחרי הוספה, הסרה, שינוי שם או עדכון של מכשיר או חשבון, כדי לוודא שהמצב נשאר עדכני.
4. מטפלים בצורה נכונה בכוונות DISCONNECT כדי להפסיק לדווח על מכשירים לא פעילים. אחרי קבלת ה-intent‏ DISCONNECT, שירות הענן צריך להפסיק לפרסם שינויים ב-Google באמצעות בקשת סנכרון ודיווח על מצב.

‫429 המשאב מוצה

הסיבה: השילוב חרג מהמכסה שהוקצתה לו.

פתרון: פועלים לפי ההוראות בקטע "שלב 2א: ניפוי באגים בבעיות שקשורות למכסות" במרכז הבקרה לניהול מכסות. מידע נוסף זמין במאמר מכסות ומגבלות של בית חכם.

תקינות המכשיר – דיוק המצב

אם רמת הדיוק של המצב היא 99.5%ומעלה, המשתמשים יראו תוצאות נכונות כשהם יסתכלו על המצבים של המכשיר או ישתמשו בתכונות מבוססות-AI כמו Ask Home. אם רמת הדיוק של המצב נמוכה, יכול להיות שהאוטומציות לא יופעלו והערכים בהיסטוריה לא יופיעו בכרטיסיית הפעילות של GHA בזמן הנכון. מידע נוסף זמין במאמר דיווח על מצב. חשוב לדעת: צריך לעמוד ביעד של דיוק המצב בכל המאפיינים הנתמכים.

1. רכיבי הדיוק

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

• דיוק מבוסס-שאילתה: מאומת כשמשתמש או מערכת בודקים באופן פעיל את הסטטוס הנוכחי של מכשיר.
• דיוק מבוסס-EXECUTE: מאומת על ידי הערכת מצב המכשיר לאחר הפקודה, כפי שדווח בעקבות בקשת בקרה.

2. מדדים במרכז הבקרה (חישוב שעתי)

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

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

דיוק המצב השעתי = (אחוז דיוק השאילתה + אחוז דיוק הביצוע) / 2

כל מסלול מוגדר כך:

• אחוז הדיוק של השאילתות = (דגימות מדויקות של שאילתות לשעה) / (סה"כ דגימות של שאילתות לשעה)
• ‫ %דיוק הביצוע = (דגימות מדויקות של ביצוע לפי שעה) / (סה"כ דגימות של ביצוע לפי שעה)

ציון הדיוק של המאפיין (מחושב לכל מאפיין) = SUM(Query Accurate Samples + Execution Accurate Samples) / SUM(Query Total Samples + Execution Total Samples)

ציון האיכות מעריך את הביצועים המינימליים המחמירים בכל המערכת האקולוגית, ולכן כל תכונה נתמכת שעומדת בדרישות צריכה לעמוד בנפרד ביעד של >= 99.5% דיוק במצב (זה לא ממוצע של כל התכונות).

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

3. שיפור הדיוק של תקינות המכשיר והמצב שלו

חוסר התאמה מתרחש כשהמצב שמאוחסן ב-Home Graph לא תואם לתוצאות של QUERY בזמן אמת.

שגיאות מסוג "שדה חסר"

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD"
    deviceId: "curtain"
    deviceType: "action.devices.types.CURTAIN"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-13T12:20:26Z"
    queryReportStateDifferences: {
      queryState: "open_close    {
        open_percent: 0.0
        missing open_direction
      }"
      reportState: "open_close   {
        open_state {
          open_percent: 100.0
          open_direction: "LEFT"
        }
      }"
    }
    reportedTime: "2022-05-13T07:14:35Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T12:20:26Z"
    stateName: "open_state"
    traitName: "TRAIT_OPEN_CLOSE"
  }
  

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD"
    deviceId: "sensor"
    deviceType: "action.devices.types.SENSOR"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-28T10:40:33Z"
    queryReportStateDifferences: {
      queryState: "temperature_setting {
         thermostat_mode: "off"
         thermostat_temperature_ambient: 20.0
         active_thermostat_mode: "none"
      }"
      reportState: "temperature_setting {
         thermostat_mode: "off"
         active_thermostat_mode: "none"
      }"
    }
    reportedTime: "2024-09-20T15:00:00Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-28T10:40:33Z"
    stateName: "thermostat_temperature_ambient"
    traitName: "TRAIT_TEMPERATURE_SETTING"
  }
  

הסיבה: בשגיאות DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD או DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD, קבוצת השדות של המטען הייעודי (payload) שונה בין התגובה ל-QUERY לבין הבקשה ל-Report State באותו מכשיר.

הפתרון: מוודאים שמבנה הנתונים זהה בשני הנתיבים. אם תכונה מסוימת נכללת ב-SYNC, השדות התואמים שלה חייבים להיות נוכחים ועקביים גם בדוחות היזומים וגם בשאילתות התגובתיות.

שגיאות מסוג "לא מדויק"

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_INACCURATE"
    deviceId: "outlet"
    deviceType: "action.devices.types.OUTLET"
    isMissingField: false
    isOffline: false
    queriedTime: "2026-04-12T16:02:58Z"
    queryReportStateDifferences: {
      queryState: "on_off    {
        on: false
      }"
      reportState: "on_off   {
        on: true
      }"
    }
    reportedTime: "2025-03-10T01:56:44Z"
    requestId: "abc"
    result: "INACCURATE"
    snapshotTime: "2026-04-12T16:02:58Z"
    stateName: "on"
    traitName: "TRAIT_ON_OFF"
  }
  

הסיבה: בשגיאה DETAILED_ACCURACY_RESULT_INACCURATE, יש פער בין הערך שמוחזר בתגובה ל-QUERY לבין הערך האחרון של Report State.

הפתרון: ודאו שהתכונה Report State מופעלת בכל פעם שסטטוס המכשיר משתנה, ושהתכונות Report State ו-QUERY תמיד מספקות את אותם ערכים עדכניים ואת כל השדות הנדרשים כדי לשמור על עקביות הנתונים.

"reportStateLog": {
   "isMissingField": false,
   "snapshotTime": "2026-04-13T07:56:21Z",
   "traitName": "TRAIT_ON_OFF",
   "detailedAccuracyResult": "DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE",
   "executionReportStateDifferences": {
      "expectedPostExecutionDeviceState": {
         "onOff": {
         "on": false
         }
      },
      "preExecutionDeviceState": {
         "onOff": {
         "on": true
         }
      },
      "executionCommand": {
         "requestId": "test001",
         "beginTimestamp": "2026-04-13T07:56:20Z",
         "action": {
         "trait": "TRAIT_ON_OFF",
         "actionType": "ONOFF_OFF"
         },
         "status": {
         "statusType": "SUCCESS_STATUS"
         },
         "endTimestamp": "2026-04-13T07:56:21Z",
         "executionType": "PARTNER_CLOUD"
      },
      "reportState": {}
   },
   "accuracy": "MISSING_REPORT_STATE",
   "deviceType": "action.devices.types.LIGHT",
   "agentId": "abc",
   "stateName": "on",
   "result": "MISSING_REPORT_STATE"
   }
  

הסיבה: בשגיאה DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE, השותף ביצע את הפקודה בהצלחה, אבל לא דיווח ל-Google על מצב המכשיר המעודכן.

הפתרון: תמיד שולחים עדכון של Report State אחרי הפעלת הפקודה, כדי ש-Home Graph יקבל את מצב המכשיר החדש.

eportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED"
    deviceId: "switch"
    deviceType: "action.devices.types.SWITCH"
    isMissingField: false
    isOffline: true
    queriedTime: "2026-04-13T13:53:26Z"
    queryReportStateDifferences: {
      queryState: "online    {
        online: false
      }
      "
      reportState: ""
    }
    reportedTime: "1970-01-01T00:00:00Z"
    requestId: "test001"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T13:53:26Z"
    stateName: "online"
    traitName: "TRAIT_ONLINE"
   }
  

הסיבה: בשגיאה DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED, לא התקבל דיווח על מצב המכשיר (המצב ריק וחותמת הזמן שדווחה היא ב-epoch), למרות שתוצאות ה-QUERY מספקות את הסטטוס הנוכחי. זה מצביע על כך שעדכוני המצב לא מופעלים, לא מגיעים ל-HomeGraph או שהמכשיר לא מדווח בהצלחה על שינויים בקישוריות או בסטטוס הפעילות שלו.

פתרון: מוודאים שהפונקציה Report State מופעלת ונשלחת בהצלחה בכל שינוי במצב. מוודאים שהלוגיקה של הקצה העורפי מטפלת בצורה נכונה בעדכוני הסטטוס, מאשרת שההעברה ל-Google HomeGraph בוצעה בהצלחה ומוודאת שהמכשיר מסנכרן את המצב שלו באופן עקבי כדי לשמור על הדיוק של ממשק המשתמש ומנוע האוטומציה.