matter-interaction 0.4.1

Matter Interaction Model message framing: invoke, read, and write request/response encoding.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

# matter-interaction

Matter Interaction Model (IM) message framing — Matter Core Specification §10.
Builds the request messages a controller puts on the wire and parses the
responses that come back. You supply already-encoded cluster TLV (from
`matter-clusters`, or your own) and the paths; this crate frames them.

Part of [`matter-rust`](https://github.com/phunapps/matter-rust). Most users
want [`matter-controller`](https://crates.io/crates/matter-controller), which
drives these codecs over a live CASE session. Reach for `matter-interaction`
directly when you own the transport and want the IM message layer on its own.

> Status: **0.4.1**, published on crates.io. Depends only on `matter-codec`,
> and performs no IO. Stability: a `0.x` crate, so a **minor** bump may break
> API.

```toml
[dependencies]
matter-interaction = "0.4"
```

## What it does

- **Invoke** — a single command (`build_invoke_request`), several commands in
  one message (`build_invoke_request_batch` /
  `parse_invoke_response_batch`), a group/broadcast invoke
  (`build_invoke_request_group`), and the timed variant
  (`build_invoke_request_timed`). Responses parse to a command payload or a
  per-command `ImStatus`.
- **Read** — concrete *and* wildcard paths (`ReadPath` leaves endpoint,
  cluster, or attribute unset for "all"), plus `build_read_request_full` for a
  request carrying attribute paths, event paths, and event filters together.
- **Subscribe** — `SubscribeRequest` / `build_subscribe_request`,
  `parse_subscribe_response`, and the `StatusResponse` the subscriber sends to
  acknowledge each report (`build_status_response`).
- **Chunked reports** — `ReportAccumulator` reassembles a report split across
  messages, including a list attribute split across chunk boundaries, with
  configurable element and byte ceilings.
- **Write** — one-message writes (`build_write_request`), the timed variant,
  and `build_list_write_chunks` for a list attribute too large to send in a
  single message.
- **Events** — `EventPath` and `EventFilter` on both reads and subscriptions,
  and `EventReportIB` parsing (priority, timestamp, payload) via
  `ReportData::events`.
- **Timed interactions** — the `TimedRequest` message
  (`build_timed_request`), which precedes a write or invoke that carries the
  timed flag.
- **Server side** — `parse_invoke_request` and the `build_invoke_response_*`
  builders, for answering an invoke rather than issuing one. This workspace's
  OTA provider is built on them.

## What it does not do

- No IO, no sessions, no exchanges, no MRP — that is
  [`matter-transport`](https://crates.io/crates/matter-transport).
- No cluster semantics. Command and attribute payload bytes are opaque here;
  typed codecs live in
  [`matter-clusters`](https://crates.io/crates/matter-clusters).
- No controller-side policy. The batch builders are here, but deciding what to
  batch and honouring a device's `MaxPathsPerInvoke` is the caller's job —
  `matter-controller` does it.

## Verification

Byte-parity against matter.js fixtures in `test-vectors/commissioning/im/`
(see `tests/im_byte_parity.rs`), captured via `cargo xtask capture-im`.

## License

Apache 2.0. See [LICENSE](../../LICENSE).