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, inny z wykrywaniem ruchu, a jeszcze inny z narzędziami, takimi jak aktualizacja OTA urządzenia.

Role węzłów

Rola węzła to zbiór 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 jednym węzłem. Przykłady to Google Home app (GHA), Google Assistant i Google Nest Hub (2nd gen). Niektóre typy urządzeń, takie jak włącznik/wyłącznik światła, mają rolę kontrolera.
• Controlee: węzeł, którym może sterować co najmniej jeden węzeł. Większość typów urządzeń może pełnić rolę urządzenia sterowanego, z wyjątkiem niektórych typów urządzeń, które pełnią rolę urządzenia sterującego, np. włącznika/wyłącznika światła. Włącznik/wyłącznik światła może być tylko kontrolerem. Nie może być podmiotem kontrolowanym.
• Dostawca OTA: węzeł, który może udostępniać aktualizacje oprogramowania OTA.
• Podmiot wysyłający prośbę o aktualizację OTA: węzeł, który może wysyłać prośby o aktualizacje 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 na inteligentnym gniazdku lub klaster sterowania poziomem na ściemnianym punkcie końcowym oświetlenia.

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 lampami, a listwa zasilająca może udostępniać sterowanie poszczególnymi gniazdkami.

Atrybuty

Na ostatnim poziomie znajdziemy Atrybuty, czyli stany węzła, takie jak atrybut bieżący poziom klastra sterowania poziomem. Atrybuty mogą być zdefiniowane jako różne typy danych, np. 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 zdalnego wywołania procedury w Matter. Polecenia przypominają czasowniki, np. zamknij drzwi w przypadku klastra zamka do drzwi. Polecenia mogą generować odpowiedzi i wyniki. W Matter takie odpowiedzi są również definiowane jako polecenia, ale działają w odwrotnym kierunku.

Wydarzenia

Klastry mogą też zawierać zdarzenia, które można traktować jako zapis przeszłych zmian stanu. Atrybuty reprezentują bieżące stany, a zdarzenia to dziennik przeszłości. Zawierają one rosnący licznik, sygnaturę czasową i priorytet. Umożliwiają rejestrowanie przejść między stanami, a także 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 obejmują funkcje obsługi punktu końcowego, takie jak wykrywanie, adresowanie, diagnostyka i aktualizacja oprogramowania. Z drugiej strony klastry aplikacji obsługują podstawowe działania, takie jak włączanie i wyłączanie czy pomiar temperatury.

Typy urządzeń

Jakie kombinacje klastrów należy uwzględnić, gdy producent planuje wprowadzenie nowego urządzenia?

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 do drzwi czy Odtwarzacz wideo.

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

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 przechowuje atrybuty, zdarzenia i polecenia, a klient jest bezstanowy i odpowiada za inicjowanie interakcji z klastrem serwerów zdalnych, a tym samym wykonuje te czynności:

• Odczytuje zdalne atrybuty i zapisuje w nich dane.
• odczytuje zdalne zdarzenia.
• wywoływanie poleceń zdalnych.

Chociaż model danych ma hierarchiczną strukturę w węźle, relacja między węzłami nie jest hierarchiczna. Węzły w Matter nie mają relacji pionowych kontroler/urządzenie peryferyjne ani lider/obserwator. Wręcz przeciwnie, relacja jest pozioma: każdy klaster może być serwerem lub klientem. 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 lampki stołowe: węzeł A i węzeł B. Oba węzły implementują typ urządzenia Włączanie/wyłączanie światła. Ten typ urządzenia zawiera klaster On/Off Server, który kontroluje odpowiednie fizyczne wyjścia światła.

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

W tym przykładzie włączony/wyłączony klaster klienta na węźle A zmienia atrybuty włączonego/wyłączonego klastra serwera na węźle A i B, a klaster klienta na węźle B zmienia tylko klaster serwera na węźle B.

W następnej sekcji szczegółowo opiszemy, jak działają klastry klienta i serwera, czyli model interakcji.

Klaster deskryptorów

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

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

Każdy typ urządzenia wymaga implementacji klastrów deskryptorów. Typ urządzenia głównego jest zdefiniowany w punkcie końcowym 0. Odczytanie klastra deskryptora zapewni klientowi możliwość przechodzenia przez całe drzewo dostępnych punktów końcowych i wykonywania odpowiednich operacji.

Urządzenie inicjujące lub sterujące, takie jak telefon lub hub, może używać informacji z klastra deskryptorów do modelowania urządzenia (światła, przełącznika, pompy, termostatu) i określonych funkcji zaimplementowanych w danej instancji urządzenia, wyświetlając użytkownikowi odpowiedni interfejs.

Klastry serwerów

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 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 z wyjątkiem samego siebie (punktu końcowego 0).

Pole PartsList innych punktów końcowych będzie zwykle puste. Na przykład czujnik temperatury wymaga klastra serwerów pomiaru temperatury i niczego więcej.

Inne typy urządzeń mogą być tworzone w strukturze drzewa składającej się z więcej niż 1 instancji DeviceType. 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ń aplikacji z treściami, z których każdy znajduje się w innym punkcie końcowym.