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 unikatowy, identyfikowalny i adresowalny zasób w sieci, który użytkownik może postrzegać jako funkcjonalnie całość. Komunikacja sieciowa w Matter zaczyna 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 przeprowadza 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ń, 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żącego poziomu 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 DM Matter. Polecenia przypominają czasowniki, np. zamknij drzwi w przypadku klastra Zamek 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 licznik o wartościach rosnących, znacznik czasu 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 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 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 ze zdalnym klastrem serwerów, a tym samym wykonuje te czynności:

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

Chociaż model danych jest hierarchiczny 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 klastry klienta włączania/wyłączania na węźle A zmieniają atrybuty klastrów serwera włączania/wyłączania na węzłach A i B, a klaster klienta węzła B zmienia tylko klaster serwera na węźle B.

W następnej sekcji szczegółowo opiszemy, jak działają klastry klientów i serwerów, 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 wgląd w całe drzewo dostępnych punktów końcowych i umożliwi wykonywanie 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 serwera 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.