Google Home Vitals (ক্লাউড)

ড্যাশবোর্ড ও অ্যালার্টের এই স্যুট আপনাকে Google Home ইকোসিস্টেমের সাথে উচ্চ-কোয়ালিটির ইন্টিগ্রেশন বজায় রাখতে সাহায্য করে। Google সব গ্রাহকদের জন্য উচ্চ কোয়ালিটির ইকোসিস্টেম ডেভেলপ করার ব্যাপারে পার্টনারদের সহায়তা করতে প্রতিশ্রুতিবদ্ধ।

ড্যাশবোর্ডে তিনটি বিভাগ আছে, প্রতিটি বিভাগই সামগ্রিক ইন্টিগ্রেশনের কোয়ালিটি উন্নত করার জন্য গুরুত্বপূর্ণ ভূমিকা পালন করে।

1. Google থেকে পার্টনার মেট্রিক - Google থেকে আপনার ক্লাউড ব্যাকএন্ডে করা কলের হেলথ পরিমাপ করে।

2. সিস্টেমের স্বাস্থ্য - Google-এর সাথে পার্টনারের মেট্রিক - আপনার সিস্টেম থেকে Google-এ করা কলের স্বাস্থ্য পরিমাপ করে।

3. ডিভাইসের স্বাস্থ্য - স্টেট অ্যাকুরেসি - Google সিস্টেমে সেভ করা স্টেটের নির্ভুলতা পরিমাপ করে, যা ব্যবহারকারীর কোয়েরির উত্তর দেওয়ার জন্য ব্যবহার করা হয়।

মেট্রিক টার্গেট ভ্যালু পূরণ করতে না পারলে, ব্যবহারকারীর অভিজ্ঞতার উপর প্রভাব ফেলতে পারে এমন কোনও সমস্যাকে বোঝাতে, সেগুলি লাল রঙে হাইলাইট করা হয়। নিচে দেওয়া তথ্য থেকে প্রতিটি টার্গেট সম্পর্কে বিস্তারিত জানতে পারবেন এবং আপনার ব্যবহারকারীদের জন্য এটি কেন গুরুত্বপূর্ণ তাও জানতে পারবেন।

'ফলো করুন' বোতামটি আপনাকে সরাসরি ড্যাশবোর্ডে নিয়ে না গেলে, ওভারভিউ পৃষ্ঠা বেছে নিয়ে, ড্যাশবোর্ড বেছে নিয়ে এবং তারপরে আমার ড্যাশবোর্ড তালিকা থেকে Google Home Vitals Dashboard (Cloud) বেছে নিয়ে আপনার ড্যাশবোর্ড দেখতে পারবেন।

ড্যাশবোর্ডে যান

Google থেকে পার্টনারের মেট্রিক্স

কোয়েরি/এক্সিকিউট সাকসেস রেট >= ৯৯.৫% মেট্রিক থেকে বোঝা যায় যে ব্যবহারকারীর কমান্ড কত ঘন ঘন সঠিকভাবে পূরণ করা হয়। এটি Assistant-এর দেওয়া এমন উত্তর এড়াতে সাহায্য করে, যেমন "আমি ডিভাইসে পৌঁছাতে পারছি না" অথবা এখনও পূরণ করা হয়নি এমন কোনও কমান্ডকে ভুলভাবে কনফার্ম করা।

সিন্ক হওয়ার সাফল্যের হার >= ৯৯.৫% মেট্রিক পরিমাপ করে যে কত ঘনঘন সিন্ক করার অনুরোধ সঠিকভাবে পূর্ণ করা হয়, যা নিশ্চিত করে যে Google Home-এ দেখানো ডিভাইসগুলি আপনার ক্লাউড ইনফ্রাস্ট্রাকচারের সাথে কানেক্ট করা ডিভাইসের সাথে সিন্ক করা আছে।

"সাফল্য" বলতে কী বোঝায়?

Google Home প্ল্যাটফর্ম যদি কোনও সঠিক উত্তর পায়, যা থেকে বোঝা যায় যে উদ্দেশ্যপূরণ হয়েছে অথবা অনুরোধ করা স্টেট পাওয়া গেছে, তাহলে ট্রানজ্যাকশনটি সফল হয়েছে বলে চিহ্নিত করা হয়।

