Advanced

Advanced

Settings most people never need to change. Each has a sensible default, and each exists because somebody's system is not most systems.

Two settings on this page, the storage write interval and how much history to keep, are about 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 it with real numbers and suggests settings by machine.

Notification settle delay

When a device develops a problem, the integration waits before telling anyone, so a device that hiccups and recovers within moments never rings your phone. A fixed delay cannot serve a fleet where one device reports every ten seconds and another every four hours, so 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, and a device with a three-hour rhythm settles in about half an hour. Raise it and fewer transient problems reach you, at the cost of hearing about real ones later. Lower it and notifications become prompter and noisier. Detection is not affected; problems are recorded and listed the moment they are found, and this delays only the message.

Device Sentinel does not send messages yet, so this setting has nothing to delay today. It is here so the behaviour is settled before the first one goes out.

Episode recording threshold

The silence_episodes.md report records devices that went unusually quiet, for later study: it is how the integration learns whether a silent device was stuck or simply resting. A row opens when a device has been silent for this 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 and the file records more, including mild wobbles that recover on their own, which is useful when investigating a flaky device. Raise it and the file records only silences that came close to judgment. This affects one forensic file and nothing else: no detection, no notification, no learning.

Blip tolerance

When a device goes quiet and then comes back on its own, the integration usually learns that quiet time as normal, which is how a slow device earns a generous freeze window instead of being called dead every night. But a device that was actually gone, and came back only because someone replaced its battery or re-paired it by hand, should not teach the integration that being gone for hours is normal.

The integration cannot see a hand on a device. A battery pull, a re-pair, a power cycle at the wall are all invisible, so a device fixed by a person and a device that recovered on its own look identical. The only thing that tells them apart is how long the device was unreachable. A device that blinks out for a few seconds and returns was never really gone, a passing mesh hiccup, and the silence around it is real and worth learning. A device that sat unreachable for an hour before it spoke again was gone, and its return was almost certainly someone fixing it.

This setting is where that line sits: how briefly a device can be unreachable before the time counts as real downtime rather than a hiccup. Below the line, the quiet spell is learned. Above it, the spell is set aside so a hand-fixed outage never inflates the device's learned patience.

It is a floor, in minutes, and the default is 10. A device unreachable for less than this is always treated as a hiccup, whatever its rhythm. This is a floor rather than a share on its own because a hiccup is noise, the same brief thing on a fast device or a slow one, and noise is not a share of anything the device earned.

Blip tolerance share

Added on top of the blip tolerance floor, as a share of each device's own freeze window. A device that reports every few seconds keeps the floor alone, since it has almost no window to take a share of, while a device that reports every few hours is given proportionally more before an outage counts as real, because for a genuinely slow device even a long unreachable stretch can be an ordinary part of its rhythm.

The default is 10 percent. At that setting a device with a six-hour freeze window tolerates about fifty minutes of being unreachable before the time counts as real downtime, while a fast device stays at the ten-minute floor. Raise it and slow devices are given more rope before a return is treated as a repair; lower it and the floor does more of the work across the fleet. Like the floor, this changes only what is learned, never how a device is judged: a frozen or unavailable device is caught exactly as before.

The silence-episode report records how long a device was unreachable each time a quiet spell is set aside for this reason, in its UNAVAIL column, so these two settings can be tuned from what your own devices actually do rather than left at the defaults.

How much history to keep

Device Sentinel keeps a daily record for every device: the longest gap between reports, the lowest signal reading, how long the signal spent below the floor, and the battery level. These are what let slow changes be seen at all. A battery does not measurably discharge in a fortnight, a signal floor wants a season to settle, and three months of reporting gaps is what would eventually allow the two-week judgment window itself to be examined rather than assumed.

The setting runs from thirty days to a year, in steps of thirty, and defaults to ninety. More history means a larger stored file, and that file is rewritten whenever something happens, so the cost is real on a Raspberry Pi with an SD card and negligible on a machine with an SSD. On a fleet of roughly a hundred and twenty devices, thirty days is around 230 KB, ninety around 350 KB, and a full year around 900 KB.

This setting never changes what is detected. Every judgment, the freeze window and the signal floor alike, is computed from the most recent two weeks whatever this says. That is why it cannot be set below thirty days: no choice can starve the window that does the judging. Two systems with different settings detect identically; they differ only in how much they remember.

Reducing it takes effect at the next midnight rather than the moment you move the slider, so a mistake can be undone before any history is lost.

Storage write interval

The integration tracks activity for every device, which changes constantly. Writing every change to disk would mean a write every minute or two forever, which wears SD cards and adds up on any system. Instead, routine activity is held in memory and written on this interval. Anything important, a new problem, a recovery, an acknowledgment, a checked box, is always written immediately regardless.

The default is 15 minutes. On an SD card, longer is kinder. On an SSD, shorter narrows the window of activity data that a power cut could lose, which at worst costs the affected devices a few minutes of clock and heals with their next report. The range is 1 to 60 minutes.