Built to Be Efficient

Built to Be Efficient

Device Sentinel watches every device in your home and remembers what it has learned, which means it writes to disk. On a machine with an SSD that costs nothing worth thinking about. On a Raspberry Pi running from an SD card it is one of the few things that can shorten the life of the hardware, and it is worth understanding what is happening and what you can change.

This page explains what the integration does to keep writing down, and what to set if your storage is the slow or fragile kind.

Why writes matter at all

Flash storage wears out. Every cell can be rewritten a finite number of times, and cheap SD cards have far fewer of those cycles than a solid state drive. Wear levelling spreads the damage around, but it cannot create endurance that is not there. The usual cause of a dead Home Assistant SD card is not one big write; it is a small write repeated relentlessly for a year.

There is a second thing that makes it worse than it sounds. When a file like this is saved, the whole file is rewritten, not just the part that changed. Updating one timestamp for one device costs the same as rewriting everything the integration knows.

What Device Sentinel does about it

It waits. Ordinary activity, a device reporting in and its clock moving forward, does not trigger a save. Those changes are gathered up and written once per interval. On a real fleet of 125 watched devices this took the rate from about 515 writes in a night down to 36, a reduction of roughly nine in ten, with no loss of anything that matters.

It does not wait for anything important. A device going silent, a battery falling below the threshold, an item added to the problem list, a box you tick: those are written the moment they happen. The waiting applies only to the routine churn of devices reporting normally. If the power fails, you lose at most a few minutes of clocks, which every device repairs by reporting again.

It writes reports on purpose, not constantly. The four Markdown files are written at startup, at midnight, at your daily brief time, and when you press the button. They are never rewritten in the background.

It keeps the frequently changing part separate. The values that change every time a device reports are being moved into a small file of their own, so the large file holding everything learned stops being rewritten for them. On the fleet above, that is the difference between rewriting 356 KB a hundred times a day and rewriting 45 KB. This work is partly done: the small file is currently written and not yet used, so it can be checked against the real one before anything depends on it.

What you can change

Two settings on the Advanced screen decide most of it, and one ordinary habit decides the rest.

Storage write interval, one to sixty minutes, default fifteen. How long ordinary activity is held before being saved. Longer means fewer writes and a little more clock data at risk in a power cut, which self-repairs. This is the single most effective setting if writes are your concern.

interval	routine writes a day	at 90 days of history
5 minutes	288	about 100 MB a day
15 minutes (default)	96	about 33 MB a day
30 minutes	48	about 17 MB a day
60 minutes	24	about 8 MB a day

How much history to keep, thirty days to a year, default ninety. This does not change how often the file is written, but it changes how big it is, and every write costs the whole file. On a fleet of 125 devices: about 234 KB at thirty days, 356 KB at ninety, 905 KB at a year.

Excluding what you do not care about. Every device Device Sentinel watches adds to the file. Devices that are not really hardware, integrations that report constantly and tell you nothing useful, anything you would never act on: excluding them on the Global Exclusions screen makes the file smaller, and therefore every write cheaper. It is the only change here that helps on both axes at once.

None of these settings changes what is detected. Judgment always reads the most recent two weeks, and a device flagged on one system would be flagged on the other.

Suggested settings by machine

These are starting points, not rules. If in doubt, the defaults are chosen to be reasonable everywhere.

Raspberry Pi running from an SD card. This is the case the settings exist for. A write interval of thirty to sixty minutes and thirty to sixty days of history keeps both the frequency and the size down. Excluding devices you do not act on is worth doing here more than anywhere. If you are also running the standard Home Assistant recorder against the same card, that is almost certainly writing far more than this integration is, and worth looking at first.

Home Assistant Green, or a Pi booting from an SSD. Soldered flash and USB or NVMe drives both have considerably more endurance than a removable card. The defaults are sensible here. If you want more history for the sake of it, ninety to a hundred and eighty days is comfortable.

A mini PC or any machine with an SSD or NVMe drive. Writes at this scale are not a consideration. Set the interval short if you would rather lose less in a power cut, and keep as much history as you find useful. This is the configuration where a full year is worth having, because the questions long history answers, how a battery is really discharging and whether a device's rhythm is drifting over months, need months to answer.

A virtual machine on a server. What matters is the storage underneath rather than the virtual machine itself, so treat it as whichever of the above it sits on. Enterprise drives are generally in the third category. If the disk is shared with other demanding work, the middle settings are a reasonable compromise.

How to see what it is actually doing

The telemetry report in config/device_sentinel/diagnostics/ states the settings in force on its Tunables line, including the write interval and how many days are kept. The stored file itself lives in config/.storage/ and its size tells you directly what each write costs.