Google Home Vitals (Cloud)

Bu kontrol panelleri ve uyarılar, Google Home ekosistemiyle yüksek kaliteli bir entegrasyonu proaktif olarak sürdürmenize yardımcı olur. Google, tüm müşteriler için yüksek kaliteli bir ekosistem geliştirme konusunda iş ortaklarını desteklemeye kararlıdır.

Kontrol panelinde üç bölüm bulunur. Her bölüm, entegrasyonun genel kalitesine katkıda bulunan önemli bir bölümü kapsar.

1. Google'dan İş Ortağına Metrikleri: Google'dan bulut arka ucunuza yapılan çağrıların durumunu ölçer.

2. Sistem Sağlığı - Google Metrikleri İş Ortağı: Sisteminizden Google'a yapılan çağrıların sağlığını ölçer.

3. Cihaz Sağlığı - Durum Doğruluğu: Google sistemlerinde depolanan ve kullanıcı sorgularını yanıtlamak için kullanılan durumların doğruluğunu ölçer.

Metrikler hedef değerlerini karşılamadığında, kullanıcı deneyimini etkileyebilecek bir sorunu belirtmek için kırmızı renkle vurgulanır. Aşağıdaki bilgiler, her bir hedefle ilgili ayrıntıları ve bu hedeflerin kullanıcılarınız için neden önemli olduğunu açıklamaktadır.

Aşağıdaki düğme sizi doğrudan kontrol paneline yönlendirmezse Genel Bakış sayfasını, ardından Kontrol Panelleri'ni seçip Kontrol Panellerim listesinden Google Home Vitals Kontrol Paneli (Cloud)'ni seçerek kontrol panelinizi görüntüleyebilirsiniz.

Kontrol Paneli'ne git

Google'dan iş ortağına metrikleri

Sorgu/Yürütme Başarı Oranı >=%99,5 metriği, kullanıcıların komutlarının ne sıklıkta doğru şekilde yerine getirildiğini ölçer.Bu sayede, Asistan'ın "Cihaza erişemiyorum" gibi yanıtlar vermesi veya henüz yerine getirilmemiş bir komutu yanlışlıkla onaylaması önlenir.

Senkronizasyon Başarı Oranı >=%99,5 metriği, senkronizasyon isteklerinin ne sıklıkta doğru şekilde yerine getirildiğini ölçer.Bu sayede, Google Home'da gösterilen cihazların bulut altyapınıza bağlı cihazlarla senkronize olması sağlanır.

"Başarı" nasıl tanımlanır?

Google Home platformu, amaçlanan işlemin yerine getirildiğini veya istenen durumun alındığını belirten geçerli bir yanıt alırsa işlem başarılı olarak işaretlenir.

Engelleme içermeyen istisnalar (ör. lowBattery istisnasıyla birlikte SUCCESS durumu) içeren yanıtlar, başarılı işlemler olarak sayılır. Komut cihaza ulaştı ve uyarıya rağmen amaç yerine getirildi.

"Başarısızlık" nasıl tanımlanır?

Ortak platform hata kodları sayfasında bulunan ve İş Ortağı Tarafından İşlem Yapılabilir olarak işaretlenen hatalar, QUERY, EXECUTE ve SYNC başarı oranları hesaplanırken "Başarısızlık" olarak kabul edilir. Ayrıca, Hatalar ve istisnalar bölümünde bulunan hatalar da aşağıdaki istisnalar dışında "Başarısızlıklar"dır:

Yürütme Yanıtı Durum Eşitliği

Bir EXECUTE yanıtında SUCCESS durumu döndürürken yanıt yükünüzün states nesnesi, yürüttüğünüz özellikler tarafından tanımlanan tüm etkin ve güncellenmiş durum alanlarını içermelidir. Gerekli durum alanlarının atlanması veya karmaşık trait'ler için boş bir states nesnesi döndürülmesi, Google Home Platform'un yürütme sonucunu ayrıştırmamasına neden olur. Bu durum, AGENT_ISSUE veya INVALID_RESPONSE hatası olarak kaydedilir ve Sorgu ve Yürütme Başarı Oranınızı düşürür.

