Version: 3.0 (next)

IEC 104 Trigger Node

Overview

The IEC 104 Trigger Node automatically initiates MaestroHub pipelines whenever an IEC 60870-5-104 outstation (an RTU, a protection relay or a gateway) reports a point. Unlike the IEC 104 Read Points node, which returns the latest known values inside an already-running pipeline, the IEC 104 Trigger starts a new pipeline execution for each reported point — enabling fully event-driven automation without polling.

An IEC 104 outstation pushes its data: a point arrives when its value changes (spontaneous), on a fixed cycle (periodic), or in answer to an interrogation. Each point carries its value, its IEC quality flags, its cause of transmission and, for the time-tagged types, the device's own timestamp.

Core Functionality

What It Does

1. Event-Driven Pipeline Execution Start pipelines automatically whenever the outstation reports a point that matches the Monitor Points function. Latency is set by the outstation, not by any polling interval.

2. Address Filtering The underlying Monitor Points function chooses which information object addresses (IOAs) fire the trigger — single addresses and ranges such as 1001, 2000-2999, or every point — and whether interrogation responses fire it too. See Monitor Points.

3. Automatic Subscription Lifecycle The subscription is created when the pipeline becomes enabled and removed when it's disabled. A Monitor Points subscription is a filter over the points the outstation pushes and asks nothing of the outstation, so it keeps delivering across every reconnect without being re-established.

