Skip to content

Detectors

Detectors are small, deterministic pieces of logic — not a language model — that turn a windowed series of sensor readings into a machine state, a count, or an open/close event such as an excess-energy alarm. This is a hard boundary in the design: the language model never sits in the sensing path (it only helps with onboarding and explanation — see Local inference & models). If the local model server is stopped, every detector keeps running unaffected.

Every recipe’s detector block names one detector and its default parameters (see Sensors & recipes). A detector reads one or more windows of samples from the historian on a schedule, and writes events and findings back. Each detector’s threshold is calibration data, not a hard-coded constant — hardware drifts over time, so every threshold is meant to be tuned per installation rather than trusted as a universal default.

The energy detector (used by recipes such as injection_moulding.energy.heater-band-power) learns a baseline power draw for a signal over a rolling window, then opens an event once power stays above that learned baseline by more than a configured margin for a configured number of consecutive samples, and closes it again once the signal has been clean for a configured number of samples. Its parameters — baseline window, minimum excess (absolute and fractional), the statistical margin, and the open/close sample counts — are exactly the knobs a calibration pass tunes.

Each recipe includes a validation block describing a concrete check — typically comparing the detector’s learned baseline against a handheld instrument reading taken on the same signal. Running that check after an install is how you confirm the detector is reading the right thing, not just that it is running.

Every detector-and-recipe binding is proven against recorded simulator data before it ships, so a detector’s behavior on a known signal shape is checked automatically rather than only observed live.