Version: 2.0

Ignition trigger node

Ignition Trigger Node

Overview

The Ignition Trigger Node automatically initiates MaestroHub pipelines when tag values change in Inductive Automation's Ignition Gateway. Unlike polling-based approaches, this trigger provides real-time event-driven automation with intelligent debouncing—multiple rapid tag changes within 100ms are aggregated into a single pipeline execution with the latest values for all affected tags.

Core Functionality

What It Does

1. Event-Driven Pipeline Execution Start pipelines automatically when Ignition tag values change, without manual intervention or polling. Perfect for process monitoring, alarm handling, and real-time data flows.

2. Intelligent Debouncing Multiple tag changes within a 100ms window are automatically aggregated into a single event, preventing excessive pipeline executions while ensuring you receive the latest values for all changed tags.

3. Automatic Subscription Management Subscriptions are created and cleaned up automatically—no manual subscription management required. The system handles connection lifecycle, reference counting for shared tags, and resubscription after reconnections.

4. Aggregated Tag Data All tag values that changed during the debounce window are provided in a single values array, making it easy to process multiple related tag changes together.

Debounce Behavior

How Debouncing Works

The Ignition Trigger uses a 100ms fixed debounce window to aggregate rapid tag changes:

First Change: When the first tag value change occurs, a 100ms timer starts
Subsequent Changes: Any additional tag changes within this window update the buffer with the latest values (per tag path)
Timer Expires: After 100ms, the trigger fires once with an array containing the latest values for all tags that changed
Next Window: The process repeats for the next set of changes

Each function has its own independent debounce buffer.

Benefits of Debouncing

Scenario	Without Debouncing	With Debouncing
10 rapid tag changes	10 separate pipeline executions	1 pipeline execution with all 10 tag values
Burst updates	Pipeline overload, potential queueing	Smooth processing with aggregated data
Related tag changes	Process tags individually, lose context	Process all related changes together

Debounce Window

The 100ms debounce window is fixed and cannot be configured. This value provides an optimal balance between responsiveness and aggregation for most industrial automation scenarios.

Reconnection Handling

MaestroHub automatically handles connection disruptions to ensure reliable tag monitoring. Reconnection is managed by the supervisor's ReconnectWorker, with automatic resubscription of all active tags.

Automatic Recovery

When an Ignition connection is lost and restored:

Connection Lost: The system detects the disconnection automatically
Connection Restored: Subscriptions are automatically re-established via resubscribeAll()
Transparent Recovery: Pipelines continue to receive tag 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
Gateway restart	Subscriptions automatically restored when gateway comes back online
MaestroHub restart	All triggers for enabled pipelines are restored on startup

Minimizing Data Loss

While the trigger automatically reconnects, tag changes that occur during the disconnection period may be missed. For critical data, consider implementing a complementary polling mechanism or using Ignition's built-in store-and-forward capabilities.

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 monitors and initiates.

Parameters

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

Parameter	Type	Default	Required	Description
Connection	Connection ID	`""`	Yes	Ignition connection profile. Filtered to Ignition connections only.
Function	Function ID	`""`	Yes	Subscribe function within the connection. Filtered to `subscribe` function types.
Enabled	boolean	`true`	No	Enable/disable the trigger.

Function Requirement

The selected function must be an Ignition Subscribe function type (ignition.subscribe). Read, write, or browse functions cannot be used with Ignition Trigger nodes.

The Subscribe function (configured separately in the Connectors module) defines which tags to monitor:

Setting	Description	Required
Tags	Array of tag paths to subscribe to for real-time updates (e.g., `["[default]Motor1/Speed", "[default]Motor1/Amps"]`)	Yes

Tag paths use Ignition's standard format: [provider]Path/To/Tag. If no provider is specified, the [default] provider is used automatically.

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
Timeout (seconds)	number	Pipeline default	Maximum execution time for this node (1--600). Leave empty for pipeline default.
Retry on Timeout	Pipeline Default / Enabled / Disabled	Pipeline Default	Whether to retry the node if it times out.
Retry on Fail	Pipeline Default / Enabled / Disabled	Pipeline Default	Whether to retry on failure. When Enabled, shows Advanced Retry Configuration.
On Error	Pipeline Default / Stop Pipeline / Continue Execution	Pipeline Default	Behavior when node fails after all retries.

Advanced Retry Configuration (visible when Retry on Fail = Enabled)

Field	Type	Default	Range	Description
Max Attempts	number	3	1--10	Maximum retry attempts.
Initial Delay (ms)	number	1000	100--30,000	Wait before first retry.
Max Delay (ms)	number	120000	1,000--300,000	Upper bound for backoff delay.
Multiplier	number	2.0	1.0--5.0	Exponential backoff multiplier.
Jitter Factor	number	0.1	0--0.5	Random jitter (+-percentage).

Output Data Structure

When Ignition tag changes trigger pipeline execution, the trigger produces a structured output with two top-level keys: _metadata and payload. The payload contains a values array with all tag values that changed during the 100ms debounce window.

