כללי
ש: איפה ובאיזו שפה כדאי להטמיע את תשתית המעבר לענן?
תשובה: כל עוד הפלטפורמה תומכת ב-SSL (TLS) וב-OAuth 2.0, אתם יכולים להטמיע את התשתית בכל פלטפורמה ובכל שפה שתבחרו. מומלץ לפרוס את המערכת כמה שיותר קרוב לשאר התשתית, כדי לשפר את האמינות ולקצר את זמן האחזור של ההרצה במכשירי משתמשים בפועל.
ש:האם מזהי מכשירים צריכים להיות ייחודיים?
תשובה: המזהים צריכים להיות ייחודיים. אם אין לכם מזהים ייחודיים בשירות, הם צריכים להיות ייחודיים לפחות ברמת המשתמש. תארו לעצמכם משתמש עם כמה בתים, ששני הבתים משולבים עם אותו משתמש. בקשה להדלקת אור בבית אחד לא אמורה להדליק אור עם אותו מזהה בבית אחר.
ש: האם שמות המכשירים צריכים להיות ייחודיים?
תשובה: השמות לא חייבים להיות ייחודיים, אבל עם הזמן יכול להיות שנמליץ לאנשים לשפר שמות לא טובים אחרי ההגדרה כדי לשפר את חוויית המשתמש.
הנה מדריך קצר למתן שמות:
- השמות צריכים להיות כאלה שאנשים יכולים להגיד.
- אנחנו מזהים קבוצות משנה של מחרוזות, כך שאם יש לכם 'acme color light' אנחנו גם נשיב ל-'acme light'.
- מומלץ להשתמש בשם תיאורי למוצר וגם בשם אחד או יותר שהוגדרו על ידי המשתמש.
- המשתמשים לא צריכים לתת שמות לחדרים של הנורות, כי יש לנו חדרים בשביל זה. לכל חדר צריך להיות שם ייחודי, אבל תמיד אפשר להשתמש בלשון רבים כדי לשלוט בכל הנורות (לדוגמה, שתי הנורות במנורות הקיר במשרד הן 'נורה צפונית' ו'נורה מזרחית', אבל אפשר לשלוט בהן באמצעות הפקודה 'נורות').
ש: באיזו תדירות מתעדכן סטטוס המכשיר?
A: המצב הזמני מאוחזר אחרי QUERY או EXECUTE, שהן פעולות שהמשתמש יזם. אם המשתמש שואל 'האם האור דולק?' או רוצה להגביר את עוצמת האור, נצטרך לבצע שאילתה כדי לברר את המצב הנוכחי.
שאלה: האם אפשר לעדכן את תרשים הבית ישירות עם המצב הנוכחי של מכשיר?
תשובה: כן, אפשר להשתמש בקריאה ל-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 הוא מרכיב קריטי בפלטפורמה.
ש: אילו תכונות תומכות כרגע בסטטוס הדוח?
תשובה: יש תמיכה בכל ה-traits הציבוריים שמשויכים למצבים. צריך לדווח גם על כל שינוי במצב המכשיר (מחובר או לא מחובר).
שימו לב: לסצנות אין מצבים. עם זאת, יכול להיות שהן יגרמו לשינוי במצב של המכשירים. אם יש מכשיר ב-Google Home Graph שהמצב שלו השתנה, צריך לדווח על כך.
ש: האם צריך לשלוח חותמת זמן עם Report State?
תשובה: אנחנו לא דורשים חותמת זמן. המצב האחרון שנשלח יבטל את הקריאות הקודמות.
ש: האם צריך לדווח על מצב בנפרד אם כבר שולחים את המצב בשאילתה או בהפעלה?
תשובה: Home Graph מאחסן רק את המצב שנשלח באמצעות Report State. המצב שמוחזר כתגובה לכוונות EXECUTE ו-QUERY משמש רק לתגובות קוליות למשתמש ולא מאוחסן. לכן, צריך לקרוא ל-Report State גם אם המצב החדש של המכשיר כבר הוחזר כתגובה ל-EXECUTE או ל-QUERY intent.
ש: מהן ההשלכות של אי-הטמעה מלאה של Report State עד למועד האחרון שנקבע?
תשובה: הפעולה הזו תפגע בחוויית המשתמש, למשל בGoogle Home app (GHA) ובפלטפורמות ויזואליות. המשמעות היא שהרבה כוונות QUERY יישלחו כדי לבדוק את הסטטוס, ואין לנו אפשרות להבטיח מה יהיה העומס הנוסף על הענן של השותף.
שאלה: איך אפשר לבדוק את ההטמעה של Report State?
תשובה: אפשר להשתמש בכלי להצגת גרף הבית – כלי בדיקה בשירות עצמי שמציג את מצבי המכשירים הנוכחיים שמאוחסנים ב-Home Graph.
שאלה: האם אפשר להשתמש ב-requestId אקראי עבור Report State?
תשובה: אנחנו ממליצים לשותפים להשתמש באותו requestId שהם קיבלו מהבקשה EXECUTE אם ה-Report State מופעל על ידי הבקשה EXECUTE. אחרת, אפשר פשוט להשתמש ב-requestId אקראי.
ש: אם למשתמש יש כמה מכשירים ובאחד מהם חל שינוי במצב, צריך לדווח על המצב העדכני של כל המכשירים?
תשובה: לא. צריך לדווח רק על המצב של המכשיר הספציפי הזה.
שיטות מומלצות
ש: מהו זמן האחזור הסביר?
תשובה: זמן התגובה האידיאלי הוא פחות מ-200 אלפיות השנייה, וזמן תגובה של 2-5 שניות הוא סביר. אם זמן האחזור הוא בסביבות 5 שניות, אפשר לפנות אלינו.
ש: איך אפשר לגרום לרמקול עם הפעלה קולית להגיב בצורה תקינה כשהוא במצב אופליין?
תשובה: מחזירה את המצב אופליין למכשירים במצב אופליין. במקרה של השגיאה הזו, אנחנו מחזירים את הטקסט 'לא זמין כרגע' כ-TTS. מידע נוסף זמין במאמר בנושא שגיאות וחריגים.