Google Home Vitals (ระบบคลาวด์)

ชุดแดชบอร์ดและการแจ้งเตือนนี้ช่วยให้คุณรักษาการผสานรวมคุณภาพสูงกับระบบนิเวศของ Google Home ได้อย่างสม่ำเสมอ Google มุ่งมั่นที่จะสนับสนุนพาร์ทเนอร์ในการพัฒนาระบบนิเวศคุณภาพสูงสำหรับลูกค้าทุกคน

แดชบอร์ดมี 3 ส่วน โดยแต่ละส่วนจะครอบคลุมส่วนสำคัญที่ส่งผลต่อคุณภาพของการผสานรวมโดยรวม

1. เมตริก Google ไปยังพาร์ทเนอร์ - วัดประสิทธิภาพของการเรียกจาก Google ไปยังแบ็กเอนด์ระบบคลาวด์ของคุณ

2. ประสิทธิภาพของระบบ - เมตริกพาร์ทเนอร์ถึง Google - วัดประสิทธิภาพของการโทรจากระบบของคุณไปยัง Google

3. ประสิทธิภาพการทำงานของอุปกรณ์ - ความถูกต้องของสถานะ - วัดความถูกต้องของสถานะที่จัดเก็บไว้ในระบบของ Google ซึ่งใช้เพื่อตอบคำถามของผู้ใช้

เมื่อเมตริกไม่เป็นไปตามค่าเป้าหมาย ระบบจะไฮไลต์เป็นสีแดงเพื่อระบุปัญหาที่อาจส่งผลต่อประสบการณ์ของผู้ใช้ ข้อมูลต่อไปนี้จะให้รายละเอียดเกี่ยวกับเป้าหมายแต่ละรายการและเหตุผลที่เป้าหมายนั้นสำคัญต่อผู้ใช้

หากปุ่มต่อไปนี้ไม่นำคุณไปยังแดชบอร์ดโดยตรง คุณสามารถไปที่แดชบอร์ดได้โดยเลือกหน้าภาพรวม เลือกแดชบอร์ด แล้วเลือกแดชบอร์ด Google Home Vitals (ระบบคลาวด์) จากรายการแดชบอร์ดของฉันเพื่อดูแดชบอร์ด

ไปที่แดชบอร์ด

เมตริก Google ถึงพาร์ทเนอร์

เมตริกอัตราความสำเร็จในการค้นหา/ดำเนินการ >= 99.5% จะวัดความถี่ที่คำสั่งของผู้ใช้ได้รับการดำเนินการอย่างถูกต้อง ซึ่งจะช่วยหลีกเลี่ยงการตอบกลับของ Assistant เช่น "ฉันเข้าถึงอุปกรณ์ไม่ได้" หรือการยืนยันคำสั่งที่ไม่ถูกต้องซึ่งยังไม่ได้รับการดำเนินการ

เมตริกอัตราความสำเร็จในการซิงค์ >= 99.5% จะวัดความถี่ที่คำขอซิงค์ได้รับการดำเนินการอย่างถูกต้อง ซึ่งช่วยให้มั่นใจได้ว่าอุปกรณ์ที่แสดงใน Google Home ซิงค์กับอุปกรณ์ที่เชื่อมต่อกับโครงสร้างพื้นฐานของระบบคลาวด์

"ความสำเร็จ" คืออะไร

ระบบจะทำเครื่องหมายธุรกรรมว่าสำเร็จหากแพลตฟอร์ม Google Home ได้รับการตอบกลับที่ถูกต้องซึ่งระบุว่าการดำเนินการที่ต้องการเสร็จสมบูรณ์หรือดึงข้อมูลสถานะที่ขอแล้ว

การตอบกลับที่มีข้อยกเว้นที่ไม่บล็อก (เช่น สถานะ SUCCESS ที่มาพร้อมกับข้อยกเว้น lowBattery) จะนับเป็นธุรกรรมที่สำเร็จ คำสั่งไปถึงอุปกรณ์แล้วและดำเนินการตามความตั้งใจได้สำเร็จแม้จะมีคำเตือน

"ความล้มเหลว" มีคำจำกัดความว่าอย่างไร