Output Format

{
  "_metadata": {
    "connectionId": "bf29be94-fc0a-4dc4-8e5c-092f1b74eb4b",
    "functionId": "aef374c3-aa2b-454e-aabc-5657faac5950",
    "timestamp": 1704067200,
    "protocol": "ignition",
    "eventType": "TAG_CHANGE",
    "tagCount": "2"
  },
  "payload": {
    "values": [
      {
        "path": "[default]Line1/Temperature",
        "value": 78.5,
        "quality": "Good",
        "timestamp": 1704067200123
      },
      {
        "path": "[default]Line1/Pressure",
        "value": 145.2,
        "quality": "Good",
        "timestamp": 1704067200150
      }
    ]
  }
}

`_metadata` Fields

Field	Type	Description
`connectionId`	string	The Ignition connection profile ID.
`functionId`	string	The Subscribe function ID.
`timestamp`	number	Unix timestamp (seconds) when the event was received.
`protocol`	string	Always `"ignition"`.
`eventType`	string	Always `"TAG_CHANGE"`.
`tagCount`	string	Number of tags in the values array (as string).

`payload.values[]` Fields

Each entry in the values array represents one tag that changed:

Field	Type	Description
`path`	string	Full tag path including provider (e.g., `"[default]Line1/Temperature"`).
`value`	any	The current value of the tag. Type depends on the Ignition tag data type.
`quality`	string	Quality indicator (e.g., `"Good"`, `"Bad"`, `"Uncertain"`).
`timestamp`	number	Unix timestamp in milliseconds when the value changed.
`error`	string	(Only present on error) Error message if the tag read failed.

Referencing in Downstream Nodes

Use expressions to access tag data in subsequent nodes:

$trigger.payload.values -- array of all changed tag values
$trigger.payload.values[0].path -- tag path of the first changed tag
$trigger.payload.values[0].value -- value of the first changed tag
$trigger.payload.values[0].quality -- quality string of the first tag
$trigger.payload.values[0].timestamp -- when the first tag changed (Unix ms)
$trigger._metadata.connectionId -- connection profile used
$trigger._metadata.functionId -- subscribe function used
$trigger._metadata.tagCount -- number of tags that changed
$trigger._metadata.protocol -- always "ignition"

Processing Multiple Tags

Use a loop or JavaScript node to iterate through $trigger.payload.values and process each tag change:

$trigger.payload.values.forEach(tag => {
  if (tag.quality === 'Good') {
    // Process good quality tag values
  }
});

Validation Rules

Parameter Validation

Node Label

Must not be empty
Must not consist only of whitespace
Error: "Node name is required"

Connection ID

Must be provided and non-empty
Must reference a valid Ignition connection profile
Error: "Connection is required"

Function ID

Must be provided and non-empty
Must reference a valid Ignition Subscribe function
Function must belong to the specified connection
Error: "Subscribe Function is required"

Enabled Flag

Must be a boolean if provided
Error: "Enabled must be a boolean value"

Usage Examples

Production Line Monitoring

Key configuration

Label: Production Line Monitor
Connection: Plant Floor Ignition Gateway
Function: Subscribe to [default]Line1/Temperature, [default]Line1/Pressure, [default]Line1/Speed
Enabled: true
Settings: retry disabled, on error stop

Downstream usage: Iterate $trigger.payload.values to check each reading against thresholds, use $trigger.payload.values[0].path to identify which parameter changed, and $trigger.payload.values[0].timestamp for precise timing.

Equipment State Change Handler

Key configuration

Label: Equipment State Handler
Connection: Manufacturing Ignition
Function: Subscribe to [default]Equipment/*/State (state tags for all equipment)
Enabled: true
Settings: retry enabled, on error continue

Downstream usage: Extract equipment ID from $trigger.payload.values[0].path, determine state transition from $trigger.payload.values[0].value, and trigger dependent workflows.

Alarm Acknowledgment Workflow

Key configuration

Label: Alarm Ack Processor
Connection: SCADA Ignition Gateway
Function: Subscribe to [default]Alarms/*/Acknowledged (acknowledgment status for all alarms)
Enabled: true
Settings: on error stop

Downstream usage: Filter $trigger.payload.values for tags where value changed to true, extract alarm ID from path, and log to audit database.

Multi-Tag Batch Processing

Key configuration

