New Integration: smart-sniffer - Proactive Disk Health Monitoring (No more "Manual" SMART Checks)

[DAB-LABS]

Hi everyone,

I’m excited to share a new custom integration I’ve been working on: smart-sniffer.

We’ve all been there—relying on a basic “Disk Usage %” sensor only to have a drive “ghost” us without warning because we weren’t monitoring the underlying S.M.A.R.T. data. While there are ways to track this currently, I felt there was a middle ground missing between “too simple” and “too complex.”

Why smart-sniffer?

If you’ve looked into disk monitoring for Home Assistant before, you’ve likely seen these common paths:

• System Monitor (Built-in): Great for “Is my disk full?”, but it doesn’t see S.M.A.R.T. data or health status. It won’t tell you if your SSD is wearing out or if an HDD has reallocated sectors.
• Scrutiny: An amazing tool with a beautiful UI, but it can be heavy for some setups (requiring an InfluxDB backend). While it has an HA integration, you still have to manually build out your own automation logic for alerts.
• CRON Jobs & MQTT Scripts: The “old reliable” method. It’s flexible but high-friction. You have to write the scripts, schedule them, manage MQTT topics, and handle the parsing yourself.

smart-sniffer aims to be the “Set it and Forget it” alternative. It provides a lightweight Go agent that does the heavy lifting and talks directly to Home Assistant.

Key Features:

• Proactive Health Monitoring: Supports ATA, SATA, and NVMe drives with early warning indicators.
• Zero-Config Notifications: Unlike other tools where you have to build the “Alert” automation yourself, this integration automatically creates, escalates, and dismisses persistent notifications in the HA UI based on drive health.
• Auto-Discovery: Uses mDNS/Zeroconf to find your drives on the network automatically. No manual IP/Port configuration needed.
• Multi-Machine Support: Just drop the lightweight Go agent on any machine you want to monitor. Each drive shows up as its own device in HA with full sensors and diagnostics.
• Secure by Design: Supports bearer token authentication and uses SHA256-verified binary downloads.

Getting Started:

You can find the setup instructions and the Go agent over on GitHub:
DAB-LABS/smart-sniffer

I’d love to hear your thoughts or any features you think are missing! Hopefully, this helps a few of you save your data before a drive goes dark.

---

Suggested Tags: custom_integrations, hacs, monitoring, storage, smart

[SiriosDev]

Installed and Starred (hoping to see a dockered version some day)

[DAB-LABS]

I’m building an App (Add-On) for HA. No plans on a straight Docker distro. Have you checked out GitHub - AnalogJ/scrutiny: Hard Drive S.M.A.R.T Monitoring, Historical Trends & Real World Failure Thresholds · GitHub for that?

Here’s the HA App: GitHub - DAB-LABS/smart-sniffer-app: Smart Sniffer HA App · GitHub

[devzor]

Hey there!

Thanks for this! This is something i could use to replace scrutiny on my HA.
I’ve been testing the HA app and integration for some time now, here are some notes:

• mdns/zeroconf does not seem to work (on the ha app), as i don’t see the mdns service on my network. The HA integration does not pick it up automatically, though adding manually 0449a086-smart-sniffer-agent works.
• I guess smartmontools is bundled with the docker container (while i understand it’s external if the agent is used). It would be nice, if the drivedb.h could be updated . There are multiple ways to go about this. First of all, you could use a bind mount to persist /var/lib/smartmontools/drivedb/drivedb.h. The file could be updated either at the continer startup, or periodically. Or you could just provide a way to run a user customised startup script, like scrutiny , so that a user could run update-smart-drivedb with his own preferred parameters or sources at startup.
• If bearer token is used, the sidebar shortcut doesn’t seem to be able to connect, as it stays inactive.

My disk has a lot of custom fields, i’ll see how they show up in the integration after every smart field is properly detected with an up to date drivedb.h. Currently i can see the wear leveling is obviously wrong. The raw value is not percentage used, that’s for sure. You should re-check how to interpret 177.
edit: I’ve seen that 0.4.29 fixes this.

177 Wear_Leveling_Count     ------   100   100   050    -    32

If you need more logs i’d be happy to provide them.

[DAB-LABS]

Hey devzor ~ thanks for the thorough testing, really appreciate you digging in like this.

Bearer token + sidebar ~ fixed in v0.2.9, just pushed. HA’s ingress proxy wasn’t passing the auth header through, so the Web UI couldn’t talk to the agent. The proxy now injects the token on localhost requests automatically. Update and it should just work.