যেসব উত্তরে নন-ব্লকিং ব্যতিক্রম (যেমন, SUCCESS স্ট্যাটাস এর সাথে lowBattery ব্যতিক্রম) থাকে, সেগুলি সফল ট্রানজ্যাকশন হিসেবে গণ্য করা হয়। সতর্কতা মেসেজ দেখানো সত্ত্বেও কমান্ডটি ডিভাইসে পৌঁছেছে এবং উদ্দেশ্য পূরণ হয়েছে।

কীসের ভিত্তিতে "ব্যর্থ" হিসেবে বিবেচনা করা হয়?

পার্টনার অ্যাকশনেবল হিসেবে চিহ্নিত করা সাধারণ প্ল্যাটফর্মের সমস্যার কোড QUERY, EXECUTE ও SYNC সাকসেস রেট গণনা করার সময় "সমস্যা" হিসেবে বিবেচিত হয়। এছাড়াও, সমস্যা ও ব্যতিক্রম এ পাওয়া সমস্যাগুলিও "ব্যর্থতা", তবে নিম্নলিখিত ব্যতিক্রমগুলি রয়েছে:

এক্সিকিউশন রেসপন্স স্টেট প্যারিটি

EXECUTE উত্তরের মধ্যে SUCCESS স্ট্যাটাস রিটার্ন করার সময়, আপনার উত্তর পেলোডের states অবজেক্টে আপনার এক্সিকিউট করা ট্রেট দ্বারা ডিফাইন করা সব অ্যাক্টিভ ও আপডেট করা স্টেট ফিল্ড অবশ্যই থাকতে হবে। প্রয়োজনীয় স্টেট ফিল্ড বাদ দিলে অথবা জটিল ট্রেটের জন্য খালি states অবজেক্ট রিটার্ন করলে, Google Home প্ল্যাটফর্ম এক্সিকিউশন ফলাফল পার্স করতে পারবে না, এটিকে AGENT_ISSUE বা INVALID_RESPONSE ব্যর্থতা হিসেবে রেজিস্টার করবে, যার ফলে আপনার কোয়েরি ও এক্সিকিউট সফলতার হার কমে যাবে।

কোয়েরি/এক্সিকিউট ল্যাটেন্সি (p90) <= ১০০০ms মেট্রিক অনুরোধ করা অ্যাকশনের অপেক্ষা করার সময় পরিমাপ করে এবং ব্যবহারকারীদের যাতে বেশি অপেক্ষা করতে না হয় তা নিশ্চিত করতে সাহায্য করে। যেমন, তাদের লাইট বন্ধ হওয়ার জন্য কয়েক সেকেন্ড অপেক্ষা করা।

লেটেন্সি মেট্রিক

লেটেন্সি হল একটি গুরুত্বপূর্ণ সূচক যা থেকে বোঝা যায় যে আপনার ইন্টিগ্রেশন এন্ড-ইউজারের কাছে কতটা রেসপন্সিভ মনে হচ্ছে। ড্যাশবোর্ড ৯০তম পার্সেন্টাইল (P90) লেটেন্সি ট্র্যাক করে, যা আপনার "সবচেয়ে ধীরগতির" ব্যবহারকারীদের অভিজ্ঞতাকে উপস্থাপন করে (যেমন, ৮০০ms-এর P90 এর অর্থ হল ৯০% অনুরোধ ৮০০ms বা তার কম সময়ে স্বীকার করা হয়)।

টেকনিক্যাল নির্ভুলতা নিশ্চিত করতে, Google স্ট্যাটাস চেক ও ডিভাইস কমান্ডের জন্য আলাদাভাবে লেটেন্সি পরিমাপ করে।

১. QUERY লেটেন্সি (প্রশ্নবোধক)

ডিভাইসের বর্তমান অবস্থা সম্পর্কে Google জিজ্ঞাসা করলে, এটি Cloud-to-cloud রাউন্ড ট্রিপ টাইম পরিমাপ করে।