ข้อผิดพลาดที่พบในรหัสข้อผิดพลาดทั่วไปของแพลตฟอร์มซึ่งทำเครื่องหมายเป็นพาร์ทเนอร์ดำเนินการได้จะถือเป็น "ความล้มเหลว" เมื่อคำนวณอัตราความสำเร็จของ QUERY, EXECUTE และ SYNC นอกจากนี้ ข้อผิดพลาดที่พบในข้อผิดพลาดและข้อยกเว้นยังถือเป็น "ความล้มเหลว" ด้วย โดยมีข้อยกเว้นต่อไปนี้

ความเท่าเทียมกันของสถานะการตอบกลับการดำเนินการ

เมื่อแสดงผลสถานะ SUCCESS ในการตอบกลับ EXECUTE ออบเจ็กต์ states ของเพย์โหลดการตอบกลับต้องมีฟิลด์สถานะที่ใช้งานอยู่และอัปเดตทั้งหมดซึ่งกำหนดโดยลักษณะที่คุณกำลังดำเนินการ การละเว้นช่องสถานะที่จำเป็นหรือแสดงผลออบเจ็กต์ states ที่ว่างเปล่าสำหรับลักษณะที่ซับซ้อนจะทำให้แพลตฟอร์ม Google Home แยกวิเคราะห์ผลการดำเนินการไม่สำเร็จ โดยจะบันทึกเป็นความล้มเหลว AGENT_ISSUE หรือ INVALID_RESPONSE ซึ่งจะลดอัตราความสำเร็จในการค้นหาและการดำเนินการ

เมตริกเวลาในการตอบสนองของคำสั่งค้นหา/การดำเนินการ (p90) <= 1000 มิลลิวินาทีจะวัดเวลารอสำหรับการดำเนินการที่ขอ และช่วยให้มั่นใจว่าผู้ใช้ไม่ต้องรอนานเกินไป เช่น รอ 2-3 วินาทีเพื่อให้ไฟปิด

เมตริกเวลาในการตอบสนอง

เวลาในการตอบสนองเป็นตัวบ่งชี้ที่สำคัญว่าการผสานรวมของคุณตอบสนองต่อผู้ใช้ปลายทางได้ดีเพียงใด แดชบอร์ดจะติดตามเวลาในการตอบสนองเปอร์เซ็นไทล์ที่ 90 (P90) ซึ่งแสดงถึงประสบการณ์ของผู้ใช้ที่ "ช้าที่สุด" (เช่น P90 ที่ 800 มิลลิวินาทีหมายความว่าคำขอ 90% ได้รับการตอบรับภายใน 800 มิลลิวินาทีหรือน้อยกว่า)

Google วัดเวลาในการตอบสนองสำหรับการตรวจสอบสถานะแตกต่างจากคำสั่งอุปกรณ์เพื่อให้มั่นใจถึงความถูกต้องทางเทคนิค

1. เวลาในการตอบสนองของคำถาม (คำถาม)

ซึ่งจะวัดเวลาไปกลับ Cloud-to-cloud เมื่อ Google ขอสถานะปัจจุบันของอุปกรณ์

• เริ่มต้น: Google ส่งคำขอ action.devices.QUERY ไปยัง URL การดำเนินการตามคำสั่งซื้อของคุณ
• กรอบเวลาการวัด: เวลาที่ใช้สำหรับระบบคลาวด์ในการรับ ประมวลผล และส่งการตอบกลับ HTTP แบบเต็มกลับไปยัง Google
• สิ้นสุด: Google ได้รับและรับทราบเพย์โหลดการตอบกลับสุดท้ายจากบริการของคุณ

2. เวลาในการตอบสนองของ EXECUTE (การดำเนินการ)

ซึ่งจะวัดเวลาที่ใช้ในการรับทราบคำสั่งเมื่อ Google ส่งคำขอควบคุมไปยังอุปกรณ์

