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

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

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

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

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

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

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

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

الانتقال إلى لوحة التحكم

مقاييس من Google إلى الشريك

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

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

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

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

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

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

تطابق حالة استجابة التنفيذ

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

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

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

يُعدّ وقت الاستجابة مؤشرًا مهمًا على مدى استجابة عملية التكامل للمستخدم النهائي. تتتبّع لوحة البيانات وقت الاستجابة في المئويّة التسعين (P90)، ما يمثّل تجربة المستخدمين "الأبطأ" (على سبيل المثال، يعني 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، يمكن تقسيم إجمالي وقت الرحلة الكاملة إلى التدفق التسلسلي التالي:

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

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

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

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

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

[t3] تم إرسال الاستجابة (صادرة من الشريك): الطابع الزمني الذي ترسل فيه خدمتك استجابة تنفيذ الطلب مرة أخرى إلى 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. نظام أسماء النطاقات الذي يراعي الموقع الجغرافي (GeoDNS)

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

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

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

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

1. طريقة الخادم الوكيل "الترامبولين"

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

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

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

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

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

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 في الوقت المناسب. لمزيد من المعلومات، يُرجى الاطّلاع على الإبلاغ عن الحالة. يُرجى العِلم: يجب استيفاء الهدف "دقة الحالة" في جميع السمات المتوافقة.

1. مكوّنات الدقة

يتم اشتقاق المقياس من "العينات" التي يمكن أن تتحقّق Google من الحالة المُبلَغ عنها مقابل نتيجة غرض معروفة. لضمان مقياس صحة النموذج الفنية، يتم تقييم الدقة على مسارين مختلفَين:

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

2. مقاييس لوحة البيانات (الاحتساب كل ساعة)

تحتسب لوحة البيانات الدقة استنادًا إلى فترة زمنية مدتها ساعة واحدة. لضمان الثقة الإحصائية وتجنُّب معاقبة عمليات التكامل على التشويش المنخفض الإشارة، تفرض Google حدًا أدنى لحجم حركة البيانات. إذا جمعت سمة وجهاز معيّنان أقل من 100 عينة إجمالية خلال فترة 5 أيام متواصلة، تُعتبر دقتها غير مهمة إحصائيًا ويتم ضبطها على غير متوفّر.

عندما يكون هناك حجم كافٍ من العينات خلال ساعة واحدة على كلا المسارين، يتم احتساب الدقة الأساسية لكل ساعة لحالة معيّنة على أنّها متوسط النسبتَين المستقلتَين:

دقة الحالة لكل ساعة = (دقة طلب البحث % + دقة التنفيذ %) / 2

إليك تعريف كل مسار:

• دقة طلب البحث % = (العينات الدقيقة لطلب البحث لكل ساعة) / (إجمالي العينات لطلب البحث لكل ساعة)
• دقة التنفيذ % = (العينات الدقيقة للتنفيذ لكل ساعة) / (إجمالي العينات للتنفيذ لكل ساعة)

نتيجة دقة السمة (يتم احتسابها لكل سمة) = مجموع(العينات الدقيقة لطلب البحث + العينات الدقيقة للتنفيذ) / مجموع(إجمالي العينات لطلب البحث + إجمالي العينات للتنفيذ)

بما أنّ "مقياس الجودة" يقيّم الحد الأدنى الصارم للأداء في نظامك المتكامل، يجب أن تستوفي كل سمة متوافقة ومؤهّلة بشكل فردي الهدف "دقة الحالة" ≥% 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` وطلب "الإبلاغ عن الحالة" للجهاز نفسه.

الحلّ: تأكَّد من أنّ بنية البيانات متطابقة في كلا المسارين. إذا تم تضمين سمة في 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` والقيمة الأخيرة لطلب "الإبلاغ عن الحالة".

الحلّ: تأكَّد من تفعيل "الإبلاغ عن الحالة" كلما تغيّرت حالة الجهاز، وأنّ كلاً من "الإبلاغ عن الحالة" و`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، ويضمن مزامنة الجهاز لحالته باستمرار للحفاظ على دقة واجهة المستخدم ومحرّك التشغيل الآلي.