Matter: standard, livelli tecnici e limiti di interoperabilità

Torna a Riferimenti tecnici

Riferimento tecnico

Revisione tecnica

Mirko Martino

Scope revisione

Architettura Matter, reti e trasporti supportati, commissioning, modello dati, Fabric e ruoli, Multi-Admin e Joint Fabric, bridging, limiti di interoperabilità, confronto con tecnologie adiacenti e baseline Matter 1.6.1.

Ultima revisione

10 ottobre 2026

Livello tecnico · Intermedio

Baseline tecnica verificata: Matter 1.6.1
Verifica delle fonti: 10 ottobre 2026
Version-sensitive: sì

La versione corrente della specifica non coincide necessariamente con quella implementata da ogni prodotto, firmware o piattaforma.

Matter in breve

Matter è uno standard di connettività per dispositivi connessi che definisce un modello comune per descrivere funzioni, scambiare comandi e stati, gestire l’accesso e inserire i dispositivi in un dominio operativo sicuro.

Opera su IP e utilizza tecnologie di rete già esistenti. Non sostituisce quindi Thread, Wi‑Fi o Ethernet: usa queste reti per trasportare le interazioni definite dal proprio modello applicativo.

Il suo obiettivo è rendere interpretabili in modo coerente funzioni supportate come accensione, regolazione, misura, sensori, termoregolazione, chiusure, sicurezza, media ed energia. La copertura effettiva dipende però dal device type previsto dalla specifica, dalla versione adottata e dalle funzioni implementate nel prodotto.

La distinzione fondamentale è:

specifica Matter
→ prodotto e firmware certificati
→ supporto del controller o ecosistema
→ funzione verificata nel progetto

Una possibilità prevista dallo standard non dimostra, da sola, che un prodotto la implementi, che un ecosistema la esponga integralmente o che la funzione risponda ai requisiti di un progetto concreto.

Matter è nato soprattutto per il connected home. Le versioni successive hanno ampliato categorie e capacità, includendo gestione energetica, apparecchi, ricarica dei veicoli, impianti solari e batterie, telecamere e chiusure. Questa crescita non trasforma però Matter in uno standard universale per ogni funzione dell’automazione di edificio. CSA Matter 1.4, CSA Matter 1.5.

Dove si colloca nello stack

Per capire Matter occorre separare almeno tre piani.

Il primo è il modello applicativo e di interazione. Matter definisce come un dispositivo rappresenta le proprie funzioni, quali dati espone, quali comandi può ricevere, quali eventi può produrre e come i nodi interagiscono in modo autenticato.

Il secondo è la rete operativa. Le comunicazioni Matter possono transitare su Thread, Wi‑Fi o Ethernet. Queste tecnologie non diventano Matter: continuano a svolgere il proprio compito di collegamento e trasporto IP.

Il terzo è il commissioning, cioè il processo con cui un nuovo nodo viene identificato, autenticato, configurato e inserito in una Fabric. BLE, codici QR e NFC possono intervenire in questa fase, ma non devono essere confusi con la rete utilizzata successivamente per il funzionamento ordinario.

Un dispositivo Matter over Thread, per esempio, usa Matter per il modello applicativo e Thread per la rete IPv6 a bassa potenza. Un dispositivo Matter over Wi‑Fi usa lo stesso modello Matter su una rete con caratteristiche radio e operative diverse. Un dispositivo Ethernet può essere già collegato alla rete quando inizia il commissioning.

Da Matter 1.5 lo stack supporta anche TCP come trasporto IP per scambi affidabili di dati più grandi. Questo non cambia la distinzione di base: Matter rimane il modello di interazione; Thread, Wi‑Fi ed Ethernet restano le infrastrutture operative sottostanti.

Reti operative e commissioning

Thread è una rete mesh IPv6 progettata per dispositivi con risorse o alimentazione limitate. Per collegare la rete Thread alle altre reti IP occorre la funzione di Thread Border Router. Un Border Router non è, per questo solo fatto, un Matter Controller o un Matter Commissioner: i ruoli possono essere riuniti nello stesso apparato, ma restano tecnicamente distinti.

Wi‑Fi ed Ethernet collegano invece i nodi Matter alla rete IP attraverso infrastrutture con caratteristiche diverse per alimentazione, banda, copertura, segmentazione e gestione.

Durante il commissioning, un Commissioner stabilisce una sessione sicura con il nuovo dispositivo, ne esamina le informazioni essenziali, esegue l’attestazione prevista dal protocollo, configura la rete quando necessario e installa le credenziali operative della Fabric. Per dispositivi Thread o Wi‑Fi è normalmente necessaria la configurazione della rete; un dispositivo Ethernet può essere già connesso.