4. No Deduplication Every point carries the time MaestroHub received it (and, for time-tagged types, the device's time), so two reports of the same value are two distinct events. Each one starts a run.

How IEC 104 Triggering Works

IEC 104 triggering is fundamentally different from on-demand reads:

Aspect	Read Points / Interrogate	Monitor Points (Trigger)
Model	Request-response (pull)	Event-driven (push)
Execution	One read or interrogation per call	Continuous streaming on each reported point
Lifecycle	Stateless	Address filter held by the connection
Use Case	On-demand data access, snapshots	Real-time change detection, telemetry, events

When you configure an IEC 104 Trigger:

MaestroHub registers the Monitor Points function's address filter on the connection.
The outstation reports a point: a spontaneous change, a periodic value, or an interrogation response (station, group or counter).
If the point's IOA matches the filter — and, for an interrogation response, Include Interrogation Responses is on — one trigger event is emitted.
The pipeline executes with the point available as $trigger.

Interrogation responses

With Include Interrogation Responses on (the default), the station interrogation MaestroHub runs on every connect fires the trigger once for every matching point, so a pipeline sees the full current state after each reconnect. Turn it off to fire only on spontaneous and periodic reports — for example, when the pipeline raises an alert per breaker change.

Reconnection Handling

MaestroHub automatically handles link disruptions to ensure reliable monitoring.

Automatic Recovery

When the link to the outstation is lost and restored:

Connection Lost: The link is closed when a sent frame or test frame is not acknowledged within t1, or when the TCP (or TLS) connection drops. The trigger fires once per outage with quality bad and the cause under error (see Output Data Structure).
Connection Restored: A new session starts with an empty process image and runs the on-connect requests — clock synchronisation, station interrogation and counter interrogation, each as configured on the connection.
Transparent Recovery: The address filter stays registered, so pipelines receive points again as soon as the outstation reports them — no manual intervention required.

What This Means for Your Workflows

Scenario	Behavior
Transient network error	One `bad` event for the outage; points flow again after the reconnect
Outstation restart	The outstation reports end of initialisation; MaestroHub repeats the station interrogation
Edited Monitor Points function	Re-subscribing replaces the filter, so the new addresses take effect
MaestroHub restart	All triggers for enabled pipelines are restored on startup

Minimising data loss

Spontaneous reports the outstation sends while the link is down are not received. With Interrogate on Connect and Include Interrogation Responses on, the station interrogation after the reconnect delivers every point's current value, so the pipeline catches up on state — but not on the intermediate changes. For counters, keep Counter Interrogation on Connect on, or schedule a counter Interrogate node with a Schedule trigger.

Configuration Options

Basic Information

Field	Type	Description
Node Label	String (Required)	Display name for the node on the pipeline canvas. Must be non-empty (trimmed).
Description	String (Optional)	Explains what this trigger initiates.

Configuration

The trigger configuration is organized across two tabs in the UI: Parameters and Settings.

Parameter	Type	Default	Required	Description
Connection	Connection ID	`""`	Yes	The IEC 104 connection profile to receive points from. Filtered to IEC 104 connections only.
Monitor Points Function	Function ID	`""`	Yes	The function that defines which points fire the trigger. Filtered to `iec104.monitor` function types on the selected connection.
Enabled	Boolean	`true`	No	When disabled, the subscription is not created even if the pipeline is enabled.

Function Requirement

The selected function must be a Monitor Points function type (iec104.monitor). Read Points, Interrogate, Send Command, and Synchronise Clock functions cannot be used with IEC 104 Trigger nodes.

If the selected connection has no Monitor Points functions yet, the node configuration panel surfaces a link straight to the connection so you can author one.

Monitor Points Function Configuration

The selected function (authored in the Connect module) controls which points fire the trigger:

Setting	Description
Information Object Addresses	Addresses and ranges to watch, e.g. `1001, 2000-2999`. Empty = every point.
Include Interrogation Responses	On (default): points that arrive as interrogation responses also fire the trigger. Off: only spontaneous and periodic changes do.

See Monitor Points for the full function reference.

Sample Payload

The Parameters tab also holds a Sample Payload editor and a Sample Quality picker. When you run the node with Test Node in Sandbox mode, the trigger emits the sample payload as result instead of waiting for a real point, so you can validate downstream nodes before an outstation is wired up. When the editor is empty, a built-in sample point is used. Sample Quality sets the quality the sample reports in $trigger._metadata.quality, so a quality-aware pipeline can be tested with a good, uncertain or bad sample. The live subscription and the node's Fire Trigger action do not use the sample.

{
  "commonAddress": 1,
  "ioa": 1001,
  "type": "M_DP_TB_1",
  "value": 2,
  "detail": { "state": "on" },
  "quality": "good",
  "flags": { "invalid": false, "notTopical": false, "substituted": false, "blocked": false, "overflow": false, "timeInvalid": false },
  "cause": "spontaneous",
  "sourceTimestamp": "2026-09-30T10:14:03.221Z",
  "serverTimestamp": "2026-09-30T10:14:03.240Z"
}

Settings

Description

A free-text area for documenting the node's purpose and behavior. Notes entered here are saved with the pipeline and visible to all team members.

Execution Settings

Setting	Options	Default	Description
On Error	Pipeline Default / Stop Pipeline / Continue Execution	Pipeline Default	Behavior when the node fails.

Output Data Structure

When the outstation reports a point and triggers pipeline execution, the trigger produces a structured output with two top-level keys: _metadata and result. One event is emitted per reported point.

Output Format

{
  "_metadata": {
    "type": "iec104_trigger",
    "protocol": "iec104",
    "connectionId": "bf29be94-fc0a-4dc4-8e5c-092f1b74eb4b",
    "functionId": "aef374c3-aa2b-454e-aabc-5657faac5950",
    "commonAddress": "1",
    "ioa": "1001",
    "typeId": "M_DP_TB_1",
    "cause": "spontaneous",
    "sourceTimestamp": "2026-09-30T10:14:03.221Z",
    "serverTimestamp": "2026-09-30T10:14:03.240Z",
    "quality": "good",
    "timestamp": "2026-09-30T10:14:03.240123456Z"
  },
  "result": {
    "commonAddress": 1,
    "ioa": 1001,
    "type": "M_DP_TB_1",
    "value": 2,
    "detail": { "state": "on" },
    "quality": "good",
    "flags": { "invalid": false, "notTopical": false, "substituted": false, "blocked": false, "overflow": false, "timeInvalid": false },
    "cause": "spontaneous",
    "sourceTimestamp": "2026-09-30T10:14:03.221Z",
    "serverTimestamp": "2026-09-30T10:14:03.240Z"
  }
}

`result` Fields

Every point has the same top-level keys, whatever its type; what only some types carry sits in detail.

Field	Type	Description
`commonAddress`	number	The station address the point was reported under.
`ioa`	number	The point's information object address (0–16,777,215).
`type`	string	The IEC type identifier, e.g. `M_DP_TB_1`, `M_ME_NC_1`.
`value`	any	The value, written by type — see value by type.
`detail`	object	What only some types carry: `state` (double point), `transient` (step position), `counterSequence`, `carry` and `adjusted` (integrated totals). Empty for the other types.
`quality`	string	The platform's band: `bad` when the device marked the value invalid; `uncertain` when it is blocked, substituted, not topical, has overflowed, or is a counter with carry or adjustment; otherwise `good`.
`flags`	object	The individual IEC quality flags: `invalid`, `notTopical`, `substituted`, `blocked`, `overflow`, and `timeInvalid` (the device sent a time tag and marked it invalid).
`cause`	string	The cause of transmission, e.g. `spontaneous`, `periodic`, `interrogated by station`.
`sourceTimestamp`	string \| null	The device's own timestamp, in UTC. `null` for types that carry none, and when the device marked its time tag invalid (then `flags.timeInvalid` is `true`).
`serverTimestamp`	string	When MaestroHub received the point, UTC.

Value by Type

Types	`value`
Single point (`M_SP_*`)	`true` / `false`
Double point (`M_DP_*`)	`0`–`3`; `detail.state` is `intermediate`, `off`, `on` or `faulty`
Step position (`M_ST_*`)	`-64`–`63`; `detail.transient`
Bitstring (`M_BO_*`)	32-bit unsigned number
Normalized (`M_ME_NA_1`, `M_ME_TD_1`, `M_ME_ND_1`)	`-1.0` to just under `1.0`
Scaled (`M_ME_NB_1`, `M_ME_TE_1`)	whole number, `-32768`–`32767`
Short float (`M_ME_NC_1`, `M_ME_TF_1`)	number
Integrated totals (`M_IT_*`)	whole number; `detail.counterSequence`, `detail.carry`, `detail.adjusted`

Types the connector does not decode (for example protection events, types 38–40) are skipped and never fire the trigger. The connection log names each such type once.

`_metadata` Fields

Every _metadata value is a string, including the numeric ones.

Field	Type	Description
`type`	string	Always `"iec104_trigger"`.
`protocol`	string	Always `"iec104"`.
`connectionId`	string	The IEC 104 connection profile ID.
`functionId`	string	The Monitor Points function ID.
`commonAddress`	string	The station address, as a string (`"1"`).
`ioa`	string	The information object address, as a string (`"1001"`).
`typeId`	string	The IEC type identifier, e.g. `M_DP_TB_1`.
`cause`	string	The cause of transmission.
`sourceTimestamp`	string	ISO 8601 / RFC 3339, UTC — the device's own timestamp. Present only when the outstation sent a valid time tag (the time-tagged types).
`serverTimestamp`	string	ISO 8601 / RFC 3339, UTC — when MaestroHub received the point.
`quality`	string	The point's band: `good`, `uncertain` or `bad`, as in `result.quality`. `bad` also on a failure event: once per outage, when the link to the outstation is lost, the trigger fires with `quality: "bad"` and the cause under `error`. Its `result` is the last point this trigger delivered (an empty object if none had arrived yet), and it has no `sourceTimestamp`: the device said nothing at that moment. The next reported point carries its own band again. A UNS Publish node downstream inherits the verdict.
`quality_reason`	string	Only on a failure event: `comm_error`. A UNS Publish node downstream forwards it, so the stored sample reads `bad · comm_error` rather than just `bad`.
`error`	string	Only on a failure event: why the link was lost.
`timestamp`	string	ISO 8601 / RFC 3339 (nanoseconds) — when the trigger event was created, UTC.

Referencing in Downstream Nodes

Use expressions to access trigger data in subsequent nodes:

$trigger.result.value — the point's value
$trigger.result.quality — good, uncertain or bad
$trigger.result.ioa — the information object address, as a number
$trigger.result.type — the IEC type identifier
$trigger.result.detail — type-specific detail (e.g. the double-point state)
$trigger.result.flags — the individual IEC quality flags
$trigger.result.cause — why the outstation sent it
$trigger.result.sourceTimestamp — the device's timestamp, or null
$trigger.result.serverTimestamp — when MaestroHub received it
$trigger.result.commonAddress — the station address
$trigger._metadata.ioa — the address as a string, handy for routing on a topic path
$trigger._metadata.quality — the band, including the once-per-outage bad failure event
$trigger._metadata.connectionId — connection profile used
$trigger._metadata.functionId — Monitor Points function used

Validation Rules

Parameter Validation

Node Label

Must not be empty
Must not consist only of whitespace

Connection ID

Must be provided and non-empty
Must reference a valid IEC 104 connection profile

Function ID

Must be provided and non-empty
Must reference a valid Monitor Points (iec104.monitor) function
Function must belong to the specified connection

Enabled Flag

Must be a boolean if provided

Usage Examples

Breaker Position Monitoring

Key configuration

Label: Feeder Breaker Monitor
Connection: Substation North RTU
Function: Monitor Points on 1001-1004, Include Interrogation Responses off
Enabled: true
Settings: on error stop

Downstream usage: $trigger.result.detail carries the double-point state (on, off, intermediate, faulty), $trigger.result.sourceTimestamp the device's time of the change. With interrogation responses off, the pipeline fires only on real transitions — one alert per breaker operation.

Measured Values to the UNS

Key configuration

Label: Feeder Measurements
Connection: Substation North RTU
Function: Monitor Points on 2000-2999, Include Interrogation Responses on
Enabled: true
Settings: on error continue

Downstream usage: $trigger.result.value for the reading, $trigger._metadata.ioa to build the topic path, $trigger.result.quality for the quality band. With interrogation responses on, the station interrogation after every reconnect refreshes every topic.

Energy Counter Tracking

Key configuration

Label: Energy Counters
Connection: Solar Park Gateway
Function: Monitor Points on the integrated-total addresses
Enabled: true

Downstream usage: $trigger.result.value for the counter reading, $trigger.result.detail for counterSequence, carry and adjusted. A counter with carry or adjustment arrives with $trigger.result.quality uncertain.

Best Practices

Subscription Design

Filter by address. An empty address list fires the trigger for every point the outstation reports; a large RTU can report thousands. Watch only the ranges the pipeline needs, and split unrelated ranges into separate Monitor Points functions.
Decide on interrogation responses per pipeline. Keep them on when the pipeline mirrors state (UNS, historian) so it resynchronises after each reconnect; turn them off when the pipeline reacts to changes (alerts, event logs) so a reconnect does not replay every point as an event.
Match the Device Time Zone on the connection to the outstation's clock, so sourceTimestamp is correct in UTC.

Designing for Reliability

Practice	Rationale
Check `quality` before acting on a value	`bad` means the device marked the value invalid, or the link was lost (the failure event)
Keep Interrogate on Connect on	The station interrogation after a reconnect restores the current state of every point
Use a scheduled Interrogate for counters	Counter values are not reported spontaneously by every outstation
Buffer downstream for bursty outstations	An interrogation delivers every matching point at once

Error Handling Strategies

For Critical Workflows:

Set On Error to stopPipeline
Monitor pipeline execution failures via the Health dashboard
Implement alerting for stopped pipelines

For Best-Effort Processing:

Set On Error to continueExecution
Log failed executions for later analysis
Ensure downstream nodes handle partial failures gracefully

Performance Considerations

Scenario	Recommendation
Large outstations	Filter by address; an unfiltered trigger with interrogation responses on starts one run per point after every reconnect
Periodic interrogation	A short Periodic Interrogation interval with interrogation responses on starts one run per matching point on every cycle — set it no shorter than you need
Many monitored ranges	Group related ranges in one Monitor Points function; spread unrelated ones across functions and pipelines

Enable vs. Disable

Use the trigger's Enabled parameter to temporarily pause monitoring without changing pipeline state
Disable triggers during maintenance windows to prevent processing the interrogation burst that follows a reconnect
Document the reason for disabled triggers in the node's Description field

Overview​

Core Functionality​

What It Does​

How IEC 104 Triggering Works​

Reconnection Handling​

Automatic Recovery​

What This Means for Your Workflows​

Configuration Options​

Basic Information​

Configuration​

Monitor Points Function Configuration​

Sample Payload​

Settings​

Output Data Structure​

Output Format​

result Fields​

Value by Type​

_metadata Fields​

Referencing in Downstream Nodes​

Validation Rules​

Parameter Validation​

Usage Examples​

Breaker Position Monitoring​

Measured Values to the UNS​

Energy Counter Tracking​

Best Practices​

Subscription Design​

Designing for Reliability​

Error Handling Strategies​

Performance Considerations​

Enable vs. Disable​

Overview

Core Functionality

What It Does

How IEC 104 Triggering Works

Reconnection Handling

Automatic Recovery

What This Means for Your Workflows

Configuration Options

Basic Information

Configuration

Monitor Points Function Configuration

Sample Payload

Settings

Output Data Structure

Output Format

`result` Fields

Value by Type

`_metadata` Fields

Referencing in Downstream Nodes

Validation Rules

Parameter Validation

Usage Examples

Breaker Position Monitoring

Measured Values to the UNS

Energy Counter Tracking

Best Practices

Subscription Design

Designing for Reliability

Error Handling Strategies

Performance Considerations

Enable vs. Disable