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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เวลาในการตอบสนองเป็นตัวบ่งชี้ที่สำคัญว่าการผสานรวมของคุณตอบสนองต่อ ผู้ใช้ปลายทางได้ดีเพียงใด แดชบอร์ดจะติดตามเวลาในการตอบสนองเปอร์เซ็นไทล์ที่ 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 การจัดการคำสั่งซื้อ
• กรอบเวลาการวัดผล: เวลาที่ใช้สำหรับระบบคลาวด์ในการรับคำสั่งและ ส่งการตอบกลับเพื่อรับทราบ
• สิ้นสุด: Google ได้รับการตอบกลับสถานะ SUCCESS, PENDING หรือ OFFLINE
• ขอบเขตทางเทคนิค: เมตริกนี้จะวัดเวลา "การรับทราบการตอบกลับ" ระหว่างระบบคลาวด์ของ Google กับระบบคลาวด์ของคุณ โดยจะไม่วัดเวลาที่ฮาร์ดแวร์จริง (เช่น หลอดไฟ) ใช้ในการเปลี่ยนสถานะจริง เนื่องจากมักเกี่ยวข้องกับเวลาในการตอบสนองของเครือข่ายที่ทำงานร่วมกันในพื้นที่ที่อยู่นอกเส้นทางจากระบบคลาวด์ไปยังระบบคลาวด์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

วิธีแก้ไข

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

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

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

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

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

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

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

1. องค์ประกอบความแม่นยำ

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

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

แดชบอร์ดจะคำนวณความแม่นยำตามช่วงเวลา 1 ชั่วโมง หากชั่วโมงใดมีตัวอย่างรวมน้อยกว่า 100 รายการ (S_Total < 100) ความแม่นยำของชั่วโมงนั้นจะตั้งค่าเป็น N/A

มุมมองที่ 1: ความแม่นยำโดยรวม (ค่าเฉลี่ยทั่วโลก)

ซึ่งแสดงถึงความแม่นยำโดยรวมของการผสานรวมในอุปกรณ์ทุกประเภท และลักษณะที่รวมกัน โดยจะแสดงค่าเฉลี่ยแบบถ่วงน้ำหนักของสถานะ ทั้งระบบนิเวศ

• การคำนวณ: ความแม่นยำของสถานะทั้งหมดในอุปกรณ์ทุกเครื่อง / สถานะทั้งหมดทั้งหมด ในอุปกรณ์ทุกเครื่อง

มุมมอง 2: ชุดค่าผสมประเภท/ลักษณะที่ต่ำที่สุด

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

• การคำนวณ: ความแม่นยำของรัฐ / รัฐทั้งหมดขั้นต่ำสำหรับชุดค่าผสมลักษณะ/อุปกรณ์ทั้งหมด

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

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

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

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