BLE è stato il meccanismo più comune per la scoperta e il collegamento iniziale. Non è usato come trasporto operativo ordinario delle interazioni Matter dopo il commissioning.

Matter 1.6 ha aggiunto il commissioning completo tramite comunicazione NFC bidirezionale. Nelle versioni precedenti l’NFC poteva fornire il payload iniziale, mentre lo scambio proseguiva tramite un altro canale. Con la nuova funzione, l’intero scambio di commissioning può avvenire tramite NFC, anche in scenari nei quali il dispositivo non è ancora installato o alimentato definitivamente. La funzione resta subordinata al supporto effettivo del dispositivo, del Commissioner e della piattaforma. CSA Matter 1.6.

Il codice QR, il codice numerico, BLE e NFC non sono quindi elementi intercambiabili dello stesso livello: alcuni trasferiscono informazioni di onboarding, altri permettono scoperta o comunicazione durante il commissioning, mentre Thread, Wi‑Fi ed Ethernet sostengono il funzionamento operativo.

Device type, endpoint, cluster e funzioni

Matter rappresenta un dispositivo attraverso un modello dati organizzato.

Un Node è un partecipante identificabile nella rete Matter. Il nodo contiene uno o più Endpoint, utilizzati per rappresentare funzioni o parti logiche del dispositivo.

A ogni endpoint sono associati uno o più Device Type. Il Device Type stabilisce quale genere di dispositivo o funzione è rappresentato e quali cluster devono o possono essere presenti.

I Cluster raggruppano attributi, comandi ed eventi riferiti a una capacità. Un cluster può, per esempio, descrivere accensione, livello, temperatura, misura energetica, stato operativo o gestione degli accessi.

Questa struttura permette a un controller di interrogare il dispositivo e capire quali funzioni sono dichiarate. Non significa però che tutti i dispositivi appartenenti a una categoria abbiano le stesse capacità: alcune funzioni sono obbligatorie, altre opzionali o condizionate da feature specifiche.

Un dispositivo può inoltre utilizzare più endpoint per rappresentare componenti distinti. Un bridge può creare endpoint corrispondenti ai dispositivi non Matter che rende visibili nella Fabric.

La verifica professionale deve quindi scendere almeno a questi livelli:

• Device Type effettivamente certificato;
• revisione del Device Type;
• cluster presenti;
• feature dichiarate;
• attributi, comandi ed eventi realmente implementati;
• eventuali capacità opzionali;
• funzioni effettivamente rese disponibili dal controller.

Il semplice marchio Matter non sostituisce questa verifica.

Fabric, Commissioner, Administrator e Controller

Una Fabric è un dominio operativo di fiducia. Raggruppa nodi che condividono una radice di fiducia e credenziali che consentono loro di identificarsi e comunicare in modo sicuro.

La Fabric non coincide necessariamente con una LAN, una rete Wi‑Fi, un’abitazione o una zona dell’edificio. È prima di tutto un dominio amministrativo e crittografico.

Il Commissioner conduce il commissioning: stabilisce il contatto iniziale, verifica il dispositivo e gli assegna le credenziali necessarie per entrare nella Fabric.

L’Administrator gestisce la sicurezza, le credenziali e i privilegi associati alla Fabric.

Il Controller interagisce con altri nodi: legge stati, invia comandi, gestisce sottoscrizioni o coordina automazioni, secondo le funzioni che implementa.

Questi ruoli possono essere concentrati nella stessa app, hub o piattaforma, oppure distribuiti. Per un progetto non basta quindi annotare che è presente un “hub”: occorre capire quali ruoli svolge, quali restano disponibili senza cloud, chi mantiene le credenziali e cosa accade se l’apparato viene sostituito.

La documentazione di progetto dovrebbe identificare almeno:

• proprietario o responsabile della Fabric;
• account o identità amministrative;
• Commissioner utilizzato;
• controller operativi;
• procedure di aggiunta, rimozione, reset e sostituzione;
• responsabilità per aggiornamenti e conservazione della configurazione.

Multi-Admin e Joint Fabric

Matter supporta il Multi-Admin: un nodo può essere inserito in più Fabric, amministrate da soggetti o piattaforme differenti. Ogni Fabric mantiene il proprio dominio di fiducia e le proprie credenziali.