• শুরু: Google আপনার ফুলফিলমেন্ট URL-এ একটি action.devices.QUERY অনুরোধ পাঠায়।
• মাপার উইন্ডো: আপনার ক্লাউডকে সম্পূর্ণ HTTP রেসপন্স পেতে, প্রসেস করতে এবং Google-এ ফেরত পাঠাতে যত সময় লাগে।
• শেষ: Google আপনার পরিষেবা থেকে চূড়ান্ত উত্তর পেল এবং তা স্বীকার করল।

২. EXECUTE লেটেন্সি (অ্যাকশন)

Google কোনও ডিভাইসে কন্ট্রোল অনুরোধ পাঠালে, এটি কমান্ড অ্যাকনলেজমেন্টের সময় পরিমাপ করে।

• শুরু: Google আপনার ফুলফিলমেন্ট URL-এ একটি action.devices.EXECUTE অনুরোধ পাঠায়।
• মাপার উইন্ডো: আপনার ক্লাউড কমান্ড গ্রহণ করতে এবং স্বীকৃতিমূলক উত্তর রিটার্ন করতে যে সময় লাগে।
• শেষ: Google SUCCESS, PENDING বা OFFLINE স্ট্যাটাস উত্তর পায়।
• টেকনিক্যাল স্কোপ: এই মেট্রিক Google-এর ক্লাউড ও আপনার ক্লাউডের মধ্যে "উত্তর প্রাপ্তি" সংক্রান্ত সময় পরিমাপ করে। এটি ফিজিক্যাল হার্ডওয়্যারের (যেমন, একটি লাইটবাল্ব) ফিজিক্যাল স্টেট পরিবর্তন সম্পূর্ণ করতে কত সময় লাগে তা পরিমাপ করে না, কারণ এতে প্রায়ই ক্লাউড-টু-ক্লাউড পাথ এর বাইরে লোকাল মেশ নেটওয়ার্ক লেটেন্সি অন্তর্ভুক্ত থাকে।

EXECUTE/QUERY লেটেন্সি টাইমলাইন ব্রেকডাউন

EXECUTE বা QUERY লেটেন্সির জন্য টাইমস্ট্যাম্প বিশ্লেষণ করার সময়, মোট রাউন্ড-ট্রিপ টাইমকে নিম্নলিখিত ক্রমিক ফ্লোতে ভাগ করা যেতে পারে:

এই ব্রেকডাউন যেহেতু Google ও পার্টনারের দিক থেকে পাওয়া টাইমস্ট্যাম্পের তুলনা করে, পার্টনার সার্ভারকে অবশ্যই NTP (নেটওয়ার্ক টাইম প্রোটোকল)-এর সাথে সিঙ্ক্রোনাইজ করতে হবে। এমনকি সামান্য ক্লক ড্রিফ্ট (৫০-১০০ms) হলেও, তা গণনা করা ট্রানজিট টাইমকে (t2 - t1 ও t4 - t3) বিকৃত করে দেবে, যার ফলে নেগেটিভ ট্রানজিট লেটেন্সির মতো যুক্তিযুক্তভাবে অসম্ভব মেট্রিক তৈরি হতে পারে।

[t1] অনুরোধ পাঠানো হয়েছে (Google আউটবাউন্ড): Google ইনটেন্ট অনুরোধ শুরু করে। t1 সরাসরি এক্সপোজ করা হয় না বলে, ফাইনাল ইনবাউন্ড টাইমস্ট্যাম্প থেকে মোট লেটেন্সি বাদ দিয়ে এটি আনুমানিক গণনা করা হয়।

নেটওয়ার্ক ট্রানজিট (t1 থেকে t2): আপনার ফুলফিলমেন্ট এন্ডপয়েন্টে পৌঁছানোর আগে আনুমানিক নেটওয়ার্ক ট্রানজিট ও কিউ টাইম।

[t2] অনুরোধ পাওয়া গেছে (পার্টনার ইনগ্রেস): ঠিক সেই টাইমস্ট্যাম্প যখন অনুরোধটি আপনার এনভায়রনমেন্টের API গেটওয়ে বা ইনগ্রেস সার্ভারে পৌঁছেছে।

