Urządzenia w ekosystemie Google Home można implementować za pomocą Cloud-to-cloud, Matter, lub obu tych rozwiązań. Niektóre typy urządzeń są bardziej złożone niż inne, co utrudnia ich tworzenie przy użyciu interfejsów Home API w sposób, który umożliwia płynną współpracę z innymi urządzeniami w ekosystemie.
Jednym z wyzwań związanych z implementacją niektórych z tych typów urządzeń jest to, że mogą one składać się z różnych kombinacji cech. Nie wszystkie kombinacje działają tak dobrze jak inne. Ponadto model danych Cloud-to-cloud jest mapowany na model danych Matter, ale nie zawsze w sposób jednoznaczny i bezpośredni. Więcej informacji o modelach danych i ich mapowaniach znajdziesz w artykule Model danych w Androidzie.
Na tej stronie znajdziesz więcej informacji o tym, jak modele danych dla konkretnych urządzeń są mapowane na siebie, oraz wskazówki dotyczące tego, których cech należy użyć do implementacji tych typów urządzeń.
Piekarnik
Piekarnik
(OvenDevice)
Implementacja typu urządzenia i jego cech składowych nie jest tak prosta jak w przypadku innych typów urządzeń. Istnieje kilka sposobów implementacji piekarnika w
Matter, ale nie wszystkie z nich zapewniają bezproblemową
współpracę z innymi urządzeniami lub z ekosystemem Google Home.
Mapowanie cech
Zamiast implementować urządzenie Matter Oven za pomocą klastrów
Oven Mode i On Off, zalecamy użycie klastra Oven Cavity Operational
State. Klaster ten jest reprezentowany w interfejsach Home API przez cechę
OvenCavityOperationalState
i jest mapowany na cechę Cloud-to-cloud
RunCycle. Definiuje on fazy takie jak „wstępne ogrzewanie”, „rozgrzany” i „chłodzenie”.
| Interfejsy Home API | Cloud-to-cloud |
|---|---|
OvenCavityOperationalState
|
RunCycle
|
Model danych piekarnika Cloud-to-cloud ma pewne ograniczenia. Model danych piekarnika
Cloud-to-cloud umożliwia tylko jedną komorę,
z jednym RunCycle. Z kolei Matter modeluje
piekarnik wielokomorowy jako punkt końcowy urządzenia z klastrem Oven Cavity Operational State
dla każdej komory.
W przypadku niektórych piekarników może być odpowiednie, aby lista faz zmieniała się w czasie działania. Na przykład piekarniki, które obsługują rozgrzewanie, mogą mieć różne wpisy na liście faz podczas rozgrzewania niż podczas pieczenia lub chłodzenia.
Zalecana implementacja
Jak wspomnieliśmy w poprzedniej sekcji, implementacja Matterpiekarnika
powinna implementować klaster Oven Cavity Operational State, który
jest modelowany w interfejsach Home API jako
OvenCavityOperationalState
cecha.
Aby uzyskać jak najlepsze rezultaty, upewnij się, że urządzenie piekarnika Cloud-to-cloud implementuje cechę RunCycle i publikuje bieżący stan, ustawiając atrybut currentRunCycle. Ten atrybut jest
obserwowalny przez interfejsy Home API za pomocą
OvenCavityOperationalState.phaseList
i
OvenCavityOperationalState.currentPhase
atrybutów.
Urządzenie piekarnika powinno też publikować powiadomienie o cyklu pracy, aktualizując atrybuty priority, status i currentCycleRemainingTime cechy RunCycle. Poniższy przykład powoduje wysłanie zdarzenia
OperationalState.OperationCompletion i może służyć
do wskazania, że piekarnik przeszedł z cyklu „wstępne ogrzewanie” do cyklu
„rozgrzany”:
{
"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 Oven Cavity Operational State odwołaj się do atrybutu currentPhase, aby sprawdzić, 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 komunikat, gdy piekarnik osiągnie wybraną temperaturę.