• เริ่มต้น: Google ส่งคำขอ action.devices.EXECUTE ไปยัง URL Fulfillment ของคุณ
• กรอบเวลาการวัด: เวลาที่ใช้สำหรับระบบคลาวด์ในการรับคำสั่งและส่งการตอบรับกลับมา
• สิ้นสุด: Google ได้รับการตอบกลับสถานะ SUCCESS, PENDING หรือ OFFLINE
• ขอบเขตทางเทคนิค: เมตริกนี้จะวัดเวลา "การรับทราบการตอบกลับ" ระหว่างระบบคลาวด์ของ Google กับระบบคลาวด์ของคุณ แต่ไม่ได้วัดเวลาที่ฮาร์ดแวร์จริง (เช่น หลอดไฟ) ใช้ในการเปลี่ยนสถานะทางกายภาพให้เสร็จสมบูรณ์ เนื่องจากมักเกี่ยวข้องกับเวลาในการตอบสนองของเครือข่ายที่ทำงานร่วมกันในพื้นที่นอกเส้นทางแบบ Cloud-to-Cloud

รายละเอียดไทม์ไลน์เวลาในการตอบสนองของ EXECUTE/QUERY

เมื่อวิเคราะห์การประทับเวลาสำหรับเวลาในการตอบสนองของ EXECUTE หรือ QUERY คุณสามารถแบ่งเวลาไปกลับทั้งหมดออกเป็นลำดับขั้นตอนต่อไปนี้

เนื่องจากรายละเอียดนี้เปรียบเทียบการประทับเวลาฝั่ง Google และฝั่งพาร์ทเนอร์ เซิร์ฟเวอร์ของพาร์ทเนอร์จึงต้องซิงค์กับ NTP (Network Time Protocol) แม้แต่ความคลาดเคลื่อนของนาฬิกาเพียงเล็กน้อย (50-100 มิลลิวินาที) ก็จะบิดเบือนเวลาขนส่งที่คำนวณได้ (t2 - t1 และ t4 - t3) ซึ่งอาจนำไปสู่เมตริกที่เป็นไปไม่ได้ในทางตรรกะ เช่น เวลาในการตอบสนองของการขนส่งที่เป็นค่าลบ

[t1] ส่งคำขอแล้ว (ขาออกจาก Google): Google เริ่มต้นคำขอ Intent เนื่องจาก t1 ไม่ได้แสดงโดยตรง จึงคำนวณโดยประมาณโดยการลบเวลาในการตอบสนองทั้งหมดออกจากการประทับเวลาขาเข้าสุดท้าย

การส่งผ่านเครือข่าย (t1 ถึง t2): เวลาในการส่งผ่านเครือข่ายและเวลาในการรอคิวก่อนที่จะถึงปลายทางการดำเนินการตามคำสั่งซื้อโดยประมาณ

[t2] ได้รับคำขอ (ขาเข้าของพาร์ทเนอร์): การประทับเวลาที่แน่นอนเมื่อคำขอมาถึงเกตเวย์ API หรือเซิร์ฟเวอร์ขาเข้าของสภาพแวดล้อมของคุณ

การประมวลผลของพาร์ทเนอร์ (t2 ถึง t3): เวลาในการตอบสนองของการดำเนินการภายใน การกำหนดเส้นทาง และการจัดการอุปกรณ์ภายในสภาพแวดล้อมระบบคลาวด์ของคุณทั้งหมด

[t3] ส่งการตอบกลับ (ขาออกของพาร์ทเนอร์): การประทับเวลาเมื่อบริการของคุณส่งการตอบกลับการดำเนินการตามคำสั่งซื้อกลับไปยัง Google

Return Transit (t3 ถึง t4): เวลาที่ใช้ในการกำหนดเส้นทางเครือข่ายขากลับและการเชื่อมต่อกลับไปยัง Google จนเสร็จสมบูรณ์

[t4] คำขอเสร็จสิ้น (Google ขาเข้า): Google ได้รับและประมวลผลการตอบกลับขั้นสุดท้าย การประทับเวลานี้จะบันทึกไว้อย่างชัดเจนในบันทึก Google Cloud เป็น receiveTimestamp

เพื่อให้เห็นภาพว่าเมตริกเหล่านี้เชื่อมโยงกันอย่างไร ให้พิจารณาตัวอย่างคำขอ EXECUTE ที่มีเวลาในการตอบสนองที่บันทึกไว้ทั้งหมด (latencyMsec) เท่ากับ 1, 700 มิลลิวินาที และGoogle Cloud receiveTimestamp (t4) เท่ากับ 2026-05-25T15:25:00.550Z

