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

อะไรคือตัวกำหนด "ความล้มเหลว"

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

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

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

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

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

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

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

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

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

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

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

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

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

การแบ่งตามไทม์ไลน์ของเวลาในการตอบสนองของการดำเนินการ/การค้นหา

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Global Load Balancing (GLB)

   ใช้ Global Application Load Balancer (มีให้บริการจากผู้ให้บริการระบบคลาวด์รายใหญ่ส่วนใหญ่) แทนการกำหนดเส้นทางแบบคงที่

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

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

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

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

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

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

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

1. วิธีการพร็อกซีแบบ "แทรมโพลีน"

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

   1. Google เข้าถึง URL ส่วนกลางของคุณ

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

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

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

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 ไม่พบ

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

วิธีแก้ไข

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

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

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

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

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

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

1. คอมโพเนนต์ความแม่นยำ

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

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

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

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

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

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

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

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

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

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

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

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

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

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