Google Home Vitals (Cloud)

डैशबोर्ड और सूचनाओं के इस सुइट की मदद से, Google Home के नेटवर्क के साथ बेहतर इंटिग्रेशन बनाए रखा जा सकता है. Google, सभी ग्राहकों के लिए अच्छी क्वालिटी वाला ईकोसिस्टम बनाने में पार्टनर की मदद करने के लिए प्रतिबद्ध है

डैशबोर्ड में तीन सेक्शन होते हैं. हर सेक्शन में एक अहम हिस्सा शामिल होता है, जो इंटिग्रेशन की क्वालिटी को बेहतर बनाने में मदद करता है.

  1. Google से पार्टनर मेट्रिक - इससे Google से आपके क्लाउड बैकएंड पर किए गए कॉल की परफ़ॉर्मेंस का पता चलता है.

  2. सिस्टम की परफ़ॉर्मेंस - Google की मेट्रिक के साथ पार्टनर की मेट्रिक की तुलना - इससे यह पता चलता है कि आपके सिस्टम से Google को किए गए कॉल की परफ़ॉर्मेंस कैसी है.

  3. डिवाइस की स्थिति - सटीक जानकारी - इससे Google के सिस्टम में सेव की गई स्थितियों की सटीक जानकारी का पता चलता है. इन स्थितियों का इस्तेमाल, उपयोगकर्ता की क्वेरी के जवाब देने के लिए किया जाता है.

जब मेट्रिक, टारगेट वैल्यू के मुताबिक नहीं होती हैं, तो उन्हें लाल रंग में हाइलाइट किया जाता है. इससे पता चलता है कि कोई ऐसी समस्या है जिससे उपयोगकर्ता अनुभव पर असर पड़ सकता है. यहां दी गई जानकारी में, हर टारगेट के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि यह आपके उपयोगकर्ताओं के लिए क्यों ज़रूरी है.

अगर नीचे दिए गए बटन पर क्लिक करने से, आपको सीधे डैशबोर्ड पर नहीं ले जाया जाता है, तो खास जानकारी पेज को चुनकर डैशबोर्ड पर जाएं. इसके बाद, डैशबोर्ड को चुनें. इसके बाद, मेरे डैशबोर्ड सूची में जाकर, Google Home Vitals डैशबोर्ड (क्लाउड) को चुनें. इससे आपको अपना डैशबोर्ड दिखेगा.

डैशबोर्ड पर जाएं

Google से पार्टनर को भेजी जाने वाली मेट्रिक

क्वेरी/कार्रवाई पूरी होने की दर >= 99.5% मेट्रिक से यह पता चलता है कि उपयोगकर्ताओं के निर्देशों को कितनी बार सही तरीके से पूरा किया गया. इससे Assistant के ऐसे जवाबों से बचने में मदद मिलती है जैसे कि "डिवाइस से कनेक्ट नहीं किया जा सका" या किसी ऐसे निर्देश की पुष्टि करना जिसे पूरा नहीं किया गया है.

"सफलता" किसे माना जाता है?

किसी लेन-देन को तब 'सफल' के तौर पर मार्क किया जाता है, जब Google Home प्लैटफ़ॉर्म को कोई मान्य जवाब मिलता है. इससे पता चलता है कि अनुरोध की गई कार्रवाई पूरी हो गई है या अनुरोध की गई स्थिति वापस मिल गई है.

जिन जवाबों में नॉन-ब्लॉकिंग अपवाद शामिल होते हैं (उदाहरण के लिए, lowBattery अपवाद के साथ SUCCESS स्टेटस), उन्हें सफल लेन-देन के तौर पर गिना जाता है. चेतावनी के बावजूद, डिवाइस को निर्देश मिल गया और इंटेंट पूरा हो गया.

"विफल" किसे माना जाता है?

