Ten zestaw paneli i alertów pomaga proaktywnie utrzymywać integrację wysokiej jakości z ekosystemem Google Home. Google dokłada wszelkich starań, aby wspierać partnerów w tworzeniu ekosystemu wysokiej jakości dla wszystkich klientów.
Panel składa się z 3 sekcji, z których każda obejmuje kluczową część wpływającą na jakość ogólnej integracji.
Dane Google dotyczące partnera – mierzą kondycję połączeń z Google z Twoim backendem w chmurze.
Kondycja systemu – dane partnera dotyczące Google – mierzą kondycję połączeń z Twojego systemu z Google.
Kondycja urządzenia – dokładność stanu – mierzy dokładność stanów przechowywanych w systemach Google, które są używane do obsługi zapytań użytkowników.
Gdy dane nie spełniają wartości docelowych, są wyróżniane na czerwono, co wskazuje na problem, który może mieć wpływ na wygodę użytkowników. Poniższe informacje zawierają szczegóły dotyczące każdego celu i wyjaśniają, dlaczego jest on ważny dla użytkowników.
Jeśli ten przycisk nie przekierowuje bezpośrednio do panelu, możesz go otworzyć, klikając kolejno Przegląd > Panele i na liście Moje panele wybierając Panel Google Home Vitals (Cloud).
Dane Google dotyczące partnera
Dane Współczynnik powodzenia zapytań/wykonywania >= 99,5% mierzą, jak często polecenia użytkowników są prawidłowo wykonywane.Pomaga to uniknąć odpowiedzi Asystenta typu „Nie mogę się połączyć z urządzeniem” lub nieprawidłowego potwierdzania polecenia, które nie zostało wykonane.
Co oznacza „powodzenie”?
Transakcja jest oznaczana jako udana, jeśli platforma Google Home otrzyma prawidłową odpowiedź wskazującą, że zamierzone działanie zostało wykonane lub żądany stan został pobrany.
Odpowiedzi, które zawierają wyjątki nieblokujące (np. stan SUCCESS z wyjątkiem lowBattery), są liczone jako udane transakcje.
Polecenie dotarło do urządzenia, a intencja została spełniona pomimo ostrzeżenia.
Co oznacza „niepowodzenie”?
Błędy znalezione w sekcji Typowe kody błędów platformy które są oznaczone jako Wymagane działanie partnera są uznawane za "niepowodzenia" podczas obliczania współczynników powodzenia zapytań i wykonywania. Dodatkowo błędy znalezione w sekcji Błędy i wyjątki są również "niepowodzeniami", z wyjątkiem tych:
| Wyjątki dotyczące niepowodzeń | ||
|---|---|---|
| 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 |
Wskaźnik Czas oczekiwania na zapytanie/wykonanie (p90) <= 1000 ms mierzy czas oczekiwania na żądane działanie i pomaga zapewnić, że użytkownicy nie będą musieli zbyt długo czekać, np. kilka sekund na wyłączenie światła.
Dane dotyczące czasu oczekiwania
Czas oczekiwania jest kluczowym wskaźnikiem tego, jak szybko integracja reaguje na działania użytkownika. Panel śledzi czas oczekiwania na 90. percentylu (P90), który reprezentuje wygodę „najwolniejszych” użytkowników (np. P90 wynoszący 800 ms oznacza, że 90% żądań jest potwierdzanych w ciągu 800 ms lub krócej).
Aby zapewnić dokładność techniczną, Google mierzy czas oczekiwania inaczej w przypadku sprawdzania stanu niż w przypadku poleceń urządzenia.
1. Czas oczekiwania na zapytanie (interrogative)
Mierzy czas podróży w obie strony Cloud-to-cloud, gdy Google prosi o bieżący stan urządzenia.
- Początek: Google wysyła żądanie
action.devices.QUERYna Twój adres URL realizacji. - Okres pomiaru: czas potrzebny Twojej chmurze na odebranie, przetworzenie i przesłanie pełnej odpowiedzi HTTP z powrotem do Google.
- Koniec: Google otrzymuje i potwierdza końcowy ładunek odpowiedzi z Twojej usługi.
2. Czas oczekiwania na wykonanie (action)
Mierzy czas potwierdzenia polecenia, gdy Google wysyła żądanie sterowania do urządzenia.
- Początek: Google wysyła żądanie
action.devices.EXECUTEna Twój adres URL realizacji. - Okres pomiaru: czas potrzebny Twojej chmurze na odebranie polecenia i zwrócenie odpowiedzi z potwierdzeniem.
- Koniec: Google otrzymuje odpowiedź ze stanem
SUCCESS,PENDINGlubOFFLINE. - Zakres techniczny: te dane mierzą czas „potwierdzenia odpowiedzi” między chmurą Google a Twoją chmurą. Nie mierzą czasu potrzebnego sprzętowi (np. żarówce) na zmianę stanu fizycznego, ponieważ często wiąże się to z czasem oczekiwania w lokalnej sieci typu mesh poza ścieżką między chmurami.
Opcje skracania czasu oczekiwania
Zalecenia dotyczące architektury w przypadku routingu geograficznego
Jeśli wdrożenie protokołu Anycast IP nie jest możliwe, zalecamy te ekonomiczne alternatywy, aby zapewnić, że użytkownicy będą obsługiwani przez najbliższe regionalne centrum danych.
Globalne równoważenie obciążenia (GLB)
Zamiast routingu statycznego używaj globalnego systemu równoważenia obciążenia aplikacji (dostępnego u większości głównych dostawców usług w chmurze).
Jak to działa: konfigurujesz pojedynczy globalny punkt wejścia (adres URL), który znajduje się na brzegu sieci. System równoważenia obciążenia automatycznie wykrywa geograficzne pochodzenie żądania z klastrów realizacji Google i kieruje ruch do najbliższego regionalnego backendu.
Zaleta: zapewnia wydajność protokołu Anycast przy znacznie niższym stopniu złożoności konfiguracji i kosztach.
DNS z uwzględnieniem lokalizacji geograficznej (GeoDNS)
Jak to działa: skonfiguruj dostawcę DNS tak, aby rozpoznawał Twój adres URL realizacji na podstawie położenia geograficznego zapytania DNS.
Wdrożenie: upewnij się, że dostawca DNS jest zoptymalizowany pod kątem punktów wyjścia Google. Gdy regionalne usługi realizacji Google (np. w Stanach Zjednoczonych, UE lub Azji) rozpoznają Twoją domenę, otrzymają adres IP centrum danych w tym regionie.
Strategie optymalizacji na poziomie aplikacji
Oprócz routingu na poziomie infrastruktury możesz wdrożyć te strategie na poziomie aplikacji, aby skrócić czas oczekiwania podczas przetwarzania żądań.
Metoda serwera proxy „Trampoline”
Jeśli musisz utrzymywać główne centrum danych, używaj regionalnych serwerów proxy (Trampolines) do obsługi początkowego uzgadniania.
Google wysyła żądanie na Twój globalny adres URL.
Żądanie odbiera regionalny serwer proxy (np. funkcja Nginx lub Lambda).
Serwer proxy przekazuje ładunek przez wewnętrzną szybką sieć szkieletową do głównej bazy danych.
Zaleta: skraca czas „uzgadniania TCP”, który często jest największym czynnikiem wpływającym na czas oczekiwania w przypadku żądań na duże odległości.
Wskazówki dotyczące regionu tokena dostępu
Podczas procesu łączenia kont (OAuth) Twój system może zidentyfikować region domowy użytkownika.
Wdrożenie: zakoduj identyfikator regionu w tokenie
access_tokenwydanym Google. Gdy Google wysyła żądanie realizacji, Twoja brama może natychmiast sprawdzić token i przekierować żądanie do odpowiedniego klastra regionalnego bez konieczności wyszukiwania w bazie danych.
Kondycja systemu – dane partnera dotyczące Google
Utrzymywanie współczynnika powodzenia >= 99,5% pomaga zapewnić, że stany urządzeń są prawidłowe w Google Home, urządzenia są dodawane i usuwane, automatyzacje są uruchamiane, a zdarzenia z historii pojawiają się na karcie Aktywność w Google Home app (GHA).
Współczynnik powodzenia jest obliczany na podstawie kodów odpowiedzi HTTP zwracanych przez Google, gdy Twoja chmura wysyła aktualizacje stanu. Aby partnerzy nie byli karani za problemy z infrastrukturą po stronie Google, dane wykluczają błędy wewnętrzne Google z liczby niepowodzeń. Wywołania interfejsu API uwzględnione w obliczeniach znajdziesz w dokumentacji interfejsu HomeGraph API.
Co oznacza „powodzenie”?
- 2xx (powodzenie): aktualizacja stanu została pomyślnie odebrana i przetworzona przez Home Graph.
Co oznacza „niepowodzenie”?
- 4xx (błąd partnera): te kody oznaczają niepowodzenia i wskazują na problem z żądaniem wysłanym z Twojej chmury. Typowe kody:
- 400 Nieprawidłowe żądanie: serwer nie mógł przetworzyć żądania z powodu nieprawidłowej składni. Typowe przyczyny to nieprawidłowy format JSON lub użycie wartości null zamiast "" w przypadku wartości ciągu.
- 404 Nie znaleziono: nie udało się znaleźć żądanego zasobu. Zwykle oznacza to, że Google nie może znaleźć żądanego urządzenia. Może to też oznaczać, że konto użytkownika nie jest połączone lub otrzymano nieprawidłowy identyfikator
agentUserId. Upewnij się, że identyfikatoragentUserIdjest zgodny z wartością podaną w odpowiedzi SYNC i że prawidłowo obsługujesz intencjeDISCONNECT. - 429 Zasób wyczerpany: Twoja integracja przekroczyła przydzielony limit. Instrukcje dotyczące zarządzania limitami znajdziesz w sekcji „Krok 1” powyżej.
Kondycja urządzenia – dokładność stanu
Spełnienie lub przekroczenie dokładności stanu >= 99,5% pomaga zapewnić, że użytkownicy będą widzieć prawidłowe wyniki, gdy wyświetlają stany urządzeń lub korzystają z funkcji opartych na AI, takich jak Zapytaj Home. Jeśli dokładność stanu jest niska, automatyzacje mogą się nie uruchamiać, a wpisy w historii mogą nie pojawiać się na karcie Aktywność w aplikacji GHA we właściwym czasie. Więcej informacji znajdziesz w sekcji Zgłaszanie stanu.
Panel jakości śledzi te dane co godzinę za pomocą 2 różnych danych: Ogólna dokładność i Najniższa kombinacja typu/cechy.
1. Składniki dokładności
Dane są wyprowadzane z „próbek”, w których Google może zweryfikować zgłoszony stan na podstawie znanego wyniku intencji.
2. Dane panelu (obliczenia godzinowe)
Panel oblicza dokładność na podstawie 1-godzinnego interwału. Jeśli w ciągu godziny łączna liczba próbek jest mniejsza niż 100 (S_Total < 100), dokładność w tym okresie jest ustawiana na N/A.
Widok 1. Ogólna dokładność (średnia globalna)
Reprezentuje łączną dokładność integracji we wszystkich typach urządzeń i cechach. Jest to średnia ważona kondycji całego ekosystemu.
- Obliczenia: łączna dokładność stanu na wszystkich urządzeniach / łączna liczba stanów na wszystkich urządzeniach.
Widok 2. Najniższa kombinacja typu/cechy
Identyfikuje najbardziej zawodną kategorię w Twojej integracji. Zapobiega ukrywaniu urządzeń o niskiej jakości przez urządzenia o dużej liczbie i wysokiej jakości. Jeśli na przykład masz dużą liczbę świateł o dokładności stanu powyżej 99,5%, ale małą liczbę przełączników o niskiej dokładności stanu, ten widok wyróżni potrzebę poprawy w przypadku przełączników, które mogą zostać pominięte w wartości średniej.
- Obliczenia: minimum dokładności stanu / łączna liczba stanów dla wszystkich kombinacji cech i urządzeń.