Built to Be Efficient

Built to Be Efficient

Device Sentinel watches every device in your home, remembers what it learns, and records this data 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 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 located in the hidden .storage subdirectory. The data is divided into two files according to how often the data changes.

• The clocks file (device_sentinel.clocks) is tiny, about 45 KB for a fleet of 125 devices. It carries the per-device values that move whenever a device reports: the activity clock, current signal reading, and battery levels.
• The main file (device_sentinel.storage) is much larger, about 400 KB at 30 days of history. It carries everything learned over time: the daily history, verdicts, problem list, and recent incident records.

Because a device reporting normally only touches the tiny clocks file, the large main file is spared the churn of ordinary activity. Because of this, routine write volume falls 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 chosen storage write interval. Historically, this coalescing reduced nightly writes from roughly 515 down to 36.

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

To protect against data loss, the integration saves data immediately when something important happens: 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.

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 in memory before being saved. It is the most effective adjustment you can make if write volume concerns you. A longer interval means drastically fewer data 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 size averages about 400 KB; at the full 360, it grows to about 3.0 MB. Because of this, it is strongly recommended not to exceed the default 90 days unless you have a powerful system with lots of storage and memory so as to not bog down your system during large data writes.

For an SD card installation, a storage write interval of 30 minutes (or 60 minutes for maximum economy) paired with a 30 to 60-day history retention is our recommended configuration. If you are on an SSD, the defaults are optimal.