Model danych urządzenia

Urządzenia w Matter mają dobrze zdefiniowany model danych (DM), który jest hierarchicznym modelem funkcji urządzenia. Na najwyższym poziomie tej hierarchii znajduje się urządzenie.

Urządzenia i punkty końcowe

Wszystkie urządzenia, w tym smartfony i asystenty domowe, składają się z węzłów¹. Węzeł to jednoznacznie identyfikowalny i zaadresowalny zasób w sieci, który użytkownik może postrzegać jako funkcjonalną całość. Komunikacja sieciowa w Matter rozpoczyna się i kończy w węźle.

Węzły to zbiory punktów końcowych. Każdy punkt końcowy zawiera zestaw funkcji. Na przykład jeden punkt końcowy może być powiązany z funkcją oświetlenia, inny z wykrywaniem ruchu, a jeszcze inny z narzędziami, takimi jak OTA urządzenia.

Role węzłów

Rola węzła to zestaw powiązanych zachowań. Każdy węzeł może mieć co najmniej 1 rolę. Role węzłów obejmują:

• Komisarz: węzeł, który wykonuje uruchomienie.
• Kontroler: węzeł, który może sterować co najmniej jednym węzłem. Przykłady: Google Home app (GHA), Google Assistant i Google Nest Hub (2nd gen). Niektóre typy urządzeń, takie jak przełącznik światła, mają rolę kontrolera.
• Urządzenie kontrolowane: węzeł, który może być kontrolowany przez co najmniej 1 węzeł. Większość typów urządzeń może być urządzeniem sterowanym, z wyjątkiem niektórych typów urządzeń, które mają rolę kontrolera, takich jak włącznik/wyłącznik światła. Przełącznik światła może być tylko kontrolerem. Nie może być urządzeniem kontrolowanym.
• Dostawca OTA: węzeł, który może dostarczać aktualizacje oprogramowania OTA.
• Żądający OTA: węzeł, który może żądać aktualizacji oprogramowania OTA.

Klastry

W ramach punktu końcowego węzeł ma co najmniej 1 klaster. Są one kolejnym krokiem w hierarchii urządzeń, ponieważ grupują określone funkcje, takie jak klaster włączania/wyłączania w inteligentnej wtyczce lub klaster regulacji poziomu w punkcie końcowym ściemnianego światła.

Węzeł może też mieć kilka punktów końcowych, z których każdy tworzy instancję tej samej funkcji. Na przykład oprawa oświetleniowa może umożliwiać niezależne sterowanie poszczególnymi lampami, a listwa zasilająca – poszczególnymi gniazdami.

Atrybuty

Na ostatnim poziomie znajdziemy atrybuty, czyli stany węzła, takie jak atrybut bieżącego poziomu klastra sterowania poziomem. Atrybuty mogą być definiowane jako różne typy danych, takie jak uint8, ciągi znaków lub tablice.

Polecenia

Oprócz atrybutów klastry mają też polecenia, które są działaniami, jakie można wykonać. Są one odpowiednikiem zdalnego wywołania procedury w modelu danych Matter. Polecenia są podobne do czasowników, np. zamknij drzwi w klastrze Zamek drzwi. Polecenia mogą generować odpowiedzi i wyniki. W Matter takie odpowiedzi są również definiowane jako Polecenia, ale działające w odwrotnym kierunku.

Wydarzenia

Klastry mogą też mieć zdarzenia, które można traktować jako zapis wcześniejszych zmian stanu. Atrybuty reprezentują bieżące stany, natomiast zdarzenia są dziennikiem przeszłości i zawierają monotonicznie rosnący licznik, sygnaturę czasową i priorytet. Umożliwiają one rejestrowanie zmian stanu, a także modelowanie danych, którego nie można łatwo osiągnąć za pomocą atrybutów.

Punkt końcowy 0 jest zarezerwowany dla klastrów narzędzi. Klastry użytkowe to konkretne klastry, które obejmują funkcje obsługi punktu końcowego, takie jak wykrywanie, adresowanie, diagnostyka i aktualizacja oprogramowania. Z kolei klastry aplikacji obsługują działania podstawowe, takie jak włączanie i wyłączanie czy pomiar temperatury.

Typy urządzeń

Jakie kombinacje klastrów powinny być uwzględniane, gdy producent planuje nowe urządzenie?

Specyfikacja Matter wymaga, aby urządzenie implementowało lub rozszerzało co najmniej 1 typ urządzenia. Typ urządzenia to zbiór obowiązkowych i opcjonalnych klastrów, które definiują atrybuty najwyższego poziomu urządzenia fizycznego, takie jak Ściemniane światło, Zamek drzwi czy Odtwarzacz wideo.

