Skip to content

Built to Be Efficient

TheThinkingHome edited this page Aug 7, 2026 · 13 revisions

Built to Be Efficient

Device Sentinel watches every device in your home and remembers what it learns. Because it constantly records data, it must write to disk. On a machine with an SSD, this cost is negligible. However, if you run Home Assistant on a Raspberry Pi with an SD card, repeated small writes are among the few things that genuinely shorten the life of your hardware.

We knew this from the beginning, so Device Sentinel's storage design treats flash wear as a strict constraint rather than an afterthought. This page explains exactly how the integration minimizes disk activity to protect your fragile storage, and how you can tailor the write schedule to fit your specific system.

How the Integration Manages Its Writing

Storage is divided between two files under .storage according to how often the data actually changes.

  • The clocks file (device_sentinel.clocks) is tiny, about 45 KB for a fleet of 125 watched devices. It carries the per-device values that move whenever a device reports, such as the activity clock and current signal reading, and it is their only home.
  • The main file (device_sentinel.storage) is much larger, about 405 KB for that same fleet part-way into its history. It carries everything learned over time: the daily history, verdicts, problem list, and recent incident records, and nothing that changes with routine activity.

For its first weeks the main file also carried a spare copy of every clock, kept purely so that stepping back to an older version could never lose anything. An outside witness compared the two files every fifteen minutes across the whole proving period and found them out of agreement exactly zero times, so the copies are no longer written, after a one-time backup of both files was taken first. Each routine write of the main file became about 40 KB smaller.

Because a device reporting normally only touches the tiny clocks file, the large main file is spared the churn of ordinary activity entirely. When we introduced this split, routine write volume fell by roughly 64 percent.

Routine changes are also coalesced rather than written as they occur. When a device reports and its clock advances, that change is held in memory and saved together with everything else that accumulated during your defined storage write interval. Historically, this coalescing reduced nightly writes from roughly 515 down to just 36.

The large file is evaluated on that exact same schedule, but it is only written if something worth keeping has happened since its last write. On a settled system, the main file is touched only a handful of times a day.

Coalescing never applies to anything a restart must not lose. If a device goes silent, a battery crosses your threshold, or an item is added to the problem list, these are written to both files the moment they happen. Both files are also written once more at every clean shutdown. The exposure in a power cut is therefore limited to at most one interval of routine clock progress, which automatically repairs itself the moment each device reports again. A power cut is also recognized as one on the next start, and handled; Recovery describes what happens.

The four Markdown reports are written at startup, at midnight, at your daily brief time, and when you press the Regenerate Reports button, never continuously in the background.

The Settings That Govern It

You have full control over how often writing occurs via two settings on the Advanced screen.

  • Storage write interval (1 to 60 minutes, default 15): This sets how long routine changes are held before being saved. It is the single most effective adjustment you can make if write volume concerns you. A longer interval means drastically fewer writes, in exchange for slightly more of the self-repairing clock data being at risk during a power cut.
  • How much history to keep (30 to 360 days, default 90): This determines how many days of per-device daily history are retained, which ultimately controls how large the big file grows. At 30 days, the file maxes out around 440 KB; at the full 360, it grows to about 3.1 MB. This only affects stored history; your detection behavior never changes with this setting.

For an SD card installation, a storage write interval of 30 minutes (or 60 minutes for maximum economy) paired with the default 90-day history is our recommended configuration. If you are on an SSD, the defaults are fine and the subject needs no further thought.

Clone this wiki locally