Google Home Vitals (السحابة الإلكترونية)

تساعدك هذه المجموعة من لوحات البيانات والتنبيهات في الحفاظ بشكل استباقي على عملية دمج عالية الجودة مع منظومة Google Home المتكاملة. تلتزم Google بدعم الشركاء في تطوير منظومة متكاملة عالية الجودة لجميع العملاء.

تتضمّن لوحة البيانات ثلاثة أقسام، يغطي كل منها جزءًا رئيسيًا يساهم في جودة عملية الدمج بشكل عام.

1. مقاييس Google إلى الشريك: تقيس حالة المكالمات من Google إلى الخلفية السحابية.

2. سلامة النظام - مقاييس الشريك إلى Google: تقيس سلامة المكالمات من نظامك إلى Google.

3. سلامة الجهاز - دقة الحالة: يقيس هذا المقياس دقة الحالات المخزَّنة في أنظمة Google، والتي تُستخدَم لعرض طلبات المستخدمين.

عندما لا تستوفي المقاييس القيم المستهدَفة، يتم تمييزها باللون الأحمر للإشارة إلى مشكلة قد تؤثر في تجربة المستخدم. توفّر المعلومات التالية تفاصيل عن كل هدف وسبب أهميته للمستخدمين.

إذا لم ينقلك الزر التالي مباشرةً إلى لوحة البيانات، يمكنك الوصول إليها من خلال الانتقال إلى صفحة نظرة عامة، ثم اختيار لوحات البيانات، ثم اختيار لوحة بيانات Google Home Vitals (السحابية) من قائمة لوحات البيانات الخاصة بي لعرض لوحة البيانات.

الانتقال إلى لوحة البيانات

مقاييس Google to Partner

يقيس مقياس معدّل نجاح الطلب/التنفيذ >=%99.5 عدد المرات التي يتم فيها تنفيذ طلبات المستخدمين بشكل صحيح، ما يساعد في تجنُّب ردود "مساعد Google" مثل "لا يمكنني الوصول إلى الجهاز" أو تأكيد طلب لم يتم تنفيذه بعد بشكل غير صحيح.

يُقاس مقياس معدّل نجاح المزامنة >=%99.5 بعدد المرات التي يتم فيها تنفيذ طلبات المزامنة بشكل صحيح، ما يضمن مزامنة الأجهزة المعروضة في Google Home مع الأجهزة المتصلة بالبنية الأساسية للسحابة الإلكترونية.

ما الذي يحدد "النجاح"؟

يتم وضع علامة على المعاملة على أنّها ناجحة إذا تلقّت منصة Google Home ردًا صالحًا يشير إلى أنّه تم تنفيذ الإجراء المطلوب أو تم استرداد الحالة المطلوبة.

يتم احتساب الردود التي تتضمّن استثناءات غير محظورة (على سبيل المثال، حالة SUCCESS مصحوبة باستثناء lowBattery) كمعاملات ناجحة. وصل الأمر إلى الجهاز وتم تنفيذ الإجراء المطلوب على الرغم من التحذير.

ما الذي يحدّد "الفشل"؟

تُعتبر الأخطاء التي تم العثور عليها في رموز الأخطاء الشائعة في المنصة والتي تم وضع علامة Partner Actionable عليها "أخطاء" عند احتساب معدّلات نجاح طلبات QUERY وEXECUTE وSYNC. بالإضافة إلى ذلك، فإنّ الأخطاء الموجودة في الأخطاء والاستثناءات تُعدّ أيضًا "أخطاء"، مع الاستثناءات التالية:

التكافؤ في حالة الاستجابة للتنفيذ

عند عرض حالة SUCCESS في استجابة EXECUTE، يجب أن يحتوي كائن states في حمولة الاستجابة على جميع حقول الحالة النشطة والمعدَّلة التي تحدّدها السمات التي تنفّذها. سيؤدي حذف حقول الحالة المطلوبة أو عرض عنصر states فارغ للسمات المعقّدة إلى فشل Google Home Platform في تحليل نتيجة التنفيذ، وتسجيلها على أنّها خطأ AGENT_ISSUE أو INVALID_RESPONSE، ما يؤدي إلى خفض معدّل نجاح طلبات البحث والتنفيذ.

يقيس مقياس وقت استجابة الطلب/التنفيذ (p90) <= 1000 ملي ثانية وقت انتظار الإجراء المطلوب ويساعد في ضمان عدم اضطرار المستخدمين إلى الانتظار لفترة طويلة، على سبيل المثال، الانتظار لبضع ثوانٍ حتى ينطفئ الضوء.

مقاييس وقت الاستجابة

