Rangkaian dasbor dan pemberitahuan ini membantu Anda secara proaktif mempertahankan integrasi berkualitas tinggi dengan ekosistem Google Home. Google berkomitmen untuk mendukung partner dalam mengembangkan ekosistem berkualitas tinggi bagi semua pelanggan
Dasbor ini memiliki tiga bagian, yang masing-masing mencakup bagian penting yang berkontribusi pada kualitas integrasi secara keseluruhan.
Metrik Partner ke Google - Mengukur kualitas panggilan dari Google ke backend cloud Anda.
Kesehatan Sistem - Metrik Partner ke Google - Mengukur kesehatan panggilan dari sistem Anda ke Google.
Kesehatan Perangkat - Akurasi Status - Mengukur akurasi status yang disimpan dalam sistem Google, yang digunakan untuk menayangkan kueri pengguna.
Jika metrik tidak memenuhi nilai targetnya, metrik tersebut akan ditandai dengan warna merah untuk menunjukkan masalah yang dapat memengaruhi pengalaman pengguna. Informasi berikut memberikan detail tentang setiap target dan alasan pentingnya bagi pengguna Anda.
Jika tombol berikut tidak mengarahkan Anda langsung ke dasbor, Anda dapat membukanya dengan memilih halaman Ringkasan, memilih Dasbor, lalu dari daftar Dasbor Saya, pilih Dasbor Data Penting Google Home (Cloud) untuk melihat dasbor Anda.
Metrik Google untuk Partner
Metrik Tingkat Keberhasilan Kueri/Eksekusi >= 99,5% mengukur seberapa sering perintah pengguna dipenuhi dengan benar, yang membantu menghindari respons Asisten seperti "Saya tidak dapat menjangkau perangkat" atau salah mengonfirmasi perintah yang tidak dipenuhi.
Apa yang menentukan "Keberhasilan"?
Transaksi ditandai sebagai berhasil jika platform Google Home menerima respons yang valid yang menunjukkan bahwa tindakan yang dimaksud telah dilakukan atau status yang diminta telah diambil.
Respons yang mencakup pengecualian non-pemblokiran (misalnya, status SUCCESS
yang disertai dengan pengecualian lowBattery) dihitung sebagai transaksi yang berhasil.
Perintah mencapai perangkat dan maksudnya terpenuhi meskipun ada peringatan.
Apa yang mendefinisikan "Kegagalan"?
Error yang ditemukan di Kode error platform umum yang ditandai sebagai Dapat Ditindaklanjuti Partner dianggap sebagai "Kegagalan" saat menghitung Tingkat Keberhasilan KUERI dan EKSEKUSI. Selain itu, error yang ditemukan di Error dan pengecualian juga merupakan "Kegagalan", dengan pengecualian berikut:
| Pengecualian kegagalan | ||
|---|---|---|
| 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 |
Metrik Latensi Kueri/Eksekusi (p90) <= 1000 md mengukur waktu tunggu tindakan yang diminta dan membantu memastikan pengguna tidak perlu menunggu terlalu lama, misalnya, menunggu beberapa detik hingga lampu mereka mati.
Metrik latensi
Latensi adalah indikator penting tentang seberapa responsif integrasi Anda terhadap pengguna akhir. Dasbor melacak Latensi Persentil ke-90 (P90), yang mewakili pengalaman pengguna "paling lambat" (misalnya, P90 800 md berarti 90% permintaan diakui dalam 800 md atau kurang).
Google mengukur latensi secara berbeda untuk pemeriksaan status dan perintah perangkat guna memastikan akurasi teknis.
1. Latensi QUERY (Interogatif)
Ini mengukur waktu perjalanan pulang pergi Cloud-to-cloud saat Google meminta status perangkat saat ini.
- Mulai: Google mengirimkan permintaan
action.devices.QUERYke URL pemenuhan Anda. - Jendela Pengukuran: Waktu yang diperlukan agar cloud Anda menerima, memproses, dan mengirimkan kembali respons HTTP lengkap ke Google.
- Akhir: Google menerima dan mengonfirmasi payload respons akhir dari layanan Anda.
2. Latensi EKSEKUSI (Tindakan)
Metrik ini mengukur waktu konfirmasi perintah saat Google mengirim permintaan kontrol ke perangkat.
- Mulai: Google mengirimkan permintaan
action.devices.EXECUTEke URL pemenuhan Anda. - Jendela Pengukuran: Waktu yang diperlukan agar cloud Anda menerima perintah dan mengembalikan respons konfirmasi.
- Akhir: Google menerima respons status
SUCCESS,PENDING, atauOFFLINE. - Cakupan Teknis: Metrik ini mengukur waktu "Penerimaan Respons" antara cloud Google dan cloud Anda. Metrik ini tidak mengukur waktu yang diperlukan hardware fisik (misalnya, bohlam) untuk menyelesaikan perubahan status fisik, karena sering kali melibatkan latensi jaringan mesh lokal di luar jalur cloud-ke-cloud.
Opsi pengurangan latensi
Rekomendasi arsitektur untuk geo-routing
Jika penerapan IP Anycast tidak memungkinkan, sebaiknya gunakan alternatif hemat biaya berikut untuk memastikan pengguna dilayani oleh pusat data regional terdekat.
Load Balancing Global (GLB)
Daripada menggunakan perutean statis, gunakan Load Balancer Aplikasi Global (tersedia dari sebagian besar penyedia cloud utama).
Cara kerjanya: Anda mengonfigurasi satu titik entri global (URL) yang berada di tepi jaringan. Load balancer otomatis mendeteksi asal geografis permintaan dari cluster pemenuhan Google dan merutekan traffic ke backend responsif regional terdekat.
Manfaat: Opsi ini memberikan performa Anycast dengan biaya dan kompleksitas konfigurasi yang jauh lebih rendah.
DNS yang Mendeteksi Lokasi Geografis (GeoDNS)
Cara kerjanya: Konfigurasi penyedia DNS Anda untuk menyelesaikan URL pemenuhan ke alamat IP yang berbeda berdasarkan lokasi geografis kueri DNS.
Penerapan: Pastikan penyedia DNS Anda dioptimalkan untuk titik keluar Google. Saat layanan pemenuhan regional Google (misalnya, di Amerika Serikat, Uni Eropa, atau Asia) menyelesaikan domain Anda, layanan tersebut akan menerima alamat IP untuk pusat data di wilayah tertentu tersebut.
Strategi pengoptimalan di lapisan aplikasi
Selain perutean tingkat infrastruktur, Anda dapat menerapkan strategi berikut di lapisan aplikasi untuk mengurangi latensi dalam pemrosesan permintaan.
Metode Proxy "Trampoline"
Jika Anda harus mempertahankan pusat data utama, gunakan server proxy ringan regional (Trampolin) untuk menangani handshake awal.
Google mengakses URL global Anda.
Proxy regional (misalnya, fungsi Nginx atau Lambda ringan) menerima permintaan.
Proxy meneruskan payload melalui backbone internal berkecepatan tinggi ke database utama.
Manfaat: Hal ini mengurangi waktu "TCP Handshake", yang sering kali menjadi penyebab terbesar latensi untuk permintaan jarak jauh.
Petunjuk Region Token Akses
Selama proses Penautan Akun (OAuth), sistem Anda dapat mengidentifikasi wilayah rumah pengguna.
Penerapan: Enkode ID wilayah ke dalam
access_tokenyang dikeluarkan untuk Google. Saat Google mengirimkan permintaan pemenuhan, gateway Anda dapat segera memeriksa token dan merutekan permintaan ke cluster regional yang benar tanpa memerlukan pencarian database.
Kesehatan Sistem - Metrik Partner ke Google
Mempertahankan Tingkat Keberhasilan >= 99,5% membantu memastikan bahwa status perangkat benar di Google Home, perangkat ditambahkan dan dihapus, otomatisasi dipicu, dan peristiwa histori muncul di tab Aktivitas Google Home app (GHA).
Tingkat Keberhasilan dihitung berdasarkan kode respons HTTP yang ditampilkan oleh Google saat cloud Anda mengirimkan update status. Untuk memastikan partner tidak dihukum karena masalah infrastruktur di sisi Google, metrik ini mengecualikan error internal Google dari jumlah kegagalan. Panggilan API yang disertakan dalam penghitungan dapat ditemukan di referensi HomeGraph API.
Apa yang menentukan "Keberhasilan"?
2xx (Berhasil): Pembaruan status berhasil diterima dan diproses oleh HomeGraph.
Apa yang mendefinisikan "Kegagalan"?
Error 4xx (Error Partner) menunjukkan kegagalan dan mengindikasikan masalah pada permintaan yang dikirim dari cloud Anda. Kode umum meliputi:
400 Bad Request (400 Permintaan Tidak Valid)
Penyebab: Server tidak dapat memproses permintaan karena sintaksis tidak valid. Penyebab umumnya mencakup JSON yang salah format atau menggunakan null, bukan "" untuk nilai string.
Solusi: Pastikan isi permintaan adalah JSON yang valid (tidak ada struktur yang salah bentuk atau nilai null untuk kolom string), dan verifikasi bahwa agentUserId cocok dengan nilai dari respons SYNC.
404 Tidak Ditemukan
Penyebab: deviceId atau agentUserId tidak ditemukan di HomeGraph (belum disinkronkan,
sudah dibatalkan tautannya, atau ID tidak cocok).
Solusi:
- Pastikan
agentUserIdcocok dengan nilai yang diberikan dalam respons SYNC. - Gunakan Home Graph SYNC API untuk menentukan apakah error 404 Not Found disebabkan oleh perangkat atau pengguna yang tidak ada di HomeGraph.
- Pastikan untuk memicu
requestSyncsetelah perangkat atau akun ditambahkan, dihapus, diganti namanya, atau diperbarui untuk memastikan status tetap terbaru. - Menangani intent
DISCONNECTdengan benar untuk menghentikan pelaporan perangkat yang tidak aktif. Setelah menerima maksudDISCONNECT, layanan cloud Anda harus berhenti memublikasikan perubahan ke Google dengan Minta Sinkronisasi dan Laporkan Status.
429 Resource Habis
Penyebab: Integrasi Anda telah melampaui kuota yang dialokasikan.
Solusi: Lihat petunjuk di bagian "Langkah 2a: Debug Masalah Kuota" di dasbor untuk pengelolaan kuota. Anda juga dapat melihat Kuota dan batas Smart Home untuk mengetahui informasi selengkapnya.
Kondisi Perangkat - Akurasi status
Memenuhi atau melampaui Akurasi Status >= 99,5% membantu memastikan pengguna melihat hasil yang benar saat mereka melihat status perangkat atau menggunakan fitur AI seperti Tanya Rumah. Jika akurasi status rendah, otomatisasi mungkin tidak berjalan dan entri histori mungkin tidak muncul di tab Aktivitas GHA pada waktu yang tepat. Untuk mengetahui informasi selengkapnya, lihat Status Laporan.
Dasbor kualitas melacaknya setiap jam menggunakan dua metrik yang berbeda: Akurasi Keseluruhan dan Kombinasi Tipe/Ciri Terendah.
1. Komponen Akurasi
Metrik ini berasal dari "sampel" tempat Google dapat memverifikasi status yang dilaporkan terhadap hasil maksud yang diketahui.
2. Metrik Dasbor (Penghitungan Per Jam)
Dasbor menghitung akurasi berdasarkan interval 1 jam. Jika dalam satu jam terdapat kurang dari 100 total sampel (S_Total < 100), akurasi untuk jam tersebut ditetapkan ke N/A.
Tampilan 1: Akurasi Keseluruhan (Rata-Rata Global)
Hal ini menunjukkan total akurasi integrasi Anda di semua jenis perangkat dan gabungan karakteristik. Metrik ini memberikan rata-rata tertimbang dari kesehatan seluruh ekosistem Anda.
- Penghitungan: Akurasi Total Status di semua perangkat / Total Status Total di semua perangkat.
Tampilan 2: Kombinasi Tipe/Ciri Terendah
Hal ini mengidentifikasi kategori spesifik yang paling tidak dapat diandalkan dalam integrasi Anda. Hal ini mencegah perangkat bervolume tinggi yang berkualitas tinggi menyembunyikan perangkat bervolume rendah yang berkualitas rendah. Misalnya, jika Anda memiliki volume tinggi lampu dengan Akurasi Status di atas 99,5%, tetapi volume rendah Sakelar dengan Akurasi Status rendah, hal ini menunjukkan peningkatan yang diperlukan pada sakelar yang mungkin hilang dalam nilai rata-rata.
- Penghitungan: Minimum Akurasi Status / Total Status untuk semua kombinasi perangkat/trait.
3. Meningkatkan Akurasi Status & Kondisi Perangkat
Perbedaan terjadi saat status yang disimpan di Home Graph tidak cocok dengan hasil QUERY real time.
Error "Kolom Tidak Ada"
Contoh 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" }
Contoh 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" }
Penyebab: Dengan error DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD atau
DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD, kumpulan kolom
payload berbeda antara respons QUERY dan permintaan Report State untuk
perangkat yang sama.
Solusi: Pastikan struktur data sama di kedua jalur. Jika trait disertakan dalam SYNC, kolom yang sesuai harus ada dan konsisten dalam laporan proaktif dan kueri reaktif.
Error "Tidak Akurat"
Contoh 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" }
Penyebab: Untuk error DETAILED_ACCURACY_RESULT_INACCURATE, ada
perbedaan antara nilai yang ditampilkan dalam respons QUERY dan nilai Status Pelaporan terakhir.
Solusi: Pastikan Status Laporan dipicu setiap kali status perangkat berubah dan bahwa Status Laporan serta QUERY selalu memberikan nilai yang sama persis dan terbaru serta semua kolom yang diperlukan untuk menjaga konsistensi data.
Contoh 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" }
Penyebab: Dengan error DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE, partner berhasil menjalankan perintah, tetapi tidak melaporkan kembali status perangkat yang diperbarui ke Google.
Solusi: Selalu kirim update Report State setelah eksekusi perintah sehingga Home Graph menerima status perangkat baru.
Contoh 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" }
Penyebab: Untuk error DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED, tidak ada Report
State yang diterima untuk perangkat ini (status kosong dan stempel waktu yang dilaporkan
berada di epoch), meskipun hasil QUERY memberikan status saat ini.
Hal ini menunjukkan bahwa update status tidak dipicu, gagal mencapai HomeGraph, atau perangkat tidak berhasil melaporkan transisi dalam konektivitas atau status operasionalnya.
Solusi: Pastikan Report State dipicu dan berhasil dikirim untuk semua perubahan status. Pastikan logika backend menangani update status dengan benar, mengonfirmasi keberhasilan pengiriman ke Google HomeGraph, dan memastikan perangkat terus menyinkronkan statusnya agar antarmuka pengguna dan mesin otomatisasi akurat.