Building a Matter Gateway in Rust: Bridging Devices to Apple Home
A practical rs-matter prototype: endpoints, device mapping, commands, state reports and persistence, with clear limits on hardware validation.
In the previous post, we paired a prototype gateway with Apple Home using a computer and a phone. This time, let’s look at the Rust code behind the Matter side. The project uses rs-matter. Real Bluetooth Mesh interoperability, the Linux board and large deployments remain untested.
A gateway is not one big light
The gateway appears as a Matter node. Endpoint 0 provides its root functions, endpoint 1 is the aggregator, and each bridged light gets its own endpoint. The device types and clusters tell the controller what each device is and can do: Descriptor, On/Off, Bridged Device Basic Information and Groups are included in this prototype.
Mapping endpoints to devices
A small device table holds the endpoint ID, device address, name, on/off state and reachability. When Apple Home asks to turn on endpoint 2, the gateway finds the matching device address and sends a command downstream. Real products need additional provisioning, security and recovery data.
Commands and state reports
The prototype updates its local state optimistically when a command arrives, sends the command, and uses a subsequent status report to correct the state. If the device never responds, the display may temporarily be wrong. Timeouts, retries, polling and offline detection still need work.
The reverse path matters too: a physical switch can change the light. The gateway matches the incoming device address, updates the endpoint state and notifies Matter subscribers. In the phone demonstration, repeated identical broadcasts are deduplicated to avoid restoring stale state. Those plaintext broadcasts are only a demo, not a real Mesh test.
Adding devices and surviving restarts
Devices can be added or removed while the prototype runs. It assigns increasing endpoint IDs instead of immediately reusing a deleted ID, reducing the risk of confusing controller state. Long-term allocation and recovery still need design and testing.
The device mapping is saved locally, while rs-matter has its own persistent store. The mapping is written to a temporary file before replacement; this reduces the chance of corrupting the old file but is not a complete power-failure guarantee. Actual device state must be confirmed again, and real Mesh keys need a secure backup and recovery plan.
What has been tested?
The demonstration verified pairing with Apple Home, displaying and controlling simulated bridged devices, simulated status reports, and basic addition, removal and restart behavior. It has not verified the real Mesh network, operation on the target Linux board, failure recovery or hundreds of devices. Test credentials are not production certification.
The Rust release profile enables size optimization, LTO and symbol stripping. One previous desktop build was about 2.3 MB; other targets and configurations need their own measurements. Next we will replace the simulation with real hardware and test the control and reporting paths.