Model a bridge that exposes non-Matter Zigbee devices to a Matter fabric using the Aggregator device type
domain: csa-iot.org · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Implement the bridge's root endpoint as the Aggregator device type (device ID 0x000E)
For each bridged Zigbee device, create a dynamic endpoint using the Bridged Node device type (device ID 0x0013)
Add the mandatory Bridged Device Basic Information cluster (cluster ID 0x0039) on each Bridged Node endpoint to expose the non-Matter device's identity
List every bridged endpoint in the Aggregator endpoint's Descriptor cluster PartsList attribute
Map incoming Zigbee state changes to the corresponding dynamic endpoint's clusters so Matter controllers see live state
Known gotchas
the Bridged Device Basic Information cluster is mandatory on every Bridged Node endpoint -- omitting it breaks controller discovery of the bridged device's identity
PartsList on the Aggregator endpoint must be kept in sync as devices are added or removed from the non-Matter network, or controllers see stale or missing endpoints
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?