Typy urządzeń nie są określone w głównym dokumencie specyfikacji Matter, ale w dokumencie towarzyszącym: Biblioteka urządzeń. Podobnie wszystkie klastry aplikacji są zdefiniowane w bibliotece klastrów aplikacji. Te 3 dokumenty znajdziesz na stronie dla członków Connectivity Standards Alliance (Alliance).

Każdy punkt końcowy implementujący typ urządzenia musi implementować obowiązkowe klastry, które definiują ten typ urządzenia. Oprócz obowiązkowych klastrów punkt końcowy może implementować dodatkowe klastry, w tym co najmniej 1 opcjonalny klaster typu urządzenia, a nawet klastry, które nie należą do typu urządzenia.

Klienty i serwery

Klastry mogą być klastrami klienta lub klastrami serwera. Serwer jest stanowy i zawiera atrybuty, zdarzenia i polecenia, natomiast klient jest bezkolizyjny i jego zadaniem jest inicjowanie interakcji ze zdalnym klastrem serwerów, co umożliwia:

• odczytuje i zapisuje swoje zdalne atrybuty.
• odczytów zdarzeń zdalnych.
• wywołanie poleceń zdalnych.

Chociaż DM jest hierarchiczny w obrębie węzła, relacja między węzłami nie jest hierarchiczna. Węzły w Matter nie mają relacji kontroler/urządzenie peryferyjne ani lider/obserwator. Relacja jest pozioma: każdy klaster może być serwerem lub klientem. Dlatego węzeł może być zarówno serwerem, jak i klientem w odniesieniu do różnych klastrów i funkcji.

Możemy mieć na przykład 2 lampy stołowe: węzeł A i węzeł B. Oba węzły implementują typ urządzenia On/Off Light. Ten typ urządzenia obejmuje klaster serwera włączania/wyłączania, który steruje odpowiednimi fizycznymi wyjściami światła.

Jednak, jak to zwykle bywa w przypadku lamp stołowych, nasze urządzenia fizyczne będą też zawierać typ urządzenia Przełącznik światła dla lokalnych przełączników. Ten typ urządzenia musi implementować klaster On/Off Client, aby mógł kontrolować klastry serwerów.

W tym przykładzie klaster klienta On/Off w węźle A zmienia atrybuty klastra serwera On/Off w węźle A i węźle B, podczas gdy klaster klienta w węźle B zmienia tylko klaster serwera w węźle B.

W następnej sekcji szczegółowo opiszemy, jak klastry klienta i serwera wchodzą ze sobą w interakcje: model interakcji.

Klaster deskryptorów

Jak sama nazwa wskazuje, serwer klastra deskryptorów dostarcza informacje o introspekcji. Opisuje on punkt końcowy, wymieniając jego:

• Klastry serwerów.
• Klastry klientów.
• Typy urządzeń.
• dodatkowe punkty końcowe, nazywane częściami.

Każdy typ urządzenia wymaga wdrożenia klastrów deskryptorów. Typ urządzenia głównego jest zdefiniowany w punkcie końcowym 0. Odczytanie klastra deskryptorów zapewni klientowi widoczność umożliwiającą przechodzenie przez całe drzewo dostępnych punktów końcowych i wykonywanie odpowiednich operacji.

Urządzenie komisarza lub urządzenie sterujące, takie jak telefon lub centrum, może używać informacji znalezionych w klastrze deskryptorów do modelowania urządzenia (światło, przełącznik, pompa, termostat) i konkretnych funkcji zaimplementowanych przez tę konkretną instancję urządzenia, wyświetlając użytkownikowi prawidłowy interfejs.

Klastry serwerów

Atrybut ServerList zawiera listę serwerów klastra w punkcie końcowym.

Klastry klientów

Atrybut ClientList zawiera listę klientów klastra w punkcie końcowym.

Lista typów urządzeń

Atrybut DeviceTypeList to lista typów urządzeń obsługiwanych przez punkt końcowy wraz z odpowiednimi wersjami. Musi zawierać co najmniej 1 typ urządzenia.

Lista części

PartsList zawiera listę punktów końcowych używanych do implementacji tego typu urządzenia.

PartsList punktu końcowego 0 (węzła głównego) zawiera wszystkie punkty końcowe urządzenia oprócz samego siebie (punktu końcowego 0).

Wartość PartsList innych punktów końcowych jest zwykle pusta. Na przykład czujnik temperatury wymaga klastra serwera pomiaru temperatury i niczego więcej.

Inne typy urządzeń mogą być złożone w strukturę drzewa składającą się z więcej niż 1 instancji typu urządzenia. Na przykład typ urządzenia Odtwarzacz wideo może składać się z telewizora, odtwarzacza wideo, głośnika i różnych typów urządzeń z aplikacjami do odtwarzania treści, z których każdy jest powiązany z innym punktem końcowym.