Skip to main content
Version: 2.0-dev
OPC UA Trigger Node interface

OPC UA trigger node

OPC UA Trigger Node

Overview

The OPC UA Trigger Node automatically initiates MaestroHub pipelines when monitored OPC UA node values change. Unlike the OPC UA Read connector node which reads values within an already-running pipeline, the OPC UA Trigger starts new pipeline executions in response to value changes—enabling fully event-driven automation without polling.


Core Functionality

What It Does

OPC UA Trigger enables real-time, event-driven pipeline execution by:

1. Event-Driven Pipeline Execution Start pipelines automatically when OPC UA node values change, without manual intervention or polling. Perfect for equipment monitoring, alarm processing, and real-time production data flows.

2. Automatic Subscription Management Subscriptions and monitored items are created and cleaned up automatically—no manual OPC UA subscription management required.

3. Value Change Passthrough Incoming value change notifications are passed directly to the pipeline, making them available to all downstream nodes via the $input variable.


How OPC UA Monitoring Works

OPC UA monitoring is fundamentally different from read operations:

AspectRead OperationMonitor (Subscription)
ModelRequest-response (pull)Event-driven (push)
ExecutionOne-time value retrievalContinuous streaming
LifecycleStatelessStateful subscription
Use CaseOn-demand data accessReal-time change detection

When you configure an OPC UA Trigger:

  1. MaestroHub creates a Subscription on the OPC UA server
  2. Monitored Items are registered for each configured node
  3. The server samples nodes at the configured sampling interval
  4. Value changes are queued and published at the publishing interval
  5. Each notification triggers a new pipeline execution

This push-based model is optimized for low-latency, continuous telemetry in industrial environments.


Reconnection Handling

MaestroHub automatically handles connection disruptions to ensure reliable monitoring.

Automatic Recovery

When an OPC UA connection is lost and restored:

  1. Connection Lost: The system detects the disconnection automatically
  2. Connection Restored: Subscriptions and monitored items are automatically recreated
  3. Transparent Recovery: Pipelines continue to receive value changes once the connection is restored—no manual intervention required

What This Means for Your Workflows

ScenarioBehavior
Brief network interruptionAutomatic resubscription after reconnection
OPC UA server restartSubscriptions automatically restored when server comes back online
Session timeoutNew session established with all monitors restored
MaestroHub restartAll triggers for enabled pipelines are restored on startup
Queue Size and Data Loss

To minimize data loss during brief outages, configure your Monitor function with appropriate Queue Size settings. Larger queues buffer more notifications but use more server memory.


Configuration Options

Basic Information

FieldTypeDescription
Node LabelString (Required)Display name for the node on the pipeline canvas
DescriptionString (Optional)Explains what this trigger initiates

Parameters

ParameterTypeRequiredDefaultDescription
ConnectionConnection IDYes-The OPC UA connection profile to use for subscribing
FunctionFunction IDYes-The OPC UA Monitor function that defines nodes and subscription settings
EnabledBooleanNotrueWhen disabled, the subscription is not created even if the pipeline is enabled
Function Requirement

The selected function must be an OPC UA Monitor function type. Read, Write, and Browse functions cannot be used with OPC UA Trigger nodes.


Settings

Basic Settings

SettingOptionsDefaultRecommendation
Retry on Failtrue / falsefalseKeep disabled for triggers—retries don't apply to event-driven nodes
Error HandlingStop Pipeline / ContinueStop PipelineUse "Stop Pipeline" to halt on critical failures

Documentation Settings

SettingTypeDefaultPurpose
NotesTextEmptyDocument the trigger's purpose, expected data formats, or operational context
Display Note in PipelineBooleanfalseShow notes on the pipeline canvas for quick reference

Output Data Structure

When an OPC UA node value change triggers pipeline execution, the following data is available to downstream nodes via the $input variable.

Output Format

{
"type": "opcua_trigger",
"connectionId": "bf29be94-fc0a-4dc4-8e5c-092f1b74eb4b",
"functionId": "aef374c3-aa2b-454e-aabc-5657faac5950",
"enabled": true,
"node_id": "trigger.opcua-1",
"message": "OPC UA trigger provides configuration for event-based triggering",
"payload": {
"value": 23.5,
"nodeId": "ns=2;i=123",
"namespaceIndex": 2,
"identifier": "i=123",
"sourceTimestamp": "2024-01-15T10:30:00.000Z",
"serverTimestamp": "2024-01-15T10:30:00.001Z",
"statusCode": "Good"
}
}

Accessing Value Change Data

In downstream nodes, use the $input variable to access the trigger output:

FieldExpressionDescription
Node Value$input.payload.valueThe current value of the monitored node
Node ID$input.payload.nodeIdFull OPC UA node identifier (e.g., ns=2;i=123)
Namespace Index$input.payload.namespaceIndexNamespace index of the monitored node
Identifier$input.payload.identifierNode identifier string (e.g., i=123, s=Temperature)
Source Timestamp$input.payload.sourceTimestampWhen the value was sampled at the source
Server Timestamp$input.payload.serverTimestampWhen the OPC UA server processed the notification
Status Code$input.payload.statusCodeOPC UA status code indicating data quality
Connection ID$input.connectionIdThe OPC UA connection profile used
Function ID$input.functionIdThe Monitor function that received the notification
Trigger Type$input.typeAlways opcua_trigger
Working with Values

Access the monitored value directly with $input.payload.value. The value type matches the OPC UA node's data type (number, string, boolean, etc.).


Validation Rules

The OPC UA Trigger Node enforces these validation requirements:

Parameter Validation

Connection ID

  • Must be provided and non-empty
  • Must reference a valid OPC UA connection profile
  • Error: "connectionId is required"

Function ID

  • Must be provided and non-empty
  • Must reference a valid OPC UA Monitor function
  • Function must belong to the specified connection
  • Error: "functionId is required"

Enabled Flag

  • Must be a boolean if provided
  • Error: "enabled must be a boolean"

Settings Validation

On Error

  • Must be one of: stopPipeline, continueExecution, retryNode
  • Error: "onError must be a valid error handling option"

Usage Examples

Real-Time Temperature Monitoring

Scenario: Process temperature readings from industrial equipment and trigger alerts when thresholds are exceeded.

Configuration:

  • Label: Equipment Temperature Monitor
  • Connection: Factory OPC UA Server
  • Function: Monitor function subscribing to temperature nodes with 100ms publishing interval
  • Enabled: true

Downstream Processing:

  • Extract temperature from $input.payload.value
  • Compare against threshold limits
  • Send alert if threshold exceeded
  • Store reading in time-series database

Production Counter Tracking

Scenario: Track production counts in real-time for OEE calculations.

Configuration:

  • Label: Production Counter Tracker
  • Connection: PLC OPC UA Server
  • Function: Monitor function for counter nodes with queue size of 50 to capture all increments
  • Enabled: true

Downstream Processing:

  • Extract counter value and timestamp
  • Calculate production rate from consecutive values
  • Update production dashboard
  • Store in historian for shift reports

Alarm Condition Processing

Scenario: React immediately when equipment alarms activate.

Configuration:

  • Label: Equipment Alarm Handler
  • Connection: SCADA OPC UA Server
  • Function: Monitor function for alarm nodes with sampling interval of 0 (fastest)
  • Enabled: true

Downstream Processing:

  • Check alarm state from $input.payload.value
  • Look up alarm details from alarm database
  • Send notification to operators
  • Log alarm event with timestamps for compliance

Multi-Node Quality Monitoring

Scenario: Monitor multiple quality parameters from a single production line.

Configuration:

  • Label: Quality Parameter Monitor
  • Connection: Quality System OPC UA Server
  • Function: Monitor function with nodes for temperature, pressure, flow rate, and vibration
  • Enabled: true

Downstream Processing:

  • Identify which node changed from $input.payload.identifier
  • Route to appropriate quality check logic
  • Update quality dashboard
  • Trigger corrective action if out of spec

Best Practices

Subscription Configuration

  • Configure your Monitor function with appropriate Publishing Interval for your use case (100–1000ms typical)
  • Set Sampling Interval equal to or faster than publishing interval for critical nodes
  • Use Queue Size > 1 for nodes where every change must be captured

Designing for Reliability

PracticeRationale
Use appropriate Queue SizeLarger queues buffer notifications during network hiccups
Set Discard Oldest = trueEnsures you always see the most recent value
Keep monitored node count reasonableEach node adds server-side sampling overhead
Group related nodes in one functionReduces subscription overhead while maintaining logical grouping

Error Handling Strategies

For Critical Workflows:

  • Set On Error to stopPipeline
  • Monitor pipeline execution failures
  • 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

ScenarioRecommendation
High-frequency changesIncrease publishing interval to batch notifications; use larger queue sizes
Many monitored nodesSplit across multiple Monitor functions; consider sampling intervals
Critical real-time dataUse sampling interval of 0; minimize publishing interval
Resource-constrained OPC UA serversReduce number of monitored items; increase sampling intervals

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
  • Document the reason for disabled triggers in the node's Notes field