Współdziałanie na Androidzie

Urządzenia w ekosystemie Google Home można wdrażać za pomocą Cloud-to-cloud, Matter lub obu tych metod. Niektóre typy urządzeń są bardziej złożone niż inne i stanowią wyzwanie dla programistów, którzy chcą używać interfejsów Home API w sposób umożliwiający płynną współpracę z innymi urządzeniami w ekosystemie.

Jednym z wyzwań związanych z wdrażaniem niektórych z tych typów urządzeń jest to, że mogą one mieć różne kombinacje cech. Nie wszystkie kombinacje działają tak samo dobrze. Poza tym model danych Cloud-to-cloud jest mapowany na model danych Matter, ale nie zawsze w jasny sposób, jeden do jednego. Więcej informacji o modelach danych i ich mapowaniach znajdziesz w artykule Model danych na Androidzie.

Na tej stronie znajdziesz więcej informacji o tym, jak modele danych dla poszczególnych urządzeń są ze sobą powiązane, oraz wskazówki dotyczące cech, których należy użyć do wdrożenia tych typów urządzeń.

Piekarnik

Typ urządzenia Piekarnik (OvenDevice) i jego cechy komponentów nie są tak proste do wdrożenia jak w przypadku innych typów urządzeń. Piekarnik można zaimplementować na wiele sposobów w Matter, ale nie wszystkie podejścia zapewniają bezproblemową współpracę z innymi urządzeniami lub ekosystemem Google Home.

Mapowanie atrybutów

Zamiast implementować Matterurządzenie Oven za pomocą klastrów Oven Mode i On Off, zalecamy użycie klastra Oven Cavity Operational State. Ten klaster jest reprezentowany w interfejsach Home API przez cechę OvenCavityOperationalState i odpowiada cechom Cloud-to-cloud RunCycle. Określa fazy takie jak „rozgrzewanie”, „rozgrzany” i „studzenie”.

Model danych Cloud-to-cloud Piekarnik ma pewne ograniczenia. Model danych piekarnikaCloud-to-cloud umożliwia tylko jedną komoręRunCycle. Z kolei Matter modeluje piekarnik wielokomorowy jako punkt końcowy urządzenia z klastrem Stan operacyjny komory piekarnika dla każdej komory.

W przypadku niektórych piekarników lista faz może się zmieniać w czasie działania. Na przykład piekarniki obsługujące wstępne nagrzewanie mogą mieć inne wpisy na liście faz w trakcie wstępnego nagrzewania niż w trakcie nagrzewania lub schładzania.

Zalecana implementacja

Jak wspomnieliśmy w poprzedniej sekcji, implementacja MatterpiekarnikaMatterpowinna implementować klaster Stan operacyjny komory piekarnika, który w interfejsach Home API jest modelowany jako cecha OvenCavityOperationalState.

Aby uzyskać najlepsze wyniki, upewnij się, że Cloud-to-cloudpiekarnikCloud-to-cloudimplementuje cechę RunCycle i publikuje bieżący stan, ustawiając atrybut currentRunCycle. Ten atrybut jest widoczny dla interfejsów Home API za pomocą atrybutów OvenCavityOperationalState.phaseList i OvenCavityOperationalState.currentPhase.

Urządzenie Oven powinno też publikować powiadomienie o cyklu pracy, aktualizując atrybuty priority, status i currentCycleRemainingTime elementu RunCycle. Poniższy przykład powoduje wysłanie zdarzenia OperationalState.OperationCompletion i może być używany do wskazywania, że piekarnik przeszedł z cyklu „podgrzewanie wstępne” do cyklu „podgrzany”:

{
  "currentRunCycle": [
    {
      "currentCycle": "pre-heating",
      "nextCycle": "pre-heated",
      "lang": "en"
    }
  ],
  "currentTotalRemainingTime": 1200,
  "currentCycleRemainingTime": 300
}

Używanie piekarnika w automatyzacji

Podczas tworzenia automatyzacji dla piekarnika zaimplementowanego za pomocą klastra Stan operacyjny komory piekarnika odwołuj się do atrybutu currentPhase, aby dowiedzieć się, w jakim cyklu pracuje piekarnik:

   sequential {
    val starterNode =
      starter<_>(oven, OvenDevice, OvenCavityOperationalState /* Or OperationalState */)
    condition {
      expression = starterNode.phaseList[operationalState.currentPhase.toUInt()] equals "pre-heated"
    }
    action(speaker, SpeakerDevice) {
    command(AssistantBroadcast.broadcast("Oven Cycle Complete"))
  }
  // Additional actions here as needed
}

Pełny przykład znajdziesz w artykule Migaj światłami i informuj, gdy piekarnik osiągnie wybraną temperaturę.