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 jak inne. Ponadto model danych Cloud-to-cloud jest mapowany na model danych Matter, jednak nie zawsze w przejrzysty i bezpośredni sposób. 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żywać do implementowania tych typów urządzeń.
Piekarnik
Typ urządzenia Piekarnik (OvenDevice) i jego cechy komponentów nie są tak proste do wdrożenia jak inne typy urządzeń. Istnieje wiele sposobów na zaimplementowanie piekarnika w Matter, jednak 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 on fazy takie jak „wstępne ogrzewanie”, „wstępnie ogrzane” i „schładzanie”.
| Interfejsy Home API | Cloud-to-cloud |
|---|---|
OvenCavityOperationalState
|
RunCycle
|
Istnieją ograniczenia modelu danych Cloud-to-cloud Oven. Cloud-to-cloudModel danych piekarnika dopuszcza tylko jedną komoręCloud-to-cloud z jednym RunCycle. Z kolei Matter modeluje wielokomorowy piekarnik 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 podgrzewanie wstępne mogą mieć inne wpisy na liście faz w trakcie podgrzewania wstępnego niż w trakcie podgrzewania lub schładzania.
Zalecana implementacja
Jak wspomnieliśmy w poprzedniej sekcji, implementacja MatterpiekarnikaMatterpowinna implementować klaster stanu operacyjnego 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 w interfejsach 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 służyć do wskazania, że piekarnik przeszedł z cyklu „podgrzewanie” 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 znajduje się 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ące światła i powiadomienie, gdy piekarnik osiągnie wybraną temperaturę.