प्लेटफ़ॉर्म के सामान्य गड़बड़ी कोड में मिली गड़बड़ियों को "विफलताओं" के तौर पर माना जाता है. इन गड़बड़ियों को पार्टनर के लिए कार्रवाई ज़रूरी है के तौर पर मार्क किया जाता है. ऐसा QUERY और EXECUTE के पूरा होने की दर का हिसाब लगाते समय किया जाता है. इसके अलावा, गड़बड़ियां और अपवाद टैब में मिली गड़बड़ियों को भी "फ़ेल" के तौर पर दिखाया जाता है. हालांकि, इनमें ये अपवाद शामिल हैं:

गड़बड़ी के अपवाद
aboveMaximumLightEffectsDuration armLevelNeeded inOffMode
alreadyArmed bagFull lockedToRange
alreadyAtMax belowMinimumLightEffectsDuration lowBattery
alreadyAtMin binFull maxSpeedReached
alreadyClosed cancelArmingRestricted minSpeedReached
alreadyDisarmed deadBattery notSupported
alreadyDocked degreesOutOfRange अॉफ़लाइन
alreadyInState deviceJammingDetected percentOutOfRange
alreadyLocked deviceNotMounted rangeTooClose
alreadyOff deviceNotReady relinkRequired
alreadyOn deviceOffline remoteSetDisabled
alreadyOpen deviceTurnedOff safetyShutOff
alreadyPaused discreteOnlyOpenClose targetAlreadyReached
alreadyStarted functionNotSupported tooManyFailedAttempts
alreadyStopped inAutoMode valueOutOfRange
alreadyUnlocked inEcoMode

क्वेरी/कार्रवाई पूरी होने में लगने वाला समय (p90) <= 1000 मि॰से॰ मेट्रिक से, अनुरोध की गई कार्रवाई के लिए इंतज़ार के समय का पता चलता है. इससे यह पक्का करने में मदद मिलती है कि उपयोगकर्ताओं को ज़्यादा इंतज़ार न करना पड़े. उदाहरण के लिए, लाइट बंद करने के लिए कुछ सेकंड इंतज़ार करना.

इंतज़ार के समय की मेट्रिक

लेटेंसी, इस बात का अहम इंडिकेटर है कि आपका इंटिग्रेशन, असली उपयोगकर्ता के लिए कितना रिस्पॉन्सिव है. डैशबोर्ड, 90वें पर्सेंटाइल (P90) की लेटेन्सी को ट्रैक करता है. यह "सबसे धीमे" उपयोगकर्ताओं के अनुभव को दिखाता है. उदाहरण के लिए, 800 मि॰से॰ का P90 का मतलब है कि 90% अनुरोधों को 800 मि॰से॰ या उससे कम समय में स्वीकार किया जाता है.

Google, तकनीकी तौर पर सटीक जानकारी देने के लिए, स्टेटस की जांच और डिवाइस के निर्देशों के लिए अलग-अलग तरीके से इंतज़ार का समय मापता है.

1. क्वेरी के लिए इंतज़ार करने का समय (सवाल पूछने वाला)

इससे यह पता चलता है कि Google के डिवाइस की मौजूदा स्थिति के बारे में पूछने पर, Cloud-to-cloud को जवाब देने में कितना समय लगता है.

  • शुरू करना: Google, आपके फ़ुलफ़िलमेंट यूआरएल पर action.devices.QUERY अनुरोध भेजता है.
  • मेज़रमेंट विंडो: यह वह समय होता है जब आपका क्लाउड, पूरा एचटीटीपी रिस्पॉन्स पाने, उसे प्रोसेस करने, और वापस Google को भेजने में लेता है.
  • आखिरी चरण: Google को आपकी सेवा से फ़ाइनल रिस्पॉन्स पेलोड मिलता है और वह इसकी पुष्टि करता है.

2. EXECUTE Latency (Action)

