Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Fri, 21 Nov 2025 10:57:57 GMT

Hi Rahul,

The developers provided an explanation of the issue.

The main problem is that the code only triggers reporting the hardware fault, but not the hardware fault itself. Therefore, the general diagnostics server code cannot obtain the list of active hardware faults because it is not implemented.

Reading the ActiveHardwareFaults attribute triggers this:

case ActiveHardwareFaults::Id: {
    return ReadListIfSupported(&DiagnosticDataProvider::GetActiveHardwareFaults, aEncoder);
}

This means that Matter will attempt to read the active hardware faults list, but it relies entirely on DiagnosticDataProvider::GetActiveHardwareFaults being implemented (due to ReadListIfSupported). This means that if DiagnosticDataProvider::GetActiveHardwareFaults is not implemented, the list is empty.

So, what you need to do is implement your own DiagnosticDataProvider where you implement your own logic for catching the hardware fault and storing it in the list. You can use Zephyr's implementation as a base and inherit functions from there.
There is an nrfconnect implementation as well, but the only nrfconnect-specific additions are Wi-Fi related, so unless you are using Wi-Fi, there is no reason to use the nrfconnect implementation. As a note, inheriting from the nrfconnect platform is currently blocked because the constructor is private. However, this issue will be addressed by the following PR: https://github.com/nrfconnect/sdk-connectedhomeip/pull/670.

The developers have also provided an example implementation and provided it as a diff.

This is for nRF Connect SDK v3.0.0, so make sure that you are on that version.

Download the diff file and apply it:

git apply diagnostic_data_provider_temper_example.diff

This will add two new files to the Template sample diagnostic_data_provider.cpp/.h, which implements the new diagnostic data provider that inherits the Zephyr Diagnostic provider. The cpp file is added to CMakeLists.txt, and the new diagnostic data provider is registered in the Matter server (in app_task.cpp/.h).

After adding this, reading the attribute will result in seeing 1 active hardware fault:

[1763651063.542] [351701:351703] [TOO] Endpoint: 0 Cluster: 0x0000_0033 Attribute 0x0000_0005 DataVersion: 2400826327
[1763651063.542] [351701:351703] [TOO]   ActiveHardwareFaults: 1 entries
[1763651063.542] [351701:351703] [TOO]     [1]: 10

devzone.nordicsemi.com/.../diagnostic_5F00_data_5F00_provider_5F00_temper_5F00_example.diff

Best regards,
Marte

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Wed, 04 Jun 2025 09:17:26 GMT

Hi Rahul,

I asked the developers for an update. Unfortunately, I do not have anything to share. I cannot comment on the schedule for when this will get done since this needs to be prioritized against other tasks. Please get in touch with RSM if this is critical.

Best regards,
Marte

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

rahul@123 — Tue, 03 Jun 2025 09:35:55 GMT

Hi Marte,

I hope you're doing well.

I just wanted to check in to see if there’s been any updates.

Thanks again for your continued support!

Best regards,
Rahul Chauhan

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Tue, 20 May 2025 13:17:24 GMT

Hi Rahul,

I pinged the developers for an update yesterday, and they will look into it. I will update you when I know more.

Best regards,
Marte

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

rahul@123 — Mon, 19 May 2025 12:35:11 GMT

Hi Marte,

I hope you're doing well.

Just wanted to follow up and see if there’s any update regarding the attribute update in OnHardwareFaultsDetect(). I’m happy to wait if it’s still being checked internally.

Thanks again for your support!

Best regards,
Rahul Chauhan

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Fri, 09 May 2025 13:52:57 GMT

Hi,

I have not figured this out yet, but I have forwarded it internally to the developers, and I am waiting for a response. I will get back to you when I hear from them.

Best regards,
Marte

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Wed, 07 May 2025 11:58:28 GMT

Hi Rahul,

From the code, I see that OnHardwareFaultsDetect() calls on MatterReportingAttributeChangeCallback() to inform that an attribute has been updated and to trigger reporting. Still, I do not find any place where the attribute is updated, as OnHardwareFaultsDetect() only records the event.

I will have to do some more digging and discuss this internally. I will get back to you by the end of the week.

Best regards,
Marte

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

rahul@123 — Tue, 06 May 2025 06:30:20 GMT

Hi Marte,

Really appreciate your help!

The chip-tool event command works fine — I receive the HardwareFaultChange event properly when tamper_work_handler() is triggered.

But when I subscribe to the ActiveHardwareFaults attribute (0x0005), it still shows 0 entries. I was expecting the tamper (enum 10) to appear there.

Am I missing something in how to update this attribute?

Best regards,
Rahul Chauhan

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Mon, 05 May 2025 13:21:17 GMT

Hi Rahul,

It seems like your code triggers the HardwareFaultChange event instead of updating the ActiveHardwareFaults attribute. A solutions is to read or subscribe to the event instead. You can do so with the following commands:

./chip-tool generaldiagnostics read-event hardware-fault-change destination-id endpoint-id

./chip-tool generaldiagnostics subscribe-event hardware-fault-change min-interval max-interval destination-id endpoint-id

Here, you can see the output when the chip-tool is subscribed to the event and receives a report when tamper_work_handler() is called on the device:

[1746450384.039] [7523:7525] [EM] >>> [E:51032r S:48502 M:35076606] (S) Msg RX from 1:0000000000000001 [514B] to 000000000001B669 --- Type 0001:05 (IM:ReportData) (B:86)
[1746450384.039] [7523:7525] [EM] Handling via exchange: 51032r, Delegate: 0x5ad2e4b22908
[1746450384.039] [7523:7525] [TOO] Endpoint: 0 Cluster: 0x0000_0033 Event 0x0000_0000
[1746450384.039] [7523:7525] [TOO]   Event number: 3
[1746450384.039] [7523:7525] [TOO]   Priority: Critical
[1746450384.039] [7523:7525] [TOO]   Timestamp: 87825
[1746450384.039] [7523:7525] [TOO]   HardwareFaultChange: {
[1746450384.039] [7523:7525] [TOO]     Current: 1 entries
[1746450384.039] [7523:7525] [TOO]       [1]: 10
[1746450384.039] [7523:7525] [TOO]     Previous: 1 entries
[1746450384.039] [7523:7525] [TOO]       [1]: 10
[1746450384.039] [7523:7525] [TOO]    }

Best regards,
Marte

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

rahul@123 — Thu, 01 May 2025 05:36:42 GMT

Hi Maria Gilje

The button_pressed function is only used to test the tamper detection feature. Upon every button press event (no need press and hold), I am triggering hwFaultsCurrent attribute for kTamperDetected. I am not clearing it from anywhere. So theoretically chip-tool should have entry for with the tamper fault.

Is my understanding and code to test this are correct?

BR,

Rahul

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Maria Gilje — Wed, 30 Apr 2025 13:51:45 GMT

Hi Rahul,

Marte was very busy today, so I volunteered to take over.

Forgive me if my code understanding is wrong, but as I see it the tamperDetected variable will only be true when the button is continously pressed. Do you still see that chip-tool does not print any entries for the ActiveHardwareFaults entries when holding the button down while reading the attribute value? Or alternatively if you replace the toggle with a counter and modify the code to accommodate this change.

Best regards,

Maria

RE: Issue Reporting Tamper Detection via ActiveHardwareFaults (0x0005) – General Diagnostics Cluster (0x0033)

Marte Myrvold — Tue, 29 Apr 2025 13:50:32 GMT

Hi Rahul,

I have started looking into this and will get back to you tomorrow.

Best regards,
Marte