OtaSoftwareUpdateRequestor Cluster
Cluster ID: 0x002A |
Endpoint: Endpoint 0 (Root Endpoint) |
Role: Server (device acts as OTA client)
OtaSoftwareUpdateRequestor is the client side of the Matter OTA update system — i.e., the device that needs to be updated. It is responsible for querying the OTA Provider (update provider, corresponding to Cluster 0x0029) for new versions, downloading firmware, and applying updates. All Matter devices that support OTA must implement this Cluster.
Matter's OTA update is accomplished through two Clusters working together: OtaSoftwareUpdateProvider (0x0029) is the "server side", responsible for hosting firmware and responding to queries; OtaSoftwareUpdateRequestor (0x002A) is the "client side", responsible for initiating queries, downloading, and applying updates. This page describes the latter — the device-side behavior.
Commands
OtaSoftwareUpdateRequestor has only 1 command. It is not initiated by the device itself, but sent to the device by an external node (typically an OTA Provider or management node), informing the device that it can query a specific Provider for updates.
| ID | Name | Description | Direction |
|---|---|---|---|
0x00 |
AnnounceOTAProvider | Notify device of an available OTA Provider | Client → Server |
AnnounceOTAProvider — Announce OTA Provider (0x00)
An external node uses this command to inform a device: "There is an OTA Provider that can provide updates for you." Upon receiving this command, the device should query the specified Provider for updates as soon as possible (by invoking the Provider's QueryImage command). This is the core trigger mechanism for push-style OTA — allowing devices to be passively notified rather than constantly polling.
| Parameter | Type | Required | Description |
|---|---|---|---|
| ProviderNodeID | node-id | Yes | Node ID of the OTA Provider node |
| VendorID | vendor-id | Yes | Provider's Vendor ID, used by the device to determine whether to trust this Provider |
| AnnouncementReason | AnnouncementReasonEnum | Yes | Reason for the announcement (see enum description) |
| MetadataForNode | octstr | No | Custom metadata from the Provider to the device (max 512 bytes, optional) |
| Endpoint | endpoint-no | Yes | Endpoint on the Provider node where the OTA Provider Cluster resides |
Usage Scenarios
The management backend releases new firmware and sends the AnnounceOTAProvider command to all target devices via a Hub or management node. Upon receipt, devices query the specified Provider for available updates. If the AnnouncementReason is UrgentUpdateAvailable, the device should prioritize it, potentially skipping user confirmation and starting the download immediately.
Attributes
OtaSoftwareUpdateRequestor has 4 application attributes, divided into two groups: "Provider Configuration" and "Update State".
| ID | Name | Type | Group | Description |
|---|---|---|---|---|
0x0000 |
DefaultOTAProviders | list<ProviderLocation> | Provider Configuration | Default OTA Provider list |
0x0001 |
UpdatePossible | bool | Update State | Whether the device can accept updates |
0x0002 |
UpdateState | UpdateStateEnum | Update State | Current state of the OTA update state machine |
0x0003 |
UpdateStateProgress | uint8 / null | Update State | Update progress percentage (0-100) |
Provider Configuration (0x0000)
Configures which OTA Providers the device should query for updates. Each Fabric can configure at most one Provider.
| ID | Name | Type | Description |
|---|---|---|---|
0x0000 |
DefaultOTAProviders (Default OTA Providers) | list<ProviderLocation> |
List of OTA Providers the device queries by default. Each entry is a ProviderLocation struct.
Writing requires manage privileges (Administrator role).
Each Fabric can contain at most one entry — writing a new one for the same Fabric overwrites the old one
|
ProviderLocation Struct
| Field | Type | Description |
|---|---|---|
| ProviderNodeID | node-id | Node ID of the OTA Provider |
| Endpoint | endpoint-no | Endpoint on the Provider where the OTA Provider Cluster resides |
| FabricIndex | fabric-idx | Fabric index this entry belongs to (automatically populated by the system) |
DefaultOTAProviders is isolated per Fabric — each Fabric (administrative domain) can only see and modify its own entries. This means when a device joins multiple Fabrics simultaneously, each Fabric's administrator can specify their own OTA Provider independently without affecting each other.
Update State (0x0001 - 0x0003)
Reflects the device's current OTA update state. These attributes are all read-only; apps track update progress by subscribing to them.
| ID | Name | Type | Description |
|---|---|---|---|
0x0001 |
UpdatePossible (Can Update) | bool |
Whether the device can currently accept OTA updates. true means yes, false means the device currently does not allow updates
(e.g., performing a critical operation, battery too low, etc.). Default value is true
|
0x0002 |
UpdateState (Update State) | UpdateStateEnum | Current state of the device's OTA state machine (see enum description). This attribute tells you whether the device is querying, downloading, applying, or idle |
0x0003 |
UpdateStateProgress (Update Progress) | uint8 / null |
Progress percentage of the current update operation, range 0-100. Nullable — null means progress is unavailable
(e.g., when the device is in the Idle state, or when the current stage cannot calculate progress)
|
The meaning of UpdateStateProgress depends on the current value of UpdateState.
In the Downloading state it represents download progress; in the Applying state it represents installation/write progress.
Progress may reset to 0 or null when the state changes. Do not assume it is a linearly increasing global progress value.
Enum Quick Reference
UpdateStateEnum — Update State
Describes the complete lifecycle of the device's OTA state machine, with 9 states:
AnnouncementReasonEnum — Announcement Reason
Used in the AnnounceOTAProvider command to inform the device of the reason for this announcement:
ChangeReasonEnum — State Change Reason
Used in the StateTransition event to explain the reason for the state machine transition:
Events
OtaSoftwareUpdateRequestor defines 3 events covering the key milestones of the OTA lifecycle. Subscribing to these events allows real-time tracking of the device's update process, which is more timely than polling attributes.
| ID | Name | Priority | Description |
|---|---|---|---|
0x00 |
StateTransition | Info | Triggered when the OTA state machine transitions between states |
0x01 |
VersionApplied | Critical | Triggered after a new firmware version is successfully applied |
0x02 |
DownloadError | Info | Triggered when an error occurs during firmware download |
StateTransition — State Transition Event (0x00)
Triggered whenever the OTA state machine transitions from one state to another. This is the most critical event for tracking the update flow — by listening to it, you can follow every step from idle to querying, from downloading to applying.
| Field | ID | Type | Description |
|---|---|---|---|
| PreviousState | 0x00 |
UpdateStateEnum | State before the transition |
| NewState | 0x01 |
UpdateStateEnum | New state after the transition |
| Reason | 0x02 |
ChangeReasonEnum | Reason that triggered this transition |
| TargetSoftwareVersion | 0x03 |
uint32 / null | Target firmware version number. null means not yet determined (e.g., when transitioning from Idle to Querying, the target version is unknown) |
Event report example — transitioning from Idle to Downloading:
{
"eventReports": [{
"eventData": {
"path": {
"endpointId": 0,
"clusterId": "0x002A",
"eventId": "0x00" // StateTransition
},
"eventNumber": 15,
"priority": "INFO",
"data": {
"0": 1, // PreviousState = Idle
"1": 4, // NewState = Downloading
"2": 1, // Reason = Success (query succeeded, starting download)
"3": 5 // TargetSoftwareVersion = 5
}
}
}]
}
VersionApplied — Version Applied Event (0x01)
Triggered after a new firmware version is successfully applied (typically reported after device reboot). This event confirms that the update is truly complete. Its priority is Critical, ensuring it is not discarded even when the event queue is full.
| Field | ID | Type | Description |
|---|---|---|---|
| SoftwareVersion | 0x00 |
uint32 | Version number of the newly applied firmware |
| ProductID | 0x01 |
uint16 | Product ID of the device |
Event report example:
{
"eventReports": [{
"eventData": {
"path": {
"endpointId": 0,
"clusterId": "0x002A",
"eventId": "0x01" // VersionApplied
},
"eventNumber": 18,
"priority": "CRITICAL",
"data": {
"0": 5, // SoftwareVersion = 5 (newly applied version number)
"1": 4 // ProductID = 4 (product ID)
}
}
}]
}
DownloadError — Download Error Event (0x02)
Triggered when an error is encountered during firmware download. This event provides contextual information at the time of failure (bytes downloaded, progress, etc.), which helps diagnose network issues or Provider-side faults.
| Field | ID | Type | Description |
|---|---|---|---|
| SoftwareVersion | 0x00 |
uint32 | Target firmware version being downloaded |
| BytesDownloaded | 0x01 |
uint64 | Number of bytes successfully downloaded before the error |
| ProgressPercent | 0x02 |
uint8 / null | Download progress percentage (0-100) at the time of error; null means unable to calculate |
| PlatformCode | 0x03 |
int64 / null | Platform-specific error code; null means no additional information. Specific meaning is defined by the device vendor |
Event report example — error occurred at 75% download:
{
"eventReports": [{
"eventData": {
"path": {
"endpointId": 0,
"clusterId": "0x002A",
"eventId": "0x02" // DownloadError
},
"eventNumber": 16,
"priority": "INFO",
"data": {
"0": 5, // SoftwareVersion = 5
"1": 512, // BytesDownloaded = 512
"2": 75, // ProgressPercent = 75 (error occurred at 75% download)
"3": -1 // PlatformCode = -1 (platform error code, nullable)
}
}
}]
}
Example Data
Attribute read results from an idle device's OtaSoftwareUpdateRequestor Cluster:
{
// --- Default OTA Providers ---
"0x0000": [ // DefaultOTAProviders (can configure multiple)
{
"providerNodeID": 12345, // Provider's Node ID
"endpoint": 0, // Endpoint on the Provider where the OTA Provider Cluster resides
"fabricIndex": 1 // Fabric index this entry belongs to
}
],
// --- Update Capability ---
"0x0001": true, // UpdatePossible = true (device can currently accept updates)
// --- Update State ---
"0x0002": 0, // UpdateState = Idle (currently idle, not in an update flow)
"0x0003": null // UpdateStateProgress = null (no progress information)
}
The OTA Requestor Cluster resides on Endpoint 0 (Root Endpoint), not on functional endpoints.
Make sure to specify the correct Endpoint when reading attributes. Also, DefaultOTAProviders is a Fabric-scoped list,
so you can only see entries for the current Fabric.
Common Scenarios
Scenario 1: Normal OTA Update Flow
Typical flow of a complete OTA update from announcement to application:
- Management node sends
AnnounceOTAProvider (0x00)to the device, informing it of an available Provider - Device sends QueryImage request to the Provider — UpdateState changes from Idle to Querying
- Provider returns available update — device starts downloading, UpdateState changes to Downloading
- During download, UpdateStateProgress gradually increases from 0 to 100
- Download complete, device verifies firmware and starts writing — UpdateState changes to Applying
- Write complete, device reboots to apply new firmware — VersionApplied event is triggered after reboot
- UpdateState returns to Idle, ending the entire flow
Scenario 2: Provider Announcement Triggers Update
Different announcement reasons in the AnnounceOTAProvider command trigger different device behaviors:
- SimpleAnnouncement (0): Device can query at its convenience, not urgent. Suitable for regular firmware releases
- UpdateAvailable (1): Explicitly states a new version is available; device should query soon. Suitable for feature updates
- UrgentUpdateAvailable (2): Urgent security patch; device should query immediately and prioritize download. The device may skip DelayedOnUserConsent and proceed directly to download to ensure the security vulnerability is patched ASAP
When the app receives a StateTransition event, it can use the Reason field to determine whether to show a notification to the user. Updates triggered by UrgentUpdateAvailable should display a prominent alert.
Scenario 3: Update Progress Tracking
How to implement real-time OTA update progress display in an app:
- Subscribe to
UpdateState (0x0002)andUpdateStateProgress (0x0003)attributes - Also subscribe to the
StateTransition,VersionApplied, andDownloadErrorevents - Display different UI states based on UpdateState values:
- Idle → Show "Firmware is up to date" or a "Check for Updates" button
- Querying → Show "Checking for updates..."
- Downloading → Show download progress bar with value from UpdateStateProgress
- Applying → Show "Installing update, do not power off..."
- DelayedOnUserConsent → Show confirmation dialog, waiting for user consent
- RollingBack → Show "Update failed, restoring..."
- On VersionApplied event → Show "Update successful! Upgraded to version X"
- On DownloadError event → Show "Download failed" with downloaded progress and a retry button
Note: UpdateStateProgress may become null or reset to 0 during state transitions. The UI should handle the null case gracefully (e.g., hide the progress bar or show an indeterminate progress indicator).