Google Home Vitals (Cloud)

این مجموعه داشبوردها و هشدارها به شما کمک می‌کند تا به‌طور فعال یکپارچه‌سازی با کیفیت بالا با بوم‌سازگان Google Home را حفظ کنید. Google متعهد است که از شرکا در توسعه بوم‌سازگانی با کیفیت بالا برای همه مشتریان پشتیبانی کند.

داشبورد سه بخش دارد که هرکدام بخش کلیدی‌ای را پوشش می‌دهد که به کیفیت کلی ادغام کمک می‌کند.

1. سنجه‌های Google به شریک - سلامت تماس‌ها از Google به پشت‌بام ابری شما را اندازه‌گیری می‌کند.

2. سلامت سیستم - سنجه‌های شریک به Google - سلامت تماس‌ها را از سیستم شما به Google می‌سنجد.

3. سلامت دستگاه - دقت وضعیت - دقت وضعیت‌های ذخیره‌شده در سیستم‌های Google را که برای ارائه پُرسمان‌های کاربر استفاده می‌شود می‌سنجد.

وقتی سنجه‌ها به مقادیر هدف خود نمی‌رسند، با رنگ قرمز برجسته می‌شوند تا مشکلی را نشان دهند که می‌تواند بر تجربه کاربری تأثیر بگذارد. اطلاعات زیر جزئیاتی درباره هر هدف و دلیل اهمیت آن برای کاربران ارائه می‌دهد.

اگر دکمه زیر شما را مستقیماً به داشبورد نمی‌برد، می‌توانید با انتخاب صفحه نمای کلی، انتخاب داشبوردها، و سپس انتخاب داشبورد Google Home Vitals (ابر) از فهرست داشبوردهای من به آن دسترسی پیدا کنید.

رفتن به داشبورد

سنجه‌های Google به شریک

سنجه نرخ موفقیت پُرسمان/اجرا >= ۹۹٫۵٪ اندازه‌گیری می‌کند که فرمان‌های کاربران چند وقت یک‌بار به‌درستی انجام می‌شود، که به جلوگیری از پاسخ‌های «دستیار» مانند «نمی‌توانم به دستگاه دسترسی پیدا کنم» یا تأیید نادرست فرمانی که هنوز انجام نشده است کمک می‌کند.

سنجه نرخ موفقیت همگام‌سازی >= ۹۹٫۵٪ اندازه‌گیری می‌کند که درخواست‌های همگام‌سازی چند وقت یک‌بار به‌درستی انجام می‌شوند، که این امر تضمین می‌کند دستگاه‌های نشان‌داده‌شده در Google Home با دستگاه‌های متصل به زیرساخت ابری شما همگام‌سازی شده‌اند.

«موفقیت» چگونه تعریف می‌شود؟

اگر پلاتفرم Google Home پاسخ معتبری دریافت کند که نشان دهد کنش موردنظر انجام شده یا وضعیت درخواست‌شده بازیابی شده است، تراکنش به‌عنوان موفق علامت‌گذاری می‌شود.

پاسخ‌هایی که شامل استثناهای غیرمسدودکننده هستند (برای مثال، وضعیت SUCCESS همراه با استثنای lowBattery) به‌عنوان تراکنش‌های موفق شمرده می‌شوند. فرمان به دستگاه رسید و هدف با وجود هشدار برآورده شد.

«شکست» چگونه تعریف می‌شود؟

خطاهای یافت‌شده در کدهای خطای رایج پلاتفرم که به‌عنوان قابل‌اقدام توسط شریک علامت‌گذاری شده‌اند، هنگام محاسبه «نرخ‌های موفقیت» QUERY،‏ EXECUTE، و SYNC به‌عنوان «شکست» درنظر گرفته می‌شوند. علاوه‌براین، خطاهای یافت‌شده در خطاها و استثناها نیز «ناموفق» هستند، به‌جز موارد زیر:

برابری وضعیت پاسخ اجرا

