Event Triggers
How Infohub decides an event started or ended — trigger types, conditions, and the timestamp rule that catches everyone.
A trigger is the rule that tells Infohub an event has started or ended. Triggers are where most of the real work of building an event scheme lives, and where nearly all of the trouble comes from.
Start and end are separate triggers#
An event scheme has start triggers and end triggers, configured independently.
That separation is deliberate and occasionally surprising. A stoppage might start when a state tag leaves the running value and end when it returns — two different conditions on the same tag. A production run might start from an MES record and end from a tag. Nothing requires the two to be symmetrical.
It also means the two failure modes are independent:
- A start that fires and an end that never does leaves the event open indefinitely. Durations grow without limit and every duration-based measure is wrong.
- An end with no matching start produces nothing, or an event with implausible bounds.
- A start that fires twice produces duplicate or overlapping events.
When events look wrong, establish which of the two triggers is misbehaving before changing anything.
Where triggers get their information#
| Trigger source | Use for |
|---|---|
| Retrieved | A tag or query in a data source marks the transition |
| Calendar | The event boundary is a time, not a condition |
Retrieved is the usual case: a machine state tag, a running flag, a query against an MES or production table.
Calendar triggers suit events whose boundaries are genuinely times — a planned maintenance window, a scheduled cleaning slot. If the boundaries recur on a rule and tile the timeline, though, reconsider whether it is really a shift or time scheme rather than an event.
Trigger types on a tag#
For a tag-based trigger, the Trigger property selects what kind of transition fires it:
| Trigger | Fires |
|---|---|
| When the condition becomes true | On the transition into the condition |
| When the condition becomes false | On the transition out of the condition |
| When the tag's value changes | Whenever the value changes at all |
| When the tag's value remains unchanged | When the value has held steady |
| Custom Expression | On a condition you write yourself |
Supporting properties:
| Property | Purpose |
|---|---|
| Condition | The comparator: >, =, or < |
| Condition Value | What to compare the tag against |
| For Period (s) | The condition must hold this long before firing |
| Deadband | Ignore fluctuation smaller than this |
Transitions, not states#
The distinction between "becomes true" and "is true" is the one to get right.
A trigger on becomes true fires once, at the moment of transition. A machine that is stopped for two hours produces one start, not a start on every sample. That is what you want — one event per occurrence.
This is also why the pairing works: becomes true on the stopped condition starts the stoppage, and becomes false on the same condition ends it.
For Period: the noise filter#
For Period (s) requires the condition to hold for a minimum duration before the trigger fires. It is the most useful property on this page — and if you arrived here searching for an event "deadband" or a "minimum duration" setting, this is the property you are looking for: it is Infohub's debounce for event triggers.
Real plant signals bounce. A line that momentarily dips below its running speed during normal operation will, without a hold time, generate a stoppage event every few minutes. A hundred spurious two-second stoppages a day drown the genuine ones and make a Pareto chart useless.
Set it to just below the shortest occurrence you actually care about. If stoppages under thirty seconds are not worth recording, a hold of twenty-five seconds removes an enormous amount of noise and loses nothing you wanted.
Tune this against real data, not in theory. Run the scheme forward for a day with a modest hold time and count the events. If there are far more than the plant believes happened, increase it. This one property is the difference between a downtime analysis people trust and one they ignore.
Deadband does a similar job on the value axis rather than the time axis, ignoring fluctuation too small to be meaningful. The two are complementary.
Query-based triggers#
SQL connectors let a trigger be a query — how a production order in an MES table becomes an event in Infohub. The Query Period property controls the window the query examines.
There is one rule that catches almost everyone.
A trigger query must return absolute timestamps inside the window. Infohub examines a window of time and asks the query what happened in it. The query must return full absolute timestamps — date and time — that fall within that window.
A query returning a time of day (06:00) with no date will not match. Neither will one returning a date with no time where a time is expected. The query returns nothing usable, no events are created, and there is no error to read — it simply looks as though nothing happened.
If a query-based trigger produces no events, run the query manually with a real window substituted and look at the timestamps it returns before investigating anything else.
The other point worth stating: a trigger query returns the moments events start or end, not the periods they cover. You are not returning a row per production run with a start and an end; you are returning the transition points. Two triggers, one for starts and one for ends, each returning timestamps.
Use [PeriodStart] and [PeriodEnd] to bound the query, with a half-open range, exactly as for a retrieved measure. See SQL Databases.
Late data and the refresh offset#
Triggers only see what the source has when they run. Plant data arrives late — a state change logged a little after the fact, a production order confirmed the next morning.
The scheme's Refresh Offset is what handles this, by re-examining a window of recent time on each pass. If events appear correctly but only after being wrong for a while, or if manually confirmed events are never picked up, the offset is too small. See Designing an Event Scheme.
Getting a trigger right#
The approach that saves time:
- Chart the trigger tag first. Look at how it actually behaves over a few days — how often it changes, whether it bounces, what values it takes. Configuring a trigger without looking at the signal is guessing.
- Write the rule as a sentence. "A stoppage starts when the state tag leaves 20 for more than 25 seconds."
- Configure the start trigger only and let it run forward.
- Count the events against what the plant says happened. Adjust the hold time.
- Add the end trigger. Confirm events close.
- Check durations. For a state-based scheme, do the durations across a day add up to roughly a day?
- Only then backfill, and only a bounded range.
Diagnosing#
| Symptom | Cause |
|---|---|
| Far too many short events | No hold time, or too short — set For Period |
| Events never close, durations grow forever | End trigger not firing; check its condition |
| No events at all from a query trigger | Query returning relative or partial timestamps, not absolute ones inside the window |
| No events at all from a tag trigger | Condition never met; chart the tag and check the comparator and value |
| Duplicate or overlapping events | Start firing repeatedly; use a transition type rather than a state |
| Events appear then get corrected | Late data — increase Refresh Offset |
| Manually confirmed events never captured | Refresh Offset far too small for human timescales |
| Durations sum to much more than the day | Overlapping events; the start and end conditions are not mutually exclusive |
| Durations sum to much less than the day | Gaps — some transitions are being missed, often to a hold time set too long |
| Events correct going forward, wrong historically | Trigger fixed after backfill; clear and rebuild the affected range |