Sorgu/Yürütme Gecikmesi (p90) <= 1000 ms metriği, istenen işlem bekleme süresini ölçer ve kullanıcıların çok uzun süre beklemesini (ör. ışıklarının sönmesi için birkaç saniye bekleme) önlemeye yardımcı olur.

Gecikme metrikleri

Gecikme, entegrasyonunuzun son kullanıcıya ne kadar duyarlı hissettirdiğinin kritik bir göstergesidir. Kontrol panelinde, "en yavaş" kullanıcılarınızın deneyimini temsil eden 90. Yüzdelik (P90) Gecikme izlenir (örneğin, 800 ms'lik bir P90, isteklerin% 90'ının 800 ms veya daha kısa sürede onaylandığı anlamına gelir).

Google, teknik doğruluğu sağlamak için durum kontrolleri ile cihaz komutlarının gecikmesini farklı şekilde ölçer.

1. SORGULAMA Gecikmesi (Soru)

Bu metrik, Google bir cihazın mevcut durumunu sorduğunda Cloud-to-cloud gidiş dönüş süresini ölçer.

• Başlangıç: Google, karşılama URL'nize bir action.devices.QUERY isteği gönderir.
• Ölçüm Aralığı: Bulutunuzun tam HTTP yanıtını alması, işlemesi ve Google'a geri iletmesi için geçen süre.
• Son: Google, hizmetinizden gelen son yanıt yükünü alır ve onaylar.

2. EXECUTE Gecikmesi (İşlem)

Bu metrik, Google bir cihaza kontrol isteği gönderdiğinde komutun onaylanma süresini ölçer.

• Başlangıç: Google, karşılama URL'nize bir action.devices.EXECUTE isteği gönderir.
• Ölçüm Aralığı: Bulutunuzun komutu alması ve bir onay yanıtı döndürmesi için geçen süre.
• Son: Google, SUCCESS, PENDING veya OFFLINE durum yanıtını alır.
• Teknik Kapsam: Bu metrik, Google'ın bulutu ile sizin bulutunuz arasındaki"Yanıt Onayı" süresini ölçer. Fiziksel donanımın (örneğin, bir ampul) fiziksel durum değişikliğini tamamlaması için gereken süreyi ölçmez. Bu süre genellikle buluttan buluta yolun dışındaki yerel bağlantılı ağ gecikmesini içerir.

EXECUTE/QUERY gecikme süresi zaman çizelgesi dökümü

EXECUTE veya QUERY gecikmesi için zaman damgalarını analiz ederken toplam gidiş dönüş süresi aşağıdaki sıralı akışa ayrılabilir:

Bu dökümde Google tarafı ile iş ortağı tarafındaki zaman damgaları karşılaştırıldığından iş ortağı sunucularının Ağ Saati Protokolü (NTP) ile senkronize edilmesi gerekir. Küçük bir saat sapması (50-100 ms) bile hesaplanan nakliye sürelerini (t2 - t1 ve t4 - t3) bozarak negatif nakliye gecikmeleri gibi mantıksal olarak imkansız metriklere yol açabilir.

[t1] İstek Gönderildi (Google Giden): Google, intent isteğini başlatır. t1 doğrudan gösterilmediğinden, toplam gecikme süresinin son gelen zaman damgasından çıkarılmasıyla yaklaşık olarak hesaplanır.

Ağ geçişi (t1 - t2): Karşılama uç noktanıza ulaşmadan önceki tahmini ağ geçişi ve sıra süresi.

[t2] İstek Alındı (İş Ortağı Girişi): İsteğin ortamınızın API ağ geçidine veya giriş sunucusuna ulaştığı tam zaman damgası.

İş Ortağı İşleme (t2 - t3): Tamamen bulut ortamınızda gerçekleşen dahili yürütme, yönlendirme ve cihaz işleme gecikmesi.

[t3] Yanıt Gönderildi (İş Ortağı Çıkışı): Hizmetinizin karşılama yanıtını Google'a geri gönderdiği zaman damgası.

Dönüş Transit Süresi (t3 - t4): Dönüş ağ yönlendirmesi ve Google'a geri bağlantı tamamlama süresi.

