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.

OTA Dual-Cluster Architecture

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.

ParameterTypeRequiredDescription
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

FieldTypeDescription
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)
Fabric-Level Isolation

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)
Progress Percentage Meaning Changes with State

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:

0
Unknown Unknown — the device has just started and the update state has not been determined yet
1
Idle Idle — no update activity, running normally
2
Querying Querying — currently querying the Provider for available updates
3
DelayedOnQuery Query delayed — the Provider requested the device wait before retrying the query
4
Downloading Downloading — currently downloading the firmware image from the Provider
5
Applying Applying — writing the downloaded firmware to flash and verifying
6
DelayedOnApply Apply delayed — firmware is ready, waiting for the right time to reboot and apply (e.g., waiting for user confirmation or off-peak hours)
7
RollingBack Rolling back — update failed, restoring to the previous firmware version
8
DelayedOnUserConsent Waiting for user consent — update is ready, waiting for user confirmation on the device or in the app before proceeding

AnnouncementReasonEnum — Announcement Reason

Used in the AnnounceOTAProvider command to inform the device of the reason for this announcement:

0
SimpleAnnouncement Simple announcement — merely informs that a Provider exists; the device can decide whether to query
1
UpdateAvailable Update available — explicitly states a new version exists; the device should query soon
2
UrgentUpdateAvailable Urgent update — a security patch or critical bug fix is available; the device should query immediately and prioritize the update

ChangeReasonEnum — State Change Reason

Used in the StateTransition event to explain the reason for the state machine transition:

0
Unknown Unknown reason
1
Success Previous operation succeeded, progressing normally to the next stage
2
Failure Operation failed (e.g., download interrupted, verification failed)
3
TimeOut Operation timed out (e.g., Provider not responding)
4
DelayByProvider Delay requested by Provider — the Provider returned Busy or specified a retry wait time

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.

FieldIDTypeDescription
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.

FieldIDTypeDescription
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.

FieldIDTypeDescription
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)
}
Developer Tip

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:

  1. Management node sends AnnounceOTAProvider (0x00) to the device, informing it of an available Provider
  2. Device sends QueryImage request to the Provider — UpdateState changes from Idle to Querying
  3. Provider returns available update — device starts downloading, UpdateState changes to Downloading
  4. During download, UpdateStateProgress gradually increases from 0 to 100
  5. Download complete, device verifies firmware and starts writing — UpdateState changes to Applying
  6. Write complete, device reboots to apply new firmware — VersionApplied event is triggered after reboot
  7. 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:

  1. SimpleAnnouncement (0): Device can query at its convenience, not urgent. Suitable for regular firmware releases
  2. UpdateAvailable (1): Explicitly states a new version is available; device should query soon. Suitable for feature updates
  3. 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:

  1. Subscribe to UpdateState (0x0002) and UpdateStateProgress (0x0003) attributes
  2. Also subscribe to the StateTransition, VersionApplied, and DownloadError events
  3. 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..."
  4. On VersionApplied event → Show "Update successful! Upgraded to version X"
  5. 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).