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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आगे बढ़ें
Cloud Monitoring