Proč máme chtít Matter?
Co se dozvíte v článku
Odpověď je jednoduchá, protože bude vše jednodušší. Ale nepředbíhejme. Cílem konsorcia Connectivity Standards Alliance bylo vytvořit otevřený komunikační standard, uvolněný pod licencí Apache 2.0, který by zjednodušil komunikaci mezi jednotlivými zařízeními. Hlavně ale také odstranil největší bolest jiných protokolů – vazbu na vybraného výrobce.
Když se podíváme právě na jiné protokoly používané v chytré domácnosti, jako je např. Zigbee, Z-Wave či HAP (HomeKit Accessory Protocol), uživatelé byli nuceni používat daného výrobce/ekosystém, ke kterému si pořídili bránu a připojit tak zařízení od někoho jiného bylo problematické. Ano, toto bylo možné (ovšem pro zkušenější uživatele) vyřešit zprovozněním Zigbee2MQTT běžící nad fyzickým adaptérem pro danou technologii. Ale není to zcela univerzální řešení, neboť tvůrce a přispěvatelé tohoto oblíbeného software průběžně přidávají a testují nová zařízení.
Standard Matter kromě vyřešení letitých problémů s kompatibilitou napříč zařízeními zásadně řeší i bezpečnost. Používá se totiž end-to-end šifrování, tedy veškerá data se šifrují a dešifrují přímo na zdrojových a cílových zařízeních. Není tedy možné komunikaci odposledchnout po transportní vrstvě. Pro šifrování obsahu zpráv (payload) se používá AES-128-CCM a pro výměnu klíčů asymetrická kryptografie ECC NIST P256.
Veškerá komunikace pak probíhá lokálně, což je z mého pohledu největší výhoda. Nejsou potřeba žádné cloudy, nemusíme se bát neoprávněného přístupu a komunikace je rychlá a spolehlivá. Tomu pomáhá fakt, že veškerá komunikace probíhá výhradně na protokolu IPv6.
Šestkového protokolu se však nemusíte obávat. Vůbec není potřeba mít od poskytovatele internetového připojení delegovaný globální IPv6 prefix, ani zásadně měnit domácí infrastrukturu. Proč vlastně nestačí „léty osvědčený“, ale v dnešní moderní době již omezený a zastaralý protokol IPv4? Je zkrátka potřeba, aby bylo možné s každým zařízením komunikovat přímo a bez různých překladových technologií (NAT). K tomu je protokol IPv6 velice vhodný díky svému širokému adresování, současně také díky dalším vylepšením, která přináší.
Podívejme se nejdříve na adresní prostor. Každé zařízení si vygeneruje několik adres. První je link-local adresa fe80::/10, která je odvezena standardním způsobem pomocí EUI-64 a zařízení si tuto adresu vygeneruje samo. Používá se pro komunikaci v rámci jednoho segmentu. Další adresa může být unique local (ULA) fd00::/8, kterou již předěluje router (tedy existuje více sítí), nepřenáší se do internetu, ale funguje napříč celou domácností a přes tuto adresu spolu všichni komunikují. Zařízení může samozřejmě obdržet i globálně routovanou adresu 2000::/3, to ovšem závisí na konkrétní konfiguraci routeru a sítě. Samozřejmostí je i multicastová adresa ff00::/8.
Multicast je zde velice důležitý. V protokolu IPv6 je totiž k dispozici rozšířená podpora multicastu mDNS/DNS-SD, který se používá v několika zásadních situacích. První je, aby se zařízení v síti dokázala sama najít, představit se a připojit. Není potřeba konfigurovat IP adresy a další parametry, které vlastně ani nové zařízení nezná. Netuší, v jaké je síti a kam se připojit. Proto pošle jednu zprávu na multicastovou adresu, která se po síti doručí všem, kteří na ní dokáži reagovat.
S multicastem je to jako ve škole: vyučující stojí před tabulí a zadává úkol. Řekne ho jen jednou a všichni studenti ve třídě (tedy v konkrétní multicastové skupině) tomu porozumí a začnou pracovat. Studenti v jiné učebně či na chodbě tuto zprávu samozřejmě nepřijmou – není určena pro ně. Druhou situací jsou skupinové zprávy, kdy je potřeba např. jedním povelem rozsvítit pět žárovek v místnosti. Výhody multicastu jsou nasnadě, zprávu stačí vyslat jen jednou a ušetříme tím datový tok.
Matter controller
Pro plnou funkčnost ekosystému Matter, tedy pro správu a ovládání jednotlivých zařízení, potřebujeme centrální prvek – řídicí jednotku nebo-li Matter controller. Výhodou oproti jiným technologiím je, že je součástí některých fyzických zařízení, která můžeme mít doma a není tedy nutné pořizovat nic dalšího. Jedná se např. o Apple TV 4K, Apple HomePod, Google Nest, Amazon Echo nebo vybrané chytré televizory Samsung. Pokud takové zařízení nemáme, můžeme využít softwarovou implementaci Matter serveru. Prakticky si to ukážeme později.
QR kód
Každé zařízení podporující Matter má přímo na sobě, případně na obalu či svém návodu, unikátní QR kód společně s číselným kódem. Je to tedy podobný princip, jako třeba u zařízení se Z-Wave, který jsem popisoval v dřívějším článku. Pro spárování zařízení tedy potřebujeme telefon se zapnutým Bluetooth.
Fotoaparátem je možné tento QR kód buď rovnou načíst a potvrdit proces, případně rovnou spustit vlastní aplikaci, kterou pro chytrou domácnost používáme a tam zvolit možnost přidání zařízení. Alternativně pro případ nečitelnosti QR kódu (typicky při rozsvícené žárovce) či jiné nenadálé události použijeme číselný kód pro ruční párování.
Zajímá vás, co je vlastně obsahem QR kódu? Mě ano a proto jsem vyzkoušel načíst žárovku značky MOES obyčejnou čtečkou QR kódu a získal jsem tento řetězec: MT:GE.016P614GEOP4C910. Je to vlastní base38 kódování s omezenou znakovou sadou a specifickou strukturou. Popis této struktury a současně možnost výstup rovnou dešifrovat je k dispozici na stránce dekodéru Matter QR. Také je možné využít utilitu chip-tool ze snapu a zjistit požadované informace.
Podrobnější informace, včetně těch pro vývojáře, o každém zařízení nejen na základě VendorID, ProductID apod. pak nalezneme na webu matter-survey.org.
Párování zařízení
Než si vysvětlíme, na jakém principu probíhá párování nového zařízení, podíváme se ještě na jednu důležitou věc ohledně zabezpečení. Každé zařízení podporující Matter má totiž z výroby jedinečný X.509 certifikát, kterému se říká DAC (Device Attestation Certificate). Ten je podepsán certifikátem PAI (Product Attestation Intermediate), který je v zařízení také uložen a drží jej daný výrobce zařízení.
Tento certifikát je podepsán certifikátem PAA (Product Attestation Authority) a funguje jako kořenová certifikační autorita a poskytuje tak bod důvěry. Seznam důvěryhodných certifikátů PAA je pak bezpečně uložen v úložišti organizace CSA, v DCL (Distributed Compliance Ledger). Právě certifikát DAC má zásadní roli. Pomocí něj se ověřuje, že je zařízení validní a patří skutečnému výrobci. Jakmile tento certifikát není platný, zařízení je controllerem odmítnuto.
Samotné párování pak probíhá dle následujícího schematu. Po zapnutí zařízení a načtení QR kódu pomocí Bluetooth se sestaví spojení PASE (Password Authenticated Session Establishment). Je to šifrovaný kanál zatím bez certifikátů na základě tajemství z QR kódu (pole Passcode v předchozí kapitole) a sestavuje se pouze jednou. Controller ověří certifikáty DAC a PAI a celý řetězec důvěry až ke kořenovému certifikátu PAA. Následně se pošle zařízení CSR žádost o nový certifikát, vygeneruje se certifikát NOC (Node Operational Credential) na controlleru a pošle na zařízení.
Nakonec proběhne konfigurace sítě a uzavření spojení. Veškerá další komunikace (ovládání, stavy apod.) mezi controllerem a zařízením je vždy založena na sestavení CASE (Certificate Authenticated Session Establishment) spojení, které právě používá certifikát NOC pro zajištění šifrovaného kanálu. Tento certifikát je tedy klíčový pro end-to-end šifrování a pro veškerou komunikaci. Při jeho ztrátě se musí provést proces párování znovu.
Matter over co?
Nyní se dostáváme k poměrně zásadnímu zjištění. Pokud jste se již poohlíželi po nějakém zařízení s podporou Matter, jistě jste si všimli, že to není tak jednoduché. Matter totiž není jen jeden. Tento standard je totiž pouze aplikační vrstva navržená pro IoT zařízení. Na rozdíl od jiných technologií užívaných v chytré domácnosti vůbec neřeší komunikační rozhraní. Proto je tak univerzální a dává uživatelům volnost v tom, které řešení nakonec využijí. V budoucnu také mohou vzniknout nějaká úplně jiná. Momentálně máme k dispozici buď Wi-Fi/Ethernet nebo Thread.
Pro lepší orientaci doporučuji navštívit web matterdevices.io, kde je pěkně udržovaná databáze dostupných zařízení a to včetně použitého komunikačního protokolu.
Matter over Wi-Fi
Komunikačním protokol Wi-Fi je pro domácí nasazení nejjednodušší. Wi-Fi síť má ve své domácnosti snad každý, stačí ji tedy jen využít a vyjma Matter controlleru již nepotřebujeme nasazovat nic dalšího. Z pohledu bezpečnosti je vhodné pro IoT zařízení vyčlenit vlastní VLAN, pokud to domácí síť umožňuje. Každopádně provoz zařízení Matter bude zcela závislý na tom, jak dobře máme domácí Wi-Fi síť nastavenou, případně pokrytou v případě větších domácností. Celé to zní jednoduše, ale má to však jedno úskalí.
Jak jsem popisoval v předchozích kapitolách, kromě funkčního protokolu IPv6 je potřeba mít i plně funkční multicast. Tyto dvě skutečnosti bývají problém zejména u levnějších routerů/AP, neboť můžeme narazit na následující potíže.
Ochrana proti tzv. Multicast Storm. Router/AP zkrátka buď multicastový provoz silně omezuje nebo zcela zahazuje, aby zabránil generování nadměrného množství paketů a zajistil stabilitu sítě. Je potřeba povolit IGMP Snooping, aby se tento provoz posílal jen těm zařízením, která ho opravdu chtějí přijmout. Případně ještě explicitně povolenou podporu mDNS.
Problém může být také izolace klientů na AP, typicky aktivní při nastavené síti pro hosty. Jedná se o funkci pro zabránění komunikace mezi zařízeními navzájem. Matter naopak vyžaduje přímý přístup bez prostředníka na všechna zařízení. S aktivní izolací se nepodaří nové zařízení ani spárovat.
V některé síti může být protokol IPv6 zcela zakázán nebo dokonce není podporován. Pro správné fungování je potřeba, aby protokol IPv6 fungoval nativně alespoň v lokální síti. Pokud jsou IoT zařízení umístěna ve vlastní VLAN, je ještě nutné, aby provoz nebyl blokován firewallem a router uměl pomocí autokonfigurace SLAAC přidělit ULA adresy.
Ještě taková zajímavost: když jsem zkoušel připojovat již zmíněnou MOES Wi-Fi žárovku, kromě správně nakonfigurovaných šestkových IP adres si žárovka pomocí DHCP klienta nastavila i IPv4 adresu. Jak je to možné? Jednoduše, čipy uvnitř těchto zařízení jsou zkrátka dual-stackové. Nicméně tuto adresu Matter reálně nepotřebuje, může se použít v zásadě jen pro OTA aktualizace, pokud cílový webserver nedisponuje šestkovou adresou.
Matter over Thread
Krátké pojednání o síti Thread jsem popisoval v předešlém článku. Na ten naváži a doplním některé další zajímavé skutečnosti, proč stojí za to dát přednost Thread namísto Wi-Fi.
Předně, síť Thread je již od počátku navržena primárně pro IoT provoz, kde je kladen důraz na malé a úsporné pakety (ideální pro bateriová zařízení). MTU v IEEE 802.15.4 je totiž stanoveno na 127 bajtů. Úspory je docíleno tak, že se společně s protokolem IPv6 používá klíčová technologie 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks). Ta pomocí technik IPHC (IPv6 Header Compression) a NHC (Next Header Compression) provádí kompresi dat. Využívá se toho, že některá pole v hlavičce jsou buď předvídatelná, jiná se dají dopočítat z jiných částí paketu a nebo se využívá společného kontextu, na základě kterého je možné také část dat zkrátit.
Běžná IPv6 hlavička má velikost 40 bajtů, IPHC ji dokáže zkrátit v nejlepším případě až na dva bajty. NHC pak komprimuje následující hlavičky, tedy nejčastěji transportní protokoly TCP a UDP nebo rozšiřující hlavičky IPv6. Třeba UDP hlavičku je možné z původních osmi bajtů takto zkrátit také až na dva. Stejně tak porty, neboť se zde komunikuje na specifických, po sobě jdoucích portech. Díky celkové kompresi pak může režie klesnout z 48 bajtů (hlavička + UDP) hravě pod 10 bajtů. To už poměrně zásadně šetří baterie koncových zařízení.
Také již víme, že Thread je síť typu mesh. V každé síti tak existuje jeden uzel typu Leader, který řídí a koordinuje celou síť. V jednom okamžiku může být skutečně pouze jeden, ale v případě potřeby (ztráta signálu, odstranění zařízení) se jím automaticky stane jiné vhodné zařízení. Další rolí v síti je Router, který bývá typicky napájen z elektrické sítě a dokáže rozšiřovat mesh síť. Je tedy stále „vzhůru“, odebírá multicast, udržuje směrovací informace o síti. Současně tak vytváří redundantní cesty k ostatním router zařízením, která jsou pak vzájemně propojená a eliminuje se tak výpadek části sítě.
Nakonec samozřejmě existují koncová zařízení, která jsou připojena ke konkrétnímu uzlu (routeru), nerozšiřují síť, nemají redundantní cesty a většinu času „spí“, čímž šetří svojí baterii. Čas od času se probudí a zašlou svému nadřazenému uzlu nové zprávy. Toto je typické třeba pro teplotní senzor, neboť ten nemusí posílat informace o svém stavu každou sekundu.
Nejdůležitější součástí je pak Thread Border Router, který plní roli mostu mezi sítí Thread a zbytkem světa. Může vystupovat např. jako NAT64/DNS64, aby zpřístupnil zařízením aktualizace OTA z webových serverů, které disponují pouze IPv4 adresami. Umožňuje vzdálený přístup a je právě nezbytný pro provoz Matter zařízení na síti Thread. Protože Matter, jak již víme, je aplikační protokol a musí tedy existovat vrstva, která vše propojí mezi sebou.
V jedné Thread síti může existovat více border routerů, čímž zajistíme dostatečnou odolnost proti výpadku. V případě selhání jednoho z nich, roli automaticky převezme jiný. To i v případě, že máme kombinaci fyzického a softwarového zařízení. Stejně jako v případě Matter controlleru, výrobci do stejných zařízení implementují právě i funkční Thread border routeru. Tedy pokud již doma disponujeme jedním z uvedených zařízení, máme již k dispozici jak Matter controller tak i Thread border router. Nás bude ale zajímat ta softwarová implementace.
Adresování v síti Thread
Ještě než přistoupíme k praktickému nasazení, podívejme se jak funguje adresování v síti. Každé zařízení samozřejmě obdrží IPv6 link-local adresu fe80::/10, ale oproti Wi-Fi je zde jedna změna při jejím generování. MAC adresa Thread zařízení není 48bitová, ale 64bitová. Říká se jí Extended MAC Address. Není tedy nutné vkládat ff:fe doprostřed dle specifikace EUI-64.
Dále Thread Border Router každému zařízení přidělí tzv. Off-mesh routable adresu fd00::/8, což je vlastně analogie k ULA adrese. Tato adresa se používá ke komunikaci mimo síť Thread a umožňuje spojení např. právě s Home Assistantem, jiným Matter controllerem nebo pro aktualizace OTA.
Ale to není vše, při inicializaci sítě se ještě vygeneruje Mesh-local EID prefix fd00::/8, ze kterého vychází RLOC (Routing Locator). Ten je zásadní pro interní routing v mesh síti a rozdílem mezi ULA adresou je, že IP adresa typu RLOC je vázaná na konkrétní router. Proto se může v čase měnit podle toho, jak dochází ke změnám v topologii sítě.
Aby mohla vzniknout výsledná adresa, definuje se identifikátor RLOC16, který vzniká ze dvou hodnot. RouterID vzniká v okamžiku, kdy se uzel stane routerem a ChildID, který přiděluje router koncovému zařízení při připojení. Router má vždy hodnotu ChildID rovno nule. Matematickou operací pak dostaneme výsledný identifikátor.
RLOC16 = (RouterID << 10) | ChildID
Adresa typu RLOC vznikne spojením Mesh-local EID prefixu, vložením 0000:00ff:fe00 a identifikátoru RLOC16. Konkrétní pak může vypadat např. takto fdde:1594:b677:8ca9:0000:00ff:fe00:d000/64. Cílem použití této adresy je tedy jednoznačně určit příslušnost k dané Thread síti (prefix) a kde se přesně, tj. za konkrétním routerem, konkrétní uzel nachází.
Zprovoznění v Home Assistantu
V této kapitole budu uvažovat případ, že nevlastníme žádné fyzické zařízení, které má v sobě zabudovanou podporu Matter či Thread Border Routeru. Ukážeme si totiž zprovozní potřebných softwarových implementací a jednotlivých integrací.
Matter server
Ať se rozhodneme pro Matter over Wi-Fi nebo Matter over Thread, potřebujeme nejdříve Matter server. Používáme-li Home Assistant Operating System, stačí jej nainstalovat z oficiálních doplňků. Máme-li instalaci Home Assistant Container, pak jej musíme zprovoznit sami, nejlépe pomocí Docker compose s definovaným persistentním úložištěm:
services:
matter-server:
container_name: matter-server
image: ghcr.io/home-assistant-libs/python-matter-server:stable
network_mode: host
volumes:
- /mnt/docker/matter:/data
restart: always
Po nastartování dockerového kontejneru bude na portu 5580 naslouchat Matter webservice. Nyní zbývá přidat do Home Assistanta integraci Matter, do které zadáme URL ws://localhost:5580/ws. Tím je Matter server/controller funkční a je možné začít přidávat zařízení.
Musíme mít však funkční mobilní aplikaci pro Home Assistant, neboť párování probíhá výhradně pomocí Bluetooth z mobilního zařízení. Je to jednoduché, půjdeme do menu Nastavení → Matter, klikneme na tlačítko Přidat zařízení, vybereme Je nové a pak už jen načteme QR kód fotoaparátem mobilu.
Thread Border Router
Instalaci Thread Border Routeru jsem již popisoval v předchozím článku, včetně doporučení na vhodný USB dongle. Doba trochu pokročila a tedy kromě již zmiňovaného a skvělého Home Assistant Connect ZBT-2 doporučuji také Sonoff Dongle Plus MG24, což je nástupce staršího Sonoff Plus ZBDongle-E. Má stejný čip jako zařízení ZBT-2, je oproti ZBDongle-E rychlejší a má výkonnější anténu. Sám tento pro Thread síť využívám a ten starší jako záložní.
Nebo je možné s jeho pomocí nasadit druhý, redundantní Thread Border Router. I zde stále platí, že přeflashováním firmware může daný USB dongle vystupovat pro síť Zigbee nebo Thread. Ale doporučuje se mít dvě nezávislá zařízení, byť nová zařízení již podporují MultiPAN a měla by umět obsloužit obě sítě najednou.
Docker compose pro využití s Home Assistant Container, s definovaným persistentním úložištěm a USB zařízením pak vypadá takto:
services:
otbr:
container_name: otbr
image: openthread/border-router:latest
network_mode: host
privileged: true
cap_add:
- NET_ADMIN
- NET_RAWs
environment:
OT_RCP_DEVICE: "spinel+hdlc+uart:///dev/ttyUSB0"
OT_INFRA_IF: "WAN_IF_NAME"
OT_THREAD_IF: "wpan0"
OT_WEB_LISTEN_ADDR: "IP_ADDR"
OT_WEB_LISTEN_PORT: 8080
OT_REST_LISTEN_ADDR: "IP_ADDR"
OT_REST_LISTEN_PORT: 8081
OT_LOG_LEVEL: 7
devices:
- /dev/serial/by-id/XXXX:/dev/ttyUSB0
- /dev/net/tun:/dev/net/tun
volumes:
- /mnt/docker/otbr:/data
restart: always
Softwarová implementace Thread Border Routeru je citlivá na správné nastavení parametrů jádra. Jinak se může stát, že se zařízení bude tvářit, že se páruje do sítě, ale tento proces nikdy nebude dokončen nebo mezi sebou nebudou prvky vůbec komunikovat. Nezapomeňte si nastavit vše potřebné okolo IPv6:
net.ipv6.conf.${WAN_IF_NAME}.accept_ra = 2
net.ipv6.conf.${WAN_IF_NAME}.accept_ra_rt_info_max_plen = 64
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv4.ip_forward = 1
Po spuštění vlastního Border Routeru nezapomeneme přidat do Home Assistant integraci Open Thread Border Router a samozřejmě integraci Thread podle již uvedeného postupu. Nyní máme vše připravené a můžeme začít používat i zařízení s Matter over Thread.
Závěrem ještě uvedu několik zajímavých příkazů, které mohou pomoci při ladění nebo jen pro přehled, jak to v Thread síti vypadá. Využijeme utilitu ot-ctl:
$ docker exec -it otbr ot-ctl > state // role uzlu > ipaadr // všechny IP adresy uzlu > ping fd42:... // test dostupnosti konkrétního uzlu > br omrprefix // použitý prefix Off-mesh routable > prefix rloc16 // RLOC16 identifikátor uzlu > netdata show // kompletní network data sítě > dataset active // všechny důležité parametry sítě > leaderdata // informace o leaderu sítě > neighbor table // seznam pouze přímých sousedů > router table // cesty k routerům v celé síti > child table // seznam připojených koncových zařízení ... > help // nápověda pro další příkazy
Wi-Fi nebo Thread?
Matter over Wi-Fi nebo Thread? Toť otázka. Můžeme však kombinovat oba protokoly, protože Home Assistant to bez problémů pokryje a vzájemně propojí. Pokud však s Matterem začínáte, doporučuji rovnou sáhnout po Thread. Zařízení nebudou závislá na domácí Wi-Fi, komunikace bude úspornější, cesty redundantní, automaticky se prodlouží pokrytí a díky několika OTBR routerům zde vlastně není SPOF (Single Point of Failure).
Thread zařízení se pomalu začínají objevovat na trhu. Ovšem od začátku roku 2026 přišel obchod s nábytkem IKEA s kompletní nabídkou nových produktů chytré domácnosti, Matter over Thread, které postupně nahrazují původní řešení postavené na Zigbee (řada Tradfri). Již jsou běžně k dostání různé druhy a velikosti žárovek, vypínačů/tlačítek, teplotních, pohybových, dveřních či záplavových senzorů, zásuvek s měřením spotřeby a podobně. To vše za velice příjemnou cenu, takže to určitě stojí za to vyzkoušet.
Některá zařízení jsou sice trochu větší než konkurence (např. dveřní senzor umí konkurence v menší velikosti), ale má to racionální důvod. Vše je napájeno jednou až dvěma bateriemi typu AAA, klidně dobíjecími NiMH, ostatně jak na každém obalu IKEA doporučuje. V čem je to výhodné? Větší baterie vydrží déle, než klasické knoflíkové, které ostatní výrobci používají – CR2450, CR2032 nebo dokonce CR1632. Konečně odpadá to neustálé vyměňování, protože právě ty knoflíkové baterie opravdu moc nevydrží a současně jsou více náchylné na změny teplot.