Questo permette, per esempio, di rendere lo stesso dispositivo disponibile a più ecosistemi senza affidare a uno solo l’intera relazione amministrativa. Non significa tuttavia che le interfacce, le automazioni e le funzioni esposte risultino identiche in ogni ambiente.

Nel Multi-Admin tradizionale, lo stesso nodo partecipa a più Fabric indipendenti. Matter 1.6 introduce anche Joint Fabric, che consente a più controller autorizzati di co-amministrare una Fabric condivisa attraverso un Datastore comune. È una capacità recente e version-sensitive: disponibilità, interoperabilità e modalità amministrative devono essere verificate nei prodotti e negli ecosistemi coinvolti.

Bridge e dispositivi non Matter

Un Matter Bridge collega dispositivi che usano un’altra tecnologia e li rappresenta verso la Fabric attraverso endpoint e cluster Matter.

Il bridge non trasforma fisicamente il dispositivo sottostante in un dispositivo Matter nativo. Traduce una parte del suo modello funzionale.

Un controller Matter può quindi vedere una lampada, un sensore o una chiusura collegati tramite bridge come funzioni Matter utilizzabili. La qualità della rappresentazione dipende però dalla corrispondenza tra:

• funzioni disponibili nel protocollo nativo;
• mapping implementato dal bridge;
• Device Type e cluster Matter applicabili;
• capacità comprese dal controller;
• comportamento del prodotto e del firmware.

Una funzione proprietaria o non rappresentabile mediante i cluster usati dal bridge può non essere disponibile. Anche diagnostica, aggiornamenti, configurazione avanzata e commissioning del protocollo sottostante possono continuare a richiedere gli strumenti originari.

Il bridge introduce inoltre una dipendenza operativa: disponibilità, alimentazione, aggiornamento e sostituzione del bridge possono influire sull’accesso ai dispositivi rappresentati. La documentazione deve distinguere i dispositivi Matter nativi da quelli bridged e indicare quali funzioni sono effettivamente mappate. CSA — Why Bridging Matters.

Che cosa Matter standardizza

Matter standardizza, entro il proprio perimetro:

• un modello dati composto da nodi, endpoint, device type e cluster;
• attributi, comandi ed eventi delle funzioni supportate;
• un modello di interazione tra nodi;
• scoperta e identificazione dei servizi;
• commissioning e credenziali operative;
• autenticazione, controllo degli accessi e comunicazione protetta;
• modalità per amministrazione multipla e bridging;
• meccanismi applicabili agli aggiornamenti software;
• requisiti di conformità e certificazione.

Matter non definisce automaticamente:

• il progetto funzionale di un edificio;
• le sequenze operative complete dell’impianto;
• il dimensionamento o la qualità della rete;
• la copertura radio;
• la struttura delle VLAN o delle politiche IT;
• la responsabilità di manutenzione;
• l’interfaccia utente di ciascun ecosistema;
• i servizi remoti o il modello commerciale del fornitore;
• la documentazione e le prove necessarie per l’handover;
• le funzioni non comprese nel Device Type o nel prodotto.

Lo standard riduce una parte del lavoro di integrazione, ma non elimina la necessità di progettare, verificare e documentare il sistema.

Cosa Matter non significa

Matter non è Thread. Matter definisce il modello applicativo; Thread è una possibile rete IPv6 sottostante.

Matter non è un sostituto universale di Zigbee. Zigbee comprende rete mesh e modello applicativo propri. Un’installazione Zigbee può essere resa parzialmente accessibile tramite bridge, ma ciò non equivale a una conversione completa.

Matter non è uno standard completo per ogni sistema di building automation. La Device Type Library copre una gamma crescente di dispositivi, ma non contiene automaticamente tutte le funzioni, responsabilità e procedure richieste da un edificio professionale.

Matter non rende identiche le piattaforme. Due ecosistemi possono supportare Device Type, cluster, feature, interfacce e automazioni differenti.

Matter non elimina ogni forma di dipendenza dal fornitore. Account, app, controller, aggiornamenti, cloud, bridge e procedure di ripristino possono ancora dipendere dall’implementazione.

Matter non significa cloud-free per definizione. Le interazioni operative supportate possono avvenire localmente, ma controllo remoto, registrazione, notifiche, archiviazione o funzioni ulteriori possono usare servizi cloud.

Matter non garantisce automaticamente l’interoperabilità di progetto. La certificazione del prodotto fornisce evidenza di conformità al programma e alla versione dichiarata, ma non garantisce da sola l’interoperabilità della configurazione di progetto. Occorre verificare le funzioni richieste nella combinazione reale di firmware, controller, rete e configurazione.