هنگام برگرداندن وضعیت SUCCESS در پاسخ EXECUTE، شیء states در محموله پاسخ شما باید حاوی همه فیلدهای حالت فعال و به‌روزشده‌ای باشد که توسط ویژگی‌های درحال اجرا تعریف شده‌اند. Omitting required state fields, or returning an empty states object for complex traits, will cause the Google Home platform to fail to parse the execution result, registering it as an AGENT_ISSUE or INVALID_RESPONSE failure which drops your Query and Execute Success Rate.

سنجه تأخیر پرسمان/اجرا (p90) <= ۱۰۰۰ میلی‌ثانیه زمان انتظار کنش درخواست‌شده را اندازه‌گیری می‌کند و کمک می‌کند مطمئن شوید کاربران مجبور نیستند خیلی منتظر بمانند، برای مثال، چند ثانیه منتظر بمانند تا چراغشان خاموش شود.

سنجه‌های تأخیر

تأخیر شاخصی حیاتی برای میزان پاسخ‌گویی ادغام شما به کاربر نهایی است. داشبورد «تأخیر صدک نودم» (P90) را ردیابی می‌کند که نشان‌دهنده تجربه «کندترین» کاربران شما است (برای مثال، P90 با مقدار ۸۰۰ میلی‌ثانیه یعنی ۹۰٪ درخواست‌ها در ۸۰۰ میلی‌ثانیه یا کمتر تأیید شده‌اند).

Google برای اطمینان از دقت فنی، تأخیر را برای بررسی وضعیت متفاوت از فرمان‌های دستگاه اندازه‌گیری می‌کند.

۱. تأخیر پُرسمان (پرسشی)

این زمان رفت‌وبرگشت Cloud-to-cloud را وقتی Google وضعیت فعلی دستگاه را می‌پرسد اندازه‌گیری می‌کند.

• شروع: Google درخواست action.devices.QUERY را به نشانی وب برآورده‌سازی شما ارسال می‌کند.
• پنجره اندازه‌گیری: مدت زمانی که طول می‌کشد تا فضای ابری شما پاسخ کامل HTTP را دریافت، پردازش، و به Google ارسال کند.
• پایان: Google بار داده پاسخ نهایی را از سرویس شما دریافت و تأیید می‌کند.

۲. تأخیر EXECUTE (کنش)

این معیار زمان تأیید فرمان را وقتی Google درخواست کنترل به دستگاه ارسال می‌کند اندازه‌گیری می‌کند.

• شروع: Google درخواست action.devices.EXECUTE را به نشانی وب برآورده‌سازی شما ارسال می‌کند.
• پنجره اندازه‌گیری: مدت زمانی که طول می‌کشد تا فضای ابری شما فرمان را دریافت کند و پاسخ تأیید را برگرداند.
• پایان: Google پاسخ وضعیت SUCCESS، PENDING، یا OFFLINE را دریافت می‌کند.
• محدوده فنی: این سنجه زمان «تأیید پاسخ» بین ابر Google و ابر شما را اندازه‌گیری می‌کند. این معیار مدت‌زمانی را که طول می‌کشد تا سخت‌افزار فیزیکی (برای مثال، لامپ) تغییر وضعیت فیزیکی را تکمیل کند اندازه‌گیری نمی‌کند، زیرا این امر اغلب شامل تأخیر شبکه توری محلی خارج از مسیر ابربه‌ابر می‌شود.

تفکیک خط زمان تأخیر EXECUTE/QUERY

هنگام تجزیه‌وتحلیل مُهرهای زمان برای تأخیر EXECUTE یا QUERY، کل زمان رفت‌وبرگشت را می‌توان به جریان متوالی زیر تقسیم کرد:

ازآنجایی‌که این تفکیک مُهرهای زمان طرف Google و طرف «شریک» را مقایسه می‌کند، سرورهای «شریک» باید با NTP (پروتکل زمان شبکه) همگام‌سازی شوند. حتی یک انحراف جزئی ساعت (۵۰ تا ۱۰۰ میلی‌ثانیه) زمان‌های محاسبه‌شده حمل‌ونقل (t2 - t1 و t4 - t3) را تحریف می‌کند و به‌طور بالقوه منجر به معیارهای غیرممکن منطقی مانند تأخیرهای منفی حمل‌ونقل می‌شود.

