Diese Suite aus Dashboards und Benachrichtigungen hilft Ihnen, proaktiv eine hochwertige Integration in das Google Home-Ökosystem aufrechtzuerhalten. Google möchte Partner dabei unterstützen, ein hochwertiges Ökosystem für alle Kunden zu entwickeln.
Das Dashboard besteht aus drei Abschnitten, die jeweils einen wichtigen Teil abdecken, der zur Qualität einer Gesamtintegration beiträgt.
Messwerte von Google an Partner : Misst den Status von Aufrufen von Google an Ihr Cloud-Backend.
Systemstatus – Messwerte von Partner an Google : Misst den Status von Aufrufen von Ihrem System an Google.
Gerätezustand – Statusgenauigkeit : Misst die Genauigkeit von Status, die in Google-Systemen gespeichert sind und zum Beantworten 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. Die folgenden Informationen enthalten Details zu den einzelnen Zielen und warum sie für Ihre Nutzer wichtig sind.
Wenn Sie über die folgende Schaltfläche nicht direkt zum Dashboard gelangen, können Sie es aufrufen, indem Sie die Seite Übersicht auswählen, Dashboards und dann in der Liste Meine Dashboards die Option Google Home Vitals Dashboard (Cloud) auswählen.
Messwerte von Google an Partner
Der Messwert Erfolgsrate für Abfragen/Ausführungen >= 99,5% gibt an, wie oft Nutzerbefehle korrekt ausgeführt werden.So können Assistant-Antworten wie „Ich kann das Gerät nicht erreichen“ oder die falsche Bestätigung eines Befehls, der nicht ausgeführt wurde, vermieden werden.
Was definiert „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 mit einer lowBattery-Ausnahme), werden als erfolgreiche Transaktionen gezählt.
Der Befehl hat das Gerät erreicht und der Intent wurde trotz der Warnung erfüllt.
Was definiert „Fehler“?
Die Fehler, die unter Häufige Plattformfehlercodes gefunden wurden und als Partner Actionable markiert sind, werden bei der Berechnung der Erfolgsraten für QUERY und EXECUTE als "Fehler" betrachtet. Außerdem sind die Fehler unter Fehler und Ausnahmen ebenfalls „Fehler“, mit den folgenden Ausnahmen:
| Ausnahmen bei Fehlern | ||
|---|---|---|
| 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 |
Der Messwert Latenz für Abfragen/Ausführungen (90. Perzentil) <= 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. einige Sekunden, bis das Licht ausgeschaltet wird.
Latenzmesswerte
Die Latenz ist ein wichtiger Indikator dafür, wie schnell Ihre Integration für den Endnutzer reagiert. Im Dashboard wird die Latenz des 90. Perzentils (P90) erfasst, die die Erfahrung Ihrer „langsamsten“ Nutzer darstellt. Ein P90 von 800 ms bedeutet beispielsweise, dass 90% der Anfragen in 800 ms oder weniger bestätigt werden.
Google misst die Latenz für Statusprüfungen und Gerätebefehle unterschiedlich, um die technische Genauigkeit zu gewährleisten.
1. Abfragelatenz (interrogativ)
Hier 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 Ihre Auftragsausführungs-URL. - Messzeitraum: 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. Ausführungslatenz (Aktion)
Hier wird die Zeit für die Befehlsbestätigung gemessen, wenn Google eine Steueranfrage an ein Gerät sendet.
- Start: Google sendet eine
action.devices.EXECUTE-Anfrage an Ihre Auftragsausführungs-URL. - Messzeitraum: Die Zeit, die Ihre Cloud benötigt, um den Befehl zu empfangen und eine Bestätigungsantwort zurückzugeben.
- Ende: Google empfängt die Statusantwort
SUCCESS,PENDINGoderOFFLINE. - Technischer Umfang: Dieser Messwert misst die Zeit für die Bestätigung der Antwort zwischen der Cloud von Google und Ihrer Cloud. Er misst nicht die Zeit, die die physische Hardware (z. B. eine Glühbirne) benötigt, um die physische Statusänderung abzuschließen, da dies oft die Latenz des lokalen Mesh-Netzwerks außerhalb des Cloud-to-Cloud-Pfads beinhaltet.
Optionen zur Reduzierung der Latenz
Architektonische Empfehlungen für das geografische Routing
Wenn die Anycast-IP-Implementierung nicht möglich ist, empfehlen wir die folgenden kostengünstigen Alternativen, um sicherzustellen, dass Nutzer vom nächstgelegenen regionalen Rechenzentrum bedient werden.
Globales Load-Balancing (GLB)
Verwenden Sie anstelle des statischen Routings einen globalen Application Load Balancer (verfügbar bei den meisten großen Cloud-Anbietern).
Funktionsweise:Sie konfigurieren einen einzelnen globalen Einstiegspunkt (URL), der sich am Netzwerkrand befindet. Der Load-Balancer erkennt automatisch den geografischen Ursprung der Anfrage von den Auftragsausführungsclustern von Google und leitet den Traffic an Ihr nächstgelegenes fehlerfreies regionales Backend weiter.
Vorteil:Dies bietet die Leistung von Anycast mit deutlich geringerer Konfigurationskomplexität und geringeren Kosten.
Standortbezogenes DNS (GeoDNS)
Funktionsweise:Konfigurieren Sie Ihren DNS-Anbieter so, dass Ihre 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 Egress-Punkte von Google optimiert ist. Wenn die regionalen Auftragsausführungsdienste 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
Neben dem Routing auf Infrastrukturebene können Sie die folgenden Strategien auf der Anwendungsebene implementieren, um die Latenz bei der Anfrageverarbeitung zu reduzieren.
Die „Trampolin“-Proxy-Methode
Wenn Sie ein primäres Rechenzentrum beibehalten müssen, verwenden Sie regionale Lightweight-Proxy-Server (Trampoline), um den ersten Handshake zu verarbeiten.
Google ruft Ihre globale URL auf.
Ein regionaler Proxy (z. B. eine Lightweight-Nginx- oder Lambda-Funktion) empfängt die Anfrage.
Der Proxy leitet die Nutzlast über Ihr internes Hochgeschwindigkeits-Backbone an die primäre Datenbank weiter.
Vorteil:Dadurch wird die Zeit für den TCP-Handshake reduziert, die oft den größten Beitrag zur Latenz bei Anfragen über große Entfernungen leistet.
Hinweise zur Region für Zugriffstoken
Während der Kontoverknüpfung (OAuth) kann Ihr System die Heimatregion des Nutzers ermitteln.
Implementierung:Codieren Sie eine Regions-ID in das
access_token, das an Google ausgegeben wird. Wenn Google eine Auftragsausfü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.
Systemstatus – Messwerte von Partner an Google
Wenn Sie eine Erfolgsrate von >= 99,5% beibehalten, können Sie sicherstellen, dass die Gerätestatus in Google Home korrekt sind, Geräte hinzugefügt und entfernt werden, Automatisierungen ausgelöst werden und Verlaufsereignisse auf dem Tab „Aktivität“ der Google Home app (GHA) angezeigt werden.
Die Erfolgsrate wird anhand der HTTP-Antwortcodes berechnet, die von Google zurückgegeben werden, wenn Ihre Cloud Statusaktualisierungen sendet. Damit Partner nicht für infrastrukturbezogene Probleme auf Google-Seite bestraft werden, werden interne Google-Fehler bei der Berechnung der Fehleranzahl ausgeschlossen. Die in der Berechnung enthaltenen API-Aufrufe finden Sie in der HomeGraph API-Referenz.
Was definiert „Erfolg“?
- 2xx (Erfolg): Die Statusaktualisierung wurde von Home Graph erfolgreich empfangen und verarbeitet.
Was definiert „Fehler“?
- 4xx (Partnerfehler): Diese Fehler stellen Fehler dar und weisen auf ein Problem mit der Anfrage hin, die von Ihrer Cloud gesendet wurde. Häufige Codes sind:
- 400 Bad Request: 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.
- 404 Not Found: Die angeforderte Ressource konnte nicht gefunden werden. In der Regel bedeutet dies, dass Google das angeforderte Gerät nicht finden kann. Es kann auch bedeuten, dass das Nutzerkonto nicht verknüpft ist oder eine ungültige
agentUserIdempfangen wurde. Achten Sie darauf, dass dieagentUserIdmit dem in Ihrer SYNC-Antwort angegebenen Wert übereinstimmt und dass SieDISCONNECT-Intents ordnungsgemäß verarbeiten. - 429 Resource Exhausted: Ihre Integration hat das zugewiesene Kontingent überschritten. Eine Anleitung zur Kontingentverwaltung finden Sie oben im Abschnitt „Schritt 1“ des Dashboards.
Gerätezustand – Statusgenauigkeit
Wenn Sie eine Statusgenauigkeit von >= 99,5% erreichen oder übertreffen, können Sie sicherstellen, dass Nutzer korrekte Ergebnisse sehen, wenn sie Gerätestatus aufrufen oder KI-Funktionen wie „Home fragen“ verwenden. Wenn die Statusgenauigkeit niedrig ist, werden Automatisierungen möglicherweise nicht ausgelöst und Verlaufseinträge werden möglicherweise nicht rechtzeitig auf dem Tab „Aktivität“ der GHAangezeigt. Weitere Informationen finden Sie unter Status melden.
Im Qualitäts-Dashboard wird dies stündlich anhand von zwei verschiedenen Messwerten erfasst: Gesamtgenauigkeit und Niedrigste Kombination aus Typ und Merkmal.
1. Komponenten der Genauigkeit
Der Messwert wird aus „Beispielen“ abgeleitet, bei denen Google den gemeldeten Status mit einem bekannten Intent-Ergebnis vergleichen kann.
2. Dashboardmesswerte (stündliche Berechnung)
Im Dashboard wird die Genauigkeit basierend auf einem 1-Stunden-Intervall berechnet. Wenn in einer Stunde weniger als 100 Gesamtbeispiele vorhanden sind (S_Total < 100), wird die Genauigkeit für diese Stunde auf N/A festgelegt.
Ansicht 1: Gesamtgenauigkeit (globaler Durchschnitt)
Dies ist die Gesamtgenauigkeit Ihrer Integration für alle Gerätetypen und Merkmale zusammen. Sie bietet einen gewichteten Durchschnitt des Status Ihres gesamten Ökosystems.
- Berechnung: Gesamtgenauigkeit des Status für alle Geräte / Gesamtstatus für alle Geräte.
Ansicht 2: Niedrigste Kombination aus Typ und Merkmal
Hier wird die unzuverlässigste spezifische Kategorie in Ihrer Integration ermittelt. So wird verhindert, dass Geräte mit hohem Volumen und hoher Qualität Geräte mit niedrigem Volumen und niedriger Qualität verbergen. Wenn Sie beispielsweise eine große Anzahl von Lampen mit einer Statusgenauigkeit von über 99,5% haben, aber nur wenige Schalter mit einer niedrigen Statusgenauigkeit, wird hier die Verbesserung hervorgehoben, die bei Schaltern erforderlich ist und die bei einem Durchschnittswert möglicherweise nicht sichtbar ist.
- Berechnung: Minimum der Statusgenauigkeit / Gesamtstatus für alle Kombinationen aus Trait und Gerät.