Advanced

Advanced

These are settings most people should never need to change. Every one has a sensible default, and every one exists because not everybody's system is the average system.

Two of the settings on this page, the storage write interval and how much history to keep, concern storage rather than detection. If you are running Home Assistant from an SD card, increasing the write interval and decreasing the amount of history to keep is a good idea. If you are running on a fast mini-PC with an SSD and plenty of RAM, feel free to write data quicker and to retain more historical data. If you want to know the costs, Built to Be Efficient explains their economics in detail and suggests settings by hardware.

Notification Debounce

When a device develops a problem, the integration waits before sending its notifications, so a network hiccup that heals in moments does not interrupt you with a phone push notification. This does not delay detection. Problems are recorded and added to the problem list and daily brief the moment they are found; this slider delays only the message sent to your phone and the dashboard card.

A fixed delay cannot serve a fleet where one device reports every ten seconds and another every four hours. Instead, the delay scales: it is a percentage of each device's learned grace, the patience the freeze engine has already computed.

At the default of 30 percent, a device that reports every ten seconds settles in about a minute, while a device with a three-hour rhythm settles in about forty-five minutes.

• Raise it: Fewer transient problems reach you, but you will hear about real problems later.
• Lower it: Notifications become prompter, but noisier.

Silence Episode Recording Threshold

The silence_episodes diagnostic report records devices that became unusually quiet, so you can study whether a silent device was genuinely stuck or merely resting.

A row opens in this report when a device has been silent for most of its freeze limit. At the default of 50 percent, a row opens halfway to the freeze line.

• Lower it: The file records more, including mild wobbles that self-recover. This is useful when investigating a flaky device.
• Raise it: The file records only silences that came close to judgment.

This setting affects one forensic file and nothing else. It changes no detection, triggers no notification, and affects no learning.

Repeat Offender Threshold

The daily brief carries a section called Keeps Failing On Its Own, for the device whose interruptions keep having no explanation. The integration cannot reliably detect a television that reads unavailable whenever somebody turns it off, or a dying battery crossing its threshold many times a day, so instead of guessing, the brief names the pattern and you decide.

An interruption counts toward the section only when it is unexplained: no restart, no bridge or broker outage, no integration reload, and no pairing window accounts for it. The judgment is the same attribution the brief's own sentences use, so the section and the prose cannot disagree about the same event. The line carries the count, how many days it spread over, and the worst day, because eighteen over six days is a failing device while fifteen all in one afternoon was one afternoon.

This slider is how many unexplained interruptions inside a week put a device in the section. The range is 1 to 4, and the default is 2.

• Lower it: Devices are named sooner, on weaker patterns.
• Raise it: The section waits for a stronger pattern before naming anything.

Unavailable Debounce (Fast and Slow)

These two settings work together to answer the question separating self-recoveries from human repairs. Because the integration cannot see your hands, a hand-fix and a self-recovery look identical. The one distinguishing signal is how long the device sat unreachable.

When a device goes quiet and returns on its own, that quiet time is learned. However, a device that was genuinely gone and came back only because a person fixed it, a battery swap, a re-pair, a power cycle, should not teach the integration that hours or days of absence are normal.

These settings place the line between the two.

• Unavailable Debounce for Fast Reporting Devices: A floor in minutes, defaulting to 10. Below this, an absence is learned, whatever the device's rhythm. (This setting is useful for fast reporting devices.)
• Unavailable Debounce for Slow Reporting Devices: Added on top of the floor as a share of each device's own freeze window, defaulting to 10 percent. A fast reporter keeps just the floor, as it has almost no window to take a share of. A slow device is given proportionally more rope, because for it, even a long unreachable stretch can be ordinary. At defaults, a device with a six-hour window tolerates about fifty minutes of being unreachable before the time counts as real downtime. (This setting is useful for slower reporting devices.)

Both of these settings change only what is learned, never how a device is judged. A frozen or unavailable device is caught exactly as before.

How Much History to Keep

Device Sentinel keeps one record per device per day: the longest gap between reports, the lowest signal reading, the time spent below the signal floor, and the battery level. This history is what allows slow changes to be seen at all: a battery does not measurably discharge in two weeks, and a signal floor needs 30 days to become accurate.

The setting ranges from 30 days to a year in steps of 30, and defaults to 90.

This history lives in the larger of the two storage files, so this setting changes that file's size and what each write costs. On a fleet of about 125 devices, once filled, 30 days is about 400 KB, 90 days is about 880 KB, and a year is about 3.0 MB. Built to Be Efficient explains how data is written and retained and how to tune this setting for your Home Assistant server.

Reducing this setting takes effect at the next midnight, not the moment the slider moves, so a mistake can be undone before any history is lost.

Storage Write Interval

Routine activity is held in memory and written once per interval rather than writing to disk every time a device speaks. The range is 1 to 60 minutes, with a default of 15.

The integration's larger storage file is checked on this same schedule but written only when something in the file has changed or been updated. Anything important, a new problem, a recovery, an acknowledgment, a settings change, is written to both files immediately, restarting the interval clock.

• On an SD card or a slower processor: Longer is safer to your hardware.
• On an SSD with a fast processor and a generous amount of RAM: Shorter narrows the small window of routine activity a power loss could lose. The power loss itself is recognized on the next start and handled; What Is Recorded About Your House describes what happens.

Maintenance Window in Minutes

The integration is unable to distinguish a device self-recovering from a long period of silence from a frozen device requiring manual intervention, such as a power cycle, battery pull, device button press, or rebind.

So that the silence from a manual intervention is not learned, maintenance mode was created. Put the integration in maintenance mode and no recovery is learned. This setting is the amount of time the Maintenance Mode window stays open once the button on the device page is pressed. The range is 5 to 60 minutes, and the default is 10.

Data Trim

At the foot of the screen, collapsed, sit the two pickers that erase learned history: one for whole integrations, one for single devices. This is the one place in the integration where saving a screen performs an action rather than storing a setting, and it is collapsed so it does not sit open under the cursor of somebody adjusting a slider.

Use it when support asks you to, or when you know a device's record has gone wrong and you want that device to start over. The measure the tool was built to: a support message can read "go to the Advanced tab, pick that device, save."

What a trim erases. The device's statistics, its silence episodes, its incidents, and its Problem List entries. An integration trim is the same erasure applied to every device on that integration.

What survives. The device itself, which is rediscovered within seconds and begins learning a new baseline with a fresh seven-day arming period. Every mute and every exclusion, because erasing data is not a statement about wanting the device gone. System events, restarts, outages, and pairing windows, because those belong to the house rather than to any device, and clearing them would falsify the explanations other devices' events depend on. Acknowledgments on other devices.

The safeguards. Before anything is deleted, a stamped copy of both storage files is written to config/device_sentinel/trim_backups, one pair per trim, never overwritten. If that copy cannot be written, nothing is deleted. The backups accumulate until you delete them yourself; nothing expires them. The pickers empty themselves after the save, so a later save of any other setting on this screen cannot repeat the erasure.

The pickers offer everything. Watched, muted, excluded, and set-aside devices all appear, whether or not they currently hold any data, because a faulty record can read as empty and the empty-looking device is exactly the one support will ask you to pick. Trimming a device with nothing recorded is allowed and does nothing except write its event. The integration is shown beside each name, because two devices can share a name, and the one on the wrong integration is the wrong pick.

The record of it. Every trim writes a system event and appears in the daily brief, naming what was picked and what went, so a person reading back a week can see why a device's history begins on a Tuesday. Maintenance Mode has no effect on a trim.