इससे यह पता चलता है कि Google किसी डिवाइस को कंट्रोल करने का अनुरोध भेजता है, तो उसे जवाब मिलने में कितना समय लगता है.

  • शुरू करना: Google, आपके फ़ुलफ़िलमेंट यूआरएल पर action.devices.EXECUTE अनुरोध भेजता है.
  • मेज़रमेंट विंडो: आपके क्लाउड को कमांड मिलने और पुष्टि करने वाला जवाब देने में लगने वाला समय.
  • आखिर में: Google को SUCCESS, PENDING या OFFLINE स्टेटस की प्रतिक्रिया मिलती है.
  • तकनीकी दायरा: यह मेट्रिक, Google के क्लाउड और आपके क्लाउड के बीच "रिस्पॉन्स की पुष्टि" करने में लगने वाले समय को मेज़र करती है. यह इस बात का पता नहीं लगाता कि फ़िज़िकल हार्डवेयर (उदाहरण के लिए, लाइटबल्ब) को अपनी स्थिति बदलने में कितना समय लगता है. ऐसा इसलिए, क्योंकि इसमें अक्सर क्लाउड-टू-क्लाउड पाथ के बाहर, लोकल मेश नेटवर्क की लेटेन्सी शामिल होती है.

इंतज़ार का समय कम करने के विकल्प

जियो-रूटिंग के लिए आर्किटेक्चर से जुड़े सुझाव

अगर एनीकास्ट आईपी लागू करना मुमकिन नहीं है, तो हमारा सुझाव है कि आप लागत कम करने वाले इन विकल्पों का इस्तेमाल करें. इससे यह पक्का किया जा सकेगा कि उपयोगकर्ताओं को उनके इलाके के सबसे नज़दीकी डेटा सेंटर से सेवा मिले.

  1. ग्लोबल लोड बैलेंसिंग (जीएलबी)

    स्टैटिक राउटिंग के बजाय, ग्लोबल ऐप्लिकेशन लोड बैलेंसर का इस्तेमाल करें. यह सुविधा, क्लाउड सेवाएं देने वाली ज़्यादातर बड़ी कंपनियों के पास उपलब्ध है.

    • यह कैसे काम करता है: आपको एक ग्लोबल एंट्री पॉइंट (यूआरएल) कॉन्फ़िगर करना होता है. यह नेटवर्क के किनारे पर होता है. लोड बैलेंसर, Google के फ़ुलफ़िलमेंट क्लस्टर से आने वाले अनुरोध की भौगोलिक जगह का अपने-आप पता लगाता है. साथ ही, ट्रैफ़िक को आपके इलाके के सबसे नज़दीकी और सही तरीके से काम कर रहे बैकएंड पर भेजता है.

    • फ़ायदा: इससे एनीकास्ट की परफ़ॉर्मेंस के बारे में पता चलता है. साथ ही, इसे कॉन्फ़िगर करने में कम समय लगता है और इसकी लागत भी कम होती है.

  2. भौगोलिक जगह की जानकारी के हिसाब से डीएनएस (जियोडीएनएस)

    • यह कैसे काम करता है: डीएनएस की सेवा देने वाली कंपनी को कॉन्फ़िगर करें, ताकि वह डीएनएस क्वेरी की भौगोलिक जगह के आधार पर, आपके फ़ुलफ़िलमेंट यूआरएल को अलग-अलग आईपी पतों पर ले जा सके.

    • लागू करना: पक्का करें कि आपका डीएनएस प्रोवाइडर, Google के इग्रेस पॉइंट के लिए ऑप्टिमाइज़ किया गया हो. जब Google की क्षेत्रीय फ़ुलफ़िलमेंट सेवाएं (उदाहरण के लिए, अमेरिका, ईयू या एशिया में) आपके डोमेन की समस्या हल करती हैं, तो उन्हें उस क्षेत्र के डेटा सेंटर का आईपी पता मिलेगा.

ऐप्लिकेशन लेयर पर ऑप्टिमाइज़ेशन की रणनीतियां