يُعدّ وقت الاستجابة مؤشرًا مهمًا على مدى سرعة استجابة عملية الدمج للمستخدم النهائي. تتتبّع لوحة البيانات وقت الاستجابة في الشريحة المئوية التسعين (P90)، والذي يمثّل تجربة المستخدمين "الأبطأ" (على سبيل المثال، يعني وقت الاستجابة في الشريحة المئوية التسعين الذي يبلغ 800 ملي ثانية أنّه يتم الإقرار بـ% 90 من الطلبات في غضون 800 ملي ثانية أو أقل).

تقيس Google وقت الاستجابة بشكل مختلف لعمليات التحقّق من الحالة مقارنةً بأوامر الأجهزة لضمان الدقة الفنية.

1. وقت الاستجابة لطلب البحث (استفهامي)

يقيس هذا المقياس مدة رحلة الذهاب والعودة لـ Cloud-to-cloud عندما تطلب Google الحالة الحالية للجهاز.

• البداية: ترسل Google طلب action.devices.QUERY إلى عنوان URL الخاص بتنفيذ الطلبات.
• نافذة القياس: الوقت الذي تستغرقه السحابة الإلكترونية لتلقّي استجابة HTTP الكاملة ومعالجتها وإرسالها مرة أخرى إلى Google.
• النهاية: تتلقّى Google حمولة الاستجابة النهائية من خدمتك وتقرّ باستلامها.

2. وقت استجابة التنفيذ (الإجراء)

يقيس هذا المقياس وقت الإقرار بالأمر عندما ترسل Google طلب تحكّم إلى جهاز.

• البداية: ترسل Google طلب action.devices.EXECUTE إلى عنوان URL الخاص بتنفيذ الطلبات.
• نافذة القياس: الوقت الذي تستغرقه السحابة الإلكترونية لتلقّي الأمر وإرسال ردّ بالإقرار
• النهاية: تتلقّى Google ردًّا يتضمّن الحالة SUCCESS أو PENDING أو OFFLINE.
• النطاق الفني: يقيس هذا المقياس وقت "إقرار الاستجابة" بين سحابة Google وسحابتك. ولا يقيس الوقت الذي يستغرقه الجهاز (مثل المصباح الكهربائي) لإكمال تغيير الحالة المادية، لأنّ ذلك غالبًا ما يتضمّن وقت استجابة الشبكة المتداخلة المحلية خارج مسار الاتصال من السحابة الإلكترونية إلى السحابة الإلكترونية.

تفاصيل المخطط الزمني لوقت استجابة EXECUTE/QUERY

عند تحليل الطوابع الزمنية لوقت استجابة EXECUTE أو QUERY، يمكن تقسيم إجمالي وقت الذهاب والعودة إلى التسلسل التالي:

بما أنّ هذا التقسيم يقارن بين الطوابع الزمنية من جانب Google ومن جانب الشريك، يجب مزامنة خوادم الشريك مع بروتوكول وقت الشبكة (NTP). حتى الانحراف البسيط في الساعة (من 50 إلى 100 ملي ثانية) سيؤدي إلى تشويه مُدد النقل المحسوبة (t2 - t1 وt4 - t3)، ما قد يؤدي إلى مقاييس مستحيلة منطقيًا مثل مُدد النقل السلبية.

[t1] تم إرسال الطلب (صادر من Google): تبدأ Google طلب النية. بما أنّ t1 لا يتم عرضه مباشرةً، يتم احتسابه تقريبًا من خلال طرح إجمالي وقت الاستجابة من الطابع الزمني النهائي للوارد.

نقل الشبكة (من t1 إلى t2): الوقت المقدَّر لنقل الشبكة والانتظار في قائمة الانتظار قبل الوصول إلى نقطة نهاية التنفيذ.

‫[t2] وقت تلقّي الطلب (Partner Ingress): الطابع الزمني الدقيق لوصول الطلب إلى بوابة واجهة برمجة التطبيقات أو خادم الدخول في بيئتك.

المعالجة من قِبل الشريك (من t2 إلى t3): يشير ذلك إلى وقت الاستجابة الداخلي للتنفيذ والتوجيه والتعامل مع الأجهزة بالكامل داخل بيئة السحابة الإلكترونية.

‫[t3] Response Sent (Partner Egress): الطابع الزمني الذي ترسِل فيه خدمتك ردّ التنفيذ إلى Google.

العبور في الاتجاه المعاكس (من t3 إلى t4): يشير إلى الوقت المستغرَق في توجيه الشبكة في الاتجاه المعاكس وإكمال الاتصال للعودة إلى Google.

[t4] اكتمال الطلب (وارد إلى Google): تتلقّى Google الردّ النهائي وتعالجه. يتم تسجيل هذا الطابع الزمني صراحةً في سجلات Google Cloud على أنه receiveTimestamp.

