ชุดแดชบอร์ดและการแจ้งเตือนนี้ช่วยให้คุณรักษาการผสานรวมกับระบบนิเวศของ Google Home ให้มีคุณภาพสูงได้อย่างเชิงรุก Google มุ่งมั่นที่จะสนับสนุนพาร์ทเนอร์ในการพัฒนาระบบนิเวศคุณภาพสูงสำหรับลูกค้าทุกคน
แดชบอร์ดมี 3 ส่วน โดยแต่ละส่วนครอบคลุมส่วนสำคัญที่มีส่วนช่วยให้การผสานรวมโดยรวมมีคุณภาพ
เมตริกจาก Google ไปยังพาร์ทเนอร์ - วัดประสิทธิภาพการเรียกใช้จาก Google ไปยัง แบ็กเอนด์ระบบคลาวด์ของคุณ
ประสิทธิภาพของระบบ - เมตริกจากพาร์ทเนอร์ไปยัง Google - วัดประสิทธิภาพการเรียกใช้ จากระบบของคุณไปยัง Google
ประสิทธิภาพของอุปกรณ์ - ความแม่นยำของสถานะ - วัดความแม่นยำของสถานะที่จัดเก็บไว้ ในระบบของ Google ซึ่งใช้เพื่อแสดงผลการค้นหาของผู้ใช้
เมื่อเมตริกไม่เป็นไปตามค่าเป้าหมาย ระบบจะไฮไลต์เมตริกเป็นสีแดงเพื่อบ่งบอกถึงปัญหาที่อาจส่งผลต่อประสบการณ์ของผู้ใช้ ข้อมูลต่อไปนี้จะให้รายละเอียดเกี่ยวกับเป้าหมายแต่ละรายการและเหตุผลที่เป้าหมายเหล่านั้นมีความสำคัญต่อผู้ใช้
หากปุ่มต่อไปนี้ไม่นำคุณไปยังแดชบอร์ดโดยตรง คุณสามารถไปที่แดชบอร์ดได้โดยเลือกหน้าภาพรวม เลือกแดชบอร์ด แล้วเลือก แดชบอร์ด Google Home Vitals (Cloud) จากรายการแดชบอร์ดของฉัน เพื่อดูแดชบอร์ด
เมตริกจาก Google ไปยังพาร์ทเนอร์
เมตริกอัตราความสำเร็จของการค้นหา/การดำเนินการ >= 99.5% จะวัดความถี่ที่คำสั่งของผู้ใช้ได้รับการดำเนินการอย่างถูกต้อง ซึ่งช่วยหลีกเลี่ยงการตอบกลับของ Assistant เช่น "ฉันเข้าถึงอุปกรณ์ไม่ได้" หรือการยืนยันคำสั่งที่ไม่ได้ดำเนินการอย่างไม่ถูกต้อง
อะไรคือสิ่งที่กำหนดว่า "สำเร็จ"
ระบบจะทำเครื่องหมายธุรกรรมว่าสำเร็จหากแพลตฟอร์ม Google Home ได้รับการตอบกลับที่ถูกต้องซึ่งบ่งบอกว่ามีการดำเนินการตามที่ต้องการหรือมีการดึงข้อมูลสถานะที่ขอ
การตอบกลับที่มีข้อยกเว้นที่ไม่บล็อก (เช่น สถานะ SUCCESS พร้อมด้วยข้อยกเว้น lowBattery) จะถูกนับเป็นธุรกรรมที่สำเร็จ
คำสั่งไปถึงอุปกรณ์และมีการดำเนินการตามความตั้งใจ แม้จะมีคำเตือนก็ตาม
อะไรคือสิ่งที่กำหนดว่า "ล้มเหลว"
ข้อผิดพลาดที่พบใน รหัสข้อผิดพลาดของแพลตฟอร์มทั่วไป ซึ่งทำเครื่องหมายเป็น พาร์ทเนอร์ดำเนินการได้ จะถือเป็น "ความล้มเหลว" เมื่อ คำนวณอัตราความสำเร็จของการค้นหาและการดำเนินการ นอกจากนี้ ข้อผิดพลาดที่พบ ใน ข้อผิดพลาดและข้อยกเว้น จะถือเป็น "ความล้มเหลว" ด้วย ยกเว้นกรณีต่อไปนี้
| ข้อยกเว้นของความล้มเหลว | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | offline |
| alreadyInState | deviceJammingDetected | percentOutOfRange |
| alreadyLocked | deviceNotMounted | rangeTooClose |
| alreadyOff | deviceNotReady | relinkRequired |
| alreadyOn | deviceOffline | remoteSetDisabled |
| alreadyOpen | deviceTurnedOff | safetyShutOff |
| alreadyPaused | discreteOnlyOpenClose | targetAlreadyReached |
| alreadyStarted | functionNotSupported | tooManyFailedAttempts |
| alreadyStopped | inAutoMode | valueOutOfRange |
| alreadyUnlocked | inEcoMode |
เมตริกเวลาในการตอบสนองต่อการค้นหา/การดำเนินการ (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 กับระบบคลาวด์ของคุณ เมตริกนี้ไม่ได้วัดเวลาที่ฮาร์ดแวร์จริง (เช่น หลอดไฟ) ใช้ในการเปลี่ยนสถานะทางกายภาพให้เสร็จสมบูรณ์ เนื่องจากมักเกี่ยวข้องกับเวลาในการตอบสนองของเครือข่ายที่ทำงานร่วมกันในพื้นที่นอกเส้นทางจากระบบคลาวด์ไปยังระบบคลาวด์
ตัวเลือกการลดเวลาในการตอบสนอง
คำแนะนำด้านสถาปัตยกรรมสำหรับการกำหนดเส้นทางตามภูมิศาสตร์
หากการติดตั้งใช้งาน Anycast IP ไม่สามารถทำได้ เราขอแนะนำทางเลือกที่มีประสิทธิภาพด้านต้นทุนต่อไปนี้เพื่อให้มั่นใจว่าผู้ใช้จะได้รับบริการจากศูนย์ข้อมูลระดับภูมิภาคที่ใกล้ที่สุด
Global Load Balancing (GLB)
ใช้ Global Application Load Balancer (มีให้บริการจากผู้ให้บริการระบบคลาวด์รายใหญ่ส่วนใหญ่) แทนการกำหนดเส้นทางแบบคงที่
วิธีการทำงาน: คุณกำหนดค่าจุดแรกเข้าส่วนกลาง (URL) เพียงจุดเดียวที่อยู่บริเวณขอบของเครือข่าย ตัวจัดสรรภาระงานจะตรวจหาแหล่งที่มาทางภูมิศาสตร์ของคำขอจากคลัสเตอร์การดำเนินการของ Google โดยอัตโนมัติ และกำหนดเส้นทางการเข้าชมไปยังแบ็กเอนด์ระดับภูมิภาคที่ใช้งานได้ใกล้ที่สุด
ข้อดี: วิธีนี้ให้ประสิทธิภาพของ Anycast โดยมีความซับซ้อนในการกำหนดค่าและต้นทุนที่ต่ำกว่าอย่างมาก
DNS ที่รับรู้ตำแหน่งทางภูมิศาสตร์ (GeoDNS)
วิธีการทำงาน: กำหนดค่าผู้ให้บริการ DNS ให้แปลง URL การดำเนินการเป็นที่อยู่ IP ต่างๆ ตามสถานที่ตั้งทางภูมิศาสตร์ของคำขอ DNS
การติดตั้งใช้งาน: ตรวจสอบว่าผู้ให้บริการ DNS ได้รับการเพิ่มประสิทธิภาพสำหรับจุดขาออกของ Google เมื่อบริการการดำเนินการระดับภูมิภาคของ Google (เช่น ในสหรัฐอเมริกา สหภาพยุโรป หรือเอเชีย) แปลงโดเมนของคุณ ระบบจะได้รับที่อยู่ IP สำหรับศูนย์ข้อมูลในภูมิภาคนั้นๆ
กลยุทธ์การเพิ่มประสิทธิภาพที่เลเยอร์แอปพลิเคชัน
นอกเหนือจากการกำหนดเส้นทางระดับโครงสร้างพื้นฐานแล้ว คุณยังสามารถใช้กลยุทธ์ต่อไปนี้ที่เลเยอร์แอปพลิเคชันเพื่อลดเวลาในการตอบสนองในการประมวลผลคำขอ
วิธีการพร็อกซีแบบ "แทรมโพลีน"
หากคุณต้องดูแลศูนย์ข้อมูลหลัก ให้ใช้เซิร์ฟเวอร์พร็อกซีแบบเบา (แทรมโพลีน) ระดับภูมิภาคเพื่อจัดการการเริ่มต้นการเชื่อมต่อ
Google เข้าถึง URL ส่วนกลางของคุณ
พร็อกซีระดับภูมิภาค (เช่น ฟังก์ชัน Nginx หรือ Lambda แบบเบา) ได้รับคำขอ
พร็อกซีส่งต่อเพย์โหลดผ่านแบ็กโบนภายในความเร็วสูงไปยังฐานข้อมูลหลัก
ข้อดี: วิธีนี้ช่วยลดเวลา "การเริ่มต้นการเชื่อมต่อ TCP" ซึ่งมักเป็นปัจจัยที่ทำให้เกิดเวลาในการตอบสนองมากที่สุดสำหรับคำขอระยะไกล
คำแนะนำเกี่ยวกับภูมิภาคของโทเค็นเพื่อการเข้าถึง
ในระหว่างกระบวนการลิงก์บัญชี (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 (ยังไม่ได้ซิงค์ ยกเลิกการลิงก์แล้ว หรือรหัสไม่ตรงกัน)
วิธีแก้ไข
- ตรวจสอบว่า
agentUserIdตรงกับค่าที่ระบุในการตอบกลับ SYNC - ใช้ Home Graph SYNC API เพื่อตรวจสอบว่าข้อผิดพลาด 404 ไม่พบเกิดจากไม่มีอุปกรณ์ หรือผู้ใช้ใน HomeGraph
- อย่าลืมทริกเกอร์
requestSyncหลังจากเพิ่ม นำออก เปลี่ยนชื่อ หรืออัปเดตอุปกรณ์หรือบัญชีเพื่อให้สถานะ เป็นข้อมูลล่าสุด - จัดการ Intent
DISCONNECTอย่างเหมาะสม เพื่อหยุดการรายงานอุปกรณ์ที่ล้าสมัย หลังจากได้รับ IntentDISCONNECTแล้ว บริการระบบคลาวด์ของคุณควรหยุดเผยแพร่การเปลี่ยนแปลงไปยัง Google ด้วย Request Sync และ Report State
429 ทรัพยากรหมดแล้ว
สาเหตุ: การผสานรวมของคุณใช้โควต้าที่จัดสรรไว้เกิน
วิธีแก้ไข: ดูวิธีการในส่วน "ขั้นตอนที่ 2ก: แก้ไขข้อผิดพลาดเกี่ยวกับโควต้า" ในแดชบอร์ดสำหรับการจัดการโควต้า นอกจากนี้ คุณยังดูข้อมูลเพิ่มเติมได้ที่ โควต้าและขีดจำกัดของ Smart Home
ประสิทธิภาพของอุปกรณ์ - ความแม่นยำของสถานะ
การมีความแม่นยำของสถานะ >= 99.5% หรือสูงกว่าช่วยให้มั่นใจว่าผู้ใช้จะเห็นผลลัพธ์ที่ถูกต้องเมื่อดูสถานะอุปกรณ์หรือใช้ฟีเจอร์ AI เช่น ถาม Google Home หากความแม่นยำของสถานะต่ำ ระบบอัตโนมัติอาจไม่ทำงานและรายการประวัติอาจไม่ ปรากฏในแท็บกิจกรรมของ GHA ในเวลาที่ถูกต้อง ดูข้อมูลเพิ่มเติมได้ที่ รายงานสถานะ
แดชบอร์ดคุณภาพจะติดตามข้อมูลนี้ทุกชั่วโมงโดยใช้เมตริก 2 รายการที่แตกต่างกัน ได้แก่ ความแม่นยำโดยรวม และการผสมผสานประเภท/ลักษณะที่ต่ำที่สุด
1. คอมโพเนนต์ความแม่นยำ
เมตริกนี้ได้มาจาก "ตัวอย่าง" ที่ Google สามารถยืนยันสถานะที่รายงานกับผลลัพธ์ของ Intent ที่ทราบ
2. เมตริกแดชบอร์ด (การคำนวณรายชั่วโมง)
แดชบอร์ดจะคำนวณความแม่นยำตามช่วงเวลา 1 ชั่วโมง หากชั่วโมงใดมีตัวอย่างทั้งหมดน้อยกว่า 100 รายการ (S_Total < 100) ระบบจะตั้งค่าความแม่นยำสำหรับชั่วโมงนั้นเป็น N/A
มุมมองที่ 1: ความแม่นยำโดยรวม (ค่าเฉลี่ยทั่วโลก)
แสดงถึงความแม่นยำทั้งหมดของการผสานรวมในอุปกรณ์ทุกประเภทและลักษณะที่รวมกัน แสดงค่าเฉลี่ยถ่วงน้ำหนักของประสิทธิภาพของระบบนิเวศทั้งหมด
- การคำนวณ: ความแม่นยำของสถานะทั้งหมดในอุปกรณ์ทุกเครื่อง / สถานะทั้งหมด ในอุปกรณ์ทุกเครื่อง
มุมมองที่ 2: การผสมผสานประเภท/ลักษณะที่ต่ำที่สุด
ระบุหมวดหมู่เฉพาะที่เชื่อถือได้น้อยที่สุดในการผสานรวม ป้องกันไม่ให้อุปกรณ์ที่มีปริมาณมากซึ่งมีคุณภาพสูงซ่อนอุปกรณ์ที่มีปริมาณน้อยซึ่งมีคุณภาพต่ำ ตัวอย่างเช่น หากคุณมีไฟจำนวนมากที่มีความแม่นยำของสถานะสูงกว่า 99.5% แต่มีสวิตช์จำนวนน้อยที่มีความแม่นยำของสถานะต่ำ มุมมองนี้จะไฮไลต์การปรับปรุงที่จำเป็นสำหรับสวิตช์ซึ่งอาจหายไปในค่าเฉลี่ย
- การคำนวณ: ค่าต่ำสุดของความแม่นยำของสถานะ / สถานะทั้งหมดสำหรับการผสมผสานลักษณะ/อุปกรณ์ ทั้งหมด
3. การปรับปรุงประสิทธิภาพของอุปกรณ์และความแม่นยำของสถานะ
ความคลาดเคลื่อนเกิดขึ้นเมื่อสถานะที่จัดเก็บไว้ใน Home Graph ไม่ตรงกับผลลัพธ์ของการค้นหาแบบเรียลไทม์
ข้อผิดพลาด "ไม่มีช่อง"
ตัวอย่าง DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD
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" }
ตัวอย่าง DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD
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 ช่องที่เกี่ยวข้องจะต้องมีอยู่และสอดคล้องกันทั้งในรายงานเชิงรุกและการค้นหาเชิงรับ
ข้อผิดพลาด "ไม่ถูกต้อง"
ตัวอย่าง DETAILED_ACCURACY_RESULT_INACCURATE
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 จะให้ค่าที่เป็นข้อมูลล่าสุดและเหมือนกันทุกประการ รวมถึงมีช่องที่จำเป็นทั้งหมดเพื่อรักษาความสอดคล้องของข้อมูล
ตัวอย่าง DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE
"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 ได้รับสถานะอุปกรณ์ใหม่
ตัวอย่าง DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED
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 จะแสดงสถานะปัจจุบันก็ตาม
ข้อผิดพลาดนี้บ่งบอกว่าการอัปเดตสถานะไม่ได้รับการทริกเกอร์ ไม่สามารถเข้าถึง HomeGraph หรืออุปกรณ์รายงานการเปลี่ยนแปลงในการเชื่อมต่อหรือสถานะการทำงานไม่สำเร็จ
วิธีแก้ไข: ตรวจสอบว่าระบบจะทริกเกอร์และส่ง Report State สำหรับการเปลี่ยนแปลงสถานะทั้งหมดได้สำเร็จ ตรวจสอบว่าตรรกะแบ็กเอนด์จัดการการอัปเดตสถานะอย่างถูกต้อง ยืนยันการส่งข้อมูลไปยัง Google HomeGraph ได้สำเร็จ และตรวจสอบว่าอุปกรณ์ซิงค์สถานะอย่างสม่ำเสมอเพื่อให้ UI และกลไกการทำงานอัตโนมัติมีความถูกต้อง