Google Home Vitals (Cloud)

Mit diesen Dashboards und Benachrichtigungen kannst du proaktiv für eine hochwertige Integration in das Google Home-Ökosystem sorgen. Google unterstützt Partnerunternehmen bei der Entwicklung eines hochwertigen Ökosystems für alle Kundenunternehmen.

Das Dashboard besteht aus drei Abschnitten, die jeweils einen wichtigen Teil der Integration abdecken.

1. Messwerte für Google-zu-Partner-Verbindungen: Messen den Zustand von Aufrufen von Google an Ihr Cloud-Backend.

2. Systemzustand – Partner-zu-Google-Messwerte: Misst den Zustand von Aufrufen von Ihrem System an Google.

3. Gerätezustand – Genauigkeit des Status: Misst die Genauigkeit der in Google-Systemen gespeicherten Status, die zur Beantwortung von Nutzeranfragen verwendet werden.

Wenn Messwerte ihre Zielwerte nicht erreichen, werden sie rot hervorgehoben, um auf ein Problem hinzuweisen, das sich auf die Nutzerfreundlichkeit auswirken könnte. Im Folgenden finden Sie Details zu den einzelnen Zielen und dazu, warum sie für Ihre Nutzer wichtig sind.

Wenn du über die folgende Schaltfläche nicht direkt zum Dashboard gelangst, kannst du es aufrufen, indem du die Seite Übersicht und dann Dashboards auswählst. Wähle dann in der Liste Meine Dashboards die Option Google Home Vitals-Dashboard (Cloud) aus, um dein Dashboard aufzurufen.

Zum Dashboard

Messwerte von Google an Partner

Der Messwert Erfolgsquote für Abfragen/Ausführungen >= 99,5% gibt an, wie oft die Befehle von Nutzern korrekt ausgeführt werden.So lassen sich Assistant-Antworten wie „Ich kann das Gerät nicht erreichen“ oder die fälschliche Bestätigung eines noch nicht ausgeführten Befehls vermeiden.

Der Messwert Synchronisierungserfolgsquote >= 99,5% gibt an, wie oft Synchronisierungsanfragen korrekt ausgeführt werden.So wird sichergestellt, dass die in Google Home angezeigten Geräte mit den Geräten synchronisiert sind, die mit Ihrer Cloud-Infrastruktur verbunden sind.

Was ist ein „Erfolg“?

Eine Transaktion wird als erfolgreich markiert, wenn die Google Home-Plattform eine gültige Antwort erhält, die angibt, dass die beabsichtigte Aktion ausgeführt oder der angeforderte Status abgerufen wurde.

Antworten, die nicht blockierende Ausnahmen enthalten (z. B. ein SUCCESS-Status, der von einer lowBattery-Ausnahme begleitet wird), werden als erfolgreiche Transaktionen gezählt. Der Befehl hat das Gerät erreicht und der Intent wurde trotz der Warnung erfüllt.

Was ist ein „Fehler“?

Die Fehler, die unter Häufige Plattformfehlercodes gefunden und als Vom Partner behebbar gekennzeichnet wurden, werden bei der Berechnung der Erfolgsquoten für QUERY, EXECUTE und SYNC als „Fehler“ betrachtet. Außerdem sind die Fehler, die unter Fehler und Ausnahmen aufgeführt sind, ebenfalls „Fehler“, mit den folgenden Ausnahmen:

Parität des Ausführungsantwortstatus

Wenn du in einer EXECUTE-Antwort den Status SUCCESS zurückgibst, muss das states-Objekt der Antwortnutzlast alle aktiven und aktualisierten Statusfelder enthalten, die durch die von dir ausgeführten Eigenschaften definiert sind. Wenn du erforderliche Statusfelder weglässt oder ein leeres states-Objekt für komplexe Attribute zurückgibst, kann die Google Home-Plattform das Ausführungsergebnis nicht parsen. Es wird dann als AGENT_ISSUE- oder INVALID_RESPONSE-Fehler registriert, was die Erfolgsquote für Abfragen und Ausführungen senkt.

Der Messwert Abfrage-/Ausführungslatenz (p90) <= 1.000 ms misst die Wartezeit für angeforderte Aktionen und trägt dazu bei, dass Nutzer nicht zu lange warten müssen, z. B. ein paar Sekunden, bis das Licht ausgeschaltet wird.

Latenzmesswerte

