Six trigger types
Scheduled trigger (PERIOD)
A system-time-based periodic trigger. It uses the system time at midnight on the day the stream was created as the baseline and drives computation at fixed intervals.
This trigger suits scenarios requiring high time precision and relatively uniform data arrival. Typical use cases include hourly device runtime statistics and per-minute production line temperature averages.
CREATE STREAM sm1 PERIOD(1h) INTO tb2 AS SELECT cast(_tlocaltime/1000000 AS TIMESTAMP), count(*) FROM tb1;
In TDengine, the scheduled trigger depends on system time rather than data writes. It executes computation at each cycle even when no new data arrives, which keeps the time series in the output table continuous.
Sliding trigger (INTERVAL SLIDING)
An event-time-based sliding window trigger that drives computation only when new data arrives. It is driven by the event time of incoming data and handles scenarios where data arrival is uneven.
INTERVAL controls the window size. SLIDING controls the step size. When SLIDING is smaller than INTERVAL, windows overlap, which makes sliding averages, rolling statistics, and similar computations possible.
CREATE STREAM sm1 INTERVAL(5m) SLIDING(5m) FROM stb1 PARTITION BY tbname INTO stb2 AS SELECT _twstart, avg(col1) FROM %%tbname WHERE _c0 >= _twstart AND _c0 <= _twend;
In TDengine-based industrial data platforms, the sliding trigger is commonly used for rolling statistics on equipment metrics.
Session window trigger (SESSION)
A window that divides data based on activity gaps. It adaptively partitions time-series data according to its activity level. When the interval between data writes exceeds the configured session timeout, the current window closes.
This trigger fits user behavior analysis and equipment operation cycle identification, where activity durations are unpredictable but clear gaps separate distinct activities.
State window trigger (STATE_WINDOW)
A trigger driven by value changes in a specified field. It switches windows when the field value changes, such as recording parameters when equipment alternates between “running” and “stopped.” This trigger fits equipment condition monitoring.
Event window trigger (EVENT_WINDOW)
Window boundaries are defined by specified start and end conditions. The TRUE_FOR parameter requires the start or end condition to persist for a specified duration, which filters out transient fluctuations.
CREATE STREAM ana_temp EVENT_WINDOW(start with 环境温度 > 80 end with 环境温度 <= 80) TRUE_FOR(10m) FROM vt_气象传感器02_471544 INTO ana_temp AS SELECT _twstart+0s as output_timestamp, avg(环境温度) as 平均环境温度 FROM vt_气象传感器02_471544 where ts >= _twstart and ts <= _twend;
When the ambient temperature exceeds 80 degrees C and stays above it for at least 10 minutes, the window opens. When the temperature drops to 80 degrees C or below, the window closes and the average temperature for that interval is computed. In alerting, this approach filters out transient noise.
Count window trigger (COUNT_WINDOW)
Fires when the number of data rows reaches a configured threshold. It supports a column-based trigger mechanism.
CREATE STREAM sm1 COUNT_WINDOW(1) FROM tb1 INTO tb3 AS SELECT _twstart, avg(col1) FROM tb2 WHERE _c0 >= _twend - 5m AND _c0 <= _twend;
This trigger fits low-frequency data collection, where each data point should be processed as soon as it arrives.
Three trigger action modes
| Mode | Description |
|---|---|
| Notify only | Results are pushed via WebSocket. Not written to the output table. |
| Compute only | Results are written to the output table. No notification is pushed. |
| Compute and notify | Results are written to the output table and a notification is pushed. |
Choosing the right action mode helps reduce system load. For alert-only scenarios, there is no need to perform redundant table writes.
Trigger tables and partitioning
The number of output tables is proportional to the number of PARTITION BY groups. Each group maintains its own output table, which keeps data isolated between groups. In Industrial IoT (IIoT) deployments, devices are typically used as the partition key, with each device getting an independent output table.
Control options
WATERMARK: Defines the tolerance window for out-of-order data. Late-arriving data is still included in the computation before the window closes. When combined with IGNORE_DISORDER, data that arrives beyond the tolerance window is discarded directly.
EXPIRED_TIME: Specifies how long data remains eligible for processing before it is ignored. This is especially important for edge computing scenarios with limited storage.
FILL_HISTORY: Computes historical data starting from a specified point in time. This prevents a data vacuum when a new stream is created.
LOW_LATENCY_CALC: A low-latency computation mode for scenarios with strict response time requirements.
PRE_FILTER: Filters data before triggering computation, reducing data volume at the source and improving overall throughput.
MAX_DELAY: The maximum wait time before a window is forcibly closed. This prevents a window from being delayed indefinitely while waiting for data.
Recalculation
The system supports automatic recalculation via the WATERMARK mechanism when late data arrives. It also provides a manual recalculation capability for batch reprocessing after data corrections. This mechanism provides eventual consistency throughout the data pipeline.
Summary
The six trigger types cover three categories of scenarios: time-driven, data-driven, and state-driven. Three action modes provide flexible response strategies. Control options keep the system stable in complex environments. Using the TDengine Stream Processing engine, developers can build efficient real-time data processing pipelines through SQL, meeting the real-time and accuracy demands of Industrial IoT and intelligent operations.