لتوضيح كيفية ارتباط هذه المقاييس ببعضها، لنفترض أنّ لدينا نموذج طلب EXECUTE بإجمالي وقت استجابة مسجَّل (latencyMsec) يبلغ 1700 ملي ثانية وGoogle Cloud receiveTimestamp (t4) يبلغ 2026-05-25T15:25:00.550Z.

خيارات تقليل وقت الاستجابة

اقتراحات بشأن البنية للتوجيه الجغرافي

إذا لم يكن تنفيذ عنوان IP لتقنية Anycast ممكنًا، ننصحك بالبدائل التالية الفعّالة من حيث التكلفة لضمان حصول المستخدمين على الخدمة من أقرب مركز بيانات إقليمي.

1. موازنة الحمل الشاملة (GLB)

   بدلاً من التوجيه الثابت، استخدِم جهاز موازنة حمل التطبيقات العالمي (متوفّر لدى معظم مقدّمي خدمات السحابة الإلكترونية الرئيسيين).

   • طريقة العمل: يمكنك ضبط نقطة دخول شاملة واحدة (عنوان URL) تقع على حافة الشبكة. يكتشف جهاز موازنة الحمل تلقائيًا المصدر الجغرافي للطلب من مجموعات التنفيذ في Google ويوجه عدد الزيارات إلى أقرب واجهة خلفية سليمة في منطقتك.

   • الميزة: يوفّر ذلك أداء تقنية anycast مع تقليل تعقيد الإعدادات والتكلفة بشكل كبير.

2. نظام أسماء النطاقات (DNS) الذي يراعي الموقع الجغرافي (GeoDNS)

   • طريقة العمل: يمكنك ضبط مزوّد نظام أسماء النطاقات لحلّ عنوان URL الخاص بالتنفيذ إلى عناوين IP مختلفة استنادًا إلى الموقع الجغرافي لطلب البحث لنظام أسماء النطاقات.

   • التنفيذ: تأكَّد من أنّ مزوّد نظام أسماء النطاقات محسَّن لنقاط الخروج من Google. عندما تحلّ خدمات التنفيذ الإقليمية من Google (على سبيل المثال، في الولايات المتحدة أو الاتحاد الأوروبي أو آسيا) نطاقك، ستتلقّى عنوان IP لمركز البيانات في تلك المنطقة المحدّدة.

استراتيجيات التحسين على مستوى طبقة التطبيقات

بالإضافة إلى التوجيه على مستوى البنية الأساسية، يمكنك تنفيذ الاستراتيجيات التالية على طبقة التطبيقات لتقليل وقت الاستجابة في معالجة الطلبات.

1. طريقة الخادم الوكيل "Trampoline"

   إذا كان عليك الاحتفاظ بمركز بيانات أساسي، استخدِم خوادم وكيل خفيفة إقليمية (Trampolines) للتعامل مع عملية الاتصال الأولية.

   1. يصل Google إلى عنوان URL العام.

   2. يتلقّى خادم وكيل إقليمي (على سبيل المثال، دالة Nginx أو Lambda خفيفة الوزن) الطلب.

   3. يعيد الوكيل توجيه الحمولة عبر شبكتك الأساسية الداخلية عالية السرعة إلى قاعدة البيانات الأساسية.

   الميزة: يقلّل ذلك من وقت "مصافحة بروتوكول التحكّم بالنقل"، والذي غالبًا ما يكون المساهم الأكبر في وقت الاستجابة للطلبات البعيدة المدى.

2. تلميحات حول منطقة رمز الدخول

   أثناء عملية ربط الحساب (OAuth)، يمكن لنظامك تحديد المنطقة التي يقيم فيها المستخدم.

   التنفيذ: يجب ترميز معرّف المنطقة في access_token الذي تم إصداره لـ Google. عندما ترسل Google طلب تنفيذ، يمكن لبوابتك فحص الرمز المميّز على الفور وتوجيه الطلب إلى المجموعة الإقليمية الصحيحة بدون الحاجة إلى البحث في قاعدة البيانات.

صحة النظام - مقاييس الشريك إلى Google

يساعد الحفاظ على معدّل نجاح أكبر من أو يساوي%99.5 في ضمان صحة حالات الأجهزة في Google Home، وإضافة الأجهزة وإزالتها، وتفعيل عمليات التشغيل الآلي، وظهور أحداث السجلّ في علامة التبويب "النشاط" في Google Home app (GHA).