ตัวเลือกการลดเวลาในการตอบสนอง

คำแนะนำด้านสถาปัตยกรรมสำหรับการกำหนดเส้นทางตามภูมิศาสตร์

หากไม่สามารถใช้ Anycast IP ได้ เราขอแนะนำทางเลือกที่คุ้มค่าต่อไปนี้เพื่อให้มั่นใจว่าผู้ใช้จะได้รับบริการจากศูนย์ข้อมูลระดับภูมิภาคที่ใกล้ที่สุด

1. การจัดสรรภาระงานทั่วโลก (GLB)

   ใช้ตัวจัดสรรภาระงานแอปพลิเคชันส่วนกลาง (มีให้บริการจากผู้ให้บริการคลาวด์รายใหญ่ส่วนใหญ่) แทนการกำหนดเส้นทางแบบคงที่

   • วิธีการทำงาน: คุณกำหนดค่าจุดแรกเข้า (URL) ทั่วโลกจุดเดียวที่อยู่ที่ขอบเครือข่าย ตัวจัดสรรภาระงานจะตรวจหาต้นทางทางภูมิศาสตร์ของคำขอจากคลัสเตอร์การดำเนินการตามคำสั่งซื้อของ Google โดยอัตโนมัติ และกำหนดเส้นทางการเข้าชมไปยังแบ็กเอนด์ที่สมบูรณ์ในภูมิภาคที่ใกล้ที่สุด

   • ประโยชน์: วิธีนี้ช่วยให้ Anycast มีประสิทธิภาพมากขึ้นโดยมีความซับซ้อนและค่าใช้จ่ายในการกำหนดค่าลดลงอย่างมาก

2. DNS ที่รับรู้ตำแหน่งทางภูมิศาสตร์ (GeoDNS)

   • วิธีการทำงาน: กำหนดค่าผู้ให้บริการ DNS เพื่อแปลง URL การดำเนินการเป็นที่อยู่ IP ต่างๆ ตามสถานที่ตั้งทางภูมิศาสตร์ของคำขอ DNS

   • การติดตั้งใช้งาน: ตรวจสอบว่าผู้ให้บริการ DNS ได้รับการเพิ่มประสิทธิภาพสำหรับจุดขาออกของ Google เมื่อบริการการดำเนินการระดับภูมิภาคของ Google (เช่น ในสหรัฐอเมริกา สหภาพยุโรป หรือเอเชีย) แก้ไขโดเมนของคุณ บริการดังกล่าวจะได้รับที่อยู่ IP สำหรับศูนย์ข้อมูลในภูมิภาคนั้นๆ

กลยุทธ์การเพิ่มประสิทธิภาพที่เลเยอร์ของแอปพลิเคชัน

นอกจากการกำหนดเส้นทางระดับโครงสร้างพื้นฐานแล้ว คุณยังใช้กลยุทธ์ต่อไปนี้ที่เลเยอร์ของแอปพลิเคชันเพื่อลดเวลาในการตอบสนองในการประมวลผลคำขอได้ด้วย

1. วิธีพร็อกซีแบบ "Trampoline"

   หากคุณต้องรักษาศูนย์ข้อมูลหลักไว้ ให้ใช้พร็อกซีเซิร์ฟเวอร์แบบ Lightweight ระดับภูมิภาค (Trampoline) เพื่อจัดการแฮนด์เชคเริ่มต้น

   1. Google เข้าถึง URL ทั่วโลกของคุณ

   2. พร็อกซีระดับภูมิภาค (เช่น ฟังก์ชัน Nginx หรือ Lambda แบบ Lightweight) จะได้รับคำขอ

   3. พร็อกซีจะส่งต่อเพย์โหลดผ่านเครือข่ายแกนหลักความเร็วสูงภายในไปยังฐานข้อมูลหลัก

   ประโยชน์: วิธีนี้จะช่วยลดเวลา "TCP Handshake" ซึ่งมักเป็นสาเหตุหลักของเวลาในการตอบสนองสำหรับคำขอระยะไกล

