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 asystenci domowi, składają się z węzłów¹. Węzeł to unikalny, identyfikowalny i adresowalny 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 zbiór punktów końcowych. Każdy punkt końcowy zawiera zestaw funkcji. Na przykład punkt końcowy może być powiązany z funkcją oświetlenia, podczas gdy 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 uruchamianie.
• Kontroler: węzeł, który może sterować co najmniej 1 węzłem. Przykłady to Google Home app (GHA), Google Assistant, i Google Nest Hub (2nd gen). Niektóre typy urządzeń, np. włącznik światła, mają rolę kontrolera .
• Kontrolowany: węzeł, który może być sterowany przez co najmniej 1 węzeł. Większość typów urządzeń może być kontrolowana, z wyjątkiem niektórych typów urządzeń które mają rolę kontrolera, np. włącznika światła. Włącznik światła może być tylko kontrolerem. Nie może być kontrolowany.
• Dostawca OTA: węzeł, który może udostępniać aktualizacje oprogramowania OTA.
• Osoba wysyłająca prośbę o OTA: węzeł, który może wysyłać prośby o aktualizacje oprogramowania OTA.

Klastry

W punkcie końcowym węzeł ma co najmniej 1 klaster. Jest to kolejny poziom w hierarchii urządzeń, ponieważ grupuje on określone funkcje, takie jak klaster włączania/wyłączania w inteligentnej wtyczce lub klaster sterowania poziomem 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 udostępniać niezależne sterowanie poszczególnymi światłami, a listwa zasilająca może udostępniać sterowanie poszczególnymi gniazdami.

Atrybuty

Na ostatnim poziomie znajdziemy atrybuty, czyli stany utrzymywane przez węzeł, takie jak atrybut bieżący poziom klastra sterowania poziomem. Atrybuty mogą być zdefiniowane jako różne typy danych, takie jak uint8, ciągi znaków lub tablice.

Polecenia

Oprócz atrybutów klastry mają też polecenia, czyli działania, które można wykonać. Są one odpowiednikiem w Matter's DM zdalnego wywołania procedury. Polecenia przypominają czasowniki, np. zamknij drzwi w klastrze zamka w drzwiach. Polecenia mogą generować odpowiedzi i wyniki. W Matter, takie odpowiedzi są też definiowane jako polecenia, ale w odwrotnym kierunku.

Wydarzenia

Na koniec klastry mogą też mieć wydarzenia, które można traktować jako zapis poprzednich przejść między stanami. Atrybuty reprezentują bieżące stany, a wydarzenia to dziennik przeszłości, który zawiera rosnący licznik, sygnaturę czasową i priorytet. Umożliwiają one rejestrowanie przejść między stanami oraz modelowanie danych, które nie jest łatwo osiągalne za pomocą atrybutów.

Punkt końcowy 0 jest zarezerwowany dla klastrów narzędziowych. Klastry narzędziowe to konkretne klastry, które zawierają funkcje serwisowe w punkcie końcowym, takie jak wykrywanie, adresowanie, diagnostyka i aktualizacja oprogramowania. Z kolei klastry aplikacji obsługują podstawowe działania, takie jak włączanie/wyłączanie lub pomiar temperatury.

Typy urządzeń

Jakie kombinacje klastrów powinny być uwzględnione, 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 w drzwiach lub odtwarzacz wideo.

Typy urządzeń nie są określone w Matter głównym dokumencie specyfikacji, ale w dokumencie towarzyszącym – bibliotece urządzeń. Podobnie wszystkie klastry aplikacji są zdefiniowane w bibliotece klastrów aplikacji. Te 3 dokumenty można znaleźć na Connectivity Standards Alliance (Alliance) stronie internetowej członków.

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 są częścią typu urządzenia.

Klienci i serwery

Klastry mogą być klastrami klienta lub klastrami serwera. Serwer jest stanowy i zawiera atrybuty, wydarzenia i polecenia, a klient jest bezstanowy i jego zadaniem jest inicjowanie interakcji ze zdalnym klastrem serwera, a tym samym wykonywanie tych działań:

• odczytywanie i zapisywanie zdalnych atrybutów,
• odczytywanie zdalnych wydarzeń,
• wywoływanie zdalnych poleceń.

O ile DM jest hierarchiczny w węźle, o tyle relacja między węzłami nie jest. Węzły w Matter nie mają relacji pionowych kontroler/urządzenie peryferyjne ani lider/naśladowca. Wręcz przeciwnie, 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 na przykład mieć 2 lampy stołowe: węzeł A i węzeł B. Oba węzły implementują typ urządzenia włącznik światła. Ten typ urządzenia zawiera klaster serwera włącznika/wyłącznika , który steruje odpowiednimi fizycznymi źródłami światła.

Jednak tak jak w przypadku typowych lamp stołowych, nasze urządzenia fizyczne będą też zawierać typ urządzenia włącznik światła dla lokalnych włączników. Ten typ urządzenia musi implementować klaster klienta włącznika , aby mógł sterować klastrami serwera.

W tym przykładzie klaster klienta włącznika w węźle A zmienia atrybuty klastra serwera włącznika w węźle A i węźle B, a klaster klienta w węźle B zmienia tylko klaster serwera w samym węźle B.

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

Klaster deskryptora

Jak sama nazwa wskazuje, serwer klastra deskryptora udostępnia informacje o introspekcji. Opisuje punkt końcowy, wymieniając jego:

• klastry serwera,
• klastry klienta,
• typy urządzeń,
• dodatkowe punkty końcowe, zwane częściami.

Każdy typ urządzenia wymaga implementacji klastrów deskryptora. Typ urządzenia głównego jest zdefiniowany w punkcie końcowym 0. Odczytanie jego klastra deskryptora zapewni klientowi widoczność, która umożliwi mu przechodzenie przez pełne drzewo dostępnych punktów końcowych i wykonywanie odpowiednich operacji.

Komisarz lub urządzenie sterujące, takie jak telefon lub hub, może używać informacji znalezionych w klastrze deskryptora do modelowania urządzenia (światła, przełącznika, pompy, termostatu) i konkretnych funkcji zaimplementowanych przez tę instancję urządzenia, wyświetlając użytkownikowi prawidłowy interfejs.

Klastry serwera

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

Klastry klienta

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 ich odpowiednimi wersjami. Musi zawierać co najmniej 1 typ urządzenia.

Lista części

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

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

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

Inne typy urządzeń mogą być tworzone w strukturze drzewa z więcej niż 1 instancji typu urządzenia. Na przykład typ urządzenia odtwarzacza wideo może składać się z typów urządzeń telewizora, odtwarzacza wideo, głośnika i różnych aplikacji do treści, z których każdy znajduje się w innym punkcie końcowym.