Google Home Vitals (Cloud)

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

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

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

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

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

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

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

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

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

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

"सफल" की परिभाषा क्या है?

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

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

"विफल" की परिभाषा क्या है?

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

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

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

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

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

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

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

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

2. कार्रवाई के लिए इंतज़ार का समय (कार्रवाई)

इससे, निर्देश को स्वीकार करने में लगने वाले समय का पता चलता है. यह समय तब लगता है, जब 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): Google को वापस आने में लगने वाला नेटवर्क राउटिंग और कनेक्शन पूरा होने का समय.

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

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

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

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

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

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

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

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

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

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)'s 'गतिविधि' टैब में दिखें.

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

"सफल" की परिभाषा क्या है?

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

"विफल" की परिभाषा क्या है?

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

400 खराब अनुरोध

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

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

पेज नहीं मिला

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

समाधान:

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

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

वजह: आपके इंटिग्रेशन ने, तय किए गए कोटे से ज़्यादा अनुरोध किए हैं.

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

डिवाइस की परफ़ॉर्मेंस - डिवाइस की स्थिति की सटीक जानकारी

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

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

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

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

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

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

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

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

यहां हर तरीके की परिभाषा दी गई है:

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

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

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

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