Die Latenz ist ein wichtiger Indikator dafür, wie reaktionsschnell sich Ihre Integration für den Endnutzer anfühlt. Im Dashboard wird die Latenz des 90. Perzentils (P90) erfasst, die die Erfahrung Ihrer „langsamsten“ Nutzer darstellt. Ein P90-Wert von 800 ms bedeutet beispielsweise, dass 90% der Anfragen in maximal 800 ms bestätigt werden.

Google misst die Latenz bei Statusprüfungen anders als bei Gerätebefehlen, um die technische Genauigkeit zu gewährleisten.

1. QUERY Latency (Interrogative)

Damit wird die Cloud-to-cloud-Umlaufzeit gemessen, wenn Google den aktuellen Status eines Geräts abfragt.

• Start: Google sendet eine action.devices.QUERY-Anfrage an deine Ausführungs-URL.
• Messfenster: Die Zeit, die Ihre Cloud benötigt, um die vollständige HTTP-Antwort zu empfangen, zu verarbeiten und an Google zurückzusenden.
• Ende: Google empfängt und bestätigt die endgültige Antwortnutzlast von Ihrem Dienst.

2. EXECUTE-Latenz (Aktion)

Damit wird die Zeit für die Bestätigung des Befehls gemessen, wenn Google eine Steuerungsanfrage an ein Gerät sendet.

• Start: Google sendet eine action.devices.EXECUTE-Anfrage an deine Ausführungs-URL.
• Messfenster: Die Zeit, die Ihre Cloud benötigt, um den Befehl zu empfangen und eine Bestätigungsantwort zurückzugeben.
• Ende: Google erhält die Statusantwort SUCCESS, PENDING oder OFFLINE.
• Technischer Umfang: Mit diesem Messwert wird die „Response Ack“-Zeit zwischen der Google Cloud und Ihrer Cloud gemessen. Die Zeit, die die physische Hardware (z. B. eine Glühbirne) benötigt, um die physische Zustandsänderung abzuschließen, wird nicht gemessen, da dies oft mit der Latenz des lokalen Mesh-Netzwerks außerhalb des Cloud-zu-Cloud-Pfads zusammenhängt.

Aufschlüsselung der EXECUTE/QUERY-Latenzzeitachse

Bei der Analyse von Zeitstempeln für eine EXECUTE- oder QUERY-Latenz kann die gesamte Umlaufzeit in den folgenden sequenziellen Ablauf unterteilt werden:

Da bei dieser Aufschlüsselung die Zeitstempel von Google und Partnern verglichen werden, müssen die Partnerserver mit NTP (Network Time Protocol) synchronisiert werden. Selbst eine geringfügige Taktabweichung (50–100 ms) verzerrt die berechneten Laufzeiten (t2 - t1 und t4 - t3), was zu logisch unmöglichen Messwerten wie negativen Laufzeitlatenzen führen kann.

[t1] Anfrage gesendet (Google Outbound): Google initiiert die Intent-Anfrage. Da t1 nicht direkt verfügbar ist, wird es ungefähr berechnet, indem die Gesamtlatenz vom endgültigen eingehenden Zeitstempel subtrahiert wird.

Netzwerkübertragung (t1 bis t2): Die geschätzte Netzwerkübertragungs- und Warteschlangenzeit, bevor der Erfüllungsendpunkt erreicht wird.

[t2] Anfrage empfangen (Partner-Ingress): Der genaue Zeitstempel, zu dem die Anfrage beim API-Gateway oder Ingress-Server Ihrer Umgebung eingeht.

Partnerverarbeitung (t2 bis t3): Die interne Ausführung, das Routing und die Latenz bei der Geräteverarbeitung, die vollständig in Ihrer Cloud-Umgebung stattfinden.

[t3] Antwort gesendet (ausgehender Traffic des Partners): Der Zeitstempel, zu dem Ihr Dienst die Ausführungsantwort an Google sendet.

Rückweg (t3 bis t4): Die Zeit für das Netzwerkrouting und den Verbindungsaufbau zurück zu Google.

[t4] Anfrage abgeschlossen (Google Inbound): Google empfängt und verarbeitet die endgültige Antwort. Dieser Zeitstempel wird in Ihren Google Cloud-Logs explizit als receiveTimestamp aufgezeichnet.

