Question about the result

[Damnedniko]

Hello,
I am surprised to have my SMART failed due to this value coming from no where and to don't have RAW value. Is it normal ?

[Starosdev]

Hey @Damnedniko, thanks for the detailed report and screenshots -- this was very helpful in tracking down the root cause.

We identified the issue: there was a hardcoded threshold of 100 in the devstat evaluation logic that was originally designed for devstat_7_8 (Percentage Used Endurance Indicator), but it was being applied to all critical device statistics attributes. This meant error count attributes like devstat_4_8 (Number of Reported Uncorrectable Errors) with a value of 452 were incorrectly marked as FAILED because 452 >= 100.

The fix is in PR #237:

• Per-attribute thresholds: Only devstat_7_8 (percentage-based) now uses the 100 threshold. Error count attributes no longer have a hardcoded threshold.
• Two-tier evaluation: Critical error count attributes with non-zero values now show as WARNING (yellow) instead of FAILED (red). Warnings do not propagate to device-level failure, so your drive will no longer show as FAILED from this alone.
• Blank raw value fix: The expanded detail view for devstat attributes was showing a blank raw value field -- this is also fixed.

Could you test the fix once it lands in a release and report back whether the behavior is correct on your end? Specifically:

1. devstat_4_8 should show as WARNING (not FAILED)
2. The device itself should not be marked as FAILED (unless other attributes are failing)
3. The expanded row should show the raw value instead of blank

Thanks!

[Damnedniko]

Sure, I am waiting the release haha :p I wanna also test the new button to do on demand S.M.A.R.T and will give you a feedback about it.

[Starosdev]

Are you running the latest version? The fix was pushed a few days ago

[Damnedniko]

I am using it on docker in my Synology. Did you already release a new version for docker ?

[Damnedniko]

Hi @Starosdev , I just install the last omnibus version, the 1.29 but I don't really see change. Should I adapt my yml ?

[Damnedniko]

Now the failed is changed in warning but the state of the disk stay in failed

[Starosdev]

@Damnedniko Thanks for confirming this and posting the screenshot -- it helped us track down a real bug.

What's happening: The v1.29 fix for devstat evaluation is working correctly at the attribute level -- devstat_4_8 now shows as WARNING (yellow) instead of FAILED (red), which is the intended behavior. However, we found a separate bug that prevents the device-level status from being reset back to PASSED once it has been marked FAILED.

The root cause is a GORM (our database library) issue where resetting a status field to zero is silently ignored. So the device stays stuck as "FAILED: SCRUTINY" even though no attributes are actually failing anymore. This affects any device that was previously FAILED and should now be PASSED -- the fix in v1.29 correctly re-evaluated the attribute, but the device-level status in the database was never actually updated.

We've filed this as #262 and will have a fix in the next release.

Workaround until then: Deleting and re-registering the device (by restarting the collector) should clear the stale FAILED status, but we understand that's not ideal. We'll get a proper fix out soon.

Thanks again for your patience and for reporting this clearly -- it made a big difference.

[Damnedniko]

@Starosdev looks issue the result dissepears completly. Is it normal ?

[Starosdev]

@Damnedniko Yes, this is expected and means the fix is working correctly.

What changed: In v1.29.2 we fixed a bug where the device-level status was stuck as FAILED even when no attributes were actually failing (#262). Now the status properly resets.

Your devstat_4_8 (Number of Reported Uncorrectable Errors) still shows as WARNING (yellow) -- that is intentional. WARNING means the attribute has a non-zero error count worth monitoring, but it does not cause the device to be marked as FAILED. Only attributes that exceed a defined failure threshold will mark the device as FAILED.

So to summarize:

• Device shows PASSED (green) -- correct, no attributes are in a FAILED state
• devstat_4_8 shows WARNING (yellow) -- correct, non-zero error count flagged for awareness
• The old FAILED status was a false positive caused by the two bugs we fixed in v1.29 and v1.29.2

That said, 452 uncorrectable errors is still something to keep an eye on. If the count keeps climbing over time, it may indicate the drive is degrading. The history chart for that attribute will help you track the trend.

[Damnedniko]

@Starosdev I am a bit confuse.

In the version 1.29.0, the parameter devstat_4_8 with the value 452 was switch to warning and the disk still in failed.

In the version 1.29.2, the parameter devstat_4_8 is now with the value 0 and switch to passed so the disk is now passed. But it seems that the historic of some parameters dissapears like devstat_4_8 or the id 197.

Can you have a look ?

[Starosdev]

@Damnedniko A couple of things to clarify:

The v1.29.2 fix did not require any manual steps. Just upgrading and waiting for the next collector run would have been enough -- the device status would have automatically reset to PASSED on the next SMART submission. No need to delete or re-register the device.

Did you delete the device through the UI before re-registering it? Deleting a device removes all its historical data from the database (InfluxDB), which would explain both:

1. The history disappearing for devstat_4_8 and attribute 197
2. The devstat_4_8 value showing 0 instead of 452 (the history was wiped, and the new data starts fresh)

I also noticed the drive in your latest screenshot appears to be a different model (WDC WD40PUR02) than the original one (WDC WD40EFRX-68N32N0). Could you confirm whether this is the same physical drive?

If you did delete the device, the history loss is unfortunately expected -- deletion is permanent. Going forward, the history will rebuild as the collector submits new SMART data over time. Sorry about the confusion with the workaround suggestion -- the v1.29.2 fix made it unnecessary.

[Damnedniko]

You are right, that's not the same disk that I was looking haha I am sorry here everything seems fine now :)

[Starosdev]

@Damnedniko No worries! Glad everything is working correctly now. Thanks for helping us find and verify the fix. Closing this one out.