Google Home Vitals (Cloud)

Serangkaian dasbor dan pemberitahuan ini membantu Anda mempertahankan integrasi berkualitas tinggi dengan ekosistem Google Home secara proaktif. 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.

  1. Metrik Google untuk Partner - Mengukur kondisi panggilan dari Google ke backend cloud Anda.

  2. Kondisi Sistem - Metrik Partner untuk Google - Mengukur kondisi panggilan dari sistem Anda ke Google.

  3. Kondisi 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 target tersebut penting bagi pengguna Anda.

Jika tombol berikut tidak mengarahkan Anda langsung ke dasbor, Anda dapat mengaksesnya dengan memilih halaman Ringkasan , memilih Dasbor , lalu dari daftar Dasbor Saya , pilih Dasbor Vitalitas Google Home (Cloud) untuk melihat dasbor Anda.

Buka Dasbor

Metrik Google untuk Partner

Metrik Rasio Keberhasilan Kueri/Eksekusi >= 99,5% mengukur seberapa sering perintah pengguna dipenuhi dengan benar, yang membantu menghindari respons Asisten seperti "Saya tidak dapat menghubungi perangkat" atau mengonfirmasi perintah yang tidak dipenuhi dengan tidak benar.

Apa yang dimaksud dengan "Keberhasilan"?

Transaksi ditandai sebagai berhasil jika platform Google Home menerima respons yang valid yang menunjukkan bahwa tindakan yang dimaksud telah dipenuhi atau status yang diminta telah diambil.

Respons yang menyertakan pengecualian non-pemblokiran (misalnya, status SUCCESS yang disertai dengan pengecualian lowBattery) dihitung sebagai transaksi yang berhasil. Perintah berhasil mencapai perangkat dan tujuan terpenuhi meskipun ada peringatan.

Apa yang dimaksud dengan "Kegagalan"?

Error yang ditemukan di Kode error platform umum yang ditandai sebagai Tindakan Partner dianggap sebagai "Kegagalan" saat menghitung Rasio Keberhasilan QUERY dan EXECUTE. 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 agar lampu mereka mati.

Metrik latensi

Latensi adalah indikator penting tentang seberapa responsif integrasi Anda bagi pengguna akhir. Dasbor melacak Latensi Persentil ke-90 (P90), yang mewakili pengalaman pengguna "paling lambat" (misalnya, P90 sebesar 800 md berarti 90% permintaan diakui dalam waktu 800 md atau kurang).

Google mengukur latensi secara berbeda untuk pemeriksaan status dan perintah perangkat guna memastikan akurasi teknis.

1. Latensi QUERY (Interogatif)

Metrik ini mengukur waktu pulang pergi Cloud-to-cloud saat Google meminta status perangkat saat ini.

  • Mulai: Google mengirimkan permintaan action.devices.QUERY ke URL pemenuhan Anda.
  • Jendela Pengukuran: Waktu yang dibutuhkan cloud Anda untuk menerima, memproses, dan mengirimkan kembali respons HTTP lengkap ke Google.
  • Akhir: Google menerima dan mengakui payload respons akhir dari layanan Anda.

2. Latensi EXECUTE (Tindakan)

Metrik ini mengukur waktu pengakuan perintah saat Google mengirimkan permintaan kontrol ke perangkat.

  • Mulai: Google mengirimkan permintaan action.devices.EXECUTE ke URL pemenuhan Anda.
  • Jendela Pengukuran: Waktu yang dibutuhkan cloud Anda untuk menerima perintah dan menampilkan respons pengakuan.
  • Akhir: Google menerima respons status SUCCESS, PENDING, atau OFFLINE.
  • Cakupan Teknis: Metrik ini mengukur waktu "Pengakuan Respons" antara cloud Google dan cloud Anda. Metrik ini tidak mengukur waktu yang dibutuhkan hardware fisik (misalnya, bola lampu) untuk menyelesaikan perubahan status fisik, karena sering kali melibatkan latensi jaringan mesh lokal di luar jalur cloud-to-cloud.