Label: Batch Recipe Monitor
Connection: Recipe Management Ignition
Function: Subscribe to [default]Recipe/Active/* (all active recipe parameters)
Enabled: true
Settings: retry enabled, on error stop

Downstream usage: The debounce window ensures all related recipe parameter changes arrive in a single $trigger.payload.values array. Validate the complete recipe configuration before applying setpoints.

Best Practices

Connection Health Monitoring

Configure your Ignition connection with appropriate Keep Alive intervals
Enable Auto Reconnect on the connection profile for automatic recovery
Monitor connection status through MaestroHub's connection health dashboard
Test reconnection behavior during maintenance windows

Designing Subscriptions

Practice	Rationale
Group related tags	Leverage debouncing to process related changes together
Use specific tag paths	Reduces unnecessary processing and improves performance
Include the provider prefix	Always use `[default]` or the explicit provider name for clarity
Consider tag update rates	High-frequency tags may benefit from additional filtering
Monitor subscription count	Each subscription consumes gateway resources

Tag Path Conventions

Ignition tag paths follow the format [provider]Path/To/Tag:

Example Path	Description
`[default]Line1/Temperature`	Temperature tag on Line 1 using the default provider
`[default]Equipment/Motor1/Speed`	Motor speed tag in an Equipment folder
`[historian]Archive/DailyAvg`	Tag from the historian provider

If no provider is specified in the Subscribe function, the [default] provider is used automatically.

Working with Debounced Data

Processing the Values Array:

Always check that $trigger.payload.values has entries before processing
Validate tag quality before using values ("Good" indicates reliable data)
Handle missing or null values gracefully
Consider tag timestamps when ordering is important

Performance Considerations:

The debounce window aggregates changes, reducing pipeline executions
Process all tags in the array efficiently to maintain throughput
Avoid heavy processing in tight loops over large tag arrays

Tag Quality Handling

Always check tag quality before processing values:

$trigger.payload.values.forEach(tag => {
  switch(tag.quality) {
    case 'Good':
      // Process reliable data
      break;
    case 'Bad':
      // Log error, skip processing
      break;
    case 'Uncertain':
      // Decide based on use case
      break;
  }
  // Check for errors
  if (tag.error) {
    // Handle tag read error
  }
});

Error Handling Strategies

For Critical Monitoring:

Set On Error to stopPipeline
Implement alerting for stopped pipelines
Monitor pipeline execution failures
Consider backup monitoring mechanisms

For Best-Effort Processing:

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

Enable vs. Disable

Use the trigger's Enabled parameter to temporarily pause monitoring without changing pipeline state
Disable triggers during maintenance windows to prevent unnecessary processing
Document the reason for disabled triggers in the node's Notes field
Re-enable triggers after testing configuration changes

Performance Optimization

Scenario	Recommendation
High-frequency tags	Use specific subscriptions; consider additional filtering in Ignition
Large tag counts	Monitor pipeline execution queue; optimize downstream processing
Multiple triggers on same tags	MaestroHub optimizes with shared subscriptions via reference counting—no action needed
Burst updates	Debouncing handles this automatically; ensure downstream can process arrays efficiently

Troubleshooting

Common Issues

No Pipeline Executions

Verify the trigger is enabled
Check that the pipeline is enabled
Confirm the Ignition connection is active
Verify tags are actually changing values
Check subscription function configuration

Missing Tag Changes

Connection was down during changes (expected behavior)
Tag quality may be Bad (filtered by subscription)
Subscription function may not include the tag path
Check Ignition Gateway subscription status

Too Many Pipeline Executions

Debouncing should prevent this; verify 100ms window is working
Check if multiple triggers are configured for same tags
Review tag update rates in Ignition

Empty Values Array

Subscription may have no matching tags
All tag changes may have Bad quality
Connection issue during debounce window

Tag Errors

Check $trigger.payload.values[0].error for error messages
Verify tag paths exist in Ignition Gateway
Ensure the tag provider is accessible

Overview​

Core Functionality​

What It Does​

Debounce Behavior​

How Debouncing Works​

Benefits of Debouncing​

Reconnection Handling​

Automatic Recovery​

What This Means for Your Workflows​

Configuration Options​

Basic Information​

Parameters​

Subscribe Function Configuration​

Settings​

Output Data Structure​

Output Format​

_metadata Fields​

payload.values[] Fields​

Referencing in Downstream Nodes​

Validation Rules​

Parameter Validation​

Usage Examples​

Production Line Monitoring​

Equipment State Change Handler​

Alarm Acknowledgment Workflow​

Multi-Tag Batch Processing​

Best Practices​

Connection Health Monitoring​

Designing Subscriptions​

Tag Path Conventions​

Working with Debounced Data​

Tag Quality Handling​

Error Handling Strategies​

Enable vs. Disable​

Performance Optimization​

Troubleshooting​

Common Issues​

Overview

Core Functionality

What It Does

Debounce Behavior

How Debouncing Works

Benefits of Debouncing

Reconnection Handling

Automatic Recovery

What This Means for Your Workflows

Configuration Options

Basic Information

Parameters

Subscribe Function Configuration

Settings

Output Data Structure

Output Format

`_metadata` Fields

`payload.values[]` Fields

Referencing in Downstream Nodes

Validation Rules

Parameter Validation

Usage Examples

Production Line Monitoring

Equipment State Change Handler

Alarm Acknowledgment Workflow

Multi-Tag Batch Processing

Best Practices

Connection Health Monitoring

Designing Subscriptions

Tag Path Conventions

Working with Debounced Data

Tag Quality Handling

Error Handling Strategies

Enable vs. Disable

Performance Optimization

Troubleshooting

Common Issues