Um zu veranschaulichen, wie diese Messwerte zusammenhängen, betrachten wir eine Beispielanfrage von EXECUTE mit einer protokollierten Gesamtlatenz (latencyMsec) von 1.700 ms und einem Google Cloud receiveTimestamp (t4) von 2026-05-25T15:25:00.550Z.

Optionen zur Reduzierung der Latenz

Architekturempfehlungen für das geografische Routing

Wenn die Implementierung von Anycast-IP-Adressen nicht möglich ist, empfehlen wir die folgenden kostengünstigen Alternativen, um sicherzustellen, dass Nutzer vom nächstgelegenen regionalen Rechenzentrum bedient werden.

1. Globales Load Balancing (GLB)

   Verwenden Sie anstelle von statischem Routing einen globalen Application Load Balancer (von den meisten großen Cloud-Anbietern verfügbar).

   • Funktionsweise: Sie konfigurieren einen einzelnen globalen Einstiegspunkt (URL) am Netzwerkrand. Der Load Balancer erkennt automatisch den geografischen Ursprung der Anfrage von den Fulfillment-Clustern von Google und leitet den Traffic an das nächstgelegene regionale fehlerfreie Backend weiter.

   • Vorteil: Dies bietet die Leistung von Anycast bei deutlich geringerer Konfigurationskomplexität und geringeren Kosten.

2. Standortbezogenes DNS (GeoDNS)

   • Funktionsweise: Konfiguriere deinen DNS-Anbieter so, dass deine Auftragsausführungs-URL basierend auf dem geografischen Standort der DNS-Abfrage in verschiedene IP-Adressen aufgelöst wird.

   • Implementierung: Achten Sie darauf, dass Ihr DNS-Anbieter für die ausgehenden Traffic-Punkte von Google optimiert ist. Wenn die regionalen Fulfillment-Dienste von Google (z. B. in den USA, der EU oder Asien) Ihre Domain auflösen, erhalten sie die IP-Adresse für das Rechenzentrum in dieser bestimmten Region.

Optimierungsstrategien auf der Anwendungsebene

Zusätzlich zum Routing auf Infrastrukturebene können Sie die folgenden Strategien auf der Anwendungsebene implementieren, um die Latenz bei der Anfrageverarbeitung zu reduzieren.

1. Die „Trampolin“-Proxy-Methode

   Wenn Sie ein primäres Rechenzentrum unterhalten müssen, verwenden Sie regionale Lightweight-Proxyserver (Trampoline), um den ersten Handshake zu verarbeiten.

   1. Google ruft Ihre globale URL auf.

   2. Ein regionaler Proxy (z. B. eine einfache Nginx- oder Lambda-Funktion) empfängt die Anfrage.

   3. Der Proxy leitet die Nutzlast über Ihren internen Hochgeschwindigkeits-Backbone an die primäre Datenbank weiter.

   Vorteil: Dadurch wird die Zeit für den „TCP-Handshake“ verkürzt, der bei Anfragen über große Entfernungen oft den größten Beitrag zur Latenz leistet.

2. Regionshinweise für Zugriffstokens

   Während der Kontoverknüpfung (OAuth) kann dein System die Heimatregion des Nutzers ermitteln.

   Implementierung:Codieren Sie eine Regionskennung in die access_token, die an Google ausgegeben wird. Wenn Google eine Ausführungsanfrage sendet, kann Ihr Gateway das Token sofort prüfen und die Anfrage an den richtigen regionalen Cluster weiterleiten, ohne dass eine Datenbanksuche erforderlich ist.

Systemzustand – Messwerte für Partner an Google

Eine Erfolgsquote von mindestens 99,5% trägt dazu bei, dass Gerätestatus in Google Home korrekt sind, Geräte hinzugefügt und entfernt werden, automatisierte Abläufe ausgelöst werden und Verlaufsereignisse auf dem Tab „Aktivität“ von Google Home app (GHA) angezeigt werden.

Die Erfolgsquote wird anhand der HTTP-Antwortcodes berechnet, die von Google zurückgegeben werden, wenn Ihre Cloud Statusaktualisierungen sendet. Damit Partner nicht für Infrastrukturprobleme auf Google-Seite bestraft werden, werden bei der Berechnung des Messwerts interne Google-Fehler nicht berücksichtigt. Die in der Berechnung enthaltenen API-Aufrufe finden Sie in der HomeGraph API-Referenz.

Was ist ein „Erfolg“?