drivedb.h ~ also in v0.2.9. The app now runs update-smart-drivedb at startup and persists the updated database to /data. Your Transcend should get proper attribute definitions without any manual steps. On our test box it jumped from revision 5706 to 6114.

mDNS ~ this one I’d like to understand better if you have a minute. A couple things that would help:

1. Are you running any VLANs or separate IoT network?
2. Can you check Settings → System → Network ~ there’s a built-in mDNS browser in HA at the bottom. Do you see any _smartha._tcp entries there?
3. What does your HA hostname look like? (Settings → System → General)

The mDNS advertisement is working on our test environments so I’m curious what’s different about yours. It can be fickle, tho…

Wear leveling ~ glad 0.4.29 sorted that.

~DAB

[devzor]

Hey there!

Thanks for the quick fixes.

@DAB-LABS

Are you running any VLANs or separate IoT network?

Yes, my bare metal haos has 1 adapter, with an untagged vlan, and a tagged vlan.
The .99 vlan(eno1.99) is used for a couple of tuya stuff, the main lan(default eno1) is my primary lan, with matter and everything else basically. Something like this:

➜  ~ ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
- connected: true
  enabled: true
  interface: eno1.99
  ipv4:
    address:
    - 10.12.99.157/24
    gateway: 10.12.99.1
    method: auto
    nameservers:
    - 10.12.99.1
    ready: true
    route_metric: null
  ipv6:
    addr_gen_mode: default
    address:
    - 2001:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/64
    - fe80::b8fc:6c29:b812:e45/64
    gateway: fe80::aab8:e0ff:fe00:6bfe
    ip6_privacy: default
    method: auto
    nameservers:
    - fe80::aab8:e0ff:fe00:6bfe
    ready: true
    route_metric: null
  llmnr: announce
  mac: 4C:52:62:A0:F0:CD
  mdns: announce
  primary: false
  type: vlan
  vlan:
    id: 99
    parent: cb5514c3-3683-3e45-b094-322dd5d084d7
  wifi: null
- connected: true
  enabled: true
  interface: eno1
  ipv4:
    address:
    - 10.12.1.155/24
    gateway: 10.12.1.1
    method: auto
    nameservers:
    - 10.12.1.1
    ready: true
    route_metric: null
  ipv6:
    addr_gen_mode: default
    address:
    - 2001:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/64
    - fe80::ad94:ae89:b9df:70d0/64
    gateway: fe80::aab8:e0ff:fe00:6bfe
    ip6_privacy: default
    method: auto
    nameservers:
    - fe80::aab8:e0ff:fe00:6bfe
    ready: true
    route_metric: null
  llmnr: announce
  mac: 4C:52:62:A0:F0:CD
  mdns: announce
  primary: true
  type: ethernet
  vlan: null
  wifi: null
supervisor_internet: true

@DAB-LABS

Can you check Settings → System → Network ~ there’s a built-in mDNS browser in HA at the bottom. Do you see any _smartha._tcp entries there?

I don’t have any _smartha._tcp entries there:

Also my pc, which is on the same network as eno1 cannot see this service using a mdns browser.

@DAB-LABS

What does your HA hostname look like? (Settings → System → General)

The hostname is homeassistant , and this is the only device with that name on the network.

This is the log of the addon App:

