IIoT connector

Overview

The IIoT Connector is an MQTT client that can establish a connection to an MQTT broker. As soon as the connection is established, the IIoT Connector can publish or subscribe to messages.

Different systems can be connected:

• MQTT broker (e.g. Mosquitto or HiveMQ)

• easyConnect (Weidmüller IIoT cloud platform)

• ResMa® (Weidmüller energy and process data software onPremise)

The IIoT Connector supports MQTT versions v5 and v3.1.1.

Navigation

The IIoT Connector area (1) can be accessed via the start page.

Connector overview

Overview for managing existing connectors and entry point for adding new connectors.

1. Add connector: Entry point for adding a connector. After clicking, a selection opens in which the target to be connected to is selected. You can choose between ResMa®, easyConnect or an MQTT broker.

2. Name: Name of the connector. The name is selected by the user when adding the connector. Subsequent editing is not possible.

3. Target: Target type to which the connector is connected.

4. Connection status: Current status of the connection. Here you can see whether the connector is connected to the target or inactive. Licence information is also displayed here.

5. Message overview: Number of messages sent and received.

6. Options menu: Entry point for options of the respective connector such as Connect, Edit or Delete.

7. Global connection indicator: The global connection indicator appears if at least one existing connector was unable to establish a connection to its target.

Add easyConnect or ResMa Connector

The easyConnect and ResMa Connectors are created identically.

1. Connector name: Can be freely assigned, but must be unique.

2. Activation code: The code is used to confirm the identity of the client and to secure access to the MQTT broker. The code must be generated in easyConnect or ResMa® and entered here. The creation of the code in ResMa® is described in detail below.

3. Server URL: For ResMa connections, replace the passage [RESMA_HOST]:[PORT] with the IP or DNS entry of your ResMa server and the corresponding port (default is 8080).

4. Cloud communication: If deactivated, no values can be received or sent outside of your own network.

5. Time interval Keep-Alive: The interval defines how often a ping signal is sent to maintain the connection to the broker (default: 180 seconds). A shorter interval increases the stability of the connection, while a longer interval reduces the network load.

Generate activation code in ResMa

To establish the connection between PROCON-Connect and ResMa®, an activation code must be created in ResMa® and then stored in PROCON-Connect.

To do this, carry out the following steps in ResMa®:

1. Log in to your ResMa® system.

2. Switch the object tree from the Standard view to the Connector view.

3. Switch the object tree to edit mode.

4. Right-click on the location to which you want to add the IIoT Connector. A context menu opens.

5. Select the ‘New device’ option in the context menu. This opens the configuration page for the IIoT Connector.

6. Give the connector a name. This is transferred to the object tree.

7. Select the activation code from this overview and copy it using the key combination Ctrl + c.

8. Click on Save to finalise the configuration of the connector.

You can then paste the copied activation code into the configuration of the IIoT Connector in PROCON-Connect using the key combination Ctrl + v.

Add MQTT Connector

The configuration of the MQTT connector is divided into three tabs. In the Communication section (1), almost the same values must be entered as for the other connectors.

1. Connector name: Can be freely assigned, but must be unique.

2. MQTT URL: Valid URL of the MQTT broker to be connected to.

3. Cloud communication: If deactivated, no values can be received or sent outside of your own network.

4. Time interval Keep-Alive: The interval defines how often a ping signal is sent to maintain the connection to the broker (default: 180 seconds). A shorter interval increases the stability of the connection, while a longer interval reduces the network load.

5. MQTT protocol: Version of the protocol. The version must be adapted to the MQTT broker to be connected. The version influences the status codes used in the communication between the MQTT client and MQTT broker.

Valid access data for the connector is required in the ‘Security’ tab (1).

1. Authentication: Valid user and password for the connector.

2. Certificates: Activate client certificates and upload them using the button.

   Upload client key and CA certificate

The MQTT client data is entered in the last tab ‘Configuration’ (1). The quality of service can be selected between maximum once / minimum once or exactly once for all of them

1. Client ID: Unique ID.

2. Publish Definition: Type information on the values.

3. Publish Instance: Provision of the values.

4. Subscribe Instance: Read the values.

5. Last Will: The Last Will message informs the broker which message to send to the subscribers if the client unexpectedly loses the connection. This allows other subscribers to be notified of the client’s failure.

Quality of service (QoS)

