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

विफलता के अपवाद
aboveMaximumLightEffectsDuration armLevelNeeded inOffMode
alreadyArmed bagFull lockedToRange
alreadyAtMax belowMinimumLightEffectsDuration lowBattery
alreadyAtMin binFull maxSpeedReached
alreadyClosed cancelArmingRestricted minSpeedReached
alreadyDisarmed deadBattery notSupported
alreadyDocked degreesOutOfRange offline
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. क्वेरी के लिए इंतज़ार का समय (पूछताछ)

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

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

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

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

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

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

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

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

  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 ट्रिगर किया जाए. इससे यह पक्का किया जा सकेगा कि स्थिति अप-टू-डेट रहे.
  4. DISCONNECT इंटेंट को सही तरीके से मैनेज करें , ताकि पुराने डिवाइसों की रिपोर्टिंग बंद की जा सके. `DISCONNECT` इंटेंट मिलने के बाद, आपकी क्लाउड सेवा को, Request Sync और Report State की मदद से Google को बदलाव पब्लिश करना बंद कर देना चाहिए.DISCONNECT

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

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

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

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

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

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

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

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

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

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

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

हर घंटे की स्थिति की सटीक जानकारी = (क्वेरी की सटीक जानकारी का प्रतिशत + EXECUTE की सटीक जानकारी का प्रतिशत) / 2

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

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

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

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

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

3. डिवाइस की परफ़ॉर्मेंस और स्थिति की सटीक जानकारी को बेहतर बनाना

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

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

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

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

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

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

पीछे जाएं
जांच के नतीजे सबमिट करना
आगे बढ़ें
क्लाउड निगरानी के साथ मेट्रिक पर नज़र रखना