Google Home Vitals (ক্লাউড)

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

ড্যাশবোর্ডে তিনটি বিভাগ রয়েছে, যার প্রতিটি একটি মূল অংশ কভার করে যা সামগ্রিক ইন্টিগ্রেশনের গুণমানে অবদান রাখে।

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

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

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

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

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

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

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

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

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

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

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

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

"ব্যর্থতা" বলতে কী বোঝায়?

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

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

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

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

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

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

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

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

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 (নেটওয়ার্ক টাইম প্রোটোকল)-এর সাথে সিঙ্ক করতে হবে। এমনকি ঘড়ির সময় সামান্য (৫০-১০০ মিলি সেকেন্ড) এদিক-ওদিক হলেও, ট্রানজিট টাইম (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 হিসেবে স্পষ্টভাবে রেকর্ড করা হয়েছে।

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

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

জিও-রাউটিংয়ের জন্য আর্কিটেকচারাল সাজেশন

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

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

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

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

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

2. জিও-লোকেশন অ্যাওয়ার ডিএনএস (GeoDNS)

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

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

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

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

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

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

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

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

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

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

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

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

   প্রয়োগ: Google-এর জন্য ইস্যু করা access_token-এ অঞ্চল শনাক্তকারী এনকোড করুন। 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. HomeGraph-এ কোনও ডিভাইস বা ব্যবহারকারী না থাকার কারণে 404 পাওয়া যায়নি সমস্যাটি হয়েছে কিনা তা নির্ধারণ করতে Home Graph SYNC API ব্যবহার করুন।
3. ডিভাইস বা অ্যাকাউন্ট যোগ, সরানো, নাম পরিবর্তন বা আপডেট করার পরে requestSync ট্রিগার করতে ভুলবেন না যাতে স্ট্যাটাস আপ-টু-ডেট থাকে।
4. পুরনো ডিভাইসের ব্যাপারে রিপোর্ট করা বন্ধ করতে DISCONNECT ইনটেন্ট সঠিকভাবে ম্যানেজ করুন। DISCONNECT ইনটেন্ট পাওয়ার পরে, আপনার ক্লাউড পরিষেবার উচিত সিঙ্ক করার অনুরোধ এবং স্ট্যাটাস রিপোর্ট-এর মাধ্যমে Google-এ পরিবর্তন প্রকাশ করা বন্ধ করা।

429 রিসোর্স শেষ হয়ে গেছে

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

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

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

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

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

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

• কোয়েরি ভিত্তিক নির্ভুলতা: কোনও ব্যবহারকারী বা সিস্টেম যখন ডিভাইসের বর্তমান স্ট্যাটাস সক্রিয়ভাবে যাচাই করে তখন এটি যাচাই করা হয়।
• EXECUTE ভিত্তিক নির্ভুলতা: কন্ট্রোল অনুরোধের পরে রিপোর্ট করা পোস্ট-কমান্ড ডিভাইস স্ট্যাটাস মূল্যায়ন করে যাচাই করা হয়েছে।

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

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

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

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

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

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

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

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

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

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

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 ফলাফল বর্তমান স্ট্যাটাস প্রদান করে। এটি ইঙ্গিত করে যে স্ট্যাটাস আপডেট ট্রিগার করা হচ্ছে না, HomeGraph-এ পৌঁছাতে পারছে না বা ডিভাইসটি তার কানেক্টিভিটি বা অপারেশনাল স্ট্যাটাসে ট্রানজিশন সফলভাবে রিপোর্ট করছে না।

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