2xx (Erfolg): Die Statusaktualisierung wurde von Home Graph empfangen und verarbeitet.

Was ist ein „Fehler“?

4xx (Partnerfehler) stehen für Fehler und weisen auf ein Problem mit der Anfrage hin, die von deiner Cloud gesendet wurde. Häufige Codes sind:

400 Fehlerhafte Anfrage

Ursache: Der Server konnte die Anfrage aufgrund einer ungültigen Syntax nicht verarbeiten. Häufige Ursachen sind fehlerhaftes JSON oder die Verwendung von null anstelle von „“ für einen Stringwert.

Lösung: Achte darauf, dass der Anfragetext gültiges JSON ist (keine fehlerhafte Struktur oder Nullwerte für Stringfelder) und dass agentUserId mit dem Wert aus der SYNC-Antwort übereinstimmt.

404 Nicht gefunden

Ursache: deviceId oder agentUserId wurde nicht im HomeGraph gefunden (noch nicht synchronisiert, Verknüpfung bereits aufgehoben oder ID-Konflikt).

Lösung:

1. Achte darauf, dass die agentUserId mit dem Wert in deiner SYNC-Antwort übereinstimmt.
2. Verwende die Home Graph SYNC API, um festzustellen, ob der Fehler „404 Nicht gefunden“ durch ein fehlendes Gerät oder einen fehlenden Nutzer in Home Graph verursacht wird.
3. Achte darauf, dass requestSync nach dem Hinzufügen, Entfernen, Umbenennen oder Aktualisieren von Geräten oder Konten ausgelöst wird, damit der Status auf dem neuesten Stand bleibt.
4. Verarbeite DISCONNECT-Intents ordnungsgemäß, damit keine veralteten Geräte mehr gemeldet werden. Nachdem Ihr Cloud-Dienst den Intent DISCONNECT empfangen hat, sollte er keine Änderungen mehr mit Request Sync und Report State an Google veröffentlichen.

429 – Ressource erschöpft

Ursache: Ihre Integration hat das zugewiesene Kontingent überschritten.

Lösung: Folgen Sie der Anleitung im Abschnitt „Schritt 2a: Kontingentprobleme beheben“ im Dashboard für die Kontingentverwaltung. Weitere Informationen findest du unter Kontingente und Limits für Smart Home.

Gerätezustand – Genauigkeit des Status

Wenn die Genauigkeit des Status >= 99,5% ist, werden Nutzern korrekte Ergebnisse angezeigt, wenn sie den Gerätestatus aufrufen oder KI-Funktionen wie „Frag Home“ verwenden. Wenn die Genauigkeit des Status gering ist, werden Automatisierungen möglicherweise nicht ausgelöst und Verlaufseinträge werden möglicherweise nicht zur richtigen Zeit auf dem Tab „Aktivität“ der GHA angezeigt. Weitere Informationen findest du unter Report State. Hinweis:Das Ziel für die Statusgenauigkeit muss für ALLE unterstützten Eigenschaften erreicht werden.

1. Genauigkeitskomponenten

Der Messwert wird aus „Stichproben“ abgeleitet, bei denen Google den gemeldeten Status mit einem bekannten Intent-Ergebnis vergleichen kann. Für die technische Präzision wird die Genauigkeit auf zwei verschiedene Arten bewertet:

• ABFRAGE-basierte Genauigkeit:Wird überprüft, wenn ein Nutzer oder System den aktuellen Status eines Geräts aktiv abfragt.
• EXECUTE-basierte Genauigkeit:Wird durch die Auswertung des Gerätestatus nach dem Befehl überprüft, der nach einer Steuerungsanfrage zurückgemeldet wird.

2. Dashboard-Messwerte (stündliche Berechnung)

Im Dashboard wird die Genauigkeit anhand eines 1-Stunden-Intervalls berechnet. Um statistische Zuverlässigkeit zu gewährleisten und zu vermeiden, dass Integrationen mit geringem Signal-Rausch-Verhältnis benachteiligt werden, erzwingt Google einen Mindestschwellenwert für das Trafficvolumen. Wenn für eine bestimmte Kombination aus Merkmal und Gerät in einem rollierenden 5-Tage-Fenster weniger als 100 Stichproben erfasst werden, gilt die Genauigkeit als statistisch unbedeutend und wird auf Nicht verfügbar gesetzt.

