Skip to main content

Controlling

Controlling covers how your app reacts to and commands Matter devices after commissioning — reading and writing cluster attributes through ESPRMMatterDeviceParam.

There is one app API and two independent transports. The SDK picks a transport at runtime; each path has its own interfaces and adapters.


Shared app API

Both paths use the same calls. You do not choose local vs remote in UI code:

await powerParam.getValue();
await powerParam.setValue(true);

The SDK maps the param to endpoint / cluster / attribute (or command) via cluster config, then runs executeMatterControl.

Default order (DEFAULT_MATTER_TRANSPORT_ORDER):

  1. matter_localLocal Control
  2. matter_controllerRemote Control

Only modes present in node.availableTransports are tried. On failure, the next mode is used. If none succeed → NODE_UNREACHABLE.

info

Transport manager + remote path require @espressif/rainmaker-matter-sdk 3.1.0+.


Two paths — clear separation

Local ControlRemote Control
Transport keymatter_localmatter_controller
How it reaches the devicePhone → native Matter stack → device on LANPhone → RainMaker cloud cmd-resp → RainMaker Controller → device on fabric
When to usePhone on home Wi‑Fi / same LAN as devicePhone off LAN; hub online in the cloud
Required adaptermatterControlAdapterNone (built-in SDK handler)
SDK interfaceESPMatterControlAdapterInterfaceMatterControllerTransportMetadata on the peer + cmd-resp
Home app referenceESPMatterControlAdapter.tsWiring in app layer; see RainMaker Controller
Depends onNative Matter stack; usually local discovery for reachabilityController node on fabric; peer availableTransports.matter_controller

Local and remote are independent. You can ship:

  • Local only — configure matterControlAdapter, never register matter_controller
  • Remote only — skip the control adapter; register controller transport on peers (LAN ops will not work)
  • Both — default Home app setup; local first, remote as fallback

Dependencies and adapters by path

Local Control depends on

DependencyRole
matterControlAdapterNative read / write / invoke
ESPMatterControlAdapterInterfaceContract the adapter implements
Optional: matterLocalDiscoveryAdapterMarks peers reachable → fills matter_local transport
Optional: clusterConfigBuilds params the UI binds to
Native Matter module (Android/iOS)Actual CASE session on LAN

Details: Local Control · adapters: Matter Adapters

Remote Control depends on

DependencyRole
RainMaker Controller node on the fabricRelays Matter ops
availableTransports.matter_controller + controllerNodeId on the peerEnables the remote transport
Built-in matterControllerControlHandlercreateCmdResp → poll → parse (no app adapter)
Logged-in user / cloud APICmd-resp to the controller node
Does not use matterControlAdapterLocal adapter is unused for this hop

Details: Remote Control · hub: RainMaker Controller


Documentation map

GuideContent
This pageHow control works overall; local vs remote; interfaces
Local ControlAdapter methods, configure, read/write/invoke
Remote ControlController transport, fallback, wiring
RainMaker ControllerHub node, discovery, services
Enable Controller TransportRegister matter_controller, cmd IDs
App-Side Controller WiringHome-app found/lost + MTDevices

On this page