Opsi pengurangan latensi

Rekomendasi arsitektur untuk perutean geografis

Jika penerapan IP Anycast tidak memungkinkan, sebaiknya gunakan alternatif hemat biaya berikut untuk memastikan pengguna dilayani oleh pusat data regional terdekat.

  1. Load Balancing Global (GLB)

    Daripada 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: Hal ini memberikan performa Anycast dengan kompleksitas dan biaya konfigurasi yang jauh lebih rendah.

  2. DNS yang Mendeteksi Lokasi Geografis (GeoDNS)

    • Cara kerjanya: Konfigurasi penyedia DNS Anda untuk me-resolve URL pemenuhan ke alamat IP yang berbeda berdasarkan lokasi geografis kueri DNS.

    • Implementasi: Pastikan penyedia DNS Anda dioptimalkan untuk titik keluar Google. Saat layanan pemenuhan regional Google (misalnya, di AS, Uni Eropa, atau Asia) me-resolve domain Anda, layanan tersebut akan menerima alamat IP untuk pusat data di wilayah tertentu.

Strategi pengoptimalan di lapisan aplikasi

Selain perutean tingkat infrastruktur, Anda dapat menerapkan strategi berikut di lapisan aplikasi untuk mengurangi latensi dalam pemrosesan permintaan.

  1. Metode Proxy "Trampoline"

    Jika Anda harus mempertahankan pusat data utama, gunakan server proxy regional ringan (Trampoline) untuk menangani handshake awal.

    1. Google mengakses URL global Anda.

    2. Proxy regional (misalnya, fungsi Nginx atau Lambda ringan) menerima permintaan.

    3. Proxy meneruskan payload melalui backbone internal berkecepatan tinggi ke database utama.

    Manfaat: Hal ini mengurangi waktu "TCP Handshake", yang sering kali menjadi kontributor terbesar latensi untuk permintaan jarak jauh.

  2. Petunjuk Region Token Akses

    Selama proses Penautan Akun (OAuth), sistem Anda dapat mengidentifikasi wilayah asal pengguna.

    Implementasi: Enkode ID region ke dalam access_token yang dikeluarkan ke Google. Saat Google mengirimkan permintaan pemenuhan, gateway Anda dapat langsung memeriksa token dan merutekan permintaan ke cluster regional yang benar tanpa memerlukan pencarian database.

Kondisi Sistem - Metrik Partner untuk Google

Mempertahankan Rasio Keberhasilan >= 99,5% membantu memastikan status perangkat benar di Google Home, perangkat ditambahkan dan dihapus, otomatisasi dipicu, dan peristiwa histori muncul di tab Aktivitas Google Home app (GHA).

Rasio Keberhasilan dihitung berdasarkan kode respons HTTP yang ditampilkan oleh Google saat cloud Anda mengirimkan update status. Untuk memastikan partner tidak dihukum karena masalah infrastruktur sisi Google, metrik ini mengecualikan error internal Google dari jumlah kegagalan. Panggilan API yang disertakan dalam perhitungan dapat ditemukan di referensi HomeGraph API.

Apa yang dimaksud dengan "Keberhasilan"?

2xx (Berhasil): Update status berhasil diterima dan diproses oleh Home Graph.

Apa yang dimaksud dengan "Kegagalan"?

4xx (Error Partner) menunjukkan kegagalan dan menunjukkan masalah pada permintaan yang dikirim dari cloud Anda. Kode umum mencakup:

400 Bad Request (400 Permintaan Tidak Valid)

Penyebab: Server tidak dapat memproses permintaan karena sintaksis tidak valid. Penyebab umum 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 format atau nilai null untuk kolom string), dan verifikasi bahwa agentUserId cocok dengan nilai dari respons SYNC.

404 Not Found (404 Tidak Ditemukan)

