Google Home Vitals (Cloud)

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

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

1. Google to Partner Metrics - इससे Google से आपके क्लाउड बैकएंड तक होने वाले कॉल की परफ़ॉर्मेंस का पता चलता है.

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

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

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

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

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

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

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

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

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

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

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

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

Execution Response State Parity

EXECUTE रिस्पॉन्स में SUCCESS स्टेटस दिखाते समय, आपके रिस्पॉन्स पेलोड के states ऑब्जेक्ट में, उन सभी चालू और अपडेट किए गए स्टेटस फ़ील्ड की जानकारी ज़रूर होनी चाहिए जिन्हें आपने लागू किया है. ज़रूरी स्थिति वाले फ़ील्ड को शामिल न करने या जटिल ट्रेट के लिए खाली states ऑब्जेक्ट वापस लाने पर, Google Home Platform, प्रोग्राम चलाने के नतीजे को पार्स नहीं कर पाएगा. इसे AGENT_ISSUE या INVALID_RESPONSE के तौर पर रजिस्टर किया जाएगा. इससे क्वेरी और एक्ज़ीक्यूट होने की दर कम हो जाएगी.

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

लेटेंसी मेट्रिक

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

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

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

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

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

2. EXECUTE Latency (Action)

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

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

EXECUTE/QUERY के लिए इंतज़ार करने के समय की टाइमलाइन का ब्रेकडाउन

EXECUTE या QUERY के लिए टाइमस्टैंप का विश्लेषण करते समय, कुल राउंड-ट्रिप टाइम को इस क्रम में बांटा जा सकता है:

इस ब्रेकडाउन में, Google और पार्टनर के टाइमस्टैंप की तुलना की जाती है. इसलिए, पार्टनर के सर्वर को एनटीपी (नेटवर्क टाइम प्रोटोकॉल) के साथ सिंक किया जाना चाहिए. अगर क्लॉक में थोड़ा भी अंतर (50 से 100 मि॰से॰) होता है, तो ट्रांज़िट समय (t2 - t1 और t4 - t3) में गड़बड़ी हो सकती है. इससे ऐसी मेट्रिक मिल सकती हैं जो लॉजिक के हिसाब से सही नहीं हैं. जैसे, ट्रांज़िट में लगने वाला समय नेगेटिव में हो सकता है.

[t1] अनुरोध भेजा गया (Google आउटबाउंड): Google, इंटेंट का अनुरोध शुरू करता है. t1 सीधे तौर पर नहीं दिखता है. इसलिए, इसका हिसाब लगाने के लिए, फ़ाइनल इनबाउंड टाइमस्टैंप से कुल लेटेन्सी को घटाया जाता है.

नेटवर्क ट्रांज़िट (t1 से t2): फ़ुलफ़िलमेंट एंडपॉइंट तक पहुंचने से पहले, नेटवर्क ट्रांज़िट और कतार में लगने का अनुमानित समय.

[t2] अनुरोध मिला (पार्टनर इनग्रेस): यह वह सटीक टाइमस्टैंप होता है, जब अनुरोध आपके एनवायरमेंट के एपीआई गेटवे या इनग्रेस सर्वर पर पहुंचता है.

पार्टनर प्रोसेसिंग (t2 से t3): यह आपके क्लाउड एनवायरमेंट में, इंटरनल एक्ज़ीक्यूशन, रूटिंग, और डिवाइस हैंडलिंग में लगने वाला समय होता है.

[t3] जवाब भेजा गया (पार्टनर के सिस्टम से): यह वह टाइमस्टैंप होता है, जब आपकी सेवा, अनुरोध पूरा होने का जवाब वापस Google को भेजती है.

ट्रांज़िट से वापस आना (t3 से t4): इसमें, नेटवर्क की राउटिंग और कनेक्शन पूरा होने में लगने वाला समय शामिल होता है.

