Skip to content
Sign inGet Started

Event Duration versus Event Timeout: Three Primitives, Three Different Jobs

By Saeed Baatiah · Published:

Short answer

Duration sets how long a condition must last before one event is created. Event Timeout sets how long the device refuses to create another one afterwards. Unplug Delay judges whether the state is stable at all and discards the event when it is not. Three names, three separate jobs, no substitution possible.

Key takeaways

  • Duration is a minimum-length gate on a single event: the condition must hold that long before anything is created.
  • Event Timeout (ID 11603) defaults to 0 with a range of 0 to 60 seconds, and its documented purpose is filtering redundant events, it governs the gap between events, not the event itself.
  • Unplug Delay (ID 11511) is neither: it records only if the state persists, and ignores the event entirely if the state keeps changing.
  • Appropriate Duration values differ by orders of magnitude, towing defaults to 1,000 ms while crash defaults to 5 ms at a 1,500 mG threshold.
  • Setting Event Timeout to suppress noise that Duration should have caught leaves the first spurious event intact and only hides the ones behind it.

01Three settings, one confusing family of names

Open the alert configuration on almost any tracker and you will find several time-valued fields whose names all sound like they are doing the same thing. Duration, delay, timeout, persistence: the vocabulary is small and the concepts are not. Because the fields sit next to each other in the interface, the natural assumption is that they are alternative ways of saying "wait a bit", and that setting whichever one you find first will quieten the alert. That assumption is where most misconfiguration begins. In reality each field acts at a different point in the life of an event, and two of them do not affect the same event at all. Getting them straight is worth the ten minutes because the wrong choice does not simply fail to help, it produces a data set that is quiet in the wrong places and noisy where you needed silence.

02Duration: a minimum-length gate on one event

Duration answers one question: how long must the triggering condition hold before this event is created at all? It operates on the front edge of a single event and it has no view of any other event. Teltonika ships it with values that make the purpose obvious once you compare two features. The towing detection Duration defaults to 1,000 milliseconds and can be set anywhere from 1 to 5,000, because a genuine tow involves sustained movement and a brief nudge in a car park does not. The crash detection Duration defaults to 5 milliseconds with a range of 0 to 1,000, applied at a 1,500 mG threshold, because a real impact is over in a few milliseconds and demanding a full second of it would mean detecting nothing. Same parameter name, two hundredfold difference in value, and both correct.

03Event Timeout: a gate on the gap, not the event

Event Timeout is a different animal. Teltonika documents it under ID 11603 with a default of 0 and a range of 0 to 60 seconds, and states its purpose explicitly as filtering redundant events. That word "redundant" is the giveaway: it is concerned with the second, third and fourth events, not the first. Once an event has been created, the timeout defines a window during which the device will not create another of the same kind. The first event always gets through unchanged. This makes it the correct tool for a condition that is genuinely present and genuinely repeating, a rough road generating a series of legitimate harsh-braking detections that you want summarised rather than enumerated. It is the wrong tool for a spurious first event, because by design it never touches the first one.

04Unplug Delay: the one that can discard the event

The third primitive is the most interesting and the least understood, because it is the only one whose outcome can be nothing at all. Teltonika documents Unplug Delay under ID 11511 as recording the event only if the state persists, and ignoring the event entirely if the state keeps changing. Read that carefully: a flapping state does not produce a late event or a merged event. It produces no event. This is a persistence judgement rather than a length gate. Duration asks whether the condition lasted long enough; Unplug Delay asks whether the condition settled. Those are not the same question, and the difference shows on a loose connector, where the state changes many times in quick succession and every individual change satisfies a short Duration while none of them represents a real unplug worth reporting.

05Picking the right one for the failure you have

The diagnosis is simpler than the vocabulary suggests, and it comes down to describing the noise before touching a setting. If you are receiving one bad event per real situation and the event is too short to be genuine, that is a front-edge problem and Duration is the parameter. If the first event is correct and the following nineteen are the annoyance, that is a gap problem and Event Timeout is the parameter. If the input is physically unreliable and the state oscillates without settling, that is a persistence problem and only Unplug Delay discards it. Attempting the wrong one produces a recognisable symptom each time: Event Timeout used against a front-edge problem leaves one spurious alert per window, and Duration used against a gap problem forces you to lengthen it until real events start disappearing too.

06What each one does to your reports

The three settings damage historical comparability in three different ways, and this is the part that gets discovered a month too late. Duration changes which events exist, so it changes counts and it changes the average duration of the surviving events upward, since the short ones were removed. Event Timeout changes counts without changing what happened, so an events-per-hour figure drops while the underlying behaviour is identical, and the peak-rate metric drops hardest, because peaks are exactly where redundancy clusters. Unplug Delay removes events entirely and silently, leaving no record that a discard occurred. None of the three is visible in a report built from events alone, which is the practical argument for holding raw records long enough to re-derive any figure whose configuration has changed.

07Configuring all three on one channel

In production the three usually coexist on the same alert, stacked in a fixed order, and it helps to picture the pipeline. A condition arrives; Duration decides whether it lasted long enough to matter; Unplug Delay decides whether it was stable rather than flapping; Event Timeout decides whether the platform has heard this recently enough to skip. Only what survives all three becomes a record. Our catalogue Teltonika FMC003 carries two digital inputs and one analog input rated 0 to 30 V, and a door or tamper switch on a digital input is the standard case where all three earn their place at once. Set them in that order, change one at a time, and write the value into the vehicle record, because six months later the only way to interpret an event count is to know which of the three produced it.

Three primitives, and the failure each one actually fixes
PrimitiveActs onFixesCannot fix
DurationFront edge of one eventEvents too short to be genuineA burst of legitimate repeats
Event Timeout (11603)Gap after an eventRedundant repeats behind the firstThe first spurious event
Unplug Delay (11511)Stability of the stateA flapping, unsettled inputA single clean but unwanted event
Typical defaulttowing 1,000 ms / crash 5 msEvent Timeout 0 sUnplug Delay discards on flapping
Effect on reportsCounts down, average duration upCounts down, peaks down hardestSilent removal, no trace

Figures and sources

Questions

What is the difference between Duration and Event Timeout?

Duration gates the front edge of one event, the condition must hold that long before anything is created. Event Timeout, ID 11603 with a default of 0 and a range of 0 to 60 seconds, gates the gap afterwards; its documented purpose is filtering redundant events, so it never touches the first one.

Why is the crash Duration so much shorter than the towing Duration?

Because the physical events differ. Towing Duration defaults to 1,000 ms with a range of 1 to 5,000, since a real tow means sustained movement. Crash Duration defaults to 5 ms with a range of 0 to 1,000 at a 1,500 mG threshold, since a real impact is over in milliseconds.

What makes Unplug Delay different from the other two?

Its outcome can be nothing at all. It records the event only if the state persists, and ignores the event entirely if the state keeps changing. That is a stability judgement rather than a length gate, which is why it is the only one that helps with a loose or intermittent connection.

I raised Event Timeout and I still get one bad alert per situation. Why?

Because Event Timeout only suppresses the events behind the first, by design. One bad alert per real situation is a front-edge problem, and Duration is the parameter that governs it. Timeout will hide repeats but will never remove the leading event.

Which of these breaks my historical reports?

All three, differently. Duration changes which events exist and pushes average duration upward. Event Timeout lowers counts without changing behaviour, hitting peak-rate figures hardest. Unplug Delay removes events silently with no record of the discard. Keep raw records long enough to re-derive any figure after a change.

Sources

Related insights