[t1] درخواست ارسال شد (برون‌مرزی Google): Google درخواست هدف را آغاز می‌کند. چون t1 مستقیماً درمعرض دید نیست، تقریباً با کم کردن کل تأخیر از مُهر زمان ورودی نهایی محاسبه می‌شود.

انتقال شبکه (t1 تا t2): زمان تخمینی انتقال شبکه و صف قبل‌از رسیدن به نقطه پایانی برآورده‌سازی شما.

[t2] درخواست دریافت شد (ورود شریک): مُهر زمان دقیق وقتی که درخواست به درگاه API یا سرور ورودی محیط شما می‌رسد.

پردازش شریک (t2 تا t3): تأخیر اجرای داخلی، مسیریابی، و مدیریت دستگاه کاملاً در محیط ابری شما.

[t3] پاسخ ارسال شد (خروج شریک): مُهر زمان وقتی که سرویس شما پاسخ انجام را به Google برمی‌گرداند.

انتقال برگشتی (t3 به t4): زمان تکمیل اتصال و مسیریابی شبکه برگشتی به Google.

[t4] نهایی شدن درخواست (ورودی Google): Google پاسخ نهایی را دریافت و پردازش می‌کند. این مُهر زمان به‌طور صریح در گزارش‌های Google Cloud شما به‌عنوان receiveTimestamp ثبت شده است.

برای نشان دادن نحوه ارتباط این سنجه‌ها با یکدیگر، یک نمونه درخواست EXECUTE با مجموع تأخیر ثبت‌شده (latencyMsec) ۱۷۰۰ میلی‌ثانیه و Google Cloud receiveTimestamp (t4) 2026-05-25T15:25:00.550Z را درنظر بگیرید.

گزینه‌های کاهش تأخیر

توصیه‌های معماری برای مسیریابی جغرافیایی

اگر پیاده‌سازی IP هرپخشی امکان‌پذیر نیست، جایگزین‌های مقرون‌به‌صرفه زیر را توصیه می‌کنیم تا مطمئن شوید کاربران از نزدیک‌ترین مرکز داده منطقه‌ای خدمات دریافت می‌کنند.

1. تراز کردن بار سراسری (GLB)

   به‌جای مسیریابی ایستا، از ترازکننده بار برنامه جهانی (در اکثر ارائه‌دهندگان اصلی ابری دردسترس است) استفاده کنید.

   • نحوه کار: یک نقطه ورودی جهانی (نشانی وب) پیکربندی می‌کنید که در لبه شبکه قرار می‌گیرد. متعادل‌کننده بار به‌طور خودکار مبدأ جغرافیایی درخواست را از خوشه‌های اجرای Google شناسایی می‌کند و ترافیک را به نزدیک‌ترین پسای سالم منطقه‌ای شما هدایت می‌کند.

   • مزیت: این گزینه عملکرد Anycast را با پیچیدگی پیکربندی و هزینه بسیار کمتر ارائه می‌دهد.

2. ساناد آگاه از موقعیت جغرافیایی (GeoDNS)

   • نحوه عملکرد: ارائه‌دهنده ساناد خود را پیکربندی کنید تا نشانی وب برآورده‌سازی شما را براساس مکان جغرافیایی پرسمان ساناد به نشانی‌های IP مختلف تبدیل کند.

   • پیاده‌سازی: مطمئن شوید ارائه‌دهنده ساناد شما برای نقاط خروجی Google بهینه‌سازی شده است. وقتی خدمات اجرای منطقه‌ای Google (برای مثال، در ایالات متحده، اتحادیه اروپا، یا آسیا) دامنه شما را حل‌وفصل می‌کند، نشانی IP مرکز داده را در آن منطقه خاص دریافت خواهد کرد.