बुनियादी ढांचे के लेवल पर राउटिंग के अलावा, अनुरोध प्रोसेस करने में लगने वाले समय को कम करने के लिए, ऐप्लिकेशन लेयर पर ये रणनीतियां लागू की जा सकती हैं.

  1. "ट्रैम्पोलिन" प्रॉक्सी तरीका

    अगर आपको प्राइमरी डेटा सेंटर बनाए रखना है, तो शुरुआती हैंडशेक को मैनेज करने के लिए, हल्के-फुल्के रीजनल प्रॉक्सी सर्वर (ट्रैम्पोलिन) का इस्तेमाल करें.

    1. Google आपके ग्लोबल यूआरएल पर जाता है.

    2. क्षेत्रीय प्रॉक्सी (उदाहरण के लिए, लाइटवेट Nginx या Lambda फ़ंक्शन) को अनुरोध मिलता है.

    3. प्रॉक्सी, पेलोड को आपके इंटरनल, हाई-स्पीड बैकबोन के ज़रिए प्राइमरी डेटाबेस को भेजता है.

    फ़ायदा: इससे "टीसीपी हैंडशेक" का समय कम हो जाता है. अक्सर, लंबी दूरी के अनुरोधों के लिए, यह समय सबसे ज़्यादा होता है.

  2. ऐक्सेस टोकन के रीजनल हिंट

    खाता लिंक करने (OAuth) की प्रोसेस के दौरान, आपका सिस्टम उपयोगकर्ता के होम रीजन की पहचान कर सकता है.

    लागू करना: क्षेत्र के आइडेंटिफ़ायर को access_token issued to Google में कोड करें. जब Google, फ़ुलफ़िलमेंट का अनुरोध भेजता है, तो आपका गेटवे तुरंत टोकन की जांच कर सकता है. साथ ही, डेटाबेस में खोज किए बिना, अनुरोध को सही रीजनल क्लस्टर पर भेज सकता है.

सिस्टम की परफ़ॉर्मेंस - पार्टनर से Google को भेजी जाने वाली मेट्रिक

99.5%या इससे ज़्यादा सफलता दर बनाए रखने से यह पक्का करने में मदद मिलती है कि Google Home में डिवाइसों की स्थितियां सही हों, डिवाइस जोड़े और हटाए गए हों, ऑटोमेशन ट्रिगर हों, और इतिहास की गतिविधियां Google Home app (GHA) के गतिविधि टैब में दिखें.

सक्सेस रेट का हिसाब, Google से मिले एचटीटीपी रिस्पॉन्स कोड के आधार पर लगाया जाता है. ये कोड, क्लाउड की ओर से स्टेटस अपडेट पुश किए जाने पर मिलते हैं. यह पक्का करने के लिए कि Google के इंफ़्रास्ट्रक्चर से जुड़ी समस्याओं की वजह से पार्टनर पर जुर्माना न लगाया जाए, इस मेट्रिक में Google की आंतरिक गड़बड़ियों को बुकिंग पूरी न होने की संख्या से हटा दिया जाता है. जिन एपीआई कॉल को कैलकुलेशन में शामिल किया जाता है वे HomeGraph API के रेफ़रंस में दिए गए हैं.

"सफलता" किसे माना जाता है?

2xx (सफलता): Home Graph को स्थिति अपडेट करने का अनुरोध मिल गया है और उसे प्रोसेस कर लिया गया है.

"विफल" किसे माना जाता है?

4xx (पार्टनर की गड़बड़ी) से पता चलता है कि अनुरोध पूरा नहीं किया जा सका. इससे यह भी पता चलता है कि आपके क्लाउड से भेजे गए अनुरोध में कोई समस्या है. सामान्य कोड में ये शामिल हैं:

400 खराब अनुरोध

वजह: अमान्य सिंटैक्स की वजह से सर्वर, अनुरोध को प्रोसेस नहीं कर सका. इसकी सामान्य वजहों में, गलत तरीके से बनाया गया JSON या स्ट्रिंग वैल्यू के लिए "" के बजाय null का इस्तेमाल करना शामिल है.

समस्या हल करने का तरीका: पक्का करें कि अनुरोध का मुख्य हिस्सा मान्य JSON फ़ॉर्मैट में हो. इसमें कोई गलत स्ट्रक्चर या स्ट्रिंग फ़ील्ड के लिए शून्य वैल्यू न हो. साथ ही, पुष्टि करें कि agentUserId, सिंक करने के रिस्पॉन्स में मौजूद वैल्यू से मेल खाता हो.

