Advanced

Advanced

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

Two of the five settings on this page, the storage write interval and how much history to keep, concern storage rather than detection. If you are running from an SD card, or simply want to know what they cost, Built to Be Efficient explains their economics in detail and suggests settings by hardware. Notification targets, tiers, and quiet hours have their own page at Notifications and Daily Brief.

Notification Settle Delay

When a device develops a problem, the integration waits before telling anyone, so a network hiccup that heals in moments never rings your phone.

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 own grace, the patience the freeze engine has already computed for it.

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 half an hour.

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

This does not delay detection. Problems are recorded and join the problem list the exact moment they are found; this slider delays only the message sent to your phone and the dashboard card. The daily brief is also unaffected: it reports what its time window held regardless of whether a problem settled, so a fault that came and went will still appear in your morning summary.

Episode Recording Threshold

The silence_episodes report records devices that went 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 a specific share of the distance between its normal rhythm and its freeze line. 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 draw a single line that solves a specific problem: separating self-recoveries from human repairs.

When a device goes quiet and returns on its own, that quiet time is normally learned. This is how a slow device earns a generous window instead of being called dead every night. 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 at the wall, should not teach the integration that hours of absence are normal.

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. Seconds of absence is a passing mesh hiccup; an hour of being unreachable before it spoke again was an outage, and its return was almost certainly a repair.

These settings place the line between the two. Unreachable time below the line is a hiccup, and the quiet spell is learned. Unreachable time above the line is set aside, so a hand-fixed outage never inflates the device's learned patience.

• Blip Tolerance: A floor in minutes, defaulting to 10. Below this, an absence is always a hiccup, whatever the device's rhythm. It is a floor rather than a percentage because a mesh hiccup is just noise, and noise is the same brief thing on a fast device or a slow one.
• 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.

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 to tune it: Every time a quiet spell is set aside for this reason, the silence-episodes report records how long the device was unreachable in its UNAVAIL column. You can use that column to tune these sliders from real durations on your own fleet rather than guessing.

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 a season to settle.

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, each about 40 KB lighter than before 0.10.14 removed the clock copies that file once carried. Built to Be Efficient puts those figures beside how often that file is written.

This setting never changes what is detected. Every judgment is computed from a recent window of its own: fourteen days for a freeze rhythm, thirty for a signal floor, seven for a battery slope. That is why this cannot go below 30 days, which is the longest of the three: no choice can starve the window that does the judging. Two systems with different history settings detect identically; they differ only in how much they remember. How Device Sentinel Learns explains why the three differ.

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, the per-device clocks that change constantly, is held in memory and written once per interval to a small file of its own, 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 worth keeping has changed. 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: Longer is kinder to your hardware.
• On an SSD: Shorter narrows the small window of routine activity a power cut could lose, which, at worst, costs the affected devices a few minutes of clock progress that heals with their very next report. The cut itself is recognized on the next start and handled; Recovery describes what happens.