راهبردهای بهینه‌سازی در لایه برنامه

فراتر از مسیریابی در سطح زیرساخت، می‌توانید راهبردهای زیر را در لایه برنامه پیاده‌سازی کنید تا تأخیر در پردازش درخواست کاهش یابد.

1. روش پراکسی «ترامپولین»

   اگر باید مرکز داده اصلی را حفظ کنید، از سرورهای پراکسی سبک منطقه‌ای (Trampolines) برای انجام دست‌دهی اولیه استفاده کنید.

   1. Google به نشانی وب جهانی شما دسترسی پیدا می‌کند.

   2. یک پراکسی منطقه‌ای (برای مثال، یک تابع سبک Nginx یا Lambda) درخواست را دریافت می‌کند.

   3. پراکسی محموله را ازطریق ستون فقرات پرسرعت داخلی شما به پایگاه داده اصلی بازارسال می‌کند.

   مزیت: این کار زمان «دست‌دهی TCP» را کاهش می‌دهد که اغلب بزرگ‌ترین عامل تأخیر در درخواست‌های راه دور است.

2. نکته‌های منطقه کد دسترسی

   درطول فرایند «پیوند دادن حساب» (OAuth)، سیستم شما می‌تواند منطقه خانه کاربر را شناسایی کند.

   پیاده‌سازی: شناسه منطقه را در access_token صادرشده برای Google کدبندی کنید. وقتی Google درخواست انجام ارسال می‌کند، درگاه شما می‌تواند فوراً توکن را بررسی کند و درخواست را بدون نیاز به جستجوی پایگاه داده به خوشه منطقه‌ای صحیح هدایت کند.

سلامت سیستم - سنجه‌های شریک به Google

حفظ نرخ موفقیت >= ۹۹٫۵٪ کمک می‌کند مطمئن شوید که وضعیت دستگاه‌ها در Google Home درست است، دستگاه‌ها اضافه و برداشته می‌شوند، خودکارسازی‌ها راه‌اندازی می‌شوند، و رویدادهای سابقه در برگه «فعالیت» Google Home app (GHA) نشان داده می‌شوند.

«نرخ موفقیت» براساس کدهای پاسخ HTTP محاسبه می‌شود که وقتی فضای ابری شما به‌روزرسانی‌های وضعیت را ارسال می‌کند، Google برمی‌گرداند. برای اطمینان از اینکه شرکا به‌دلیل مشکلات زیرساختی ازطرف Google جریمه نمی‌شوند، این سنجه خطاهای داخلی Google را از تعداد موارد ناموفق مستثنی می‌کند. فراخوانی‌های میانای برنامه‌سازی کاربردی که در محاسبه گنجانده شده‌اند در مرجع HomeGraph API قرار دارند.

«موفقیت» چگونه تعریف می‌شود؟

‫2xx (موفقیت): به‌روزرسانی وضعیت باموفقیت توسط Home Graph دریافت و پردازش شد.

«شکست» چگونه تعریف می‌شود؟

‫4xx (خطای شریک) نشان‌دهنده خرابی است و به مشکلی در درخواست ارسال‌شده از فضای ابری شما اشاره دارد. کدهای رایج عبارت‌اند از:

خطای ۴۰۰ - درخواست نامناسب

علت: سرور به‌دلیل نحو نامعتبر نتوانست درخواست را پردازش کند. دلایل رایج شامل JSON بدشکل یا استفاده از null به‌جای «» برای مقدار رشته‌ای است.

راه‌حل: مطمئن شوید که بدنه درخواست در قالب JSON معتبر باشد (ساختار بدشکل یا مقادیر تهی برای فیلدهای رشته‌ای وجود نداشته باشد)، و بررسی کنید که agentUserId با مقدار پاسخ SYNC مطابقت داشته باشد.

‫404 یافت نشد

علت: deviceId یا agentUserId در HomeGraph پیدا نشد (هنوز همگام‌سازی نشده است، قبلاً لغو پیوند شده است، یا شناسه مطابقت ندارد).