पेज नहीं मिला

वजह: HomeGraph में deviceId या agentUserId नहीं मिला. ऐसा इसलिए हो सकता है, क्योंकि यह अब तक सिंक नहीं हुआ है, पहले ही अनलिंक किया जा चुका है या आईडी मेल नहीं खा रहा है.

समाधान:

  1. पक्का करें कि agentUserId, सिंक रिस्पॉन्स में दी गई वैल्यू से मेल खाता हो.
  2. Home Graph SYNC API का इस्तेमाल करके, यह पता लगाएं कि क्या 404 Not Found गड़बड़ी, HomeGraph में डिवाइस या उपयोगकर्ता के मौजूद न होने की वजह से हुई है.
  3. डिवाइस या खाते को जोड़ने, हटाने, उसका नाम बदलने या उसे अपडेट करने के बाद, requestSync को ट्रिगर करना न भूलें, ताकि स्थिति अपडेट रहे.
  4. DISCONNECT इंटेंट को सही तरीके से हैंडल करें, ताकि पुराने डिवाइसों की रिपोर्टिंग बंद की जा सके. DISCONNECT इंटेंट मिलने के बाद, आपकी क्लाउड सेवा को Request Sync और Report State की मदद से, Google पर बदलाव पब्लिश करना बंद कर देना चाहिए.

429 संसाधन खत्म हो गया

वजह: आपके इंटिग्रेशन ने तय किया गया कोटा पार कर लिया है.

हल: कोटा मैनेजमेंट के डैशबोर्ड में, "दूसरा चरण: कोटा से जुड़ी समस्याओं को डीबग करना" सेक्शन में दिए गए निर्देश देखें. ज़्यादा जानकारी के लिए, स्मार्ट होम के कोटा और सीमाएं भी देखी जा सकती हैं.

डिवाइस की स्थिति - की सटीक जानकारी

स्टेट की सटीक जानकारी >= 99.5% होने पर, यह पक्का किया जा सकता है कि डिवाइस की स्थिति देखने या 'Home से पूछें' जैसी एआई सुविधाओं का इस्तेमाल करने पर, लोगों को सही नतीजे दिखें. अगर राज्य की जानकारी सटीक नहीं है, तो हो सकता है कि ऑटोमेशन ट्रिगर न हों. साथ ही, इतिहास की एंट्री GHA के 'गतिविधि' टैब में सही समय पर न दिखें. ज़्यादा जानकारी के लिए, रिपोर्ट की स्थिति देखें.

क्वालिटी डैशबोर्ड, हर घंटे के हिसाब से इन मेट्रिक को ट्रैक करता है: कुल सटीकता और सबसे कम टाइप/ट्रेट कॉम्बो.

1. सटीकता से जुड़े कॉम्पोनेंट

यह मेट्रिक "सैंपल" से मिलती है. इनमें Google, रिपोर्ट की गई स्थिति की पुष्टि, खोज के मकसद के ज्ञात नतीजे के आधार पर कर सकता है.

2. डैशबोर्ड मेट्रिक (हर घंटे के हिसाब से कैलकुलेट की जाती है)

डैशबोर्ड, एक घंटे के इंटरवल के आधार पर एक्युरसी का हिसाब लगाता है. अगर किसी घंटे में कुल सैंपल की संख्या 100 से कम है (S_Total < 100), तो उस घंटे के लिए सटीकता को लागू नहीं के तौर पर सेट किया जाता है.

व्यू 1: कुल सटीकता (ग्लोबल औसत)

इससे, सभी डिवाइस टाइप और सुविधाओं के लिए, आपके इंटिग्रेशन की कुल सटीकता का पता चलता है. इससे आपको अपने पूरे नेटवर्क की परफ़ॉर्मेंस का वेटेड एवरेज मिलता है.

  • कैलकुलेशन: सभी डिवाइसों पर कुल राज्य की सटीक जानकारी / सभी डिवाइसों पर कुल राज्य की जानकारी.