يتم احتساب معدّل النجاح استنادًا إلى رموز استجابة HTTP التي تعرضها Google عندما يرسل جهازك المتصل بالسحابة الإلكترونية تحديثات الحالة. لضمان عدم معاقبة الشركاء على مشاكل البنية الأساسية من جانب Google، يستبعد المقياس أخطاء Google الداخلية من عدد حالات التعذّر. يمكن العثور على طلبات البيانات من واجهة برمجة التطبيقات المضمّنة في عملية الاحتساب في مرجع HomeGraph API.

ما الذي يحدد "النجاح"؟

‫2xx (نجاح): تم تلقّي تعديل الحالة ومعالجته بنجاح من خلال Home Graph.

ما الذي يحدّد "الفشل"؟

‫4xx (خطأ في الشريك) تمثّل حالات تعذُّر وتشير إلى مشكلة في الطلب المرسَل من السحابة الإلكترونية. تشمل الرموز الشائعة ما يلي:

‫400 طلب غير صالح

السبب: تعذّر على الخادم معالجة الطلب بسبب بنية غير صالحة. تشمل الأسباب الشائعة JSON غير صالح أو استخدام قيمة فارغة بدلاً من "" لقيمة سلسلة.

الحلّ: تأكَّد من أنّ نص الطلب هو ملف JSON صالح (لا يحتوي على بنية غير صحيحة أو قيم فارغة لحقول السلسلة)، وتأكَّد من أنّ agentUserId يتطابق مع القيمة من استجابة SYNC.

‫404 لم يتم العثور على الصفحة

السبب: لم يتم العثور على deviceId أو agentUserId في HomeGraph (لم تتم المزامنة بعد، أو تم إلغاء الربط، أو عدم تطابق المعرّف).

الحلّ:

1. تأكَّد من أنّ السمة agentUserId تتطابق مع القيمة المقدَّمة في استجابة SYNC.
2. استخدِم Home Graph SYNC API لتحديد ما إذا كان الخطأ "404 لم يتم العثور على الصفحة" ناتجًا عن عدم توفّر جهاز أو مستخدم في HomeGraph.
3. يجب تفعيل requestSync بعد إضافة جهاز أو حساب أو إزالته أو إعادة تسميته أو تعديله لضمان بقاء الحالة محدّثة.
4. يجب التعامل بشكل صحيح مع طلبات DISCONNECT لإيقاف إعداد التقارير عن الأجهزة القديمة. بعد تلقّي نية DISCONNECT، يجب أن تتوقف الخدمة السحابية عن نشر التغييرات على Google باستخدام طلب المزامنة والإبلاغ عن الحالة.

‫429 تم استنفاد المورد

السبب: تجاوزت عملية الدمج الحصة المخصّصة لها.

الحلّ: اطّلِع على التعليمات الواردة في قسم "الخطوة 2أ: تصحيح أخطاء المشاكل المتعلّقة بالحصة" في لوحة البيانات لإدارة الحصص. يمكنك أيضًا الرجوع إلى الحصص والحدود القصوى في المنزل المزوّد بأجهزة ذكية لمزيد من المعلومات.

سلامة الجهاز - دقة الحالة

يساعد تحقيق دقة الحالة >=%99.5 أو تجاوزها في ضمان ظهور نتائج صحيحة للمستخدمين عند الاطّلاع على حالات الأجهزة أو استخدام ميزات تستخدم الذكاء الاصطناعي، مثل "اسأل Google Home". إذا كانت دقة الحالة منخفضة، قد لا يتم تفعيل عمليات التشغيل الآلي وقد لا تظهر إدخالات السجلّ في علامة التبويب "النشاط" في "GHA" في الوقت المناسب. لمزيد من المعلومات، يُرجى الاطّلاع على Report State. ملاحظة: يجب تحقيق هدف دقة الحالة في جميع السمات المتوافقة.

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، تختلف مجموعة حقول الحمولة بين استجابة 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، لم يتم تلقّي أي حالة تقرير لهذا الجهاز (الحالة فارغة والطابع الزمني الذي تم الإبلاغ عنه هو في بداية العصر)، على الرغم من أنّ نتائج طلب البحث توفّر الحالة الحالية. يشير ذلك إلى أنّ تعديلات الحالة إما لا يتم تشغيلها أو لا تصل إلى HomeGraph أو أنّ الجهاز لا يبلّغ بنجاح عن عمليات الانتقال في إمكانية الاتصال أو حالة العمل.

الحلّ: تأكَّد من تفعيل Report State وإرسالها بنجاح لجميع تغييرات الحالة. يجب التأكّد من أنّ منطق الخلفية يعالج تعديلات الحالة بشكل صحيح، ويؤكّد نجاح التسليم إلى Google HomeGraph، ويضمن أنّ الجهاز يزامن حالته باستمرار للحفاظ على دقة واجهة المستخدم ومحرّك التشغيل الآلي.