Penyebab: deviceId atau agentUserId tidak ditemukan di HomeGraph (belum disinkronkan, sudah dibatalkan tautannya, atau ID tidak cocok).

Solusi:

  1. Pastikan agentUserId cocok dengan nilai yang diberikan dalam respons SYNC Anda.
  2. Gunakan Home Graph SYNC API untuk menentukan apakah error 404 Not Found disebabkan oleh perangkat atau pengguna yang tidak ada di HomeGraph.
  3. Pastikan untuk memicu requestSync setelah perangkat atau akun ditambahkan, dihapus, diganti namanya, atau diperbarui untuk memastikan status tetap terbaru.
  4. Tangani intent DISCONNECT dengan benar untuk berhenti melaporkan perangkat yang tidak aktif. Setelah menerima intent DISCONNECT, layanan cloud Anda harus berhenti memublikasikan perubahan ke Google dengan Request Sync dan Report State.

429 Resource Exhausted (429 Resource Habis)

Penyebab: Integrasi Anda telah melampaui kuota yang dialokasikan.

Solusi: Lihat petunjuk di bagian "Langkah 2a: Men-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 Home. Jika akurasi status rendah, otomatisasi mungkin tidak akan berjalan dan entri histori mungkin tidak muncul di tab Aktivitas GHA's pada waktu yang tepat. Untuk mengetahui informasi selengkapnya, lihat Report State.

Dasbor kualitas melacak hal ini setiap jam menggunakan dua metrik yang berbeda: Akurasi Keseluruhan dan Kombinasi Jenis/Fitur Terendah.

1. Komponen Akurasi

Metrik ini berasal dari "sampel" tempat Google dapat memverifikasi status yang dilaporkan terhadap hasil intent yang diketahui.

2. Metrik Dasbor (Perhitungan Per Jam)

Dasbor menghitung akurasi berdasarkan interval 1 jam. Jika satu jam memiliki kurang dari 100 total sampel (S_Total < 100), akurasi untuk jam tersebut akan ditetapkan ke N/A.

Tampilan 1: Akurasi Keseluruhan (Rata-Rata Global)

Metrik ini mewakili total akurasi integrasi Anda di semua jenis dan fitur perangkat yang digabungkan. Metrik ini memberikan rata-rata tertimbang dari kondisi seluruh ekosistem Anda.

  • Perhitungan: Total Akurasi Status di semua perangkat / Total Status di semua perangkat.

Tampilan 2: Kombinasi Jenis/Fitur Terendah

Metrik ini mengidentifikasi kategori tertentu yang paling tidak dapat diandalkan dalam integrasi Anda. Metrik ini mencegah perangkat bervolume tinggi yang berkualitas tinggi menyembunyikan perangkat bervolume rendah yang berkualitas rendah. Misalnya, jika Anda memiliki lampu bervolume tinggi dengan Akurasi Status di atas 99,5%, tetapi Sakelar bervolume rendah dengan Akurasi Status rendah, hal ini akan menyoroti peningkatan yang diperlukan pada sakelar yang mungkin hilang dalam nilai rata-rata.

  • Perhitungan: Minimum Akurasi Status / Total Status untuk semua kombinasi fitur/perangkat.

3. Meningkatkan Kondisi Perangkat &Akurasi Status

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 identik di kedua jalur. Jika fitur 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 Report State terakhir.

Solusi: Pastikan Report State dipicu setiap kali status perangkat berubah dan Report State serta QUERY selalu memberikan nilai yang sama dan terbaru serta semua kolom yang diperlukan untuk mempertahankan 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 status perangkat yang diperbarui kembali 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 operasinya.

Solusi: Pastikan Report State dipicu dan berhasil dikirim untuk semua perubahan status. Verifikasi bahwa logika backend menangani update status dengan benar, mengonfirmasi keberhasilan pengiriman ke Google HomeGraph, dan memastikan perangkat secara konsisten menyinkronkan statusnya untuk menjaga akurasi antarmuka pengguna dan mesin otomatisasi.