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 Settle Delay

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.

Blip Tolerance (Floor and Share)

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.

• Blip Tolerance: 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.)
• Blip Tolerance Share: 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.

Integrations to Ignore

Every other removal in Device Sentinel keeps the record. Excluding a device on Global Exclusions or on a section screen stops it being judged and reported, and nothing else: it stays watched, it goes on learning, and the moment you take the exclusion off it is back with everything it knew. That is deliberate, because most devices you exclude are hardware you might want to hear about again.

This list is the exception, for integrations that publish measurements of nothing your house can be judged on. A device on an ignored integration is never watched, never learned from, and never recorded. It is set aside, the way service devices are, and the classification report names it as ignored.

The list starts with four:

• mobile_app: phones and tablets. They leave the house, they carry a cellular radio whose signal says nothing about your network, and their batteries are charged rather than replaced, so a battery series from one is a sawtooth that no discharge rule can read.
• fully_kiosk: wall tablets on permanent power, reading 100 percent forever.
• spook: describes Home Assistant itself rather than hardware, and escapes the service classifier because it does not mark its entries that way.
• ping: a probe that reports on every poll whether the target answered, so it can never fall silent while the integration is alive, and its devices duplicate hardware already watched through its real integration.

The list is yours. Any of the four can be removed, and any integration with watched devices can be added. Integrations whose every device is already set aside as a service device are not offered, because ignoring them would change nothing.

What happens when you add one. The devices are set aside at once, so nothing new is learned. What they had already recorded is discarded at the next local midnight, alongside the retention trim above, and not the moment you press Submit. Until that midnight, taking the integration back off the list restores it untouched. After it, taking it off starts that integration over, with no history and a fresh seven-day arming period.

Ignore is not exclude. If an integration is on this list, excluding it anywhere else does nothing, because there is no watched device left for the exclusion to act on. Where you want to stop hearing about a device but keep what it has learned, exclude it. Where the data itself is meaningless, ignore it.