שאלות נפוצות על בית חכם

כללי

שאלה: איפה ובאיזו שפה כדאי להטמיע את תשתית המעבר שלנו מענן לענן?

תשובה: כל עוד הפלטפורמה תומכת ב-SSL (TLS) וב-OAuth 2.0, אתם יכולים להטמיע את התשתית בכל פלטפורמה ובכל שפה שתבחרו. מומלץ לפרוס את התוסף כמה שיותר קרוב לשאר התשתית, כדי לשפר את האמינות ולקצר את זמן האחזור של ההפעלה במכשירי המשתמשים בפועל.

ש:האם מזהי מכשירים צריכים להיות ייחודיים?

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

ש: האם שמות המכשירים צריכים להיות ייחודיים?

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

הנה מדריך קצר למתן שמות:

  • השמות צריכים להיות כאלה שאנשים יכולים להגיד.
  • אנחנו מזהים קבוצות משנה של מחרוזות, כך שאם יש לכם 'acme color light' אנחנו גם נענה ל-'acme light'.
  • מומלץ להשתמש בשם תיאורי למוצר וגם בשם אחד או יותר שהמשתמש מגדיר.
  • המשתמשים לא צריכים לתת שמות לחדרים של התאורה, כי יש לנו חדרים בשביל זה. הם צריכים לתת שמות ייחודיים לכל חדר, אבל הם תמיד יכולים להשתמש בלשון רבים כדי לשלוט בכל התאורה (לדוגמה, שתי הנורות במנורות הקיר במשרד הן 'תאורה צפונית' ו'תאורה מזרחית', אבל אפשר לשלוט בהן באמצעות הפקודה 'תאורה').

שאלה: באיזו תדירות מתעדכן סטטוס המכשיר?

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

שאלה: האם אפשר לעדכן את תרשים הבית ישירות עם המצב הנוכחי של מכשיר?

תשובה: כן, אפשר להשתמש בקריאה ל-API ‏Report State.

קישור חשבונות ו-OAuth

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

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

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

כוונות

ש: מתי מתבצע סנכרון?

תשובה: הסנכרון מתבצע מיד אחרי השלמת OAuth, ואחרי שמתבצעת קריאה של Request Sync.

ש: למה SYNC לא עובד?

תשובה: יש כמה סיבות נפוצות לכך שהפעולה נכשלת.

  • אתם שולחים סוגי מכשירים שגויים.

    • לדוגמה, אנחנו מצפים לקבל action.devices.types.LIGHT, אבל אתם שולחים action.devices.types.Light.

  • אתם שולחים סוגי מכשירים שלא נתמכים.

    • לדוגמה, אם שולחים action.devices.types.FLASHLIGHT – זה לא משהו שאנחנו תומכים בו.

  • אתם שולחים שדות לא תקינים או לא נתמכים.

    • לדוגמה, יש לכם שדה שלא מופיע במפרט שלנו.

  • יש בעיה אחרת בעיצוב של תגובת ה-SYNC.

    • כדאי לבדוק את הסוגריים!

  • נתקלת בבעיה בקישור החשבון.

    • צריך לוודא שמתקבל טוקן גישה תקין בכותרת Auth של בקשת הסנכרון.

  • עבר יותר מדי זמן מאז שקיבלת את בקשת הסנכרון.

    • חשוב לוודא שאתם מגיבים לבקשת הסנכרון תוך 5 שניות.

שאלה: האם אפשר להשתמש בתגובה 'בהמתנה'?

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

בדיקה ושליחה

ש: אפשר להגדיר סביבת פיתוח בענן?

תשובה: כן, אפשר לבדוק סביבת ענן והגדרה שלא הושקו.

ש: הפעולה שלי לא מופיעה בקטע 'שליטה בבית' באפליקציית Google Home. מה קורה?

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

מצב הדוח

שאלה: האם יש תנאים מוקדמים להטמעה של Report State?

תשובה: הפרויקט צריך להשתמש ב-Smart Home API, לתמוך ב-OAuth2 ולכלול מאפיינים עם מצבים שאפשר לדווח עליהם.

שאלה: באיזו תדירות צריך לדווח על מצב המכשיר?

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

ש: האם צריך לשלוח את המצב המלא של המכשיר כשמבצעים קריאות של Report State?

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

ש: האם Google יכולה לשלוח שאילתה למכשיר שלי כדי לקבל את המצב שלו (כלומר, לבצע סקר במכשיר)?

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

שאלה: אילו מאפיינים תומכים כרגע בסטטוס הדוח?

תשובה: יש תמיכה בכל התכונות הציבוריות שמשויכים אליהן מצבים. צריך לדווח גם על כל שינוי במצב המכשיר (מחובר או לא מחובר).

שימו לב: לסצנות אין מצבים. עם זאת, הן עשויות לגרום לשינוי במצב של המכשירים. אם יש מכשיר ב-Google Home Graph שבו חל שינוי במצב, צריך לדווח על כך.

שאלה: האם צריך לשלוח חותמת זמן עם Report State?

תשובה: אנחנו לא דורשים חותמת זמן. המצב האחרון שנשלח יבטל את הקריאות הקודמות.

ש: האם צריך לשלוח את הסטטוס בנפרד אם כבר שולחים אותו בשאילתה או בהפעלה?

תשובה: Home Graph מאחסן רק את המצב שנשלח דרך Report State. המצב שמוחזר כתשובה לכוונות EXECUTE ו-QUERY משמש רק לתשובות קוליות למשתמש ולא מאוחסן. לכן, צריך להפעיל את Report State גם אם המצב החדש של המכשיר כבר הוחזר בתגובה ל-intent מסוג EXECUTE או QUERY.

שאלה: מהן ההשלכות של אי-הטמעה מלאה של Report State עד למועד האחרון שנקבע?

תשובה: הפעולה הזו תפגע בחוויית המשתמש, למשל בGoogle Home app (GHA) ובפלטפורמות ויזואליות. המשמעות היא שהרבה כוונות QUERY יישלחו כדי לבדוק את הסטטוס, ואין לנו אפשרות להבטיח למה זה יתאים בעומס נוסף על הענן של השותף.

שאלה: איך אפשר לבדוק את ההטמעה של Report State?

תשובה: אפשר להשתמש בכלי Home Graph Viewer – כלי בדיקה בשירות עצמי שמציג את הסטטוסים הנוכחיים של המכשירים שמאוחסנים ב-Home Graph.

שאלה: האם אפשר להשתמש ב-requestId אקראי בשביל Report State?

ת: אנחנו ממליצים לשותפים להשתמש באותו requestId שהם קיבלו מהבקשה EXECUTE אם הפונקציה Report State מופעלת על ידי הבקשה EXECUTE. אחרת, אפשר פשוט להשתמש ב-requestId אקראי.

שאלה: אם למשתמש יש כמה מכשירים ואחד מהם משנה את הסטטוס שלו, האם צריך לדווח על הסטטוס העדכני של כל המכשירים?

ת: לא. צריך לדווח רק על המצב של המכשיר הספציפי הזה.

שיטות מומלצות

ש: מהו זמן האחזור הסביר?

תשובה: זמן טעינה של פחות מ-1,000 אלפיות השנייה הוא אידיאלי, וזמן טעינה של 2 עד 5 שניות הוא סביר. אם זמן הטעינה הוא בסביבות 5 שניות, צריך ליצור איתנו קשר.

שאלה: איך אפשר לגרום לרמקול עם הפעלה קולית להגיב בצורה תקינה כשהוא במצב אופליין?

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