GeneralDiagnostics Cluster
Cluster ID: 0x0033 |
Endpoint: Fixed on Endpoint 0 (Root Endpoint)
GeneralDiagnostics provides device health status and operational diagnostics — including network interface details, reboot count, uptime, boot reason, and real-time tracking of hardware, radio, and network faults. All Matter devices must implement this Cluster; it is the primary entry point for device operations and troubleshooting.
GeneralDiagnostics only appears on Endpoint 0 (Root Endpoint), never on functional endpoints.
It reflects the health status of the entire device, not the status of a specific functional module.
When reading, make sure to specify endpointId = 0.
Commands
GeneralDiagnostics has only two commands. TestEventTrigger is used for certification testing and is typically disabled in production;
TimeSnapshot is used to get the device's current time snapshot.
Click on a command ID in the table below to jump to its detailed description.
| ID | Name | Direction | Description |
|---|---|---|---|
0x00 |
TestEventTrigger | Client → Server | Trigger an internal test event on the device |
0x01 |
TimeSnapshot | Client → Server | Get the device's current time snapshot |
TestEventTrigger — Test Event Trigger (0x00)
Triggers a preset test event on the device. This command is primarily used during Matter certification testing, allowing test tools to simulate specific device behaviors without disassembly (e.g., simulating sensor alarms, triggering fault states, etc.).
| Parameter | Type | Description |
|---|---|---|
| EnableKey | octstr (16 bytes) | Enable key — must match the device's preset key, otherwise the command is rejected. Production devices should set this key to all zeros to disable test functionality |
| EventTrigger | uint64 | Trigger identifier — identifies the specific test event to trigger, defined by the vendor or Matter test specification |
This command only works when the TestEventTriggersEnabled attribute is true.
Production devices must disable test triggers (set EnableKey to all zeros), otherwise there is a security risk —
attackers could use this command to simulate faults or tamper with device behavior.
Usage Scenarios
During Matter certification testing, test tools use this command to make the device simulate specific states (e.g., smoke alarm, network disconnection), verifying that the device's event reporting and fault handling logic meets the specification. This command is rarely used in app development.
TimeSnapshot — Time Snapshot (0x01)
Requests the device to return its current system time. No parameters required.
The device returns a TimeSnapshotResponse containing the milliseconds since boot and a POSIX timestamp (if the device has a reliable clock).
TimeSnapshotResponse Response Fields
| Field | Type | Description |
|---|---|---|
| SystemTimeMs | uint64 | Milliseconds elapsed since device boot (monotonically increasing, unaffected by clock calibration) |
| PosixTimeMs | uint64 / null | POSIX timestamp (millisecond precision). If the device has no reliable UTC clock, this field is null |
Usage Scenarios
Used when troubleshooting device time synchronization issues. For example, if device log timestamps are noticeably off, you can use TimeSnapshot to confirm whether the device's internal clock is accurate.
SystemTimeMs is a monotonic clock from boot, and can be cross-validated with the UpTime attribute.
Attributes
GeneralDiagnostics attributes are divided into four groups by function. Click on an attribute ID in the summary table below to jump to its detailed description.
| ID | Name | Type | Group | Description |
|---|---|---|---|---|
0x0000 |
NetworkInterfaces | list<NetworkInterface> | Network Interface | All network interface information of the device |
0x0001 |
RebootCount | uint16 | Runtime Statistics | Total reboot count |
0x0002 |
UpTime | uint64 | Runtime Statistics | Device uptime (seconds) |
0x0003 |
TotalOperationalHours | uint32 | Runtime Statistics | Total operational hours |
0x0004 |
BootReason | BootReasonEnum | Runtime Statistics | Reason for the most recent boot |
0x0005 |
ActiveHardwareFaults | list<HardwareFaultEnum> | Fault Tracking | List of currently active hardware faults |
0x0006 |
ActiveRadioFaults | list<RadioFaultEnum> | Fault Tracking | List of currently active radio faults |
0x0007 |
ActiveNetworkFaults | list<NetworkFaultEnum> | Fault Tracking | List of currently active network faults |
0x0008 |
TestEventTriggersEnabled | bool | Test Configuration | Whether test event triggers are enabled |
Network Interface (0x0000)
Detailed information list of all currently available network interfaces on the device.
| ID | Name | Type | Description |
|---|---|---|---|
0x0000 |
NetworkInterfaces Network Interface List |
list<NetworkInterface> | Information list of all current network interfaces on the device. Each element is a NetworkInterface struct containing interface name, status, IP address, and other details. Maximum 8 interfaces |
NetworkInterfaces is the most direct way to understand the device's network connectivity.
If the device has both WiFi and Thread interfaces, the list will contain multiple entries.
By checking IsOperational, you can determine which interface is currently active.
Runtime Statistics (0x0001-0x0004)
Device uptime statistics and boot reason — key indicators for assessing device stability.
| ID | Name | Type | Description |
|---|---|---|---|
0x0001 |
RebootCount Reboot Count |
uint16 | Total number of reboots since the device was manufactured. Frequent reboots usually indicate stability issues (unstable power supply, firmware crashes, etc.) |
0x0002 |
UpTime Uptime |
uint64 | Time elapsed since the device's most recent boot, in seconds. Can be used to determine if the device has recently rebooted |
0x0003 |
TotalOperationalHours Total Operational Hours |
uint32 | Total operational hours since the device was manufactured (rounded). This value is persisted across reboots and used for assessing device lifespan |
0x0004 |
BootReason Boot Reason |
BootReasonEnum | Reason for the device's most recent boot (see enum below). Check this field first when troubleshooting abnormal reboots |
UpTime is in seconds, while TotalOperationalHours is in hours.
For example, UpTime = 86400 means 24 hours of uptime, while TotalOperationalHours = 720 means 30 days of cumulative operation.
Fault Tracking (0x0005-0x0007)
Three list attributes track currently active faults at the hardware, radio, and network levels respectively. On a normally operating device, all three lists should be empty. A non-empty value indicates the device has detected a fault of the corresponding type.
| ID | Name | Type | Description |
|---|---|---|---|
0x0005 |
ActiveHardwareFaults Active Hardware Faults |
list<HardwareFaultEnum> | List of currently existing hardware faults. Empty list = no faults. May contain multiple different fault types simultaneously |
0x0006 |
ActiveRadioFaults Active Radio Faults |
list<RadioFaultEnum> | List of currently existing radio (wireless communication) faults. Appears when WiFi/BLE/Thread modules are abnormal |
0x0007 |
ActiveNetworkFaults Active Network Faults |
list<NetworkFaultEnum> | List of currently existing network layer faults. Such as connection failures, network interference, etc. |
These three lists record currently existing faults. When a fault state changes (new fault or recovery), the device simultaneously emits a corresponding change event (HardwareFaultChange, RadioFaultChange, NetworkFaultChange). The event contains the complete lists before and after the change, making it easy to track fault occurrence and recovery.
Test Configuration (0x0008)
Configuration attributes related to certification testing.
| ID | Name | Type | Description |
|---|---|---|---|
0x0008 |
TestEventTriggersEnabled Test Triggers Enabled |
bool | Indicates whether the device has enabled the TestEventTrigger command. Production devices must set this to false. If a shipped product reads true, it indicates a security configuration defect from the manufacturer |
Enum Quick Reference
GeneralDiagnostics involves multiple enum types, all listed below with their values.
BootReasonEnum — Boot Reason
Describes the reason for the device's most recent boot, corresponding to the BootReason (0x0004) attribute and the BootReason event.
HardwareFaultEnum — Hardware Fault
Describes hardware-level faults the device may encounter, corresponding to the ActiveHardwareFaults (0x0005) attribute.
RadioFaultEnum — Radio Fault
Describes fault types for the device's wireless communication modules, corresponding to the ActiveRadioFaults (0x0006) attribute.
NetworkFaultEnum — Network Fault
Describes network-level fault types for the device, corresponding to the ActiveNetworkFaults (0x0007) attribute.
InterfaceTypeEnum — Network Interface Type
Describes the physical type of a network interface, corresponding to the Type field in the NetworkInterface struct.
Data Structures
NetworkInterface Struct
Describes the complete information of a network interface, representing the structure of each list element in the NetworkInterfaces (0x0000) attribute.
| Field | Type | Description |
|---|---|---|
| Name | string (max 32) | Interface name, e.g., "wlan0", "eth0", "Thread" |
| IsOperational | bool | Whether the interface is running and available for communication |
| OffPremiseServicesReachableIPv4 | bool / null | Whether IPv4 through this interface can reach external (internet) services. null = unknown |
| OffPremiseServicesReachableIPv6 | bool / null | Whether IPv6 through this interface can reach external services. null = unknown |
| HardwareAddress | octstr (6 or 8 bytes) | Hardware address (MAC address) of the interface. WiFi/Ethernet uses 6 bytes, IEEE 802.15.4 (Thread) uses 8 bytes |
| IPv4Addresses | list<octstr> | List of all IPv4 addresses assigned to this interface |
| IPv6Addresses | list<octstr> | List of all IPv6 addresses assigned to this interface (typically includes link-local and global addresses) |
| Type | InterfaceTypeEnum | Physical type of the interface |
NetworkInterface data example:
{
"Name": "wlan0", // Interface name
"IsOperational": true, // Interface is running
"OffPremiseServicesReachableIPv4": true, // IPv4 can reach external services
"OffPremiseServicesReachableIPv6": null, // IPv6 reachability unknown
"HardwareAddress": "AA:BB:CC:DD:EE:FF", // MAC address
"IPv4Addresses": ["192.168.1.100"], // IPv4 address list
"IPv6Addresses": ["fe80::1", "2001:db8::1"], // IPv6 address list
"Type": 1 // WiFi interface
}
Events
GeneralDiagnostics defines 4 events, all with Critical priority. The first three correspond to change notifications for hardware/radio/network fault states respectively; the fourth is a device boot reason notification. Subscribing to these events enables real-time awareness of changes in device health status.
| ID | Name | Priority | Description |
|---|---|---|---|
0x00 |
HardwareFaultChange | Critical | Hardware fault list changed |
0x01 |
RadioFaultChange | Critical | Radio fault list changed |
0x02 |
NetworkFaultChange | Critical | Network fault list changed |
0x03 |
BootReason | Critical | Reports boot reason when device starts |
HardwareFaultChange — Hardware Fault Change (0x00)
Triggered when the device's hardware fault state changes — whether a new fault occurs or a fault is recovered. The event data includes complete fault lists before and after the change for comparison analysis.
| Field | Type | Description |
|---|---|---|
| Current | list<HardwareFaultEnum> | Current hardware fault list after the change (consistent with the ActiveHardwareFaults attribute) |
| Previous | list<HardwareFaultEnum> | Hardware fault list before the change |
Interpretation Example
Suppose you receive an event with Previous = [3], Current = [3, 9].
This indicates that a "Resettable Over-temperature (3)" fault already existed, and now a "Non-volatile Memory Error (9)" has been added.
If you subsequently receive Previous = [3, 9], Current = [9], it means the over-temperature fault has recovered, but the storage error persists.
RadioFaultChange — Radio Fault Change (0x01)
Triggered when the device's radio fault state changes. Structure is the same as HardwareFaultChange.
| Field | Type | Description |
|---|---|---|
| Current | list<RadioFaultEnum> | Current radio fault list after the change |
| Previous | list<RadioFaultEnum> | Radio fault list before the change |
NetworkFaultChange — Network Fault Change (0x02)
Triggered when the device's network fault state changes. Structure is the same as HardwareFaultChange.
| Field | Type | Description |
|---|---|---|
| Current | list<NetworkFaultEnum> | Current network fault list after the change |
| Previous | list<NetworkFaultEnum> | Network fault list before the change |
BootReason — Boot Reason Event (0x03)
This event is emitted every time the device boots, reporting the boot reason.
This is the primary clue for troubleshooting abnormal device reboots — most effective when used with the RebootCount attribute.
| Field | Type | Description |
|---|---|---|
| BootReason | BootReasonEnum | Reason for this boot |
Interpretation Example
Receiving BootReason = 3 (SoftwareWatchdogReset) indicates the device was forcibly rebooted by the watchdog due to firmware abnormality.
If you receive multiple BootReason events with the same cause in a short time, it is strongly recommended to contact the manufacturer to investigate firmware issues.
Example Data
Attribute read results from a normally running WiFi smart device's GeneralDiagnostics Cluster:
{
// --- Network Interfaces ---
"0x0000": [ // NetworkInterfaces
{
"Name": "wlan0",
"IsOperational": true,
"OffPremiseServicesReachableIPv4": true,
"OffPremiseServicesReachableIPv6": null,
"HardwareAddress": "AA:BB:CC:DD:EE:FF",
"IPv4Addresses": ["192.168.1.100"],
"IPv6Addresses": ["fe80::1"],
"Type": 1 // WiFi
}
],
// --- Runtime Statistics ---
"0x0001": 12, // RebootCount = 12 (12 total reboots)
"0x0002": 86400, // UpTime = 86400 seconds (running for 24 hours)
"0x0003": 720, // TotalOperationalHours = 720 (30 days total)
"0x0004": 1, // BootReason = PowerOnReboot (normal power-on boot)
// --- Fault Status ---
"0x0005": [], // ActiveHardwareFaults = [] (no hardware faults)
"0x0006": [], // ActiveRadioFaults = [] (no radio faults)
"0x0007": [], // ActiveNetworkFaults = [] (no network faults)
// --- Test Configuration ---
"0x0008": false // TestEventTriggersEnabled = false (test triggers not enabled)
}
A healthy device's three fault lists (0x0005 ~ 0x0007) should all be empty arrays. Non-empty values indicate the device currently has anomalies.
Combined with BootReason (0x0004) and RebootCount (0x0001), you can preliminarily assess device stability —
frequent reboots + watchdog reasons + non-empty hardware fault list strongly suggests hardware problems.
Common Scenarios
Scenario 1: Device Health Overview
- Read
UpTime (0x0002)to confirm device uptime and determine if it recently rebooted - Read
BootReason (0x0004)— if it is not PowerOnReboot(1) or SoftwareReset(6), there may be an anomaly - Read
ActiveHardwareFaults (0x0005),ActiveRadioFaults (0x0006),ActiveNetworkFaults (0x0007)to confirm no active faults - Read
RebootCount (0x0001)— if abnormally high, combine withTotalOperationalHours (0x0003)to calculate average reboot frequency
Scenario 2: Troubleshooting Device Offline Issues
- After the device comes back online, read
BootReason (0x0004)— to determine if it rebooted or just lost network connection - Read
NetworkInterfaces (0x0000), checkIsOperationalandOffPremiseServicesReachableIPv4status - Check
ActiveNetworkFaults (0x0007)for ConnectionFailed(3) or NetworkJammed(2) - Subscribe to
NetworkFaultChangeevents to monitor for subsequent network anomalies
Scenario 3: Post-Firmware-Update Verification
- After OTA upgrade completes, the device should automatically reboot
- Read
BootReason (0x0004), expected value isSoftwareUpdateCompleted (5) - If it is
SoftwareWatchdogReset (3)orHardwareWatchdogReset (4), the new firmware may have issues - Continue monitoring
ActiveHardwareFaultsandRebootCountto ensure the new version runs stably
Scenario 4: Production Security Check
- Read
TestEventTriggersEnabled (0x0008), it must befalse - If
true, the device has not disabled test mode, posing a security risk — attackers could manipulate device behavior through the TestEventTrigger command - This check is typically performed before product shipment and during security audits