
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:
| Aspect | Read Operation | Monitor (Subscription) |
|---|---|---|
| Model | Request-response (pull) | Event-driven (push) |
| Execution | One-time value retrieval | Continuous streaming |
| Lifecycle | Stateless | Stateful subscription |
| Use Case | On-demand data access | Real-time change detection |
When you configure an OPC UA Trigger:
- MaestroHub creates a Subscription on the OPC UA server
- Monitored Items are registered for each configured node
- The server samples nodes at the configured sampling interval
- Value changes are queued and published at the publishing interval
- 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:
- Connection Lost: The system detects the disconnection automatically
- Connection Restored: Subscriptions and monitored items are automatically recreated
- Transparent Recovery: Pipelines continue to receive value changes once the connection is restored—no manual intervention required
What This Means for Your Workflows
| Scenario | Behavior |
|---|---|
| Brief network interruption | Automatic resubscription after reconnection |
| OPC UA server restart | Subscriptions automatically restored when server comes back online |
| Session timeout | New session established with all monitors restored |
| MaestroHub restart | All triggers for enabled pipelines are restored on startup |
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
| Field | Type | Description |
|---|---|---|
| Node Label | String (Required) | Display name for the node on the pipeline canvas |
| Description | String (Optional) | Explains what this trigger initiates |
Parameters
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
| Connection | Connection ID | Yes | - | The OPC UA connection profile to use for subscribing |
| Function | Function ID | Yes | - | The OPC UA Monitor function that defines nodes and subscription settings |
| Enabled | Boolean | No | true | When disabled, the subscription is not created even if the pipeline is enabled |
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
| Setting | Options | Default | Recommendation |
|---|---|---|---|
| Retry on Fail | true / false | false | Keep disabled for triggers—retries don't apply to event-driven nodes |
| Error Handling | Stop Pipeline / Continue | Stop Pipeline | Use "Stop Pipeline" to halt on critical failures |
Documentation Settings
| Setting | Type | Default | Purpose |
|---|---|---|---|
| Notes | Text | Empty | Document the trigger's purpose, expected data formats, or operational context |
| Display Note in Pipeline | Boolean | false | Show 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:
| Field | Expression | Description |
|---|---|---|
| Node Value | $input.payload.value | The current value of the monitored node |
| Node ID | $input.payload.nodeId | Full OPC UA node identifier (e.g., ns=2;i=123) |
| Namespace Index | $input.payload.namespaceIndex | Namespace index of the monitored node |
| Identifier | $input.payload.identifier | Node identifier string (e.g., i=123, s=Temperature) |
| Source Timestamp | $input.payload.sourceTimestamp | When the value was sampled at the source |
| Server Timestamp | $input.payload.serverTimestamp | When the OPC UA server processed the notification |
| Status Code | $input.payload.statusCode | OPC UA status code indicating data quality |
| Connection ID | $input.connectionId | The OPC UA connection profile used |
| Function ID | $input.functionId | The Monitor function that received the notification |
| Trigger Type | $input.type | Always opcua_trigger |
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
| Practice | Rationale |
|---|---|
| Use appropriate Queue Size | Larger queues buffer notifications during network hiccups |
| Set Discard Oldest = true | Ensures you always see the most recent value |
| Keep monitored node count reasonable | Each node adds server-side sampling overhead |
| Group related nodes in one function | Reduces 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
| Scenario | Recommendation |
|---|---|
| High-frequency changes | Increase publishing interval to batch notifications; use larger queue sizes |
| Many monitored nodes | Split across multiple Monitor functions; consider sampling intervals |
| Critical real-time data | Use sampling interval of 0; minimize publishing interval |
| Resource-constrained OPC UA servers | Reduce 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