Matter non risolve da solo il commissioning professionale. Inserire un dispositivo in una Fabric non sostituisce identificazione, prove funzionali, documentazione, backup, consegna e responsabilità di manutenzione.

Un bridge Matter non espone necessariamente ogni funzione nativa. La disponibilità dipende dal mapping realizzato.

Una nuova versione della specifica non aggiorna automaticamente i dispositivi installati. Servono firmware compatibile, distribuzione dell’aggiornamento e supporto delle piattaforme.

Matter rispetto a Thread, Zigbee, KNX, BACnet e DALI

Matter e Thread

Operano su livelli differenti. Thread fornisce una rete mesh IPv6 a bassa potenza; Matter può utilizzare quella rete per le proprie interazioni applicative.

Possono coesistere nativamente. Un dispositivo Matter over Thread richiede che l’infrastruttura Thread, inclusa la funzione Border Router quando necessaria, sia adeguatamente progettata e mantenuta.

L’equivoco più comune consiste nel chiamare “Thread” l’intero sistema Matter o nel presumere che ogni dispositivo Matter utilizzi Thread.

Matter e Zigbee

Zigbee è una soluzione full-stack con rete mesh e modello applicativo propri. Matter usa invece IP e può funzionare su più reti operative.

La coesistenza è possibile attraverso un bridge, un hub multiprotocollo o dispositivi che integrano stack differenti. L’effettiva esposizione delle funzioni dipende dal mapping.

Matter non aggiorna automaticamente una rete Zigbee esistente e non rende nativamente Matter i suoi dispositivi.

Matter e KNX

KNX è uno standard per il controllo di case ed edifici che comprende architetture, media, dispositivi, progettazione e commissioning professionale. Matter ha un’origine e un perimetro maggiormente orientati ai dispositivi connessi e agli ecosistemi consumer/residenziali.

I due sistemi possono coesistere mediante gateway, bridge, piattaforme o logiche di integrazione. In un edificio, KNX può continuare a gestire funzioni di campo e automazioni progettate e commissionate in KNX mentre Matter rende disponibili alcune funzioni a controller o interfacce compatibili.

Questa è una possibile architettura, non una regola generale. Matter non sostituisce ETS, gli indirizzi di gruppo, il progetto KNX o le relative procedure di commissioning.

Matter e BACnet

BACnet è uno standard di comunicazione specificamente progettato per reti di building automation e controllo. Definisce oggetti e servizi per scambiare informazioni tra controllori, supervisori e sistemi riferiti a HVAC, energia, illuminazione, sicurezza e altri servizi edilizi. ASHRAE Standard 135.

Matter e BACnet possono essere collegati da gateway o piattaforme che traducano dati fra i due domini; le responsabilità operative restano da definire. Non sono automaticamente sostituibili: differiscono per origine, modelli operativi, ruoli amministrativi e impiego negli impianti professionali.

Matter e DALI

DALI è un protocollo specializzato per il controllo digitale bidirezionale dell’illuminazione e si basa sulla serie IEC 62386. Gestisce apparecchi, dispositivi di controllo, gruppi, scene, comandi e informazioni diagnostiche proprie del dominio luce. DALI Alliance.

Matter può esporre alcune funzioni di illuminazione attraverso un gateway o una piattaforma, ma non sostituisce l’indirizzamento, la configurazione, la certificazione DALI-2 dei prodotti o la diagnostica DALI. Il mapping deve essere verificato funzione per funzione.

Dove può essere utile negli edifici e nei progetti

Le considerazioni seguenti sono valutazioni professionali/editoriali di Building Reference, non requisiti della specifica.

Casa e residenziale

È il contesto più vicino al modello originario di Matter. Può ridurre la necessità di integrazioni proprietarie per dispositivi supportati e rendere disponibili funzioni comuni a più controller.

Restano da verificare copertura della funzione, comportamento senza Internet, proprietà della Fabric, aggiornamenti, account, reset e continuità del controller.

Hospitality

Matter può essere pertinente per funzioni selezionate nella camera o in aree circoscritte: illuminazione, clima, chiusure, sensori e interfacce utente.

L’adozione deve però confrontarsi con gestione centralizzata, turnover degli ospiti, reset affidabile, segregazione, supervisione, manutenzione e integrazione con i sistemi operativi della struttura.

Piccolo commerciale

Può offrire valore quando il progetto utilizza dispositivi supportati, ha una scala contenuta e dispone di responsabilità chiare per rete, controller e manutenzione.

