Debounce Timers in Alerting, Entry vs Exit Delay Explained

Short answer

A debounce timer does not postpone an alert. It requires the triggering condition to hold continuously for a set period before the state changes at all, so a condition that flickers never becomes an event. Teltonika sets entry at 5 seconds and exit at 2, which deliberately biases the logic against generating anything.

Key takeaways

A debounce timer is not a delay on the notification, it is a condition on whether the state changes at all, so a flickering input produces no event rather than a late one.
Teltonika parameter 11205 "Time to stopped" defaults to 5 seconds with a range of 0 to 3,600; parameter 11206 "Time to moving" defaults to 2 seconds.
Entry is deliberately more expensive than exit, which biases the state machine toward "nothing happened" and is why default settings under-report rather than over-report.
The documented entry condition is continuous: speed must stay below the start-speed threshold for the entire timeout, not merely touch it once.
Setting a debounce timer to zero does not disable filtering, it moves every sensor twitch straight into your event stream.

01The word "timer" is misleading

Most people first meet a debounce setting while trying to stop an alert from firing so often, and they read it as a delay: the condition happens, the platform waits, then it tells you. That is not what the parameter does. A debounce timer is a condition placed on the state transition itself. The device asks whether the triggering criterion has held without interruption for the whole configured period, and only if it has does the state change and the event exist. If the criterion breaks at any point during that window, the counter resets and nothing is ever produced. The practical consequence is important and often surprising: a correctly debounced system does not send late alerts, it sends fewer alerts. Nothing is queued and nothing arrives afterwards. Conditions that never held long enough simply have no representation in your data at all.

02The two numbers Teltonika actually ships

The idling detection on Teltonika trackers exposes the mechanism cleanly, because it uses two separate parameters rather than one. Parameter 11205, named "Time to stopped", defaults to 5 seconds and can be set anywhere from 0 to 3,600 seconds. Parameter 11206, "Time to moving", defaults to 2 seconds. Both control the same state machine, whether the vehicle is considered stationary, but they guard opposite transitions. Five seconds of continuous low speed are required to declare a stop; two seconds of movement are enough to cancel it. Nobody typing those defaults chose them by accident, and the gap between them is not rounding. It is a stated preference about which error the device should prefer to make, encoded as a pair of integers you can read out of the configuration and change at will.

03Why entry is harder than exit

Any state machine with debounce on both edges has to answer a question: which mistake is cheaper? Making entry expensive and exit cheap means the device is slow to believe something started and quick to believe it ended. Every borderline case therefore resolves toward "no event". A vehicle creeping along in traffic at just under the threshold needs a full five uninterrupted seconds to register as stopped, and any brief roll forward within those five seconds wipes the progress. Once it is registered as stopped, two seconds of motion end the state immediately. The asymmetry compounds across a shift: the harder entry filter removes short spurious stops, and the easier exit filter truncates genuine ones. The result is a stream that is quieter than reality, and quieter in one specific direction. That is usually the right trade, but only if you know it is being made.

04"Continuously" is the load-bearing word

Teltonika documents the entry condition explicitly: speed must stay below the start-speed threshold for the whole "Time to stopped" timeout. That wording rules out the interpretation most integrators assume, which is that the condition needs to be true at the start and true at the end. It must be true throughout. A single sample above the threshold at second three restarts the clock from zero. This is what separates a debounce from a sampling window, and it is why a debounce is genuinely robust against noise rather than merely against fast noise. It also explains a common support ticket: an operator raises the timer to suppress chatter and finds the alert has stopped appearing entirely, because on a congested route the condition never manages to hold for the longer period without at least one interruption.

05What happens when the sensor itself goes quiet

A debounce timer is only as good as the signal it is judging, and a lost satellite fix is not the same as a stopped vehicle. Teltonika handles this with a documented fallback: when there is no GPS fix, movement is determined from accelerometer data instead. Without that substitution the timer would see speed reported as zero for the whole window, satisfy its continuity requirement perfectly, and declare a stop in the middle of a tunnel. The lesson generalises beyond one vendor. Every debounce rule needs a defined answer for the case where the input is absent rather than low, because absence usually looks identical to the quiet state the filter is designed to detect. If your platform treats missing telemetry as a zero, no debounce setting anywhere will save the resulting report from being wrong.

06Reading the bias out of your own numbers