পার্টনার প্রসেসিং (t2 থেকে t3): ইন্টার্নাল এক্সিকিউশন, রাউটিং, এবং ডিভাইস ম্যানেজ করার লেটেন্সি সম্পূর্ণভাবে আপনার ক্লাউড এনভায়রনমেন্টের মধ্যে।

[t3] উত্তর পাঠানো হয়েছে (পার্টনার এগ্রেস): আপনার পরিষেবা Google-এ উত্তর পাঠানোর সময়কার টাইমস্ট্যাম্প।

ফেরার ট্রানজিট (t3 থেকে t4): ফেরার নেটওয়ার্ক রাউটিং ও কানেকশন Google-এ ফিরে আসার সময় সম্পূর্ণ করা।

[t4] অনুরোধ চূড়ান্ত করা হয়েছে (Google ইনবাউন্ড): Google চূড়ান্ত উত্তর পায় এবং সেটি প্রসেস করে। এই টাইমস্ট্যাম্প আপনার Google Cloud লগে receiveTimestamp হিসেবে স্পষ্টভাবে রেকর্ড করা হয়।

এইসব মেট্রিক কীভাবে একসাথে কাজ করে তা বোঝাতে, মোট লগ করা লেটেন্সি (latencyMsec) ১৭০০ মিলিসেকেন্ড সহ একটি নমুনা EXECUTE অনুরোধ এবং Google Cloud receiveTimestamp (t4) 2026-05-25T15:25:00.550Z বিবেচনা করুন।

লেটেন্সি কমানোর বিকল্প

জিও-রাউটিংয়ের জন্য স্থাপত্য সংক্রান্ত সাজেশন

Anycast IP প্রয়োগ করা সম্ভব না হলে, ব্যবহারকারীদের যেন সবচেয়ে কাছের আঞ্চলিক ডেটা সেন্টার পরিষেবা প্রদান করতে পারে তা নিশ্চিত করতে, আমরা নিম্নলিখিত কম খরচে বিকল্প সাজেস্ট করি।

1. গ্লোবাল লোড ব্যালেন্সিং (GLB)

   স্ট্যাটিক রাউটিংয়ের পরিবর্তে, গ্লোবাল অ্যাপ্লিকেশন লোড ব্যালেন্সার (বেশিরভাগ প্রধান ক্লাউড পরিষেবা প্রদানকারীর থেকে উপলভ্য) ব্যবহার করুন।

   • এটি কীভাবে কাজ করে: আপনি একটি গ্লোবাল এন্ট্রি পয়েন্ট (URL) কনফিগার করেন যা নেটওয়ার্কের প্রান্তে থাকে। লোড ব্যালেন্সার অটোমেটিক Google-এর ফুলফিলমেন্ট ক্লাস্টার থেকে অনুরোধের ভৌগোলিক উৎস শনাক্ত করে এবং আপনার সবচেয়ে কাছের আঞ্চলিক সুস্থ ব্যাকএন্ডে ট্রাফিক রাউট করে।

   • সুবিধা: এটি অনেক কম কনফিগারেশন জটিলতা ও খরচে Anycast-এর পারফর্ম্যান্স প্রদান করে।

2. ভৌগোলিক অবস্থান সচেতন ডিএনএস (GeoDNS)

   • এটি কীভাবে কাজ করে: DNS কোয়েরির ভৌগোলিক লোকেশনের উপর ভিত্তি করে আপনার ফুলফিলমেন্ট URL-কে আলাদা আলাদা IP অ্যাড্রেসে রেজোল্ভ করতে আপনার DNS প্রোভাইডারকে কনফিগার করুন।

   • প্রয়োগ: আপনার DNS পরিষেবা প্রদানকারী Google-এর এগ্রেস পয়েন্টের জন্য অপ্টিমাইজ করা আছে কিনা তা নিশ্চিত করুন। Google-এর আঞ্চলিক ফুলফিলমেন্ট পরিষেবা (যেমন, মার্কিন যুক্তরাষ্ট্র, ইউরোপীয় ইউনিয়ন বা এশিয়া) আপনার ডোমেন সংক্রান্ত সমস্যার সমাধান করলে, তারা সেই নির্দিষ্ট অঞ্চলের ডেটা সেন্টারের IP অ্যাড্রেস পাবে।

