MQTT-Subscribe (Trigger)

MQTT-Subscribe is the MQTT trigger used to monitor configured topics. When MQTT messages are received, it triggers the subsequent transfer. The content of the received message is then available to the connection for further processing.

In the properties dialog, you specify which broker connection is used for the subscription and how received messages are interpreted:

warning

If topics are subscribed to multiple times via MQTT Subscribe across different connections, this may result in duplicate triggers for the individual connections.

This also applies to the use of wildcards.

The individual properties are:

Property	Description
Broker Connection	Select the configured MQTT broker connection through which the topic is to be subscribed to.
Topic	Name of the topic to be monitored. Depending on the broker, topic patterns with wildcards may also be used. Clicking Start Browsing allows you to initiate a topic selection based on the current broker connection.
Quality of Service	Sets the Quality of Service value for the subscription. 0 processes messages without additional confirmation, 1 with a simple acknowledgment, and 2 with full delivery assurance. Selecting Use Plug-in Setting applies the default value stored in the MQTT plug-in.
Wait for Transfer	Specifies whether the trigger waits for the subsequent transfer to complete before the message is considered processed internally.
Payload Data Type	Specifies whether the received payload is passed to the connection as a byte array or as a string.
Payload Encoding	Specifies the character encoding used to interpret string payloads.
Null Values	Specifies how received null values are handled. In the screenshot, Prohibit Null Values is selected as an example.

note

Not all properties are always available in the General tab. Which additional options are displayed depends on the selected MQTT profile for the chosen broker connection.

Property	Description
Enable Response Topic and Correlation Data Output	Enables additional MQTT-5 information for the response topic and correlation data in the trigger output. This option is relevant if incoming messages are to be processed according to the request-response pattern and the associated MQTT v5 information is to be reused in the connection.

---

Shared Subscriptions (MQTT v5)

MQTT Version 5 required

Shared subscriptions are a feature of MQTT Version 5 and require support from both the broker and the client.

With Shared Subscriptions, multiple clients can join a shared consumer group and distribute incoming messages evenly among themselves. This enables horizontal scaling on the recipient side.

Topic Format

$shared/[groupName]/[topic]

Example:

$shared/inrayTest/SharedSubscriptionTest

Behavior

• Messages are distributed according to the round-robin principle or, depending on the broker, via “fair dispatch.” The goal is to distribute the load as evenly as possible among the clients within a group.
• Each published data record is delivered exactly once to a subscriber of the shared group (taking the respective QoS level into account).
• Clients with different groupNames receive messages independently of one another—each group operates in isolation.

Prerequisites

• Support for MQTT Version 5 by both the broker and the client.
• All participating clients must connect to the identical shared subscription topic (including the same groupName) to be part of the same consumer group.

QoS Behavior

Aspect	Description
QoS Support	QoS continues to be applied as usual (0, 1, or 2).
Impact on Distribution	The shared subscription affects only distribution, not the delivery guarantee.
Retry Attempts	If QoS > 0, depending on the broker implementation, delivery attempts may be retried if a client does not acknowledge.

Limitations and Special Features

Aspect	Description
Message Order	The order is not guaranteed, as different clients process messages.
Stateful Processing	If states or order are relevant, they must be managed externally.
Broker Dependency	The exact behavior (e.g., distribution strategy) may vary depending on the MQTT broker.

Example

Publisher sends to:

SharedSubscriptionTest

Subscribers use:

$shared/inrayTest/SharedSubscriptionTest

With three active clients in the inrayTest group, incoming messages are distributed, e.g.:

Message	Delivered to
Message 1	Client A
Message 2	Client B
Message 3	Client C
Message 4	Client C

---

MQTT 5 User Properties

The MQTT 5 User Properties tab is used to make MQTT 5 user properties from received messages available in the connection.

MQTT 5 user properties are freely definable key-value pairs that are transmitted in addition to the actual payload. They therefore do not contain payload data in the strict sense, but rather supplementary metadata about the message.

Typical use cases include:

• Identifying the origin of a message, for example, Source=Plant 3
• Providing additional technical information, for example, MessageType=Alarm or Area=Filling
• Providing additional technical details, for example SchemaVersion=1.0
• Evaluation in subsequent transfers or target systems that specifically take MQTT-5 user properties into account

Use this tab only if the receiving or downstream processing system actually requires MQTT-5 user properties. If this metadata plays no role in your workflow, the tab can remain unused.

note

As with the MQTT transfer object, MQTT-5 user properties do not replace the actual message content. Content that requires business-specific processing should continue to be transmitted in the payload or within a clear topic structure.