[t4] İstek Tamamlandı (Google'a Gelen): Google, nihai yanıtı alır ve işler. Bu zaman damgası, Google Cloud günlüklerinize açıkça receiveTimestamp olarak kaydedilir.

Bu metriklerin birbiriyle nasıl bağlantılı olduğunu göstermek için toplam günlüğe kaydedilen gecikme süresi (latencyMsec) 1.700 ms ve Google Cloud receiveTimestamp (t4) değeri 2026-05-25T15:25:00.550Z olan örnek bir EXECUTE isteğini ele alalım.

Gecikmeyi azaltma seçenekleri

Coğrafi yönlendirme için mimari öneriler

Her noktaya adresleme IP'si uygulaması mümkün değilse kullanıcıların en yakın bölgesel veri merkezinden hizmet almasını sağlamak için aşağıdaki uygun maliyetli alternatifleri öneririz.

1. Global Load Balancing (GLB)

   Statik yönlendirme yerine Global Uygulama Yük Dengeleyicisi kullanın (çoğu büyük bulut sağlayıcıda mevcuttur).

   • İşleyiş şekli: Ağın uç noktasında bulunan tek bir global giriş noktası (URL) yapılandırırsınız. Yük dengeleyici, Google'ın karşılama kümelerinden gelen isteğin coğrafi kaynağını otomatik olarak algılar ve trafiği en yakın bölgesel sağlıklı arka ucunuza yönlendirir.

   • Avantajı: Bu, Anycast'in performansını çok daha düşük yapılandırma karmaşıklığı ve maliyetiyle sunar.

2. Coğrafi Konum Bilgili DNS (GeoDNS)

   • İşleyiş şekli: DNS sağlayıcınızı, karşılama URL'nizi DNS sorgusunun coğrafi konumuna göre farklı IP adreslerine çözümleyecek şekilde yapılandırın.

   • Uygulama: DNS sağlayıcınızın Google'ın çıkış noktaları için optimize edildiğinden emin olun. Google'ın bölgesel karşılama hizmetleri (ör. ABD, AB veya Asya'da) alan adınızı çözümlediğinde, söz konusu bölgedeki veri merkezinin IP adresini alır.

Uygulama katmanında optimizasyon stratejileri

Altyapı düzeyinde yönlendirmenin yanı sıra, istek işleme sürecindeki gecikmeyi azaltmak için uygulama katmanında aşağıdaki stratejileri uygulayabilirsiniz.

1. "Trambolin" proxy yöntemi

   Birincil veri merkezi kullanmanız gerekiyorsa ilk el sıkışmayı gerçekleştirmek için bölgesel hafif proxy sunucuları (Trambolinler) kullanın.

   1. Google, global URL'nize erişir.

   2. Bölgesel bir proxy (örneğin, basit bir Nginx veya Lambda işlevi) isteği alır.

   3. Proxy, yükü dahili yüksek hızlı omurganız üzerinden birincil veritabanına iletir.

   Avantaj: Bu, genellikle uzun mesafeli isteklerde gecikmeye en çok katkıda bulunan "TCP Handshake" süresini azaltır.

2. Erişim Jetonu Bölge İpuçları

   Hesap Bağlama (OAuth) işlemi sırasında sisteminiz kullanıcının ev bölgesini tanımlayabilir.

   Uygulama: Google'a verilen access_token içine bir bölge tanımlayıcı kodlayın. Google bir karşılama isteği gönderdiğinde ağ geçidiniz, veritabanı araması yapmaya gerek kalmadan jetonu hemen inceleyebilir ve isteği doğru bölgesel kümeye yönlendirebilir.

Sistem Sağlığı - İş ortağından Google'a metrikleri

Başarı oranının%99,5'ten yüksek olması, Google Home'da cihaz durumlarının doğru olmasını, cihazların eklenip kaldırılmasını, otomasyonların tetiklenmesini ve geçmiş etkinliklerinin Google Home app (GHA) uygulamasının Etkinlik sekmesinde görünmesini sağlar.

Başarı oranı, bulutunuz durum güncellemelerini gönderdiğinde Google tarafından döndürülen HTTP yanıt kodlarına göre hesaplanır. İş ortaklarının Google tarafındaki altyapı sorunları nedeniyle cezalandırılmaması için bu metrik, Google'ın dahili hatalarını başarısızlık sayısına dahil etmez. Hesaplamaya dahil edilen API çağrıları, HomeGraph API referansında bulunur.

"Başarı" nasıl tanımlanır?

2xx (Başarılı): Durum güncellemesi Home Graph tarafından başarıyla alındı ve işlendi.

"Başarısızlık" nasıl tanımlanır?

4xx (İş Ortağı Hatası), hataları temsil eder ve bulutunuzdan gönderilen istekle ilgili bir sorunu gösterir. Yaygın kodlar şunlardır:

400 Hatalı İstek

Nedeni: Sunucu, geçersiz söz dizimi nedeniyle isteği işleyemedi. Sık karşılaşılan nedenler arasında hatalı biçimlendirilmiş JSON veya dize değeri için "" yerine null kullanılması yer alır.

Çözüm: İstek gövdesinin geçerli bir JSON olduğundan (hatalı biçimlendirilmiş yapı veya dize alanları için boş değerler olmamalıdır) ve agentUserId değerinin SYNC yanıtındaki değerle eşleştiğinden emin olun.

404 Bulunamadı

Nedeni: HomeGraph'te deviceId veya agentUserId bulunamadı (henüz senkronize edilmedi, bağlantısı zaten kaldırıldı veya kimlik uyuşmazlığı var).

Çözüm:

1. agentUserId değerinin, SYNC yanıtınızda sağlanan değerle eşleştiğinden emin olun.
2. 404 Bulunamadı hatasının HomeGraph'te eksik bir cihazdan mı yoksa kullanıcıdan mı kaynaklandığını belirlemek için Home Graph SYNC API'yi kullanın.
3. Cihaz veya hesap ekleme, kaldırma, yeniden adlandırma ya da güncelleme işlemlerinden sonra durumun güncel kalması için requestSync tetiklendiğinden emin olun.
4. Eski cihazları bildirmeyi durdurmak için DISCONNECT intent'lerini doğru şekilde işleyin. DISCONNECT intent'ini aldıktan sonra bulut hizmetiniz, Request Sync ve Report State ile Google'da değişiklik yayınlamayı durdurmalıdır.

429 Kaynak Tükendi

Nedeni: Entegrasyonunuz, kendisine ayrılan kotayı aşmıştır.

Çözüm: Kota yönetimi için kontrol panelindeki "2a Adımı: Kota Sorunlarında Hata Ayıklama" bölümündeki talimatları inceleyin. Daha fazla bilgi için Akıllı Ev kotaları ve sınırları sayfasını da inceleyebilirsiniz.

Cihaz sağlığı - Durum doğruluğu

Durum Doğruluğu'nun%99,5 veya daha yüksek olması, kullanıcıların cihaz durumlarını görüntülerken veya Home'a Sor gibi yapay zeka özelliklerini kullanırken doğru sonuçları görmesini sağlar. Durum doğruluğu düşükse otomasyonlar tetiklenmeyebilir ve geçmiş girişleri, GHA uygulamasının Etkinlik sekmesinde doğru zamanda görünmeyebilir. Daha fazla bilgi için Report State sayfasına bakın. Not: Durum Doğruluğu hedefi, desteklenen TÜM özelliklerde karşılanmalıdır.

1. Doğruluk Bileşenleri

Metrik, Google'ın bildirilen durumu bilinen bir amaç sonucuna göre doğrulayabildiği "örneklerden" türetilir. Teknik hassasiyet için doğruluk iki farklı yolla değerlendirilir:

• SORGULAMA tabanlı doğruluk: Bir kullanıcı veya sistem, cihazın mevcut durumunu etkin bir şekilde sorguladığında doğrulanır.
• EXECUTE tabanlı doğruluk: Bir kontrol isteğinin ardından bildirilen komut sonrası cihaz durumu değerlendirilerek doğrulanır.

2. Kontrol Paneli Metrikleri (Saatlik Hesaplama)

Kontrol paneli, doğruluğu 1 saatlik aralığa göre hesaplar. Google, istatistiksel güven sağlamak ve düşük sinyal gürültüsünde entegrasyonların cezalandırılmasını önlemek için minimum trafik hacmi eşiği uygular. Belirli bir özellik ve cihaz kombinasyonu, 5 günlük bir dönemde toplam 100'den az örnek toplarsa doğruluğu istatistiksel olarak önemsiz kabul edilir ve Yok olarak ayarlanır.

Bir saatte her iki yol için de yeterli örnek hacmi olduğunda, belirli bir eyalet için temel saatlik doğruluk, iki bağımsız yüzdenin ortalaması olarak hesaplanır:

Saatlik Durum Doğruluğu = (Sorgu Doğruluğu % + Yürütme Doğruluğu %) / 2

Her bir yol şu şekilde tanımlanır:

• Sorgu Doğruluğu % = (Saatlik Sorgu Doğru Örnekleri) / (Saatlik Sorgu Toplam Örnekleri)
• Yürütme Doğruluğu % = (Saatlik Yürütme Doğru Örnekleri) / (Saatlik Yürütme Toplam Örnekleri)

Özellik Doğruluk Puanı (her özellik için hesaplanır) = TOPLAM(Sorgu Doğru Örnekleri + Yürütme Doğru Örnekleri) / TOPLAM(Sorgu Toplam Örnekleri + Yürütme Toplam Örnekleri)

Kalite Puanı, ekosisteminizdeki kesin minimum performansı değerlendirdiğinden, desteklenen ve uygun olan her bir özelliğin ayrı ayrı >=% 99,5 Durum Doğruluğu hedefini karşılaması gerekir (bu, özelliklerin ortalaması değildir).

Bu görünüm, yüksek hacimli ve mükemmel doğruluk oranına sahip cihazların, daha düşük hacimli cihazlardaki doğruluk sorunlarını maskelemesini önler. Az kullanılan özelliklerin puanlarını düşürmesinden endişe eden iş ortakları, nadiren kullanılan bir özelliğin minimum trafik hacmi kontrolüyle otomatik olarak korunduğundan ve gerekli örnek eşiğini karşılamadığı sürece en düşük tür ve özellik puanına dahil edilmeyeceğinden emin olabilir.

3. Cihaz Sağlığı ve Durum Doğruluğunu İyileştirme

Home Graph'te depolanan durum, gerçek zamanlı bir QUERY'nin sonuçlarıyla eşleşmediğinde tutarsızlıklar ortaya çıkar.

"Eksik alan" hataları

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"
  }
  

Nedeni: DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD veya DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD hatası, aynı cihaz için QUERY yanıtınız ile Report State isteğiniz arasındaki yük alanları kümesinin farklı olduğunu gösterir.

Çözüm: Veri yapısının her iki yolda da aynı olduğundan emin olun. SYNC'ye bir özellik dahil edilmişse ilgili alanların hem proaktif raporlarda hem de reaktif sorgularda mevcut ve tutarlı olması gerekir.

"Yanlış" hataları

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"
  }
  