The Quality of Service (QoS) in an MQTT client determines how messages are transmitted between the client and broker. There are three QoS levels: 0, 1 and 2. Each level offers a different balance between reliability and performance. QoS levels

1. QoS 0 - At most once

   • Mode of operation: The message is sent once without the sender receiving confirmation from the recipient. There is no guarantee that the message will be received.

   • Performance: Highest performance, as no confirmations are necessary and the transfer only takes place once.

   • Use case: Suitable for non-critical data where reliable delivery is not important, e.g. sensor data that is updated frequently.

2. QoS 1 - At least once

   • Mode of operation: The message is resent until a confirmation is received from the recipient. However, it can happen that the message is delivered several times.

   • Performance: Medium performance, as the transmission may be repeated.

   • Use case: Suitable for applications where the message should arrive in any case, but multiple delivery is tolerable, e.g. payment orders or status updates.

3. QoS 2 - Exactly once

   • Functionality: The message is guaranteed to be delivered exactly once. This is achieved by a multi-stage handshake process between sender and recipient.

   • Performance: Lowest performance, as several communication steps are necessary to prevent double delivery.

   • Use case: Ideal for critical messages where double delivery is not acceptable, e.g. when transmitting order data in an ordering system.

Note

The choice of QoS level should be made depending on the specific requirements of the application in order to achieve an optimum balance between reliability and performance.

• QoS 0: Maximum once - High performance, no guarantee of delivery.

• QoS 1: At least once - balance between reliability and performance.

• QoS 2: Exactly once - Highest reliability, lower performance.

The choice of QoS level should be made depending on the specific requirements of the application in order to achieve an optimum balance between reliability and performance.

Retain

Configuration option: Retain option in the MQTT client

The retain option in an MQTT client determines whether a message is stored (‘retained’) on the broker so that it can be sent to future subscribers. This influences how the broker deals with new subscribers who log in after the message has been published.

1. Retain option activated

   • Behaviour: If the Retain option is enabled, the broker will save the last message sent for each topic that they relate to. This saved message is then automatically sent to all new subscribers as soon as they subscribe to this topic.

   • Use case: Useful if subscribers should always receive the latest information, even if they log in after the original publication. For example, if the current status of a system (such as temperature or online status) must always be available.

2. Retain option deactivated

   • Behaviour: Without the Retain option, the message will not be saved on the broker. New subscribers will only receive messages that are published after their registration. Earlier messages will not be delivered.

   • Use case: Suitable for data that is only relevant in real time, such as continuously updated sensor data where it is not important to know the last message.

Note

The choice of whether to enable or disable the retain option should be based on the needs of the application, in particular whether new subscribers need to access the last known state or not.

• Retain option activated: Saves the last message on the broker and ensures that new subscribers receive it. Ideal for status information that must always be up-to-date.

• Retain option deactivated: Messages are not saved; new subscribers only receive future messages. Ideal for real-time data where past information is not relevant.

The choice of whether to enable or disable the retain option should be based on the needs of the application, in particular whether new subscribers need to access the last known state or not.

Data definitions

Data definitions can be added for each of the added connectors. These data definitions can be used to summarise, transmit or read individual or multiple defined values.

Regardless of the selected connector, the creation of a data definition always works in the same way. Expanding the connector in the overview either displays an overview of the data definitions that have already been created, followed by the ‘Add data definition’ button or a message that none exist yet and the corresponding button to add them.

In the following dialogue, the general settings are made first.

1. Cloud data definition name: Mandatory, must be unique.

2. Connection type: Available for selection:

   • Send tags on value change (publish)

   • Send tags periodically (publish) > The cycle and the time unit must then be defined here

   • Read tags (subscribe)

If data definitions have been created, the context menu can be called up via the three dots and the data definitions can be edited or deleted.

The variables that are to be monitored can then be selected in the ‘Tags’ tab. Tags that have already been added can also be removed again.

Reliability

If the network connection between the IIoT Connector (MQTT Client) and a configured target (MQTT Broker) is interrupted, data may potentially be lost.

To prevent data loss, the IIoT Connector buffers up to 1000 messages locally for each configured target (MQTT broker). If no connection has been established by the time this limit is reached, the oldest message is overwritten with the latest message. As soon as a network connection is established, the IIoT Connector will send the messages to the target.

A time-based configurable buffer is being planned. As long as this is not implemented, the limit of 1000 messages can be adjusted via a configuration file. Please contact us if required.