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 की सफलता दर का हिसाब लगाते समय, Common platform error codes पर मिली गड़बड़ियों को "असफलता" माना जाता है. इन गड़बड़ियों को पार्टनर की कार्रवाई ज़रूरी है के तौर पर मार्क किया जाता है. इसके अलावा, Errors and exeptions पर मिली गड़बड़ियों को भी "असफलता" माना जाता है. हालांकि, इनमें ये अपवाद शामिल हैं:

असफलता के अपवाद
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) के इंतज़ार के समय को ट्रैक करता है. इससे आपके "सबसे धीमे" उपयोगकर्ताओं के अनुभव का पता चलता है. उदाहरण के लिए, 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 के क्लाउड और आपके क्लाउड के बीच "जवाब को स्वीकार करने" में लगने वाले समय का पता चलता है. इससे, फ़िज़िकल हार्डवेयर (उदाहरण के लिए, लाइट बल्ब) को अपनी स्थिति में बदलाव करने में लगने वाले समय का पता नहीं चलता. ऐसा इसलिए, क्योंकि इसमें अक्सर लोकल मेश नेटवर्क के इंतज़ार का समय शामिल होता है. यह समय, क्लाउड-टू-क्लाउड पाथ से बाहर होता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

पहला व्यू: कुल सटीक जानकारी (ग्लोबल औसत)

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

  • कैलकुलेशन: सभी डिवाइसों के लिए, स्टेटस की कुल सटीक जानकारी / सभी डिवाइसों के लिए, स्टेटस की कुल संख्या.

दूसरा व्यू: सबसे कम टाइप/ट्रेट का कॉम्बिनेशन

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

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