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 is saved, the whole file is rewritten, not just the part that changed. Updating one timestamp for one device would cost the same as rewriting everything the integration knows, which is why Device Sentinel does not keep everything in one file.

What Device Sentinel Does About It

It keeps the frequently changing part separate. There are two files. A small one holds the nine values that move every time a device reports: its activity clock, its event count, today's largest gap, and its current signal readings. A large one holds everything learned, which is the daily history, the verdicts, the problem list, and the recent incident and silence records. Ordinary activity writes the small file alone, about 45 KB on a fleet of 125 watched devices. The large one is written only when something happens that a restart must not lose, and once more at every clean shutdown. Measured across a full day on a real fleet, splitting the two cut routine writing by 64 percent.

It waits. Ordinary activity, a device reporting in and its clock moving forward, does not trigger a save of its own. Those changes are gathered up and written once per interval. On the same fleet this took the rate from about 515 writes in a night down to 36, a reduction of roughly nine in ten. That saving and the one above are separate and multiply together: fewer writes, and each routine write far smaller.

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 one interval 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.

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.

Each routine write is the small file, so its cost does not change with how much history you keep. On a fleet of about 125 devices:

interval	routine writes a day	written a day
5 minutes	288	about 13 MB
15 minutes (default)	96	about 4 MB
30 minutes	48	about 2 MB
60 minutes	24	about 1 MB

A smaller fleet writes proportionally less, because the small file holds nine values per device and nothing else.

The large file is written on a different rhythm entirely: not on a clock, but when something real happens. On a settled system that is roughly five to ten times a day. Each of those does cost the whole file, which is what the next setting governs.

How much history to keep, thirty days to a year, default ninety. Device Sentinel records one value per device per day for reporting gaps, signal lows, signal dwell, and battery level. That is about 405 new values a day on a 125-device fleet, and they are what let slow changes be seen at all. The setting decides how many of those days are kept, and therefore how large the file is:

history kept	large file, once filled
30 days	about 440 KB
90 days (default)	about 920 KB
a year	about 3.1 MB

A file takes as long to reach those sizes as the setting itself, so a fresh install sits far below its eventual figure for months. Multiply the size by the five to ten large writes a day to see what it costs: at the default, several megabytes a day, which is the same order as the routine writing above rather than a rounding error on top of it.

Excluding what you do not care about. Every device Device Sentinel watches adds to both files. 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 both files 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.

Before tuning any of that, though, read the section on the recorder below. Home Assistant's own database almost certainly writes far more to that card than this integration does.

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, and ninety to a hundred and eighty days of history is comfortable. The longer end is worth choosing if you want to watch batteries discharge or signal floors settle, since neither shows much in less than a season.

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.

The Files in Your Storage Folder

Everything Device Sentinel keeps lives in config/.storage/, which is a hidden folder that the File Editor add-on filters out of its listing. You need the Terminal add-on or a Samba share to see it. Two files belong to this integration:

• device_sentinel.storage, the large one, holding everything learned.
• device_sentinel.clocks, the small one, holding the nine fast-moving values.

Both carry the time they were written, and Device Sentinel merges them at startup, taking the clocks from whichever is newer. Nothing is lost if the power goes out between one and the other.

You may also find files ending in .bak:

• device_sentinel.storage.pre-split.bak
• device_sentinel.storage.pre-0.10.0.bak

Those are one-time copies, each taken automatically before a release changed how storage is used, so that version could be stepped back from if it went wrong. Nothing creates them any more and nothing reads them. They are safe to delete, and the only thing you give up by deleting them is the ability to return to a version older than the split. If you would rather keep them, they cost only their size and are never rewritten.

The Recorder Is Probably the Bigger Cost

Everything above concerns one integration. Home Assistant itself keeps a database of every state change in your home, and on a busy system that writes far more than Device Sentinel ever will. If you are protecting an SD card, that is the first place to look, and no setting here will make much difference until it is addressed.

Device Sentinel cannot change it for you. The recorder is a separate part of Home Assistant, configured in configuration.yaml, and an integration has no business editing another's configuration. So this is something to do yourself, and it is worth doing.

Three settings matter most. How long history is kept, how often the database is committed, and which entities are recorded at all.

recorder:
  # How many days of history to keep. The default is 10.
  purge_keep_days: 7
  # How often changes are committed, in seconds. The default is 1,
  # which is a great many small writes. Raising it batches them.
  commit_interval: 30
  exclude:
    domains:
      - device_tracker
      - automation
      - updater
    entity_globs:
      - sensor.*_uptime
      - sensor.*_linkquality

The exclusions are where the real saving usually is. Entities that change constantly and that nobody ever looks at in a history graph, link quality readings and uptime counters being the classic examples, can account for most of the database's growth.

Raising commit_interval means that after an unexpected power loss you may lose the last few seconds of history, which for most people is a fair trade for a card that lasts. Consult Home Assistant's recorder documentation for the full set of options, since these are its settings rather than ours and they change from time to time.

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 diagnostics download, from the integration's page under Settings, reports the two files by name with the time each was last written and how far apart they are. And the files themselves in config/.storage/ tell you directly what a write of each kind costs.