অ্যাপ্লিকেশন লেভেলে অপ্টিমাইজেশন স্ট্র্যাটেজি

ইনফ্রাস্ট্রাকচার-লেভেল রাউটিংয়ের বাইরে, অনুরোধ প্রসেস করার ক্ষেত্রে লেটেন্সি কমাতে, আপনি অ্যাপ্লিকেশন লেভেলে নিম্নলিখিত কৌশল প্রয়োগ করতে পারেন।

1. "ট্র্যাম্পোলিন" প্রক্সি পদ্ধতি

   আপনাকে যদি প্রাইমারি ডেটা সেন্টার বজায় রাখতেই হয়, তাহলে প্রাথমিক হ্যান্ডশেক ম্যানেজ করার জন্য আঞ্চলিক লাইটওয়েট প্রক্সি সার্ভার (ট্র্যাম্পোলিন) ব্যবহার করুন।

   1. Google আপনার গ্লোবাল URL-এ হিট করে।

   2. একটি আঞ্চলিক প্রক্সি (যেমন, একটি হালকা Nginx বা ল্যাম্বডা ফাংশন) অনুরোধটি পায়।

   3. প্রক্সি আপনার ইন্টার্নাল, হাই-স্পিড ব্যাকবোনের মাধ্যমে প্রাইমারি ডেটাবেসে পেলোড ফরওয়ার্ড করে।

   সুবিধা: এটি "TCP হ্যান্ডশেক" সময় কমায়, যা প্রায়ই দূরত্বের অনুরোধের ক্ষেত্রে লেটেন্সির সবচেয়ে বড় কারণ।

2. অ্যাক্সেস টোকেন অঞ্চল সংক্রান্ত ইঙ্গিত

   অ্যাকাউন্ট লিঙ্ক করার (OAuth) প্রসেস চলাকালীন, আপনার সিস্টেম ব্যবহারকারীর হোম অঞ্চল শনাক্ত করতে পারে।

   প্রয়োগ: access_token Google-কে ইস্যু করা হয়েছে এমন কোনও অঞ্চলে শনাক্তকারী এনকোড করুন। Google কোনও ফিলফিলমেন্ট অনুরোধ পাঠালে, আপনার গেটওয়ে তৎক্ষণাৎ টোকেনটি পরীক্ষা করে দেখতে এবং ডেটাবেস লুক-আপের প্রয়োজন ছাড়াই সঠিক আঞ্চলিক ক্লাস্টারে অনুরোধটি রুট করতে পারে।

সিস্টেমের স্বাস্থ্য - পার্টনার থেকে Google মেট্রিক

সফলতার হার >= ৯৯.৫% বজায় রাখলে, Google Home-এ ডিভাইসের স্ট্যাটাস সঠিক আছে কিনা, ডিভাইস যোগ করা ও সরানো হয়েছে কিনা, অটোমেশন ট্রিগার হয়েছে কিনা এবং Google Home app (GHA)-এর অ্যাক্টিভিটি ট্যাবে ইতিহাস ইভেন্ট দেখা যাচ্ছে কিনা তা নিশ্চিত করতে সাহায্য করে।

আপনার ক্লাউড যখন স্টেট আপডেট পুশ করে তখন Google-এর দেওয়া HTTP রেসপন্স কোডের উপর ভিত্তি করে সাফল্যের হার গণনা করা হয়। Google-এর পরিকাঠামো সংক্রান্ত সমস্যার জন্য পার্টনারদের যাতে কোনও শাস্তি না পেতে হয় তা নিশ্চিত করতে, এই মেট্রিক ব্যর্থতার সংখ্যা থেকে Google-এর অভ্যন্তরীণ সমস্যা বাদ দেয়। গণনায় অন্তর্ভুক্ত API কলগুলি HomeGraph API রেফারেন্সে পাওয়া যায়।

