What's New in 5.5

Version 5.5 positions the OPC Router for cloud analytics and AI applications: production data is transferred to the Snowflake AI Data Cloud, JSON structures are described via schemas instead of being manually recreated, MQTT values are also available outside the event, an AI answers questions based on your own data via the Model Context Protocol, and MQTT 5 introduces request/response and distributed recipients. This page describes a typical use case for each new feature, along with the configuration steps, prerequisites, and reference pages. At the end, you’ll find what changes for existing projects .

New Feature	What It’s For
Snowflake Plug-in	Write machine data to the Snowflake AI Data Cloud and retrieve results
Production data for AI via MCP	Grant AI controlled access to your data
JSON Schema	Centrally describe JSON structures, validate, and reuse JSON structures
MQTT Storage	Read the latest value of a topic without waiting for the next event
MQTT 5	Request and response via MQTT; distribute load across multiple recipients

Snowflake plug-in

Use Case: Measurement data from multiple systems should be continuously sent to the Snowflake AI Data Cloud, where it is analyzed; the results of the analysis should be fed back into production.

Here’s how to configure it:

1. In the Plug-ins section, create a Snowflake connection and enter the connection details. All queries and write operations run through a Snowflake Warehouse.
2. Configure the transfer just as you would for any other database connection—the plug-in includes the familiar database transfer objects.
3. For the return path, read the results from Snowflake and write them to their destination: to the system, into a dashboard, or as a trigger for another flow.

Keep an eye on costs: Every read or write operation via the warehouse incurs Snowflake credits—even with Auto Resume / Suspend enabled—as soon as the warehouse is active. For scenarios that only write, the manual describes two more cost-effective methods that do not require an active warehouse:

• via the REST plug-in to a Snowpipe endpoint, which loads the data asynchronously into the target tables;
• via the Cloud File Access plug-in to a cloud stage (e.g., Amazon S3), from which Snowpipe or a copy command retrieves the data—suitable for periodic or buffered writes of large volumes.

Reference: Snowflake AI Data Cloud plug-in · Connection settings

Production Data for AI via MCP

Use Case: An AI is designed to answer questions about production that currently require someone to manually gather data from multiple systems—such as “Which machine is the most productive?”, “Which machines are due for maintenance soon?”, or “At what times of day are the machines least productive?”

Here’s how to set it up: The Model Context Protocol (MCP) is an open standard that allows AI applications to access third-party systems. In OPC Router, you configure access using the REST plug-in: You make the data available as an MCP tool and specify which queries the AI is allowed to execute. You determine which data is included in the response via the underlying flows—the sources can come from any plug-ins and be consolidated into a single response.

Prerequisites and Limitations: You need a REST connection; the data sources must be configured as flows. Access is limited to what you make available—the AI sees only what you provide.

Reference: Provision of production data via MCP · REST plug-in

JSON Schema

Use Case: Multiple flows exchange the same JSON structure with an external system. Previously, this structure had to be manually recreated in each transfer object—with the risk that a field name might differ in some places.

Here’s how to configure it:

1. Create a schema in the JSON Schema plug-in: You can import an existing schema file, generate one from a sample document, or write it in the editor, which checks the structure in real time.
2. Select the storage location. Embedded schemas are stored within the project and are included during export, meaning they are available on another system without the need for separate file exchange.
3. Use the JSON Schema Transfer Object in the flow. It reads, writes, and patches JSON data and validates it against the schema; you can access individual fields using JsonPointer (RFC 6901), such as /equipment/status.
4. Specify whether the transfer object should always use the latest version of the schema or a fixed version—the latter if you want the processing to remain stable.

Prerequisites and Limitations: The included sample schemas, such as OPC UA, Siemens IECTL, or Portainer, are provided for illustrative purposes only; no guarantee is made regarding their completeness or functionality.

Reference: JSON Schema plug-in · JSON Schema transfer object · Validation

MQTT Storage

Use Case: A report is supposed to summarize the current values of several topics at 6 a.m. However, MQTT only delivers data when someone is actively publishing—if no data is being received at the time the report is triggered, no values are available.

Here’s how to configure it:

1. In the MQTT connection, on the Storage tab, enable the Enable MQTT Data Storage option. The OPC Router will then automatically create subscriptions for all entered topics and permanently store the most recently received message for each topic.
2. Drag the MQTT Storage Read transfer object into the flow, select the broker connection, and enter the topic—topic patterns with placeholders are supported.
3. Trigger the flow however you like—for example, with a time trigger. The stored value is available regardless of the last event.

Prerequisites and Limitations: The transfer object cannot be used without the Enable MQTT Data Storage option. Only the most recent message for each topic is stored; older values are overwritten, and no history is created.

Reference: MQTT Storage Read Transfer Object · MQTT Plug-in Configuration

MQTT 5.

Use Case: A device sends a request via MQTT and expects a response—until now, the sender and receiver had to agree on the topics in advance. And if a single receiver can no longer handle the volume of messages for a topic, the load should be distributed across multiple receivers.

Here’s how to configure it:

1. In the broker connection, set the MQTT Version property to v5.
2. For the request and response, use the information that MQTT 5 includes in the message itself: the reply topic, which the sender uses to specify where the reply should go, and the correlation data that the recipient sends back so that each reply can be matched to its corresponding request. Using user properties, you can also attach freely selectable key-value pairs to the message—similar to the headers in an HTTP request, such as sensorType: temperature. This allows the message to carry its metadata without requiring you to modify the payload.
3. To distribute the load, configure a shared subscription on the MQTT trigger: Multiple clients subscribe to the same shared subscription topic within the same consumer group and distribute the incoming messages among themselves.

Prerequisites and Limitations: All of the above require a broker that supports MQTT 5. For shared subscriptions, all participating clients must establish a connection using the identical shared-subscription topic and the same group name; otherwise, they will not form a shared group. The shared subscription affects only the distribution of messages, not the delivery guarantee.

Reference: MQTT plug-in configuration

What’s Changing for Existing Projects

• MQTT Storage is not enabled by default. Only when the Enable MQTT Data Storage option is selected will the OPC Router create subscriptions and store values; before that, the transfer object returns nothing.
• **Snowflake charges for every access. A flow that reads or writes every second keeps the warehouse active. For pure write streams, consider using Snowpipe or a Cloud Stage.
• MQTT 5 depends on the broker. Response topics, correlation data, user properties, and shared subscriptions are only available if the broker connection is set to v5 and the broker supports this version.
• Fixed schema version where stability matters. If a JSON Schema transfer object is set to “latest version,” a new schema version will cause its behavior to change as well.