2. คำแนะนำเกี่ยวกับภูมิภาคของโทเค็นเพื่อการเข้าถึง

   ในระหว่างกระบวนการลิงก์บัญชี (OAuth) ระบบจะระบุภูมิภาคบ้านของผู้ใช้ได้

   การติดตั้งใช้งาน: เข้ารหัสตัวระบุภูมิภาคลงใน access_token ที่ออกให้กับ Google เมื่อ Google ส่งคำขอการดำเนินการตามคำสั่งซื้อ เกตเวย์จะตรวจสอบโทเค็นและกำหนดเส้นทางคำขอไปยังคลัสเตอร์ระดับภูมิภาคที่ถูกต้องได้ทันทีโดยไม่ต้องค้นหาฐานข้อมูล

ประสิทธิภาพของระบบ - เมตริกจากพาร์ทเนอร์ไปยัง Google

การรักษาอัตราความสำเร็จ >= 99.5% จะช่วยให้มั่นใจได้ว่าสถานะอุปกรณ์ใน Google Home ถูกต้อง มีการเพิ่มและนำอุปกรณ์ออก การทำงานอัตโนมัติทริกเกอร์ และเหตุการณ์ในประวัติปรากฏในแท็บกิจกรรมของ Google Home app (GHA)

อัตราความสำเร็จจะคำนวณตามโค้ดตอบกลับ HTTP ที่ Google แสดงเมื่อระบบคลาวด์พุชการอัปเดตสถานะ เมตริกนี้จะไม่รวมข้อผิดพลาดภายในของ Google จากจำนวนการดำเนินการที่ไม่สำเร็จ เพื่อให้แน่ใจว่าพาร์ทเนอร์จะไม่ถูกลงโทษสำหรับปัญหาด้านโครงสร้างพื้นฐานฝั่ง Google การเรียก API ที่รวมอยู่ในการคำนวณจะอยู่ในเอกสารอ้างอิง HomeGraph API

"ความสำเร็จ" คืออะไร

2xx (สำเร็จ): Home Graph ได้รับและประมวลผลการอัปเดตสถานะเรียบร้อยแล้ว

"ความล้มเหลว" มีคำจำกัดความว่าอย่างไร

4xx (ข้อผิดพลาดของพาร์ทเนอร์) แสดงถึงความล้มเหลวและบ่งบอกถึงปัญหาเกี่ยวกับคำขอที่ส่งจากระบบคลาวด์ของคุณ รหัสที่พบบ่อยมีดังนี้

400 คำขอไม่ถูกต้อง

สาเหตุ: เซิร์ฟเวอร์ประมวลผลคำขอไม่ได้เนื่องจากไวยากรณ์ไม่ถูกต้อง สาเหตุที่พบบ่อย ได้แก่ JSON ที่มีรูปแบบไม่ถูกต้อง หรือการใช้ค่า Null แทน "" สำหรับค่าสตริง

วิธีแก้ไข: ตรวจสอบว่าเนื้อหาคำขอเป็น JSON ที่ถูกต้อง (ไม่มีโครงสร้างที่ผิดรูปแบบหรือค่า Null สำหรับช่องสตริง) และยืนยันว่า agentUserId ตรงกับค่าจากการตอบกลับ SYNC

404 Not Found

สาเหตุ: ไม่พบ deviceId หรือ agentUserId ใน HomeGraph (ยังไม่ได้ซิงค์ ยกเลิกการลิงก์แล้ว หรือรหัสไม่ตรงกัน)

วิธีแก้ไข

1. ตรวจสอบว่า agentUserId ตรงกับค่าที่ระบุในการตอบกลับ SYNC
2. ใช้ Home Graph SYNC API เพื่อระบุว่าข้อผิดพลาด 404 Not Found เกิดจากอุปกรณ์หรือผู้ใช้ที่ขาดหายไปใน HomeGraph หรือไม่
3. อย่าลืมเรียกใช้ requestSync หลังจากเพิ่ม นำออก เปลี่ยนชื่อ หรืออัปเดตอุปกรณ์หรือบัญชี เพื่อให้สถานะเป็นปัจจุบันอยู่เสมอ
4. จัดการ Intent DISCONNECT อย่างเหมาะสมเพื่อหยุดรายงานอุปกรณ์ที่ไม่มีการใช้งาน หลังจากได้รับ Intent DISCONNECT แล้ว บริการระบบคลาวด์ควรหยุดเผยแพร่การเปลี่ยนแปลงไปยัง Google ด้วย Request Sync และ Report State