"সাফল্য" বলতে কী বোঝায়?

2xx (সফল): Home Graph-এর মাধ্যমে স্টেট আপডেট সফলভাবে গ্রহণ ও প্রসেস করা হয়েছে।

কীসের ভিত্তিতে "ব্যর্থ" হিসেবে বিবেচনা করা হয়?

4xx (পার্টনার সংক্রান্ত সমস্যা) ব্যর্থতা বোঝায় এবং আপনার ক্লাউড থেকে পাঠানো অনুরোধে কোনও সমস্যা হয়েছে বলে ইঙ্গিত করে। সাধারণ কোডের মধ্যে এগুলি পড়ে:

400 ত্রুটিপূর্ণ অনুরোধ

কারণ: ভুল সিনট্যাক্সের কারণে সার্ভার অনুরোধ প্রসেস করতে পারেনি। সাধারণত, ভুল JSON ফর্ম্যাট বা স্ট্রিং ভ্যালুর জন্য ""-এর পরিবর্তে null ব্যবহার করলে এই সমস্যা হয়।

সমাধান: অনুরোধের বডি সঠিক JSON (কোনও ভুল গঠন বা স্ট্রিং ফিল্ডের জন্য নাল ভ্যালু) কিনা তা নিশ্চিত করুন এবং agentUserId-এর সাথে SYNC রেসপন্স-এর ভ্যালু ম্যাচ করছে কিনা তা যাচাই করুন।

404 পাওয়া যায়নি

কারণ: HomeGraph-এ deviceId বা agentUserId খুঁজে পাওয়া যায়নি (এখনও সিঙ্ক করা হয়নি, আগে থেকেই আনলিঙ্ক করা আছে অথবা আইডিতে মিল নেই)।

সমাধান:

1. agentUserId আপনার SYNC রেসপন্সে দেওয়া ভ্যালুর সাথে মিলছে কিনা তা নিশ্চিত করুন।
2. Home Graph SYNC API ব্যবহার করে নির্ধারণ করুন যে HomeGraph-এ ডিভাইস বা ব্যবহারকারী অনুপস্থিত থাকার কারণে 404 Not Found সমস্যা হয়েছে কিনা।
3. ডিভাইস বা অ্যাকাউন্ট যোগ করা, সরানো, নাম পরিবর্তন করা বা আপডেট করার পরে requestSync ট্রিগার করতে ভুলবেন না, যাতে স্ট্যাটাস আপ-টু-ডেট থাকে।
4. পুরনো ডিভাইস সম্পর্কে রিপোর্ট করা বন্ধ করতে DISCONNECT ইনটেন্ট ঠিকভাবে হ্যান্ডেল করুন। DISCONNECTইন্টেন্ট পাওয়ার পরে, আপনার ক্লাউড পরিষেবা সিঙ্ক করার অনুরোধ এবং স্টেট রিপোর্ট করুন ব্যবহার করে Google-এ পরিবর্তন প্রকাশ করা বন্ধ করে দেবে।

429 Resource Exhausted

কারণ: আপনার ইন্টিগ্রেশন বরাদ্দ করা কোটা পেরিয়ে গেছে।

সমাধান: কোটা ম্যানেজমেন্টের জন্য ড্যাশবোর্ডে "ধাপ ২ক: কোটা সংক্রান্ত সমস্যার সমাধান করুন" বিভাগে নির্দেশাবলী দেখুন। এছাড়াও, আরও তথ্যের জন্য আপনি স্মার্ট হোম কোটা ও সীমা দেখতে পারেন।

ডিভাইসের অবস্থা - স্টেট অ্যাকুরেসি

