IoT MQTT Service

The function blocks included in this library communicate via MQTT protocol with a MQTT broker. A secured connection (SSL/TLS) to the broker is built by the client. The necessary parameters are defined in the device configuration. The objects are communicated as secured json strings.

Available Function Blocks

Publish topics

Function block Publish topics

Subscribe topics

Function block Subscribe topics

MQTT client state

Function block Status MQTT Client

Elements and functionality of the MQTT protocol

Client:

MQTT clients can be different devices or applications, which are able to send and receive MQTT messages. These clients are not interconnected, as they communicate over a broker with each other. Examples of such client devices are sensors, controllers, smartphones and other devices, which can run a MQTT library. In general, clients can be publisher and subscriber at the same time.

Broker:

The broker is a central server, which receives the sent message of the publisher and forwards it to all receivers (subscribers) that have a subscription for this topic.

Example: If the broker receives a message with a temperature value from a temperature sensor in a building, it publishes the message to all receivers that subscribed to the topic with the temperature value

Message:

The message contains the topic and the actual user data, and is sent from the publisher via broker to the subscriber.

Publish:

Describes the sending of a message by a client, triggered by a certain event.

Subscribe:

Describes the registration for the receiving of messages, which contain a certain topic.

NOTE: In general, the MQTT protocol allows the usage of wildcards (# und +) for the subscription of topics. However, the described function blocks in this document do NOT support this feature.

Topic:

The topic is a text that represents a hierarchy, using a slash (/) as a separator. It stands for the subject of the message: Normally the structure looks like that:

>heater/office/upstairs/temperaturesensor/1<

Quality of Service

QoS contains 3 Levels.

  • QoS 0 guarantees that the message is delivered at most once, or it is not delivered at all. The sender does not care about the message after broadcasting (fire and forget).
  • QoS 1 guarantees that the message is always delivered at least once. If the sender does not receive an acknowledgment, the message can be sent multiple times.
  • QoS 2 guarantees that the message is always delivered exactly once and no messages are lost. This is ensured by a two-step confirmation with additional messages.

 

If events cannot be published (interrupted connection), they are buffered. That is accomplished by following two steps:

  • If the connection is re-established during the defined “keepAlive” cycle, the events which were kept in the memory are published as quickly as possible.
  • If the connection is interrupted longer than with the defined period of the “keepAlive” cycle, the events are buffered in a database. If the connection is established again, the content of the database is published as quickly as possible.