[t4] अनुरोध पूरा हुआ (Google इनबाउंड): Google को फ़ाइनल जवाब मिलता है और वह उसे प्रोसेस करता है. यह टाइमस्टैंप, आपके Google Cloud लॉग में receiveTimestamp के तौर पर रिकॉर्ड किया जाता है.

इन मेट्रिक के बीच संबंध दिखाने के लिए, EXECUTE अनुरोध का एक उदाहरण देखें. इसमें कुल लॉग की गई लेटेन्सी (latencyMsec) 1700 मि॰से॰ है और Google Cloud receiveTimestamp (t4) 2026-05-25T15:25:00.550Z है.

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

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

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

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

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

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

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

2. जियो-लोकेशन के हिसाब से डीएनएस (जियोडीएनएस)

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

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

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

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

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

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

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

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

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

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

2. ऐक्सेस टोकन के क्षेत्र से जुड़े सुझाव

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

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

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

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

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

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

2xx (Success): The state update was successfully received and processed by 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 संसाधन खत्म हो गया

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

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

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

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

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

यह मेट्रिक, "सैंपल" से मिलती है. इनमें Google, रिपोर्ट की गई स्थिति की पुष्टि, इंटेंट के जाने-पहचाने नतीजे के आधार पर कर सकता है. तकनीकी तौर पर सटीक होने के लिए, दो अलग-अलग तरीकों से जवाबों की जांच की जाती है:

• क्वेरी के आधार पर सटीक जानकारी: इसकी पुष्टि तब की जाती है, जब कोई उपयोगकर्ता या सिस्टम किसी डिवाइस की मौजूदा स्थिति के बारे में क्वेरी करता है.
• कमांड पूरी होने के बाद डिवाइस की स्थिति के आधार पर सटीक जवाब देने की क्षमता: इसकी पुष्टि, कंट्रोल करने के अनुरोध के बाद डिवाइस की स्थिति की जानकारी देने वाले पोस्ट-कमांड डिवाइस की स्थिति का आकलन करके की जाती है.

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

डैशबोर्ड, एक घंटे के इंटरवल के आधार पर, सटीक होने का स्कोर कैलकुलेट करता है. सांख्यिकीय भरोसे को पक्का करने और कम सिग्नल नॉइज़ पर इंटिग्रेशन को दंडित करने से बचने के लिए, Google ट्रैफ़िक वॉल्यूम की कम से कम सीमा लागू करता है. अगर किसी खास डिवाइस और एआई की सुविधा के कॉम्बिनेशन के लिए, पांच दिनों के रोलिंग विंडो में कुल 100 से कम सैंपल इकट्ठा होते हैं, तो इसकी सटीकता को सांख्यिकीय रूप से नगण्य माना जाता है. साथ ही, इसे लागू नहीं के तौर पर सेट किया जाता है.

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

हर घंटे के हिसाब से स्थिति की सटीक जानकारी = (क्वेरी की सटीक जानकारी % + एक्ज़ीक्यूशन की सटीक जानकारी %) / 2

यहां हर पाथवे को इस तरह से परिभाषित किया गया है:

• क्वेरी के सही होने का प्रतिशत = (हर घंटे की क्वेरी के सही सैंपल) / (हर घंटे की क्वेरी के कुल सैंपल)
• एक्ज़ीक्यूशन की सटीक दर % = (हर घंटे के हिसाब से सटीक एक्ज़ीक्यूशन वाले सैंपल) / (हर घंटे के हिसाब से कुल सैंपल)

ट्रेट एक्यूरेसी स्कोर (हर ट्रेट के लिए कैलकुलेट किया जाता है) = SUM(क्वेरी के सटीक सैंपल + एक्ज़ीक्यूशन के सटीक सैंपल) / SUM(क्वेरी के कुल सैंपल + एक्ज़ीक्यूशन के कुल सैंपल)

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

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

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

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

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

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 अनुरोध के पेलोड फ़ील्ड का सेट अलग-अलग होता है.

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

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

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

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

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

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