Nedeni: DETAILED_ACCURACY_RESULT_INACCURATE hatası için QUERY yanıtında döndürülen değer ile son Report State değeri arasında bir tutarsızlık vardır.

Çözüm: Bir cihazın durumu her değiştiğinde Report State'in tetiklendiğinden ve hem Report State hem de QUERY'nin her zaman tamamen aynı, güncel değerleri ve veri tutarlılığını korumak için gereken tüm alanları sağladığından emin olun.

"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"
   }
  

Nedeni: DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE hatası, iş ortağının komutu başarıyla yürüttüğü ancak güncellenen cihaz durumunu Google'a bildirmediği anlamına gelir.

Çözüm: Home Graph'in yeni cihaz durumunu alması için komut yürütüldükten sonra her zaman bir Report State güncellemesi gönderin.

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"
   }
  

Nedeni: DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED hatası için QUERY sonuçları mevcut durumu sağlasa da bu cihaz için Report State alınmadı (durum boş ve bildirilen zaman damgası başlangıç zamanında). Bu durum, durum güncellemelerinin tetiklenmediğini, HomeGraph'e ulaşamadığını veya cihazın bağlantı ya da faaliyet durumundaki geçişleri başarıyla bildirmediğini gösterir.

Çözüm: Report State'in tetiklendiğinden ve tüm durum değişiklikleri için başarıyla gönderildiğinden emin olun. Arka uç mantığının durum güncellemelerini doğru şekilde işlediğini, Google HomeGraph'e teslimatın başarılı olduğunu onayladığını ve kullanıcı arayüzü ile otomasyon motorunun doğru kalması için cihazın durumunu tutarlı bir şekilde senkronize ettiğini doğrulayın.