[22:28:06] INFO: Running preflight checks...
[22:28:06] INFO: smartctl version: 7.5
[22:28:07] INFO: Drives detected by smartctl: 1
[22:28:07] INFO: Drive access: OK (/dev/sda)
[22:28:09] INFO: drivedb.h: updated from upstream
[22:28:09] INFO: mDNS name: smartha-homeassistant (from HA hostname: homeassistant)
[22:28:09] INFO: Starting SMART Sniffer agent on port 9099...
[22:28:09] INFO: Starting web UI proxy on port 8099...
[22:28:09] INFO: ─────────────────────────────────────────
[22:28:09] INFO: SMART Sniffer App v0.2.9
2026/03/26 22:28:09 smartctl 7.5 detected
[22:28:09] INFO: Agent: running on port 9099
[22:28:09] INFO: mDNS: smartha-homeassistant
[22:28:09] INFO: Auth: enabled
[22:28:09] INFO: Mock: disabled
[22:28:09] INFO: Web UI: http://localhost:8099 (via ingress)
[22:28:09] INFO: Drives detected: 1
[22:28:09] INFO: ─────────────────────────────────────────
2026/03/26 22:28:09 SMART Sniffer Agent v0.4.28
2026/03/26 22:28:09 smartctl version: 7.5
2026/03/26 22:28:09 Drives detected: 1
2026/03/26 22:28:09 Listening on: 0.0.0.0:9099
2026/03/26 22:28:09 Auth: enabled
2026/03/26 22:28:09 mDNS: enabled
[webui] Serving on port 8099
[webui] Proxying /api/* → 127.0.0.1:9099
[webui] Proxying /mock/* → 127.0.0.1:9100
2026/03/26 22:28:10 cache refreshed: 1 drive(s)
2026/03/26 22:28:10 mDNS: interfaces: eth0
2026/03/26 22:28:10 mDNS: using custom instance name: smartha-homeassistant
2026/03/26 22:28:10 mDNS: preferred IP: 172.30.33.6
2026/03/26 22:28:10 mDNS: advertising smartha-homeassistant._smartha._tcp.local. on port 9099

[DAB-LABS]

Thanks for the detailed info — this is really helpful and confirms what we suspected.

Your agent is doing everything right. The logs show it’s broadcasting _smartha._tcp on the container’s bridge interface (eth0 / 172.30.33.6). The issue is on the receiving side ~ HA’s Zeroconf listener appears to not be monitoring the hassio Docker bridge in your setup, likely because the multicast route is going out one of your physical interfaces (eno1 or eno1.99) instead.

This is a known edge case with VLAN configurations and not something we can fix from the app side ~ it’s how HA’s mDNS routing works.

The good news: manual setup with the container hostname works reliably regardless of mDNS. We just pushed v0.2.10 which now prints the integration host right in the startup log:

Integration host: 0449a086-smart-sniffer-agent:9099

Update the app and you’ll see it. Use that hostname (0449a086-smart-sniffer-agent) and port 9099 when adding the integration manually under Settings → Devices & Services → Add Integration → SMART Sniffer. That hostname is stable and won’t change.

We’re going to keep investigating the mDNS-on-VLAN issue, but for now manual setup is the way to go on your network.

[devzor]

@DAB-LABS

Update the app and you’ll see it. Use that hostname (0449a086-smart-sniffer-agent) and port 9099 when adding the integration manually under Settings → Devices & Services → Add Integration → SMART Sniffer. That hostname is stable and won’t change.

I was already using that since the beginning, it works ok that way.

@DAB-LABS

Docker bridge in your setup, likely because the multicast route is going out one of your physical interfaces (eno1 or eno1.99) instead.

The mdns _smartha._tcp.local. definetly does not go out on the eno1 interface, as i’m not getting it on my windows pc. While i can see all the other homeassistant mdns announcements, like _matter._tcp.local. or _meshcop._udp.local. or _home-assistant._tcp.local. . Just checked, it’s not visible on the eno1.99 network either.

[DAB-LABS]

That’s right, the hostname connection is the intended path and you’ve had it working from day one, so you’re all set.

On the mDNS visibility: what you’re seeing is expected. The services your PC picks up (_matter, _meshcop, _home-assistant) are broadcast by HA Core from the host network. Our agent broadcasts from inside the Docker bridge, which is a different network layer, so it won’t be visible to your PC or HA’s mDNS browser regardless of VLANs. It only needs to reach the HA instance it’s running on, and the hostname connection handles that reliably.

Appreciate all the detailed debugging! It’s genuinely helpful for us to understand how things behave on different network setups.

[DAB-LABS]

Hey all ~ quick update! v0.5.0 just shipped with some features you’ve been asking about:

What’s new:

• Disk usage monitoring ~ The agent now reports filesystem usage (total/used/available) per mountpoint. The integration creates sensors for each mounted filesystem, so you get drive health AND capacity tracking in one place.
• Agent version checking ~ The integration now detects outdated agents and shows a repair notification in HA with a one-click link to update.
• Improved mDNS interface filtering ~ Auto-skips Docker bridges and VPN interfaces so your agent advertises on the right network.

For HAOS App users, the app is at v0.2.x with NVMe permission fixes, automatic drivedb.h updates, and the Agent Control Center dashboard.

If you’re running Smart Sniffer, I’d love to hear how it’s going. And if you have drives that show “UNSUPPORTED” ~ please share your smartctl -a --json output in a GitHub issue so I can improve detection!

Install/update Agent:

curl -sSL https://raw.githubusercontent.com/DAB-LABS/smart-sniffer/main/install.sh | sudo bash

Install/update via HACS:

1. Add custom repo: https://github.com/DAB-LABS/smart-sniffer (Integration)
2. Download/update SMART Sniffer
3. Restart HA

[SiriosDev]

Yeah sure, but this is better, even if not dockerized, imho

My hope stems from the fact that HA OS apps are containers in their deep, but never mind—it’s nothing really that vital.

[DAB-LABS]

Hey @SiriosDev ~ you’re not wrong, HA OS add-ons are containers all the way down.

Speaking of Docker though ~ check out PR #8 on the SMART Sniffer repo. fireinice has been putting together a standalone Docker deployment with auto-generated compose files and everything. He even stood up his own image on Docker Hub.

So for anyone running in Docker ~ that door might be open soon…

What is your use case?

~DAB

[SiriosDev]

No, my usecase is nothing special—I just have a home server where I prefer to run everything in containers to avoid potential incompatibilities, optimize backups, etc.

[DAB-LABS]

That’s a perfectly good reason; containers-for-everything on a home server is the way most people are heading, and it makes sense for us to support it properly.

Docker support is actively being worked on. We’ve got a community PR in review right now that adds a Dockerfile and auto-generated compose files. Still ironing out a few details, but it’s moving in the right direction.

I’ll post an update here once it’s ready to go.

~DAB

[Rofo (Ro)]

Just downloaded 0.5.3 which added the standby option which is great.

iirc, the release notes said that if the drive was in standby, the agent would serve up the latest cached data instead, but that it would also provide an attribute telling you which mode the drive was in, as well as a new attribute with uptime hours ?

I’ve upgraded both the agent and the HA integration and restarted HA, but I don’t see the new/revised attributes ? (I’m also missing, or cant find the OS attribute).

(The agent installer did ask if I wanted to use the new standby mode, to which I answered yes).

And finally, the new diagnostics are great, but the update interval entity is based on the frequency HA calls the agent, not the frequency the agent itself calls smartctl, so it can be a tiny bit misleading if they are different.

[DAB-LABS]

Hey RofoRo ~ great feedback, and glad the standby option is working for you.

Let me hit your points one by one.

Standby attributes – In v0.5.3, the standby indicators (in_standby and data_as_of) were conditional attributes on the Health binary sensor. They only appear when a drive is actually sleeping, so if your drives haven’t entered standby yet you wouldn’t see them. That said, we agreed that was a bit hidden – v0.5.4 (just shipped) replaces this with a dedicated Standby binary sensor per drive. It’s always visible under the drive’s device in diagnostics: On when the drive is sleeping, Off when it’s active. When On, it shows a data_as_of attribute with the timestamp of the last cached SMART reading. Much cleaner.

Uptime – The agent diagnostic entities in v0.5.3 include Last Seen and Version, but uptime isn’t surfaced as its own entity yet. The agent’s /api/health endpoint does report uptime, but we haven’t promoted it to an HA entity. It’s on the list – just didn’t make the cut for this round.

OS – You’re right, that one wasn’t surfaced in v0.5.3 either. The agent was reporting it in the health endpoint but the integration wasn’t creating an entity for it. Fixed in v0.5.4 – there’s now an Agent OS diagnostic sensor that shows linux, darwin, or windows under the agent device. Enabled by default.

Scan interval naming – Spot on. You’re exactly right that the entity was showing the HA polling frequency, not the agent’s own scan interval. We’ve renamed it to HA Poll Interval in v0.5.4 to make that distinction clear. A true Agent Scan Interval entity is on the roadmap – it needs the agent to expose its config value in the health endpoint first, which is coming in a future agent update.

To pick up all four changes: update the integration via HACS to v0.5.4 and reload. No agent update needed for this one.

Thanks for the detailed feedback – your point about the scan interval naming is the kind of thing that saves other users from the same confusion.

~David

[Rofo (Ro)]

The more I use this addon, the more useful it gets.
And your responsive updates are amazing.

Thanks for your contribution to the community.

Look forward to when the 0.5.4 update is available. Doesn’t look like its quite out yet.

[DAB-LABS]

Hey RofoRo ~ thanks, that means a lot.

v0.5.4 is out - HACS sometimes caches the repo info.

Try clicking the three dots on the SMART Sniffer entry in HACS and hit Update Information.

That should pull the latest.

~David

[Rofo (Ro)]

I checked the github repo and it didn’t look like I could see 0.5.4, but since then I’ve gone to bed and its appeared in HA now

Thankyou so much.

[Rofo (Ro)]

UPDATE:-

IGNORE THE BELOW. Rebooting my VM and reloading the integration made the missing drive appear.

UPDATE 2: It might actually be an issue, not sure, have raised an issue in github

Might be a bug in 0.5.4, but I might have had this issue when upgrading 0.5.3 as well.

This is my agent config:-

port: 9099
scan_interval: 3h
advertise_interface: ens18
standby_mode: standby

filesystems:
  - path: "/"
    uuid: "04acfd07-1d3c-48a4-9469-5eedec301d8d"
    device: "/dev/sda3"
    fstype: "ext4"
  - path: "/media/primary16"
    uuid: "xxx"
    device: "/dev/sdb1"
    fstype: "ext4"
  - path: "/media/backup16"
    uuid: "xxx"
    device: "/dev/sdd1"
    fstype: "ext4"
  - path: "/media/firecuda"
    uuid: "xxx"
    device: "/dev/sdc1"
    fstype: "ext4"

(UUids changed)

But I noticed that since the upgrade, the firecuda drive was now showing all its entities as unavailable. (root, primary and backup were all fine)

So I removed the integration and reloaded it, but getting the same issue now… the firecuda drive isn’t showing at all, even though the installer says ‘found 4 drives’.

This is the install message since upgrading the agent on the OS to 0.5.4:-

  ── Agent Summary ──────────────────────────────

  ✓ Status:         running
  ✓ Port:           9099
  ✓ IP:             192.168.0.203
  ✓ Endpoints:      http://192.168.0.203:9099
                    /api/health
                    /api/drives
                    /api/drives/{id}
                    /api/filesystems
  ○ Auth:           disabled
  ✓ Scan interval:  3h
  ✓ mDNS:           smartha-JellyFinSamba._smartha._tcp.local. (ens18)
  ✓ SMART drives:   3 detected
                    ST16000NM001G-2KK103
  ✓ Disk usage:     /,/media/primary16 /media/backup16,/media/firecuda
  ✓ Config:         /etc/smartha-agent/config.yaml

(The message smart drives: 3 detected is because the root drive is not a real drive but the volume the VM is mounted on).

deleting and re-loading the integration I get this:-

Found agent on JellyFinSamba (192.168.0.203:9099) with 4 drive(s).

But this is then what I get:-

curl http://192.168.0.203:9099/api/drives
[
  {
    "id": "dev-sda",
    "device_path": "/dev/sda",
    "model": "",
    "serial": "",
    "protocol": "SCSI"
  },
  {
    "id": "zl2gxmsj",
    "device_path": "/dev/sdb",
    "model": "ST16000NM001G-2KK103",
    "serial": "ZL2GXMSJ",
    "protocol": "ATA"
  },
  {
    "id": "zl2gxmaw",
    "device_path": "/dev/sdd",
    "model": "ST16000NM001G-2KK103",
    "serial": "ZL2GXMAW",
    "protocol": "ATA"
  }
]

However, the filesystems api replies with 4 drives:-

curl http://192.168.0.203:9099/api/filesystems
[
  {
    "id": "fs-b051d673",
    "uuid": "b051d673-9198-49ac-8115-3078ff0091cd",
    "mountpoint": "/media/primary16",
    "device": "/dev/sdb1",
    "fstype": "ext4",
    "total_bytes": 15873736208384,
    "used_bytes": 11750020345856,
    "available_bytes": 3323654160384,
    "use_percent": 74,
    "status": "ok"
  },
  {
    "id": "fs-febd73d3",
    "uuid": "febd73d3-34b5-4d18-b662-332ef1c9f347",
    "mountpoint": "/media/backup16",
    "device": "/dev/sdd1",
    "fstype": "ext4",
    "total_bytes": 15873631350784,
    "used_bytes": 11775095885824,
    "available_bytes": 3298473762816,
    "use_percent": 74.2,
    "status": "ok"
  },
  {
    "id": "fs-61685c14",
    "uuid": "61685c14-bd4c-48d3-97c2-c345a0de39cc",
    "mountpoint": "/media/firecuda",
    "device": "/dev/sdc1",
    "fstype": "ext4",
    "total_bytes": 1967845998592,
    "used_bytes": 319786172416,
    "available_bytes": 1548023160832,
    "use_percent": 16.3,
    "status": "ok"
  },
  {
    "id": "fs-04acfd07",
    "uuid": "04acfd07-1d3c-48a4-9469-5eedec301d8d",
    "mountpoint": "/",
    "device": "/dev/sda3",
    "fstype": "ext4",
    "total_bytes": 100732227584,
    "used_bytes": 51017084928,
    "available_bytes": 45259067392,
    "use_percent": 50.6,
    "status": "ok"
  }
]