Google Home Vitals (Cloud)

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

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

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

2. सिस्टम की परफ़ॉर्मेंस - पार्टनर से Google की मेट्रिक - आपके सिस्टम से Google को किए जाने वाले कॉल की परफ़ॉर्मेंस को मेज़र करता है.

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

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

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

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

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

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

सिंक होने की दर >= 99.5% मेट्रिक से पता चलता है कि सिंक करने के अनुरोध कितनी बार सही तरीके से पूरे किए गए. इससे यह पक्का होता है कि Google Home में दिखाए गए डिवाइस, आपके क्लाउड इन्फ़्रास्ट्रक्चर से कनेक्ट किए गए डिवाइसों के साथ सिंक किए गए हैं.

"सफलता" का क्या मतलब है?

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

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

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

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

कार्रवाई के जवाब की स्थिति की समानता

EXECUTE रिस्पॉन्स में SUCCESS स्टेटस दिखाते समय, आपके रिस्पॉन्स पेलोड के states ऑब्जेक्ट में, चालू और अपडेट किए गए स्टेटस के वे सभी फ़ील्ड शामिल होने चाहिए जो लागू की जा रही विशेषताओं से तय होते हैं. ज़रूरी स्टेट फ़ील्ड को शामिल न करने या जटिल विशेषताओं के लिए खाली states ऑब्जेक्ट दिखाने पर, Google Home प्लैटफ़ॉर्म, एक्ज़ीक्यूशन के नतीजे को पार्स नहीं कर पाएगा. इसे 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 Outbound): 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 है.

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

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

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

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

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

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

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

2. जियो-लोकेशन अवेयर डीएनएस (जियोडीएनएस)

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

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

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

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

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

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

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

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

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

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

2. ऐक्सेस टोकन के लिए इलाके के संकेत

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

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

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

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

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

"सफलता" का क्या मतलब है?

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

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

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

400 खराब अनुरोध

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

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

पेज नहीं मिला

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

समाधान:

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

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

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

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

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

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

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

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

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

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

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

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

हर घंटे के हिसाब से राज्य की सटीक जानकारी = (क्वेरी की सटीक जानकारी % + लागू करने की सटीक जानकारी %) / 2

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

• क्वेरी के सटीक होने का प्रतिशत = (हर घंटे क्वेरी के सटीक सैंपल) / (हर घंटे क्वेरी के कुल सैंपल)
• Execution Accuracy % = (Hourly Execution Accurate Samples) / (Hourly Execution Total Samples)

Trait Accuracy Score (calculated per trait) = 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 और 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 गड़बड़ी के लिए, इस डिवाइस के लिए कोई रिपोर्ट स्टेट नहीं मिला है. हालांकि, QUERY के नतीजों से मौजूदा स्थिति की जानकारी मिलती है. रिपोर्ट स्टेट खाली है और रिपोर्ट किया गया टाइमस्टैंप, Epoch पर है. इससे पता चलता है कि स्थिति से जुड़े अपडेट ट्रिगर नहीं हो रहे हैं, HomeGraph तक नहीं पहुंच पा रहे हैं या डिवाइस, कनेक्टिविटी या काम करने की स्थिति में होने वाले बदलावों की जानकारी नहीं दे पा रहा है.

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