Google Home Vitals (Cloud)

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

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

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

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

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

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

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

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

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

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

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

چه چیزی «موفقیت» را تعریف می‌کند؟

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

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

چه چیزی «عدم موفقیت» را تعریف می‌کند؟

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

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

وقتی وضعیت SUCCESS را در پاسخ EXECUTE برمی‌گردانید، شیء states در بار پاسخ شما باید حاوی همه فیلدهای وضعیت فعال و به‌روزشده تعریف‌شده توسط ویژگی‌هایی باشد که اجرا می‌کنید. حذف فیلدهای وضعیت الزامی، یا برگرداندن شیء states خالی برای ویژگی‌های پیچیده، باعث می‌شود پلاتفرم Google Home نتواند نتیجه اجرا را تجزیه کند و آن را به‌عنوان AGENT_ISSUE یا INVALID_RESPONSE ثبت کند که باعث کاهش «نرخ موفقیت» «پُرسمان و اجرا» می‌شود.

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

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

تأخیر نشانگر مهمی از میزان پاسخ‌گو بودن یکپارچه‌سازی شما برای کاربر نهایی است. داشبورد «تأخیر صدک ۹۰» (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 را درنظر بگیرید.

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

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

اگر پیاده‌سازی Anycast 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 یافت می‌شوند.

چه چیزی «موفقیت» را تعریف می‌کند؟

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

چه چیزی «عدم موفقیت» را تعریف می‌کند؟

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

‫۴۰۰ درخواست نادرست

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

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

‫404 یافت نشد

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

راه‌حل:

1. مطمئن شوید که agentUserId با مقدار ارائه‌شده در پاسخ «همگام‌سازی» مطابقت داشته باشد.
2. از Home Graph SYNC API استفاده کنید تا مشخص کنید خطای 404 Not Found به‌دلیل وجود نداشتن دستگاه یا کاربر در HomeGraph است یا نه.
3. حتماً پس‌از افزودن، برداشتن، تغییر نام، یا به‌روزرسانی دستگاه یا حساب، requestSync را راه‌اندازی کنید تا وضعیت به‌روز بماند.
4. برای متوقف کردن گزارش دستگاه‌های قدیمی، قصد DISCONNECT را به‌درستی مدیریت کنید. پس‌از دریافت هدف DISCONNECT، خدمات ابری شما باید انتشار تغییرات در Google را با Request Sync (درخواست همگام‌سازی) و Report State (گزارش وضعیت) متوقف کند.

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

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

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

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

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

۱. اجزای دقت

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

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

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

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

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

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

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

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

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

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

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

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

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

راه‌حل: مطمئن شوید که «وضعیت گزارش» هر زمان که وضعیت دستگاه تغییر می‌کند راه‌اندازی شود و «وضعیت گزارش» و «پُرسمان» همیشه مقادیر دقیق، به‌روز، و یکسانی را ارائه دهند و همه فیلدهای لازم برای حفظ یکپارچگی داده‌ها را داشته باشند.

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

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