429 ทรัพยากรหมดแล้ว

สาเหตุ: การผสานรวมของคุณใช้โควต้าที่จัดสรรไว้เกินแล้ว

วิธีแก้ไข: ดูวิธีการในส่วน "ขั้นตอนที่ 2ก: แก้ไขปัญหาโควต้า" ในแดชบอร์ดสำหรับการจัดการโควต้า นอกจากนี้ คุณยังดูข้อมูลเพิ่มเติมได้ที่โควต้าและขีดจำกัดของสมาร์ทโฮม

ประสิทธิภาพการทำงานของอุปกรณ์ - ความแม่นยำของสถานะ

การมีความแม่นยำของสถานะ >= 99.5% จะช่วยให้ผู้ใช้เห็นผลลัพธ์ที่ถูกต้องเมื่อดูสถานะอุปกรณ์หรือใช้ฟีเจอร์ AI เช่น ถาม Google Home หากความแม่นยำของสถานะต่ำ การทำงานอัตโนมัติอาจไม่เริ่มทำงานและรายการประวัติอาจไม่ปรากฏในแท็บกิจกรรมของ GHA ในเวลาที่เหมาะสม ดูข้อมูลเพิ่มเติมได้ที่รายงานสถานะ โปรดทราบว่าคุณต้องบรรลุเป้าหมายความแม่นยำของสถานะในลักษณะที่รองรับทั้งหมด

1. องค์ประกอบด้านความถูกต้อง

เมตริกนี้ได้มาจาก "ตัวอย่าง" ที่ Google สามารถยืนยันสถานะที่รายงานกับผลลัพธ์ของความตั้งใจที่ทราบ สำหรับความแม่นยำทางเทคนิค ระบบจะประเมินความถูกต้องผ่าน 2 เส้นทางที่แตกต่างกัน ดังนี้

• ความแม่นยำตามการค้นหา: ยืนยันเมื่อผู้ใช้หรือระบบสอบถามสถานะปัจจุบันของอุปกรณ์อย่างสม่ำเสมอ
• ความแม่นยำตามการดำเนินการ (EXECUTE): ยืนยันโดยการประเมินสถานะอุปกรณ์หลังคำสั่งที่รายงานกลับมาหลังจากคำขอควบคุม

2. เมตริกในหน้าแดชบอร์ด (การคำนวณรายชั่วโมง)

แดชบอร์ดจะคำนวณความถูกต้องตามช่วงเวลา 1 ชั่วโมง Google บังคับใช้เกณฑ์ปริมาณการเข้าชมขั้นต่ำเพื่อให้มั่นใจถึงความเชื่อมั่นทางสถิติและหลีกเลี่ยงการลงโทษการผสานรวมที่มีสัญญาณรบกวนต่ำ หากชุดค่าผสมของลักษณะและอุปกรณ์หนึ่งๆ มีตัวอย่างรวมน้อยกว่า 100 รายการในช่วงหน้าต่างแบบต่อเนื่อง 5 วัน ระบบจะถือว่าความแม่นยำไม่มีนัยสำคัญทางสถิติและตั้งค่าเป็นไม่มี

เมื่อชั่วโมงหนึ่งมีปริมาณตัวอย่างเพียงพอในทั้ง 2 เส้นทาง ระบบจะคำนวณความแม่นยำรายชั่วโมงพื้นฐานสำหรับรัฐหนึ่งๆ เป็นค่าเฉลี่ยของเปอร์เซ็นต์อิสระ 2 รายการ ดังนี้

ความแม่นยำของสถานะรายชั่วโมง = (% ความแม่นยำของการค้นหา + % ความแม่นยำของการดำเนินการ) / 2

โดยแต่ละเส้นทางมีคำจำกัดความดังนี้