স্টেট অ্যাকুরেসি >= ৯৯.৫% পূরণ করা বা তার বেশি হলে, ব্যবহারকারীরা ডিভাইসের স্টেট দেখলে বা Home-কে জিজ্ঞাসা করার মতো AI ফিচার ব্যবহার করলে সঠিক ফলাফল দেখতে পাবেন। স্টেট অ্যাকুরেসি কম হলে, অটোমেশন ফায়ার নাও হতে পারে এবং GHA-এর অ্যাক্টিভিটি ট্যাবে সঠিক সময়ে ইতিহাস এন্ট্রি নাও দেখা যেতে পারে। আরও তথ্যের জন্য, রিপোর্ট স্টেট দেখুন। মনে রাখবেন: সমস্ত মানানসই ট্রেড জুড়ে রাজ্যের নির্ভুলতা সংক্রান্ত টার্গেট পূরণ করতে হবে।

১. নির্ভুলতা সংক্রান্ত কম্পোনেন্ট

এই মেট্রিক "স্যাম্পেল" থেকে পাওয়া যায় যেখানে Google, পরিচিত ইনটেন্ট ফলাফলের বিপরীতে অভিযোগ জানানো স্টেট যাচাই করতে পারে। টেকনিক্যাল নির্ভুলতার জন্য, দুটি আলাদা আলাদা উপায়ে যথার্থতা মূল্যায়ন করা হয়:

• কোয়েরি ভিত্তিক নির্ভুলতা: কোনও ব্যবহারকারী বা সিস্টেম ডিভাইসের বর্তমান স্ট্যাটাস সম্পর্কে সক্রিয়ভাবে প্রশ্ন করলে যাচাই করা হয়।
• নির্দেশ পালন করার ক্ষেত্রে নির্ভুলতা: কন্ট্রোল সংক্রান্ত অনুরোধের পরে ডিভাইস যে স্ট্যাটাস রিপোর্ট করে তা মূল্যায়ন করে যাচাই করা হয়।

২. ড্যাশবোর্ড মেট্রিক (প্রতি ঘণ্টার গণনা)

ড্যাশবোর্ড ১-ঘণ্টার ব্যবধানের ভিত্তিতে নির্ভুলতা গণনা করে। পরিসংখ্যানগত আত্মবিশ্বাস নিশ্চিত করতে এবং কম সিগন্যাল নয়েজের কারণে ইন্টিগ্রেশনকে শাস্তি দেওয়া এড়াতে, Google একটি ন্যূনতম ট্রাফিক ভলিউম থ্রেশহোল্ড প্রয়োগ করে। কোনও নির্দিষ্ট বৈশিষ্ট্য ও ডিভাইসের কম্বিনেশন যদি ৫ দিনের মধ্যে ১০০টির কম নমুনা সংগ্রহ করে, তাহলে তার নির্ভুলতা পরিসংখ্যানগতভাবে নগণ্য বলে বিবেচিত হয় এবং প্রযোজ্য নয় হিসেবে সেট করা হয়।

কোনও ঘণ্টায় দুটি পাথওয়ে জুড়ে পর্যাপ্ত স্যাম্পেল ভলিউম থাকলে, কোনও নির্দিষ্ট রাজ্যের জন্য বেসলাইন ঘণ্টার নির্ভুলতা দুটি স্বতন্ত্র শতাংশের গড় হিসেবে গণনা করা হয়:

প্রতি ঘণ্টার স্টেট অ্যাকুরেসি = (কোয়েরি অ্যাকুরেসি % + এক্সিকিউশন অ্যাকুরেসি %) / ২

যেখানে প্রতিটি পাথওয়েকে এইভাবে সংজ্ঞায়িত করা হয়েছে:

• কোয়েরি নির্ভুলতার % = (প্রতি ঘণ্টার কোয়েরির নির্ভুল স্যাম্পেল) / (প্রতি ঘণ্টার কোয়েরির মোট স্যাম্পেল)
• এক্সিকিউশন নির্ভুলতা % = (প্রতি ঘণ্টার এক্সিকিউশন নির্ভুল স্যাম্পেল) / (প্রতি ঘণ্টার এক্সিকিউশন মোট স্যাম্পেল)

বৈশিষ্ট্য নির্ভুলতা স্কোর (প্রতিটি বৈশিষ্ট্য অনুযায়ী গণনা করা হয়) = SUM(কোয়েরি নির্ভুল স্যাম্পেল + এক্সিকিউশন নির্ভুল স্যাম্পেল) / SUM(কোয়েরি মোট স্যাম্পেল + এক্সিকিউশন মোট স্যাম্পেল)

