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.

Endpoint 0 Exclusive

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

ParameterTypeDescription
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
Security Note

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

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

IDNameTypeDescription
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
Developer Tip

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.

IDNameTypeDescription
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
Time Unit Note

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.

IDNameTypeDescription
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.
Relationship Between Fault Lists and Events

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.

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

0
Unspecified Unspecified — the device cannot determine the boot reason
1
PowerOnReboot Normal power-on — device started after power was connected
2
BrownOutReset Brown-out reset — power voltage dropped below critical threshold, triggering reset
3
SoftwareWatchdogReset Software watchdog reset — firmware running abnormally, watchdog timer expired and triggered reset
4
HardwareWatchdogReset Hardware watchdog reset — hardware-level watchdog timeout, typically more severe than software watchdog
5
SoftwareUpdateCompleted Firmware update completed — automatic reboot after successful OTA upgrade
6
SoftwareReset Software reset — reboot actively triggered by software (e.g., remote reboot command, factory reset)

HardwareFaultEnum — Hardware Fault

Describes hardware-level faults the device may encounter, corresponding to the ActiveHardwareFaults (0x0005) attribute.

0
Unspecified Unspecified hardware fault
1
Radio Radio module fault — wireless communication hardware abnormality
2
Sensor Sensor fault — temperature, humidity, and other sensor abnormalities
3
ResettableOverTemp Resettable over-temperature — temperature too high, can auto-recover after cooling
4
NonResettableOverTemp Non-resettable over-temperature — severe overheating, may have caused permanent damage
5
PowerSource Power source fault — power supply module abnormality
6
VisualDisplayFault Visual display fault — screen or LED indicator abnormality
7
AudioOutputFault Audio output fault — speaker or buzzer abnormality
8
UserInterfaceFault User interface fault — buttons, touchpad, and other input device abnormalities
9
NonVolatileMemoryError Non-volatile memory error — Flash/EEPROM read/write abnormality, data may be lost
10
TamperDetected Tamper detected — device enclosure was opened or sensor triggered tamper alarm

RadioFaultEnum — Radio Fault

Describes fault types for the device's wireless communication modules, corresponding to the ActiveRadioFaults (0x0006) attribute.

0
Unspecified Unspecified radio fault
1
WiFiFault WiFi module fault
2
CellularFault Cellular network module fault
3
ThreadFault Thread module fault
4
NFCFault NFC module fault
5
BLEFault BLE (Bluetooth Low Energy) module fault
6
EthernetFault Ethernet module fault

NetworkFaultEnum — Network Fault

Describes network-level fault types for the device, corresponding to the ActiveNetworkFaults (0x0007) attribute.

0
Unspecified Unspecified network fault
1
HardwareFailure Network hardware failure — NIC or physical connection abnormality
2
NetworkJammed Network jammed — channel congestion or electromagnetic interference detected
3
ConnectionFailed Connection failed — unable to establish or maintain network connection

InterfaceTypeEnum — Network Interface Type

Describes the physical type of a network interface, corresponding to the Type field in the NetworkInterface struct.

0
Unspecified Unspecified type
1
WiFi WiFi wireless interface
2
Ethernet Ethernet wired interface
3
Cellular Cellular mobile network interface
4
Thread Thread mesh network interface

Data Structures

NetworkInterface Struct

Describes the complete information of a network interface, representing the structure of each list element in the NetworkInterfaces (0x0000) attribute.

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

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

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

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

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

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
  1. Read UpTime (0x0002) to confirm device uptime and determine if it recently rebooted
  2. Read BootReason (0x0004) — if it is not PowerOnReboot(1) or SoftwareReset(6), there may be an anomaly
  3. Read ActiveHardwareFaults (0x0005), ActiveRadioFaults (0x0006), ActiveNetworkFaults (0x0007) to confirm no active faults
  4. Read RebootCount (0x0001) — if abnormally high, combine with TotalOperationalHours (0x0003) to calculate average reboot frequency
Scenario 2: Troubleshooting Device Offline Issues
  1. After the device comes back online, read BootReason (0x0004) — to determine if it rebooted or just lost network connection
  2. Read NetworkInterfaces (0x0000), check IsOperational and OffPremiseServicesReachableIPv4 status
  3. Check ActiveNetworkFaults (0x0007) for ConnectionFailed(3) or NetworkJammed(2)
  4. Subscribe to NetworkFaultChange events to monitor for subsequent network anomalies
Scenario 3: Post-Firmware-Update Verification
  1. After OTA upgrade completes, the device should automatically reboot
  2. Read BootReason (0x0004), expected value is SoftwareUpdateCompleted (5)
  3. If it is SoftwareWatchdogReset (3) or HardwareWatchdogReset (4), the new firmware may have issues
  4. Continue monitoring ActiveHardwareFaults and RebootCount to ensure the new version runs stably
Scenario 4: Production Security Check
  1. Read TestEventTriggersEnabled (0x0008), it must be false
  2. If true, the device has not disabled test mode, posing a security risk — attackers could manipulate device behavior through the TestEventTrigger command
  3. This check is typically performed before product shipment and during security audits