Hysteresis for Alert Thresholds, Why One Limit Chatters

Short answer

Hysteresis replaces a single alert threshold with two: a high limit that starts the condition and a lower limit that ends it. Because a value must travel the gap between them to change state, noise sitting on one number can no longer produce repeated crossings, and one real excursion yields exactly one event.

Key takeaways

A single threshold is unstable by construction: a value resting on it crosses it every time noise moves it by one unit, in either direction.
Teltonika exposes a real dual-threshold operand called "On Hysteresis", which records only when the value crosses the high limit from below the low limit, or the reverse.
Over Speeding and Green Driving already latch, the scenario stays active until the measured value falls back below the set parameter, so one excursion is one event.
The gap between the two limits is the design decision; too small and chatter returns, too large and short genuine excursions never register.
Hysteresis and debounce solve different problems: hysteresis handles a value parked on a limit, debounce handles a value that spikes and returns.

01Why a single threshold is unstable by construction

Consider a speed limit set at one number and a vehicle travelling at almost exactly that number. Every sample is a coin flip: a little above, a little below, a little above again. Each of those transitions is a genuine threshold crossing by the strict definition, and a rule written against a single limit will honour every one of them. Ten crossings in a minute produce ten alerts, all technically correct and all describing one continuous situation. The failure is not in the sensor, the network or the rule logic. It is in the geometry of the comparison: a one-dimensional boundary has no width, so a value resting on it is always one unit of noise away from being on the other side. No amount of measurement precision fixes this, because greater precision simply resolves smaller oscillations around the same line and produces more crossings, not fewer.

02What the second threshold buys you

Hysteresis replaces the single boundary with a pair: one value at which the condition begins, and a different, lower value at which it ends. In between is a band where nothing changes. A value that has crossed the high limit stays in the alert state even as it drifts back down, until it travels all the way past the low limit. That travel is the whole mechanism. Noise of one or two units can no longer flip the state, because flipping now requires movement across the entire band rather than across a line. The system has acquired memory: its output depends not only on the current reading but on which side it came from. That memory is what makes the state machine stable, and it costs nothing but a second configured number.

03The operand Teltonika actually ships

This is not a theoretical construct that integrators have to build themselves. Teltonika devices expose an input-output operand named "On Hysteresis", documented to record an event only on crossing the high limit from below the low limit, or vice versa. The wording matters because it specifies the direction requirement, not merely the existence of two numbers. A value that dips just below the high limit and comes back does not qualify, since it never reached the low limit. That is precisely the case that generates chatter under a single threshold, and precisely the case the operand is written to exclude. Because the operand sits on the generic input-output layer rather than inside one feature, it is available for any alert driven by an input: a door sensor, an analog level, a temperature probe, a lock state.

04Latching: hysteresis with the low limit at zero

Some Teltonika features implement the same idea without exposing two configurable numbers, and it is worth recognising the pattern. Over Speeding is documented to stay active until the speed decreases below the set value, with Max allowed speed defaulting to 90 km/h. Green Driving behaves the same way: the scenario stays active until the measured value decreases below the set parameter, where the defaults are 2.5 m/s² for acceleration, 2.7 for braking and 3.4 for cornering, each configurable between 0.5 and 10. Both are latching implementations. The state, once entered, refuses to leave on a momentary dip, so one real excursion produces exactly one event no matter how ragged the underlying signal was. Functionally this is hysteresis where the exit condition is defined relative to the same threshold rather than a separately configured lower one.

05Choosing the width of the band

The two limits are easy to configure and the gap between them is the only real decision. Set it too narrow and you have not solved anything, because the noise amplitude you were fighting still exceeds the band and the state still flips. Set it too wide and the alert becomes insensitive in a way that hides real behaviour: a driver who exceeds the limit, drops well back, and exceeds it again registers as one long event rather than two, and the duration figure in your report becomes meaningless. The workable rule is to measure the actual peak-to-peak noise on that channel over a representative period and make the band comfortably larger than it, then check what the widened band does to the shortest excursion you still care about detecting. Both checks are needed; either one alone produces a setting that looks reasonable and reports badly.

06Hysteresis is not debounce, and they do not substitute

These two primitives get confused constantly, and the distinction is simple once stated. Hysteresis works in the value dimension: it asks how far the reading has moved. Debounce works in the time dimension: it asks how long the condition has held. Each fixes a failure the other cannot touch. A value parked exactly on a limit for ten minutes will defeat any debounce timer, because the condition genuinely does hold and genuinely does break, alternately, for the full duration. A value that spikes far past the limit for fifty milliseconds and returns will defeat hysteresis, because it crossed both boundaries legitimately. Production alert rules generally need both, and Teltonika ships both separately for exactly that reason. Configuring one and assuming it covers the other is the commonest reason a carefully tuned alert still produces noise.

