Key points
- Matter standardises how certified devices on one IP network describe themselves and are controlled, with local control as a design goal.
- Sites also need people’s phones, apps, gateways, machines and software agents to find each other, verify identity, share working data and call each other’s capabilities, often across organisations and without a shared network.
- Teams assemble that from local MQTT brokers, edge runtimes such as AWS IoT Greengrass and Azure IoT Edge, sync databases such as Ditto, and coordination SDKs such as Offline Protocol.
- The daily payoff is fewer round trips to a distant service, fewer manual handoffs, and work that keeps moving when the uplink is slow or down.
Local coordination at work sites
Local coordination at a work site means the devices involved in a task exchanging what they need directly, near each other. A few everyday examples:
- A technician on a turbine pulls the asset’s service history from a colleague’s tablet or a site gateway, rather than waiting for a signal.
- A driver and a yard worker complete a handoff, with the job record moving from one phone to the other.
- Farm equipment shares readings with the operator’s phone in the field.
- A robot asks a nearby charger or another robot for a capability, such as a free charging slot or a map tile.
- A software agent on a gateway answers questions from apps on the same site, using data held there.
In each case the cloud is still the system of record. The point is that the step itself does not depend on a round trip to it.
Matter scope and limits
Matter standardises device interoperability in the home. The Matter project describes its aim as a universal IPv6-based protocol for smart home devices, and the Connectivity Standards Alliance (CSA) calls it a local connectivity technology. It defines device types and their commands, how devices are commissioned and certified, and how one device can belong to several ecosystems. What is Matter? covers each part.
Matter also makes assumptions that suit a home: the CSA says it was designed to have all devices on the same network, and control from outside needs an internet-connected controller in the home. Its published layers and device types describe devices and controllers. They do not include sync of application data between apps, identity for people or organisations, a mesh between phones with no shared network, or calls between software agents. Those are not gaps in Matter so much as different jobs.
The CSA itself says commercial and industrial IoT is where its influence is expanding fastest. Its 2026 example for commercial and industrial spaces is Aliro, its access standard, not a commercial profile of Matter.
Site needs beyond device-control standards
- Coordination with no shared network. People and machines move between areas, contractors bring their own devices, and some places have no Wi-Fi at all. Devices need to find each other over whatever path exists: Bluetooth LE, a local network or a relay.
- Identity across organisations. The operator, the contractor and the equipment maker each have their own systems. Devices need to verify who they are talking to without a shared account server being reachable.
- Shared working data. Checklists, job records and inspection findings that several people edit, merged when they reconnect.
- Calls to nearby capabilities. One device or agent asking another to do something, such as look up a part, print a label or run a model, with a request and response rather than a fixed device type.
- Delivery to the backend afterwards. Results held on site and delivered to the system of record when a link exists, with a clear record of what was accepted.
Local coordination building blocks
| Building block | What it gives a site | What it needs |
|---|---|---|
| Matter | Certified device control across brands, locally | One IP network, a controller, and a border router for Thread devices |
| A local MQTT broker | Publish and subscribe messaging between local clients | A broker reachable by every client over IP |
| An edge runtime (AWS IoT Greengrass, Azure IoT Edge) | Cloud-managed software on a gateway, local messaging, buffering | A gateway, and an initial connection to its cloud |
| A sync database (Ditto, Couchbase Lite) | A local database that syncs between devices and with a server | The vendor’s SDK on each device |
| A coordination SDK (Offline Protocol) | Discovery, identity, encrypted messages, shared documents and service calls between apps across paths | The SDK in each participating app |
These are not exclusive. A site can run Matter for its certified devices, an edge runtime on its gateway, and a coordination SDK in its field apps. Matter alternatives for local device coordination compares ten options in more detail.
Checklist for choosing a coordination layer
- Which participants must coordinate: certified devices, people’s phones, gateways, machines, agents, or all of them?
- Do they always share one network, or must they work across Bluetooth LE, the local network and a relay?
- Do they belong to one organisation, or must devices from different owners verify each other?
- Is the data device state, application records, or both, and how are conflicting edits merged?
- What happens to work done on site when the uplink is down, and how does it reach the backend?
- What is metered: devices, messages, users, or nothing on the local path?
Offline Protocol as a site coordination layer
Offline Protocol is a coordination layer for the participants a device-control standard leaves out. Apps on phones, computers and gateways, and the agents running on them, discover each other over Bluetooth LE, the local network or a relay, verify each other with Ed25519 identities, and exchange MLS-encrypted messages, shared documents and service calls. Its Python package runs a full peer on a Linux or desktop gateway. It does not implement Matter or control Matter devices, and the cloud stays the system of record. Traffic between devices over a local transport is never metered.