Wenn für eine Stunde ein ausreichendes Stichprobenvolumen für beide Pfade vorhanden ist, wird die stündliche Genauigkeit für einen bestimmten Status als Durchschnitt der beiden unabhängigen Prozentsätze berechnet:

Stündliche Statusgenauigkeit = (Abfragegenauigkeit in % + Ausführungsgenauigkeit in %) ÷ 2

Dabei ist jeder Pfad so definiert:

• Genauigkeit der Abfrage in % = (Stündliche genaue Abfragestichproben) / (Stündliche Abfragestichproben insgesamt)
• Ausführungsgenauigkeit in % = (Stündliche Ausführung – genaue Stichproben) ÷ (Stündliche Ausführung – Stichproben insgesamt)

Trait Accuracy Score (pro Trait berechnet) = SUM(Query Accurate Samples + Execution Accurate Samples) / SUM(Query Total Samples + Execution Total Samples)

Da der Qualitätsfaktor die Mindestleistung in deinem Ökosystem bewertet, muss jede einzelne unterstützte und berechtigte Eigenschaft das Ziel von >= 99,5% Statusgenauigkeit erfüllen.Es handelt sich hierbei nicht um einen Durchschnittswert über alle Eigenschaften.

Diese Ansicht verhindert, dass Geräte mit hohem Volumen und hervorragender Genauigkeit Genauigkeitsprobleme auf Geräten mit geringerem Volumen maskieren. Partner, die befürchten, dass selten verwendete Merkmale ihre Punktzahl senken, können beruhigt sein: Ein selten verwendetes Merkmal wird automatisch durch die Prüfung des Mindest-Traffic-Volumens geschützt und fließt erst dann in die Punktzahl für den niedrigsten Typ und das niedrigste Merkmal ein, wenn es den erforderlichen Stichprobenschwellenwert erreicht.

3. Verbesserung der Genauigkeit von Gerätezustand und ‑status

Abweichungen treten auf, wenn der im Home Graph gespeicherte Status nicht mit den Ergebnissen einer Echtzeit-ABFRAGE übereinstimmt.

Fehler „Fehlendes Feld“

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

Ursache:Bei den Fehlern DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD oder DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD unterscheiden sich die Nutzlastfelder zwischen der QUERY-Antwort und der Report State-Anfrage für dasselbe Gerät.

Lösung:Achten Sie darauf, dass die Datenstruktur in beiden Pfaden identisch ist. Wenn ein Attribut in SYNC enthalten ist, müssen die entsprechenden Felder sowohl in proaktiven Berichten als auch in reaktiven Abfragen vorhanden und konsistent sein.

Fehler vom Typ „Ungenau“

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

Ursache: Beim Fehler DETAILED_ACCURACY_RESULT_INACCURATE gibt es eine Diskrepanz zwischen dem in der QUERY-Antwort zurückgegebenen Wert und dem letzten Report State-Wert.

Lösung:Achte darauf, dass „Report State“ immer ausgelöst wird, wenn sich der Gerätestatus ändert, und dass sowohl „Report State“ als auch QUERY immer genau dieselben aktuellen Werte und alle erforderlichen Felder liefern, um die Datenkonsistenz zu wahren.

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

Ursache:Beim Fehler DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE hat der Partner den Befehl erfolgreich ausgeführt, aber den aktualisierten Gerätestatus nicht an Google gemeldet.

Lösung:Sende nach der Befehlsausführung immer ein Report State-Update, damit Home Graph den neuen Gerätestatus erhält.

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

Ursache:Beim Fehler DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED wurde für dieses Gerät kein Report State empfangen (der Status ist leer und der gemeldete Zeitstempel ist auf die Epoche gesetzt), obwohl die QUERY-Ergebnisse den aktuellen Status liefern. Das bedeutet, dass entweder keine Statusaktualisierungen ausgelöst werden, diese HomeGraph nicht erreichen oder das Gerät Änderungen des Verbindungs- oder Betriebsstatus nicht erfolgreich meldet.

Lösung:Achte darauf, dass „Report State“ für alle Statusänderungen ausgelöst und erfolgreich gesendet wird. Prüfe, ob die Backend-Logik Statusaktualisierungen korrekt verarbeitet, die erfolgreiche Übermittlung an den Google HomeGraph bestätigt und dafür sorgt, dass das Gerät seinen Status konsistent synchronisiert, damit die Benutzeroberfläche und die Automatisierungs-Engine korrekt bleiben.