Resumen del protocolo Matter 1.3: Arquitectura, tipos de dispositivos y flujo de comisionamiento
Matter es un protocolo de capa de aplicación estandarizado por la Connectivity Standards Alliance (CSA) que funciona de forma nativa sobre IPv6 en Thread, Wi-Fi y Ethernet, brindando a los dispositivos de edificios inteligentes un modelo de comunicación único, seguro e interoperable entre fabricantes sin traducción de pasarela. Matter 1.3 amplió la biblioteca de tipos de dispositivos para incluir informes de energía, hornos microondas y válvulas de agua; la arquitectura central, el modelo de datos y el flujo de comisionamiento descritos aquí se aplican desde Matter 1.0.
Pila de protocolos y capas de transporte
Matter se encuentra en la capa de aplicación y es independiente del transporte: el mismo mensaje Matter puede viajar a través de una malla Thread (UDP/IPv6 sobre IEEE 802.15.4), una red Wi-Fi (UDP/IPv6 sobre 802.11) o un segmento Ethernet cableado. Bluetooth Low Energy (BLE) se utiliza exclusivamente para el paso inicial de puesta en marcha – no se utiliza para la comunicación continua de dispositivos. El transporte principal es UDP con CASE (Certificate-Authenticated Session Establishment) que proporciona seguridad de sesión en la capa de aplicación.
| Capa | Protocolo | Notas |
|---|---|---|
| Aplicación | Matter (especificación CSA) | Clústeres, atributos, comandos, eventos |
| Seguridad de sesión | CASE / PASE | Establecimiento de sesión basado en certificados; PASE solo para puesta en marcha |
| Transporte | UDP (MRP — Message Reliability Protocol) | Retransmisión, detección de duplicados, acuse de recibo |
| Red | IPv6 | Thread: compresión 6LoWPAN; Wi-Fi/Ethernet: IPv6 nativo |
| Enlace de datos (Thread) | IEEE 802.15.4 2,4 GHz | 250 kbit/s, alcance LOS 2 km, seguridad MAC AES-128 |
| Enlace de datos (Wi-Fi) | IEEE 802.11 2,4 / 5 GHz | Wi-Fi estándar; no se requiere firmware AP Matter especial |
| Solo puesta en servicio | Bluetooth LE | Se utiliza para la incorporación mediante código QR; no se utiliza después de la puesta en servicio |
Elección entre Thread y Wi-Fi para sensores de edificios: Los dispositivos Thread suelen funcionar con batería (Sleepy End Devices) y se benefician de la malla auto-reparable y la capa MAC de bajo consumo. Los dispositivos Matter Wi-Fi se alimentan de la red y se conectan directamente a la infraestructura Wi-Fi existente. En edificios comerciales, se prefiere Thread para la densidad de sensores y actuadores; Wi-Fi para dispositivos de alto ancho de banda o fijos como termostatos y pantallas.
Tipos de dispositivo
Matter define los tipos de dispositivo en la especificación CSA Device Library. Cada tipo de dispositivo especifica qué clústeres son obligatorios y cuáles opcionales. Un comisionador Matter (Apple Home, Google Home, Amazon Alexa, Home Assistant) utiliza el tipo de dispositivo para presentar la interfaz de usuario correcta y aceptar los comandos de control adecuados.
| Tipo de dispositivo | ID del tipo de dispositivo | Clústeres obligatorios |
|---|---|---|
| Luz encendido/apagado | 0x0100 | OnOff, Identify, Groups |
| Luz regulable | 0x0101 | OnOff, LevelControl, Identify, Groups |
| Luz de temperatura de color | 0x010C | OnOff, LevelControl, ColorControl (modo CT) |
| Unidad enchufable On/Off | 0x010A | OnOff, Identify |
| Termostato | 0x0301 | Termostato, Identify, TemperatureMeasurement |
| Cubierta de ventana | 0x0202 | WindowCovering, Identify |
| Cerradura de puerta | 0x000A | DoorLock, Identify |
| Sensor de contacto | 0x0015 | BooleanState, Identify |
| Sensor de ocupación | 0x0107 | OccupancySensing, Identify |
| Sensor de temperatura | 0x0302 | TemperatureMeasurement, Identify |
| Puente | 0x000E | BridgedDeviceBasicInformation en cada punto final puenteado |
| Energy EVSE (1.2+) | 0x050C | EnergyEVSE, PowerTopology |
Modelo de datos: clústeres, atributos y comandos
El modelo de datos de Matter es el equivalente funcional de los objetos de grupo KNX y los tipos de puntos de datos. Un nodo (dispositivo físico) contiene uno o máspuntos finales; cada punto final implementa uno o más clústeres. Un clúster agrupa atributos (estado legible), comandos(acciones escribibles) y eventos (notificaciones asíncronas) en una unidad de especificación versionada. El CSA asigna IDs numéricos a todos los clústeres estándar; los clústeres de fabricantes usan IDs en el rango 0xFC00–0xFFFE.
Jerarquía del modelo de datos Matter
Node (physical device, one IPv6 address)
└── Endpoint 0 (Root Node — always present)
│ └── BasicInformation cluster (vendor, model, serial, firmware)
│ └── GeneralCommissioning cluster
│ └── OperationalCredentials cluster (fabric membership, NOC)
└── Endpoint 1 (primary device function)
│ └── OnOff cluster (0x0006)
│ Attribute: OnOff (bool) — current on/off state
│ Command: On (0x01), Off (0x00), Toggle (0x02)
│ └── LevelControl cluster (0x0008)
│ Attribute: CurrentLevel (uint8, 0–254) — brightness
│ Command: MoveToLevel, Move, Step, MoveToLevelWithOnOff
└── Endpoint 2 (secondary function, e.g. colour)
└── ColorControl cluster (0x0300)
Attribute: CurrentHue, CurrentSaturation, ColorTemperatureMireds
Command: MoveToHue, MoveToSaturation, MoveToColorTemperatureEquivalencia KNX: Un clúster Matter se corresponde estrechamente con un bloque funcional KNX. Un atributo de clúster es análogo a un objeto de grupo KNX con un DPT definido. Un comando Matter es análogo a escribir una dirección de grupo KNX. La diferencia clave: los atributos Matter se leen directamente desde el nodo del dispositivo (unicast), mientras que los objetos de grupo KNX usan broadcast. Esto hace que Matter sea significativamente más escalable para grandes despliegues de sensores.
Flujo de puesta en servicio
La puesta en servicio de Matter es el proceso de agregar un dispositivo a un fabric (un dominio de confianza lógico) controlado por un comisionado (Apple Home, Google Home, etc.). El proceso utiliza BLE para la conexión inicial fuera de la caja, PASE (Password-Authenticated Session Establishment) para el primer canal cifrado y CASE para todas las sesiones posteriores.
Secuencia de puesta en servicio Matter
Step 1 — Discovery Commissioner (phone app) scans QR code or taps NFC tag on device QR code encodes: discriminator (12-bit), setup PIN (27-bit), vendor ID, product ID, device type, commissioning flow flags Step 2 — BLE connection (for most devices) Commissioner connects to device via BLE Alternative: devices already on IP network use DNS-SD discovery Step 3 — PASE session Commissioner and device establish PASE using the setup PIN from QR code PASE uses SPAKE2+ protocol (SRP variant) — PIN never transmitted Encrypted channel established over BLE (or UDP for IP-only devices) Step 4 — Device Attestation verification Commissioner requests Attestation Information from device: - Device Attestation Certificate (DAC) — device-unique leaf cert - Product Attestation Intermediate (PAI) — manufacturer intermediate CA - Certified Declaration (CD) — CSA certification assertion Commissioner validates: DAC → PAI → PAA (Product Attestation Authority) PAA root certs are distributed with commissioner firmware If DAC chain invalid: commissioning REJECTED Step 5 — Network provisioning (Thread devices) Commissioner sends Thread Operational Dataset (OTDS) to device OTDS contains: network name, channel, PAN ID, master key, extended PAN ID Device joins Thread mesh using OTDS Step 6 — Node Operational Certificate (NOC) issuance Commissioner's fabric CA issues NOC to device (unique per fabric) NOC encodes: Node ID (64-bit), Fabric ID (64-bit), device public key Device stores NOC in secure storage (hardware-protected if available) CASE sessions use NOC for mutual authentication going forward Step 7 — Device added to fabric Commissioner stores ACL (Access Control List) on device ACL defines which fabric members can read/write which clusters Device appears in commissioner app with correct device type UI
Multi-admin: múltiples ecosistemas en un solo dispositivo
El modelo Fabric de Matter permite que un solo dispositivo se comisione simultáneamente en múltiples fabrics independientes – por ejemplo, la misma cerradura de puerta se puede agregar tanto a Apple Home como a Google Home sin que ningún ecosistema necesite confiar en el otro. Cada fabric tiene su propio Fabric ID, su propio NOC para el dispositivo y sus propias entradas ACL. Esto es fundamentalmente diferente de Zigbee o Z-Wave, donde un dispositivo solo puede pertenecer a un coordinador a la vez.
| Aspecto multi-admin | Detalle |
|---|---|
| Máx. fabrics por dispositivo | Mínimo 5, típicamente 16 (específico del dispositivo, consulte la hoja de datos) |
| Aislamiento de fabrics | Cada tejido tiene NOC, ACL y claves de sesión independientes: no hay intercambio de datos entre tejidos |
| Agregar un segundo tejido | Abrir la ventana de comisionamiento (OCW) en el dispositivo del primer tejido, luego comisionar desde el segundo ecosistema |
| Método OCW | Ventana de comisionamiento mejorada con ventana de 180 segundos; utiliza PASE con PIN de un solo uso |
| Eliminación de un tejido | Cada comisionador puede eliminarse de forma independiente; no afecta a otros tejidos |
| Estado del atributo | Compartido: el estado OnOff es la única fuente de verdad leída por todos los fabrics |
Cadena de certificados de atestación del dispositivo
Cada dispositivo Matter debe llevar un certificado de atestación del dispositivo (DAC) aprovisionado en fábrica. La cadena DAC demuestra que el dispositivo es un producto genuino certificado por CSA de un fabricante específico. Un comisionador que no pueda verificar la cadena completa hasta una raíz PAA de confianza debe rechazar la comisión; esto evita que dispositivos falsificados o no certificados se unan a un fabric Matter.
Cadena de confianza DAC
PAA (Product Attestation Authority) Root CA operated by CSA or major ecosystems (Apple, Google) PAA certs embedded in commissioner firmware CSA maintains PAA registry (publicly accessible) PAI (Product Attestation Intermediate) Issued by PAA to manufacturer One PAI per product family or manufacturing batch Stored on device, sent to commissioner during attestation DAC (Device Attestation Certificate) Issued by manufacturer's PAI CA to individual device at factory Contains: device public key (unique key pair per device) Contains: Vendor ID (VID) + Product ID (PID) matching the device Private key stored in secure storage on device — never exported DAC serial number provides revocation capability (future CRL) Certified Declaration (CD) Signed by CSA, attests product passed Matter certification testing Contains: VID, PID list, device type IDs, certification ID Embedded in device firmware as a CBOR-encoded blob
Dispositivos de desarrollo vs producción: Las compilaciones de desarrollo del SDK Matter utilizan certificados PAA de prueba que NO son confiables para los comisionadores de producción (Apple Home, Google Home). Los dispositivos construidos con la cadena DAC de prueba fallarán la atestación en ecosistemas de producción. Solo los dispositivos con un DAC de producción válido de la cadena de confianza PAA registrada en CSA pueden ser comisionados en sistemas de consumo y comerciales.
Comparación Matter vs Zigbee vs Z-Wave
Para los ingenieros de automatización de edificios que evalúan la selección de protocolos, las diferencias clave entre Matter, Zigbee y Z-Wave determinan la idoneidad para tipos de instalación específicos, densidades de dispositivos y requisitos de integración.
| Atributo | Matter + Thread | Zigbee 3.0 | Z-Wave LR |
|---|---|---|---|
| Organismo de estandarización | CSA (anteriormente Zigbee Alliance) | CSA | Silicon Labs / Z-Wave Alliance |
| Radio / PHY | IEEE 802.15.4 2,4 GHz | IEEE 802.15.4 2,4 GHz | 868/908/916 MHz sub-GHz |
| Capa de red | IPv6 (6LoWPAN) | Malla propietaria | Malla propietaria |
| Nativo IP | Sí — IPv6 de extremo a extremo | No — requiere traducción del coordinador | No — requiere traducción del hub |
| Alcance máximo (salto mesh) | ~10 m interior por salto, saltos ilimitados | ~10 m por salto, 20+ saltos | LR: ~300 m LOS, mesh 4 saltos |
| Máx. nodos (red) | Thread: 250+ por Border Router | ~200 por coordinador | Z-Wave LR: ~4000 |
| Multi-administrador | Sí – hasta 16 fabrics por dispositivo | No – un coordinador por dispositivo | No – un controlador |
| Soporte Wi-Fi | Sí (misma capa de aplicación Matter) | No | No |
| Soporte de ecosistema | Apple, Google, Amazon, Samsung | Philips Hue, IKEA, Aqara, otros | Fibaro, Ring, Aeotec, otros |
| Puesta en marcha | QR / NFC → BLE → CASE | Touchlink / direccionamiento de red | SmartStart QR |
| Seguridad | CASE (similar a TLS), atestación DAC, ACL | AES-128 CCM, centro de confianza | S2 (AES-128-CCM + ECDH) |
| Soporte de puente KNX | Sí — tipo de dispositivo Matter Bridge | A través de Zigbee2MQTT + plugin KNX | A través de Z-Wave JS + puente personalizado |
¿Necesita dispositivos Matter puestos en marcha en su proyecto de construcción?
Diseñamos y ponemos en marcha sistemas de edificios inteligentes basados en Matter: planificación de malla Thread, puesta en marcha multifabric en Apple Home y Google Home, integración de puente KNX e incorporación completa de dispositivos verificada por atestación con documentación del proyecto.
Solicitar presupuesto →