Because debounce settings suppress events rather than delay them, their effect is invisible in any report built from the events themselves. A monthly idling total computed from debounced events cannot tell you how much idling was filtered out, since the filtered periods left no trace to count. The only way to see the bias is to compare against the raw signal, which means keeping raw samples for long enough to make that comparison possible. This is the practical argument for auditing timer values as configuration rather than treating them as installer defaults nobody revisits. Two vehicles with different "Time to stopped" values will produce non-comparable idling reports even if they idle identically, and no amount of downstream analysis can reconcile them because the difference was decided before the data existed.

07Where the timer lives, and why that matters

A debounce implemented on the device and a debounce implemented in the platform are not interchangeable, even at identical values. The device sees every sample and can enforce true continuity; it also decides what is worth transmitting at all, which saves bandwidth and battery. A platform-side rule can only judge the records it received, so if the device already discarded the intervening samples the platform cannot verify continuity, it can only check the endpoints. Our catalogue Teltonika FMC003 carries two digital inputs, one analog input rated 0 to 30 V, an RS-232 port and 1-Wire, and every one of those channels is debounced at the device before anything reaches the network. The practical rule is to put the continuity requirement where the samples are, and to keep platform rules for things the device cannot know, such as cross-vehicle context.

What a debounce timer does, versus what people assume it does
Behaviour	Assumed: a delayed alert	Actual: a condition on the transition
Condition holds for the full period	Alert arrives late	Alert exists, timed from the transition
Condition breaks mid-window	Alert still arrives, later	Counter resets; no event ever exists
Effect on total event count	Unchanged	Reduced, suppressed events leave no trace
Timer set to zero	Instant alerts	Every twitch becomes an event
Input goes missing entirely	Nothing happens	Looks identical to the quiet state unless a fallback exists

Figures and sources

Teltonika Excessive Idling entry debounce, parameter, default and range: 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)
Teltonika Excessive Idling exit debounce, shorter than the entry delay by design: Parameter 11206 "Time to moving": default 2 s, range 0–3,600 s (Source: Teltonika Telematics Wiki, FMB120 Parameter list, as of 2026-08-31)
Documented entry condition for the idling state, duration-gated, not instantaneous: speed must stay below the start-speed threshold for the whole Time to stopped timeout (Source: Teltonika Telematics Wiki, FMC650 Accelerometer Features settings, as of 2026-08-31)
Teltonika fallback preventing a GPS dropout from reading as a stop: when there is no GPS fix, movement is determined from accelerometer data (Source: Teltonika Telematics Wiki, FMC920 Accelerometer Features settings, as of 2026-08-31)
Persistence-based debounce that discards rather than delays the event when state flaps: Unplug Delay (ID 11511): record only if the state persists; event ignored if it keeps changing (Source: Teltonika Telematics Wiki, FMC003 Accelerometer Features settings, as of 2026-08-31)
Granularity at which movement state is evaluated, which sets the resolution a debounce can enforce: movement criteria checked every second (Source: Teltonika Telematics Wiki, FMB120 Data acquisition settings, as of 2026-08-31)
Teltonika FMC003 input channels available to a device-side debounce rule, 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 GNSS accuracy, the signal a speed-based debounce is judging: < 2.5 m CEP; GPS, GLONASS, GALILEO, BeiDou (Source: ENTEK.AI product catalogue, as of 2026-08-31)

Questions

Does a debounce timer make my alerts arrive late?

No. It decides whether the state changes at all. If the condition holds for the full period the event is created and sent normally; if the condition breaks partway through, the counter resets and no event is ever produced. Nothing is queued for later delivery.

Why is Teltonika's entry timer longer than its exit timer?

Parameter 11205 "Time to stopped" defaults to 5 seconds while 11206 "Time to moving" defaults to 2. Making entry expensive and exit cheap means every borderline case resolves toward "no event", so the device is biased against generating an alert rather than toward it.

Should I set the debounce timer to zero to see everything?

That does not give you truth, it gives you noise. Zero removes the continuity requirement, so every momentary sensor reading that crosses the threshold becomes an event. The range on parameter 11205 runs to 3,600 seconds precisely because the right value depends on the route and the vehicle.

Can I compare idling reports between two vehicles with different timer values?

Not meaningfully. Because suppressed events leave no trace, the difference was decided before the data existed and no downstream analysis can reconcile it. Audit the timer values as configuration, and align them across any group of vehicles you intend to compare.

What happens to a debounce timer when the GPS signal drops?

Without a fallback, reported speed reads as zero for the whole window, the continuity requirement is satisfied perfectly, and the device declares a stop inside a tunnel. Teltonika documents the fix: when there is no GPS fix, movement is determined from accelerometer data instead.

What a Debounce Timer Actually Does to an Alert