Subscriber
Subscriber
The Subscriber is a Sequencer block, that can be used to subscribe and receive data from the MQTT (Message Queue Telemetry Transport) network via Sequencer Events.
Subscriber has no MQTT client functionality included in the block. Therefore, to be able to receive MQTT data, Subscriber has to be connected to a MQTTClient first, via the MQTTClient connector, as is shown in the following block diagram:
Subscriber block can be subscribed to only one topic at a time (however, it can be MQTT wildcard topic). Use multiple Subscriber blocks (can be connected to the same MQTTClient) when data from different subscriptions has to be received.
Note: There is a limitation: the Subscriber and the MQTTClient it is connected to must reside inside of the same CDP application.
Subscriber can be connected to MQTTClient also via the MQTTClientRPC router block(s). Routing via one or many MQTTClientRPC blocks can be handy when the Subscriber and the MQTTClient are in different levels of application.
Events
| Name | Input/Ouptut | Description |
|---|---|---|
| Connected | Output | Will be emitted when the MQTTClient has established the connection with the configured broker |
| Disconnected | Output | Will be emitted when the MQTTClient has lost the connection with the configured broker. |
| Subscribe | Input | Initiates a subscription to the MQTT topic specified by Topic argument. In addition, the event can contain QoS argument. Any possible previous subscription sent by the block will be unsubscribed first. Note, that on Disconnected event the subscription will also be lost and have to be re-subscribed after Connected event has been received. |
| Subscribed | Output | Will be emitted when the MQTTClient has successfully subscribed to the Topic indicated in Subscribe event. Will contain all the arguments of the original Subscribe event plus a MessageID argument. |
| SubscribeFailed | Output | Will be emitted when the MQTTClient was not able to subscribe to the Topic indicated in the Subscribe event. Will contain all the arguments of the original Subscribe event plus an Error argument. |
| Received | Output | Will be emitted on every incoming MQTT message on the subscribed topic. Contains all the following arguments, except Error. |
Arguments
| Name | Description |
|---|---|
| Topic | MQTT topic string. In Subscribe events can be MQTT wildcard topic. In Received events is the actual MQTT topic that the sender was using to send the payload. |
| QoS | Quality of service level of broker communication. Possible values are 0 (Deliver at most once), 1 (Deliver at least once) or 2 (Deliver exactly once). |
| Payload | Received MQTT payload |
| ResponseTopic | When filled, indicates a topic that the request publisher expects the response to be published to. Can exist only when MQTTClient ProtocolVersion is set to v5 (or higher) and the broker also supports MQTT v5 (or higher). |
| CorrelationData | When filled, identifies the specific request and should be echoed back by repsonder when it responds to the ResponseTopic. Can exist only when MQTTClient ProtocolVersion is set to v5 (or higher) and the broker also supports MQTT v5 (or higher). |
| MessageID | On successful subscribe (Subscribed event) or on incoming MQTT messages (Received event), contains MQTT message ID of the message. MessageID is available only when QoS > 0. |
| Error | On failure (SubscribeFailed event), contains the error message describing the failure reason |
Properties
| Name | Description |
|---|---|
| PendingCount | Pending Subscribe events - i.e. events with no Subscribed or SubscribeFailed response from MQTTClient |
Note: When you need to receive Payloads, which can contain non-printable or zero characters, you have to set the Command attribute of Received event to any value other than CM_TEXTCOMMAND (`20100_16`), that will instruct the CDP to send the event data out in binary form. Make sure you set the Command attribute to the very same value on the event receiver side. Also, make sure that the argument order is exactly the same on the event receiver side.
Note: When MQTTClient is set to support MQTT version 5 (i.e. MQTTClient ProtocolVersion is set to 5) and the broker also supports MQTT version 5, then MQTTClient can benefit from the MQTT v5 Subscription Identifier feature and internally eliminate the possible duplicate message receiving, in cases when overlapping wildcard topics are subscribed by different Subscribers at the same time.
See also Publisher and MQTTClient.
Get started with CDP Studio today
Let us help you take your great ideas and turn them into the products your customer will love.