दूसरा व्यू: सबसे कम टाइप/ट्रेट कॉम्बिनेशन

इससे आपके इंटिग्रेशन में सबसे कम भरोसेमंद कैटगरी की पहचान होती है. इससे ज़्यादा वॉल्यूम वाले ऐसे डिवाइसों को कम वॉल्यूम वाले ऐसे डिवाइसों को छिपाने से रोका जाता है जिनकी क्वालिटी खराब है. उदाहरण के लिए, अगर आपके पास 99.5% से ज़्यादा स्टेट ऐक्युरसी वाली लाइट का डेटा ज़्यादा है, लेकिन कम स्टेट ऐक्युरसी वाले स्विच का डेटा कम है, तो इससे पता चलता है कि स्विच के डेटा को बेहतर बनाने की ज़रूरत है. ऐसा हो सकता है कि औसत वैल्यू में यह जानकारी न दिखे.

  • कैलकुलेशन: सभी विशेषता / डिवाइस कॉम्बिनेशन के लिए, राज्य के हिसाब से सटीक जानकारी/राज्य के हिसाब से कुल जानकारी का कम से कम अनुपात.

3. डिवाइस की स्थिति और सटीक जानकारी को बेहतर बनाना

डेटा में अंतर तब दिखता है, जब Home Graph में सेव किया गया स्टेटस, रीयल टाइम में की गई क्वेरी के नतीजों से मेल नहीं खाता.

"फ़ील्ड मौजूद नहीं है" गड़बड़ियां

DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD का उदाहरण

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"
  }

DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD का उदाहरण

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 में शामिल किया जाता है, तो उसके फ़ील्ड मौजूद होने चाहिए. साथ ही, वे प्रॉऐक्टिव रिपोर्ट और रीऐक्टिव क्वेरी, दोनों में एक जैसे होने चाहिए.

"गलत जानकारी" वाली गड़बड़ियां

DETAILED_ACCURACY_RESULT_INACCURATE का उदाहरण

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 की आखिरी वैल्यू में अंतर है.

समाधान: पक्का करें कि डिवाइस की स्थिति में बदलाव होने पर, रिपोर्ट की स्थिति ट्रिगर हो. साथ ही, रिपोर्ट की स्थिति और क्वेरी, दोनों से हमेशा एक जैसी और अप-टू-डेट वैल्यू मिलती हों. यह भी पक्का करें कि डेटा में एकरूपता बनाए रखने के लिए, सभी ज़रूरी फ़ील्ड मौजूद हों.

DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE का उदाहरण

"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 को डिवाइस की नई स्थिति की जानकारी मिल सके.

DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED का उदाहरण

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 गड़बड़ी के लिए, इस डिवाइस के लिए कोई ReportState नहीं मिला है. स्थिति खाली है और रिपोर्ट किया गया टाइमस्टैंप, इपोक पर है. ऐसा तब हुआ है, जब QUERY के नतीजों में मौजूदा स्थिति की जानकारी दी गई है. इससे पता चलता है कि डिवाइस की स्थिति के अपडेट ट्रिगर नहीं हो रहे हैं या HomeGraph तक नहीं पहुंच पा रहे हैं. इसके अलावा, यह भी हो सकता है कि डिवाइस, कनेक्टिविटी या काम करने की स्थिति में बदलावों की जानकारी सही तरीके से नहीं दे रहा है.

समाधान: पक्का करें कि Report State ट्रिगर हो और सभी बदलावों के लिए, इसे सफलतापूर्वक भेजा गया हो. पुष्टि करें कि बैकएंड लॉजिक, स्टेटस अपडेट को सही तरीके से हैंडल करता हो. साथ ही, Google HomeGraph को डिलीवरी की पुष्टि करता हो. इसके अलावा, यह भी पक्का करता हो कि डिवाइस, अपनी स्थिति को लगातार सिंक करता हो, ताकि उपयोगकर्ता इंटरफ़ेस और ऑटोमेशन इंजन सटीक जानकारी दे सकें.

आगे बढ़ें
Cloud Monitoring