07Where the band belongs in your architecture

A hysteresis band applied at the device is genuinely stronger than one applied afterwards, because the device observes every sample and the platform only observes what was transmitted. If the intervening samples were never sent, a platform-side rule cannot know whether the value passed the low limit between two records, so it can only guess. Our catalogue Teltonika FMC003 exposes two digital inputs, one analog input rated 0 to 30 V, an RS-232 port and 1-Wire, and each of those is a channel where the operand can be applied at source. The reporting consequence is the one to plan for: because a latched state produces one event with a duration rather than many events, every report that counts events changes meaning the moment you enable hysteresis. Migrate the reports and the setting together, or last month stops comparing to this one.

One threshold versus two, on the same noisy signal
Signal behaviour	Single threshold	Hysteresis band	Event count
Value parked on the limit, ±1 unit of noise	Crosses on every sample	No state change at all	Many versus zero
One clear excursion well past the limit	One event, possibly split	One latched event with a duration	One versus one
Excursion, brief dip, excursion again	Two or three events	One event if the dip stays in the band	Three versus one
Band set narrower than the noise	Chatters	Still chatters	Unchanged
Band set very wide	Chatters	Short real excursions never register	Under-reports

Figures and sources

True dual-threshold hysteresis operand available on any I/O-driven alert: operand "On Hysteresis": record only on crossing the high limit from below the low limit, or vice versa (Source: Teltonika Telematics Wiki, FMB920 I/O settings, as of 2026-08-31)
Over Speeding latching behaviour and its default limit: active until speed decreases below the set value; Max allowed speed default 90 km/h (Source: Teltonika Telematics Wiki, FMC650 Features settings, as of 2026-08-31)
Green Driving latching behaviour, device-side hysteresis so one excursion yields one event: scenario stays active until the measured value decreases below the set parameter (Source: Teltonika Telematics Wiki, FMC650 Features settings, as of 2026-08-31)
Teltonika Green Driving harsh-event thresholds, documented numeric defaults: acceleration 2.5, braking 2.7, cornering 3.4 m/s²; each configurable 0.5–10 (Source: Teltonika Telematics Wiki, FMB120 Parameter list, as of 2026-08-31)
The time-dimension primitive hysteresis does not replace, a separate entry debounce: Parameter 11205 "Time to stopped": default 5 s, range 0–3,600 s (Source: Teltonika Telematics Wiki, FMB120 Parameter list, as of 2026-08-31)
Averaging-constant sampling rate, which sets the noise a hysteresis band must exceed: internal sampling every 40 ms (25 samples/second) (Source: Teltonika Telematics Wiki, FMB920 I/O settings, as of 2026-08-31)
Teltonika FMC003 channels on which the hysteresis operand can be applied at source, per our catalogue: 2 digital inputs, 1 analog input (0–30 V), 1× RS-232, 1-Wire (Source: ENTEK.AI product catalogue, as of 2026-08-31)
Teltonika FMC003 driver-behaviour scope that relies on the latching thresholds, per our catalogue: harsh braking, rapid acceleration, sharp cornering and speeding (Source: ENTEK.AI product catalogue, as of 2026-08-31)

Questions

What exactly is hysteresis on an alert threshold?

It is the use of two limits instead of one: a high value that starts the alert condition and a lower value that ends it. Between them is a band where nothing changes, so a value must travel the whole gap to flip the state rather than merely wobble across a line.

Does Teltonika support hysteresis, or do I have to build it?

It ships as a documented input-output operand called "On Hysteresis", which records only on crossing the high limit from below the low limit, or vice versa. Because it lives on the generic I/O layer it is available to any input-driven alert, not just one feature.

Is latching the same thing as hysteresis?

Functionally yes, with the exit condition tied to the same threshold rather than a separately configured lower one. Over Speeding stays active until speed decreases below the set value, with Max allowed speed defaulting to 90 km/h, so one excursion produces one event.

Can hysteresis replace a debounce timer?

No. Hysteresis works in the value dimension and asks how far the reading moved; debounce works in the time dimension and asks how long the condition held. A brief spike far past the limit defeats hysteresis, and a value parked on the limit defeats debounce. Production rules usually need both.

How wide should I make the band?

Measure the actual peak-to-peak noise on that channel over a representative period and make the band comfortably larger, then check what the wider band does to the shortest excursion you still want detected. Both checks are needed; either alone gives a setting that looks fine and reports badly.

Hysteresis Explained: One Threshold Chatters, Two Thresholds Cannot