• %ความแม่นยำของคำถาม = (ตัวอย่างคำถามที่ถูกต้องรายชั่วโมง) / (ตัวอย่างคำถามทั้งหมดรายชั่วโมง)
• %ความแม่นยำในการดำเนินการ = (ตัวอย่างที่แม่นยำในการดำเนินการรายชั่วโมง) / (ตัวอย่างทั้งหมดในการดำเนินการรายชั่วโมง)

คะแนนความแม่นยำของลักษณะ (คำนวณต่อลักษณะ) = SUM(ตัวอย่างที่แม่นยำของคำถาม + ตัวอย่างที่แม่นยำของการดำเนินการ) / SUM(ตัวอย่างทั้งหมดของคำถาม + ตัวอย่างทั้งหมดของการดำเนินการ)

เนื่องจากคะแนนคุณภาพจะประเมินประสิทธิภาพขั้นต่ำที่เข้มงวดในระบบนิเวศของคุณ ลักษณะที่รองรับและมีสิทธิ์ทุกรายการต้องเป็นไปตามเป้าหมายความถูกต้องของสถานะ >= 99.5% แยกกัน (ไม่ใช่ค่าเฉลี่ยของลักษณะต่างๆ)

มุมมองนี้จะป้องกันไม่ให้อุปกรณ์ที่มีปริมาณการใช้งานสูงซึ่งมีความแม่นยำสูงบดบังปัญหาด้านความแม่นยำในอุปกรณ์ที่มีปริมาณการใช้งานต่ำกว่า พาร์ทเนอร์ที่กังวลว่าลักษณะที่ใช้ไม่เต็มประสิทธิภาพจะทำให้คะแนนลดลงสามารถมั่นใจได้ว่าลักษณะที่ใช้ไม่บ่อยจะได้รับการปกป้องโดยอัตโนมัติด้วยการตรวจสอบปริมาณการเข้าชมขั้นต่ำ และจะไม่นำมาพิจารณาในคะแนนประเภทและลักษณะต่ำสุด เว้นแต่จะเป็นไปตามเกณฑ์ตัวอย่างที่กำหนด

3. การปรับปรุงประสิทธิภาพการทำงานของอุปกรณ์และความแม่นยำของสถานะ

ความคลาดเคลื่อนจะเกิดขึ้นเมื่อสถานะที่จัดเก็บไว้ใน 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 และคำขอ Report State สำหรับอุปกรณ์เดียวกันนั้นแตกต่างกัน

วิธีแก้ไข: ตรวจสอบว่าโครงสร้างข้อมูลเหมือนกันในทั้ง 2 เส้นทาง หากลักษณะรวมอยู่ใน 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 และค่า Report State ล่าสุดไม่ตรงกัน

วิธีแก้ไข: ตรวจสอบว่ามีการเรียกใช้ Report State ทุกครั้งที่สถานะอุปกรณ์เปลี่ยนแปลง และทั้ง Report State และ 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 ระบบไม่ได้รับสถานะรายงานสำหรับอุปกรณ์นี้ (สถานะว่างเปล่าและการประทับเวลาที่รายงานอยู่ที่ Epoch) แม้ว่าผลลัพธ์ QUERY จะแสดงสถานะปัจจุบันก็ตาม ซึ่งบ่งชี้ว่าไม่มีการทริกเกอร์การอัปเดตสถานะ ไม่สามารถเข้าถึง HomeGraph หรืออุปกรณ์รายงานการเปลี่ยนแปลงสถานะการเชื่อมต่อหรือสถานะการทำงานไม่สำเร็จ

วิธีแก้ไข: ตรวจสอบว่ามีการทริกเกอร์และส่ง Report State เรียบร้อยแล้วสำหรับการเปลี่ยนแปลงสถานะทั้งหมด ยืนยันว่าตรรกะแบ็กเอนด์จัดการการอัปเดตสถานะอย่างถูกต้อง ยืนยันการส่งไปยัง Google HomeGraph สำเร็จ และตรวจสอบว่าอุปกรณ์ซิงค์สถานะอย่างสม่ำเสมอเพื่อให้อินเทอร์เฟซผู้ใช้และเครื่องมือการทำงานอัตโนมัติถูกต้อง