Non dovrebbe essere scelto soltanto perché un prodotto è facile da configurare in un’app consumer.

Edifici professionali e di grandi dimensioni

Matter può essere valutato come livello di accesso o integrazione per specifiche famiglie di dispositivi. Non va automaticamente interpretato come sostituto di BMS/BACS, KNX, BACnet, DALI o di un’infrastruttura IT gestita.

Occorre verificare scalabilità, segmentazione, amministrazione, diagnostica, strumenti di commissioning, continuità operativa, documentazione, cybersecurity, ricambi e supporto lungo il ciclo di vita.

Dalla specifica alla realtà implementativa

La conformità si deve verificare lungo una catena.

1. Specifica

Stabilisce cosa può o deve essere rappresentato in una determinata versione: Device Type, cluster, feature e procedure.

2. Prodotto e firmware

Il prodotto implementa una parte applicabile della specifica. La certificazione fornisce evidenza di conformità al programma e alla versione dichiarata, ma non certifica il progetto nel quale il prodotto sarà usato. CSA Certification.

3. Controller ed ecosistema

Il controller deve comprendere il Device Type e le feature necessarie. Un attributo o cluster implementato dal dispositivo può non essere presentato nello stesso modo da tutti gli ecosistemi.

4. Funzione di progetto verificata

La funzione può essere considerata verificata nel progetto solo dopo una prova nella combinazione reale di dispositivi, firmware, controller, rete, bridge, account e configurazione.

Questa prova dovrebbe includere non solo il comando ordinario, ma anche riavvio, perdita di rete, sostituzione del controller, reset, aggiornamento, ripristino e handover.

Checklist professionale

Prima di fare affidamento su Matter, verificare:

• Device Type e revisione dichiarati;
• versione Matter certificata;
• certificato e identificazione del prodotto;
• versione firmware effettivamente installata;
• cluster, feature e comandi obbligatori o opzionali;
• supporto del controller scelto;
• funzioni realmente esposte nell’ecosistema;
• rete operativa: Thread, Wi‑Fi o Ethernet;
• disponibilità e gestione dei Thread Border Router, se applicabile;
• onboarding payload disponibile: QR code, codice manuale o tag NFC, dove supportato;
• comunicazione di commissioning supportata: BLE, rete IP o NFC bidirezionale, dove supportato da Matter 1.6 o successivo;
• proprietà della Fabric e ruoli amministrativi;
• numero e continuità dei controller;
• uso di Multi-Admin o Joint Fabric;
• mapping dei dispositivi bridged;
• funzionamento locale delle funzioni richieste;
• dipendenze da account, Internet e cloud;
• controllo degli accessi;
• aggiornamenti firmware e loro responsabilità;
• procedura di reset, rimozione e sostituzione;
• comportamento in caso di indisponibilità del bridge o controller;
• durata del supporto e fine vita;
• proprietà della configurazione;
• documentazione, prove e responsabilità di handover.

Versioni ed evoluzione

Matter adotta versioni maggiori, minori e patch. Le release minori possono introdurre Device Type, cluster e funzioni; le patch possono correggere o chiarire la specifica e allineare strumenti e modelli dati.

La baseline di questa pagina è Matter 1.6.1. Matter 1.6 ha introdotto, tra le altre funzioni, il commissioning NFC bidirezionale e Joint Fabric; la patch 1.6.1 aggiorna e allinea specifica, modelli dati, SDK e strumenti collegati.

Tre versioni devono essere tenute distinte:

1. versione corrente della specifica;
2. versione rispetto alla quale il prodotto è certificato;
3. firmware effettivamente installato.

A queste si aggiunge la versione supportata dal controller. Non è corretto dedurre il supporto di una funzione dal solo fatto che essa esista nella specifica più recente.

La pagina deve essere riesaminata quando cambia la baseline CSA o quando una modifica introduce nuove reti, procedure di commissioning, ruoli amministrativi, Device Type o condizioni di interoperabilità.

Fonti primarie e baseline tecnica

Baseline consultata:

• Matter 1.6.1 — registro delle specifiche CSA
• Matter SDK v1.6.1 — repository ufficiale CSA
• Matter 1.6 — comunicato tecnico CSA
• Matter 1.5 — categorie e trasporto
• Thread Group — specifica e risorse
• CSA — certificazione
• CSA — bridging

Le documentazioni di piattaforma devono essere utilizzate soltanto per verificare il comportamento di quella piattaforma.