راه‌حل:

1. مطمئن شوید که agentUserId با مقدار ارائه‌شده در پاسخ همگام‌سازی شما مطابقت داشته باشد.
2. از Home Graph SYNC API استفاده کنید تا مشخص شود که آیا خطای «۴۰۴ پیدا نشد» به‌دلیل نبودن دستگاه یا کاربر در HomeGraph است یا نه.
3. حتماً requestSync را پس‌از افزودن، برداشتن، تغییر نام، یا به‌روزرسانی دستگاه یا حساب راه‌اندازی کنید تا مطمئن شوید وضعیت به‌روز می‌ماند.
4. برای توقف گزارش دستگاه‌های قدیمی، هدف‌های DISCONNECT را به‌درستی مدیریت کنید. پس‌از دریافت قصد DISCONNECT، سرویس ابری شما باید انتشار تغییرات در Google را با درخواست همگام‌سازی و گزارش وضعیت متوقف کند.

‫۴۲۹ منبع تمام شد

علت: یکپارچه‌سازی شما از سهمیه تخصیص‌یافته فراتر رفته است.

راه‌حل: دستورالعمل‌های بخش «مرحله ۲الف: اشکال‌زدایی مشکلات سهمیه» در داشبورد مدیریت سهمیه را ببینید. برای اطلاعات بیشتر، می‌توانید به سهمیه‌ها و محدودیت‌های «خانه هوشمند» نیز مراجعه کنید.

سلامت دستگاه - دقت وضعیت

رسیدن به دقت وضعیت >= ۹۹٫۵٪ یا فراتر رفتن از آن کمک می‌کند مطمئن شوید کاربران هنگام مشاهده وضعیت دستگاه یا استفاده از ویژگی‌های مبتنی بر هوش مصنوعی مثل «از Home بپرسید» نتایج صحیح را می‌بینند. اگر دقت وضعیت پایین باشد، ممکن است خودکارسازی‌ها اجرا نشود و ورودی‌های سابقه در زمان مناسب در زبانه «فعالیت» GHA نشان داده نشود. برای اطلاعات بیشتر، به وضعیت گزارش مراجعه کنید. لطفاً توجه کنید: هدف «دقت وضعیت» باید در همه ویژگی‌های پشتیبانی‌شده برآورده شود.

۱. اجزای دقت

این سنجه از «نمونه‌هایی» گرفته شده است که Google می‌تواند وضعیت گزارش‌شده را دربرابر نتیجه قصد معلوم درستی‌سنجی کند. برای دقت فنی، صحت ازطریق دو مسیر متمایز ارزیابی می‌شود:

• دقت مبتنی بر پُرسمان: زمانی درستی‌سنجی می‌شود که کاربر یا سیستم به‌طور فعال وضعیت فعلی دستگاه را بررسی کند.
• دقت مبتنی بر EXECUTE: با ارزیابی وضعیت دستگاه پس‌از فرمان که به‌دنبال درخواست کنترل گزارش می‌شود تأیید می‌شود.

۲. سنجه‌های داشبورد (محاسبه ساعتی)

داشبورد دقت را براساس فاصله ۱ ساعته محاسبه می‌کند. برای اطمینان از اطمینان آماری و جلوگیری از جریمه کردن ادغام‌ها در نویز سیگنال پایین، Google آستانه حداقل حجم ترافیک را اعمال می‌کند. اگر ترکیب ویژگی و دستگاه خاصی در یک پنجره ۵ روزه متوالی کمتر از ۱۰۰ نمونه کل جمع‌آوری کند، دقت آن ازنظر آماری بی‌اهمیت تلقی می‌شود و روی ناموجود تنظیم می‌شود.

وقتی یک ساعت حجم نمونه کافی در هر دو مسیر داشته باشد، دقت ساعتی خط مبنا برای یک ایالت خاص به‌عنوان میانگین دو درصد مستقل محاسبه می‌شود:

دقت وضعیت ساعتی = (درصد دقت پُرسمان + درصد دقت اجرا) / ۲

که هر مسیر به‌صورت زیر تعریف می‌شود:

• درصد دقت پُرسمان = (نمونه‌های دقیق پُرسمان ساعتی) / (کل نمونه‌های پُرسمان ساعتی)
• درصد دقت اجرا = (نمونه‌های دقیق اجرای ساعتی) / (مجموع نمونه‌های اجرای ساعتی)

امتیاز دقت ویژگی (محاسبه‌شده برای هر ویژگی) = مجموع(نمونه‌های دقیق پُرسمان + نمونه‌های دقیق اجرا) / مجموع(کل نمونه‌های پُرسمان + کل نمونه‌های اجرا)

ازآنجایی‌که «امتیاز کیفیت» عملکرد حداقل سخت‌گیرانه را در سراسر بوم‌سازگان شما ارزیابی می‌کند، هر ویژگی پشتیبانی‌شده و واجدشرایط باید به‌طور جداگانه به هدف «دقت وضعیت» ۹۹٫۵٪ یا بیشتر برسد (این مقدار میانگین ویژگی‌ها نیست).

این نما از پنهان شدن مشکلات دقت در دستگاه‌های با حجم کمتر توسط دستگاه‌های با حجم بالا و دقت عالی جلوگیری می‌کند. شرکایی که نگران هستند ویژگی‌های کم‌استفاده امتیاز آن‌ها را کاهش دهد می‌توانند مطمئن باشند که ویژگی‌های به‌ندرت استفاده‌شده به‌طور خودکار توسط بررسی حداقل حجم ترافیک محافظت می‌شوند و در امتیاز «پایین‌ترین نوع و ویژگی» لحاظ نخواهند شد، مگراینکه به آستانه نمونه موردنیاز برسند.

۳. بهبود دقت وضعیت و سلامت دستگاه

وقتی وضعیت ذخیره‌شده در Home Graph با نتایج «پرس‌وجو» هم‌زمان مطابقت نداشته باشد، مغایرت رخ می‌دهد.

خطاهای «فیلد موجود نیست»

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، مجموعه فیلدهای بار داده بین پاسخ «پُرسمان» شما و درخواست «وضعیت گزارش» شما برای همان دستگاه متفاوت است.

راه‌حل: مطمئن شوید ساختار داده در هر دو مسیر یکسان باشد. اگر ویژگی‌ای در 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 مغایرت وجود دارد.

راه‌حل: مطمئن شوید که هرگاه وضعیت دستگاه تغییر می‌کند، «وضعیت گزارش» راه‌اندازی می‌شود و «وضعیت گزارش» و 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 گزارش نکرده است.

راه‌حل: همیشه پس‌از اجرای فرمان، به‌روزرسانی «وضعیت گزارش» را ارسال کنید تا 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، هیچ «وضعیت گزارش» برای این دستگاه دریافت نشده است (وضعیت خالی است و مُهر زمان گزارش‌شده در مبدأ زمانی است)، بااینکه نتایج QUERY وضعیت فعلی را ارائه می‌دهد. این نشان می‌دهد که به‌روزرسانی‌های وضعیت یا راه‌اندازی نمی‌شوند، یا به HomeGraph نمی‌رسند، یا دستگاه نمی‌تواند تغییرات در وضعیت اتصال یا عملیاتی خود را به‌درستی گزارش کند.

راه‌حل: مطمئن شوید که «گزارش وضعیت» برای همه تغییرات وضعیت راه‌اندازی و باموفقیت ارسال شده است. تأیید کنید که منطق پس‌زمینه به‌درستی به‌روزرسانی‌های وضعیت را مدیریت می‌کند، موفقیت تحویل به Google HomeGraph را تأیید می‌کند، و اطمینان حاصل می‌کند که دستگاه به‌طور مداوم وضعیت خود را همگام‌سازی می‌کند تا میانای کاربر و موتور خودکارسازی دقیق بمانند.