কারণ, কোয়ালিটি স্কোর আপনার ইকোসিস্টেম জুড়ে কঠোর ন্যূনতম পারফর্ম্যান্স মূল্যায়ন করে, প্রতিটি কাজ করে এমন ও উপযুক্ত ট্রেটকে আলাদা আলাদাভাবে >= ৯৯.৫% স্টেট অ্যাকুরেসি টার্গেট পূরণ করতে হবে (এটি ট্রেট জুড়ে কোনও গড় নয়)।

এই ভিউ, কম ভলিউম থাকা ডিভাইসে নির্ভুলতা সংক্রান্ত সমস্যাকে বেশি ভলিউম থাকা ডিভাইসের নির্ভুলতা সংক্রান্ত সমস্যা থেকে আলাদা করে। যেসব পার্টনারের স্কোর কম হওয়ার কারণ হল কম ব্যবহার করা ফিচার, তারা নিশ্চিন্ত থাকতে পারেন যে ন্যূনতম ট্রাফিক ভলিউম চেকের মাধ্যমে কম ব্যবহার করা ফিচার অটোমেটিক সুরক্ষিত থাকে এবং প্রয়োজনীয় স্যাম্পেল থ্রেশহোল্ড পূরণ না করা পর্যন্ত সেটি সর্বনিম্ন ধরন ও ফিচার স্কোরের মধ্যে অন্তর্ভুক্ত করা হবে না।

৩. ডিভাইসের স্বাস্থ্য ও স্ট্যাটাস অ্যাকুরেসি উন্নত করা

Home Graph-এ সেভ করা স্টেট যখন রিয়েল-টাইম কোয়েরির ফলাফলের সাথে ম্যাচ করে না, তখন ডিসক্রিপেন্সি হয়।

"ফিল্ড নেই" সংক্রান্ত সমস্যা

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-এর উত্তরে প্রাপ্ত ভ্যালু এবং শেষ রিপোর্ট স্টেট ভ্যালুর মধ্যে পার্থক্য রয়েছে।

সমাধান: কোনও ডিভাইসের স্ট্যাটাস পরিবর্তন হলেই রিপোর্ট স্টেট ট্রিগার করা হয় কিনা তা নিশ্চিত করুন এবং রিপোর্ট স্টেট ও কোয়েরি সবসময় একই, আপ-টু-ডেট ভ্যালু ও ডেটা কনসিস্টেন্সি বজায় রাখার জন্য প্রয়োজনীয় সব ফিল্ড প্রদান করে কিনা তা নিশ্চিত করুন।

"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 নতুন ডিভাইসের স্টেট পায়।

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 ফলাফলে বর্তমান স্ট্যাটাস দেওয়া সত্ত্বেও, স্টেট খালি এবং reported timestamp হল epoch)। এর থেকে বোঝা যায় যে, স্টেট আপডেট ট্রিগার করা হচ্ছে না, HomeGraph-এ পৌঁছাতে পারছে না অথবা ডিভাইসটি কানেক্টিভিটি বা অপারেশনাল স্ট্যাটাসে ট্রানজিশন সফলভাবে রিপোর্ট করতে পারছে না।

সমাধান: নিশ্চিত করুন যে রিপোর্ট স্টেট ট্রিগার করা হয়েছে এবং সমস্ত স্টেট পরিবর্তনের জন্য সফলভাবে পাঠানো হয়েছে। ব্যাকএন্ড লজিক স্ট্যাটাস আপডেট সঠিকভাবে ম্যানেজ করে কিনা, Google HomeGraph-এ ডেলিভারি সম্পূর্ণ হওয়ার বিষয়টি কনফার্ম করে কিনা এবং ডিভাইস ব্যবহারকারীর ইন্টারফেস ও অটোমেশন ইঞ্জিন সঠিক রাখার জন্য ধারাবাহিকভাবে নিজের স্টেট সিনক্রোনাইজ করে কিনা তা নিশ্চিত করুন।