Skip to main content

Cloud and IoT

A cloud or IoT destination is generally not located in the same network segment as the OPC Router. Two characteristics therefore determine the engineering configuration: Each acknowledgment takes a full network round-trip time, and the connection may be temporarily lost. The following rules apply to the MQTT plug-in, for which measurement series are provided in the manual.

Select a QoS level that is only as high as necessary​

The Quality of Service (QoS) level determines how many acknowledgment steps a message goes through between the client and the broker: QoS 0—none; QoS 1—one; QoS 2—a four-step handshake ( MQTT Performance ). This results in a measurable loss of throughput: With 100 parallel transfer flows and no connection pool, QoS 1 was about 11% and QoS 2 about 37% lower than QoS 0 ( MQTT Publish Benchmark ).

The loss increases with distance, because each acknowledgment round requires a full round-trip time; the measurement series was run with a local broker. Therefore, choose:

  • QoS 0 for values that are continuously redelivered and for which a single failure has no consequences—such as cyclic telemetry.
  • QoS 1 as the default if every value must be received and a possible duplication at the destination is tolerable.
  • QoS 2 only if duplication must be technically ruled out.

You can set the default value for a connection in the “” plug-in configuration under “.”

Connection Pool for Many Parallel Flows​

Up to about 10 concurrently transmitting flows, throughput increases linearly—each flow contributed approximately 64 messages per second in the measurement series. Beyond that, the rate per flow decreases: to 53 messages per second with 50 flows, and to 42 messages per second with 100 flows. ’s connection pool () recovers some of this loss; with a minimum of 10 and a maximum of 100, throughput increased by about 13% with 50 flows and by about 31% with 100 flows (MQTT Publish Benchmark).

So enable the pool as soon as significantly more than ten flows are sending to the same connection simultaneously. Recommended Min/Max values for each load range are listed at MQTT Performance .

note

The test series was run using a local broker in a Windows Sandbox with 4 GB of RAM and a 100-byte payload. The figures show the relative performance of the different configurations, not the performance limit of the OPC router.

To ensure that the connections in the pool are assigned different client IDs, enter one of the placeholders listed in the plug-in configuration at into the Client ID field.

Bridging Failures Instead of Losing Values​

If the destination goes down, every value generated during that time will be lost without a temporary storage mechanism. Store and Forward buffers the affected transfers and resends them as soon as the plug-in exits the error state. Please note:

  • Store and Forward must be enabled globally and additionally in the respective flow.
  • Retroactively transmitted and current values do not necessarily arrive in their original order. Therefore, include a value or recording timestamp in every message.
  • If only the current value matters—for example, in a visualization—do not enable Store and Forward: It would write outdated values with a delay. Additional reasons for exclusion are listed at When Store and Forward Should Not Be Used.

If you want received MQTT messages to not only trigger a one-time transfer but also remain available for targeted analysis later, enable the MQTT Data Storage feature in the MQTT plug-in and read the storage using the “” MQTT Storage Read Transfer Object .

Avoiding Duplicate Triggers and Backlogs​

  • Message deduplication prevents identical messages from triggering multiple transfers within a time window. Disable this feature if the payload repeats frequently but every message still counts.
  • **Wait for Transfer causes the OPC Router to respond to the broker only after the transfer is complete. This prevents backlogs but ties reception to the flow’s runtime.
  • Flow Control limits the number of concurrent unacknowledged send operations per connection. With remote or slow brokers, a transmission quota that is too small limits throughput, while one that is too large may cause the broker to respond by throttling or terminating the connection.

All three options are described in the plug-in configuration at .

Credentials as a secret​

Cloud connections require credentials, and the same credentials are typically used by multiple connections. Store them as a "" secret : The password fields will then reference this secret, and any change will take effect wherever the secret is used.