Google Home Vitals (Cloud)

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

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

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

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

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

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

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

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

Google से पार्टनर के लिए मेट्रिक

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)'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 संसाधन खत्म हो गया

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

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

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

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

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

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

• QUERY के आधार पर सटीक जानकारी: इसकी पुष्टि तब की जाती है, जब कोई उपयोगकर्ता या सिस्टम, किसी डिवाइस के मौजूदा स्टेटस के बारे में पूछता है.
• 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 को डिलीवरी की पुष्टि करे, और यह पक्का करे कि डिवाइस, अपने स्टेटस को लगातार सिंक करे, ताकि उपयोगकर्ता इंटरफ़ेस और ऑटोमेशन इंजन सटीक जानकारी दें.