Modbus

Introduction

Modbus is a widely adopted industrial communication protocol designed for connecting electronic devices. It is primarily used in process automation and factory environments to enable robust and reliable data exchange between various devices. Based on a master-slave or client-server architecture, Modbus facilitates communication between devices such as programmable logic controllers (PLCs), sensors, actuators, and monitoring systems. Its simplicity and ease of implementation have made it a standard protocol in the industry, allowing seamless integration and interoperability across different devices and systems.

ModbusMQTT enables communication with Modbus devices, taking the role as Master device. It reads values from these devices and posts them to Coreflux Central, an MQTT broker. Additionally, it can receive data from Coreflux Central and relay it back to the Modbus devices, facilitating a bidirectional data flow.

Features and Benefits

Dual Protocol Support: The connector seamlessly bridges devices operating on both Modbus TCP and RTU protocols with MQTT networks.
Tag-Based Messaging: Uses tags for MQTT topics, simplifying configuration and making data streams easier to understand and manage.
Seamless Coreflux Integration: Fits smoothly within the Coreflux ecosystem, reducing complexity and speeding up IoT solution deployment.
Operational Efficiency: Direct data flow from Modbus devices to MQTT brokers minimizes latency and potential points of failure, creating a cost-effective operational environment.
Enhanced Data Exchange: Utilizes MQTT's efficient messaging protocol for real-time data exchange, improving decision-making and system performance.

Use Cases:

Real-Time Monitoring and Control: Enables direct monitoring and control of Modbus-connected machinery via MQTT-enabled dashboards, increasing productivity and reducing downtime.
Data Aggregation: Funnels data from various Modbus devices into a unified MQTT stream, making it easier to analyze and uncover operational insights.
IoT Integration: Simplifies the integration of industrial systems with IoT ecosystems for cloud analytics, remote monitoring, and predictive maintenance.

Prerequisites

Before you install and configure the connector, make sure you have the following prerequisites:

Basic understanding of the MQTT protocol.
Basic understanding of Modbus protocol.
Coreflux account.
Coreflux MQTT broker.
MQTT Client (such as MQTT Explorer).
A Modbus device (PLC for example).

Connector installation

Using Coreflux HUB

Please refere to general docs for connector installation trough the Coreflux HUB.

Using Coreflux HUBLESS

Connector management and control are conducted using the MQTT protocol. Commands (payload) are sent to the $SYS/Coreflux/Command topic. The results of these commands are published to $SYS/Coreflux/Command/Output. The following steps will focus solely on the payload that needs to be sent.

Connect to the Coreflux MQTT Broker using your preferred client.
Login using your coreflux account:
```
-L myname@mydomain.com password`
```
Check your available connectors:
```
-l
```
Install connector:
```
-I coreflux_modbus2mqtt
```
If there were no issues during the installation you should receive a message on the $SYS/Coreflux/Command/Output:
```
Your coreflux_modbus2mqtt was installed with version <version> with the <asset_guid>. Let the magic begin! 
```

Connector Configuration

Before using the connector, it must be properly configured. This configuration process entails adjusting various parameters that affect its functionality, the setup of the device, and how they interact with each other. This involves specifying the device's IP address and selecting the class, instance, and attribute to be manipulated, among other settings. The configuration is detailed in a JSON file, divided into three main sections: MQTT Parameters, Modbus Parameters and Tags Prameters.
The instructions below will guide you through configuring each section.
By the end, you will have a comprehensive example configuration that can be tailored to your specific needs.

Warning: If a parameter is not included in your connector's configuration and it is not required, a default value will be applied. Incorrect configuration may cause the connector to not work as intended.

Information_source: This configuration is presented using a hubless setup as an example. The key takeaway is the understanding of the parameters and their significance. If you are configuring the connector via Coreflux Hub, the same parameters and configurations apply.

MQTT Parameters

The MQTTParameters in the JSON configuration define how to connect to an MQTT broker, specifying the communication details. The Address and Port indicate the broker's network location (in this case, 127.0.0.1 on port 1883), which is where the data will be sent to or received from. The parameters also detail authentication methods and the use of TLS for secure communication. This setup determines the pathway for data exchange between the device and the MQTT broker, facilitating the monitoring or control of device operations.

Parameter	Description	Required	Example	Default Value
Port	Port number on which the MQTT broker is running.	Yes	`1883`	1883
Address	IP address or hostname of the MQTT broker.	Yes	`"127.0.0.1"`	`"127.0.0.1"`
IsAnonymous	Indicates if the connection is anonymous (no username/password required).	No	`true`	`true`
Username	Username for authentication, if not anonymous.	No	`""`	`""`
Password	Password for authentication, if not anonymous.	No	`""`	`""`
WithTLS	Specifies whether TLS encryption is enabled for secure communication.	No	`true`	`false`

Example:

{
  "MQTTParameters": {
    "Port": 1883,
    "Address": "127.0.0.1",
    "IsAnonymous": true,
    "Username": "",
    "Password": "",
    "WithTLS": false
  }
}

Modbus Parameters

The Modbus in the JSON configuration specify the setup for Modbus communication between a local system and a target device. These parameters are essential for facilitating data exchange using the Modbus protocol.

There are two different ways to connect to Modbus devices: TCP/IP and RTU.

TCP/IP Connection:

Uses Ethernet networks to connect devices, allowing for easy and flexible setup over longer distances. This method leverages standard network infrastructure, making it suitable for modern industrial environments.

Parameter	Description	Required	Example	Default Value
Interface	Defines the connection interface. The options are: 'SerialRTU' (0), 'TCPIP' (1)	Yes	`TCPIP`	`"TCPIP"`
Port	Modbus server Port.	Yes	`502`	`502`
IP	Modbus server IP Address.	yes	`192.168.100.200`	`127.0.0.1`
PollingMs	Polling of registries in milliseconds	Yes	`500`	`500`
EndianType	Order of registers Options are: 'LittleEndian' (0), 'BigEndian' (1)	Yes	`LittleEndian`	`LittleEndian`
SlaveId	Unique number assigned to each Modbus device on the network	Yes	`5`	`1`

Example:

{
  "MQTTParameters": {
    "Port": 1883,
    "Address": "127.0.0.1",
    "IsAnonymous": true,
    "Username": "",
    "Password": "",
    "WithTLS": false
  },
    "ModbusParameters": {
    "Interface": "TCPIP",
    "Port": 502,
    "IP": "192.168.100.200",
    "PollingMs": 500,
    "EndianType": "LittleEndian",
    "SlaveId": 1
    }
}

RTU Connection:

Utilizes serial communication for connecting devices, typically over RS-485 or RS-232 interfaces. This method is ideal for simple, short-distance connections and is often used in legacy systems.

Parameter	Description	Required	Example	Default Value
Interface	Defines the connection interface. The options are: 'SerialRTU' (0), 'TCPIP' (1)	Yes	`SerialRTU`	`"TCPIP"`
SerialPort	Used in “SerialRTU” interface.	Yes	On Windows OS: `'COM3'`; On Linux OS: `'/dev/ttyUSB0'`	`"COM3"`
PollingMs	Polling of registries in milliseconds	Yes	`500`	`500`
Parity	Parity bit to check for errors during data transmission. Options are: 'None' (0), 'Odd' (1), 'Even' (2), 'Mark' (3), 'Space'	Yes	`2`	`0`
Retries	Number of retries	Yes	`2`	`3`
BaudRate	Data exchange speed between devices	Yes	`5000`	`9600`
StopBits	Number of bits to indicate the end of a data frame. Options are: 'None' (0), 'One' (1), 'Two' (2), 'OnePointFive' (3)	Yes	`0`	`0`
EndianType	Order of registers. Options are: 'LittleEndian' (0), 'BigEndian' (1)	Yes	`LittleEndian`	`LittleEndian`
SlaveId	Unique number assigned to each Modbus device on the network	Yes	`5`	`1`

Example:

{
  "MQTTParameters": {
    "Port": 1883,
    "Address": "127.0.0.1",
    "IsAnonymous": true,
    "Username": "",
    "Password": "",
    "WithTLS": false
  },
    "ModbusParameters": {
    "Interface": "SerialRTU",
    "SerialPort": "COM3",
    "PollingMs": 500,
    "Retries": 2,
    "BaudRate": 9600,
    "StopBits": "None",
    "EndianType": "LittleEndian",
    "SlaveId": 1
    }
}

ModbusMemoryArea Table

The ModbusMemoryArea Table outlines the different memory areas used in Modbus communication, each identified by a specific value. These areas categorize the types of data that can be accessed or controlled within Modbus devices.

ModbusMemoryArea Value	Description
0	Coils (also known as outputs, are writable and readable)
1	Discrete Inputs (read-only boolean values)
2	Input Registers (read-only numerical values)
3	Holding Registers (writable and readable renumerical values)

Tag Data Types

This section outlines the various data types used within the system, which are named and structured to mirror the data types found in the corresponding devices. This naming convention ensures a more intuitive and direct mapping of data types from the devices to our system, facilitating easier data handling and integration. Understanding these data types is crucial for effective communication and data manipulation in the system.

Data Type - Integer Value	Description	Memory Space	Lower Bound	Upper Bound
0 - Boolean	Set a specific Bit to: 0 (false) or 1 (true).	1 bits	FALSE (0)	TRUE (1)
1 - Byte	The value to be read from or written to the AttributeIndex must be a valid byte.	8	0	255
2 - INT16	Signed 16-bit integer.	16 bits	-32768	32767
3 - UINT16	Unsigned 16-bit integer.	16 bits	0	65535
4 - INT32	Signed 32-bit integer.	32 bits	-2147483648	2147483647
5 - UINT32	Unsigned 32-bit integer.	32 bits	0	4294967295
6 - INT64	Signed 64-bit integer.	64 bits	-2^63	2^63-1
7 - UINT64	Unsigned 64-bit integer.	64 bits	0	2^64-1
8 - Float32	32-bit floating point number.	32	-3.402823e+38	3.402823e+38
9 - Float64	64-bit floating point number (double).	64 bits	-1.7976931348623158e+308	1.7976931348623158e+308
10 - ASCII	Will convert the AttributeIndex value to an ASCII character.	1 bit	0	255

Saving the configuration

Connector management and control are conducted using the MQTT protocol. Commands (MQTT payload) are sent to the $SYS/Coreflux/Command topic. The results of these commands are published to $SYS/Coreflux/Command/Output. The following steps will focus solely on the payload that needs to be sent.

ℹ : Configuration requires the user to be logged in and have a connector installed. If these requirements are not met, please refer to the installation section.

Save configuration:
```
-assetConfigSave <asset_guid or assetName> <configuration>`
```
ℹ : The connector asset_guid can be obtained by consulting the $SYS/Coreflux/Assets topic.

Example:

-assetConfigSave assetName {
  "MQTTParameters": {
    "Port": 1883,
    "Address": "127.0.0.1",
    "IsAnonymous": true,
    "Username": "",
    "Password": "",
    "WithTLS": false
  },

  "ModbusParameters": {
    "Interface": "TCPIP",
    "Port": 502,
    "IP": "192.168.100.200",
    "PollingMs": 500,
    "EndianType": "LittleEndian",
    "SlaveId": 1
    },

  "Tags": [
    {
      "Name": "writeExample",
      "Route": 0,
      "MqttTopic": "machine/motorStart",
      "MqttQos": 0,
      "MqttRetain": false,
      "ModbusMemoryArea": 3,
      "ModbusMemoryAddress": 5,
      "ModbusDataType": 4,
      "SwapByte": true,
      "SwapWord": true
    }
  ]
}

Check if the configuration was saved (optional) :
```
-assetConfigLoad <asset_guid>
```

ℹ : Find more detailed information about the connector management here.

Using the connector

⚠ Warning: It is important to understand that the flow of data between the broker and the device highly depends on the configuration of both the connector and the device. In case of unexpected results, please verify the configuration and/or check the logs for any possible errors.

With Coreflux HUB

Please refer to the general docs for asset installation through the Coreflux HUB.

With Coreflux HUBLESS

Connector management and control are conducted using the MQTT protocol. Commands (MQTT payload) are sent to the $SYS/Coreflux/Command topic. The results of these commands are published to $SYS/Coreflux/Command/Output. The following steps will focus solely on the payload that needs to be sent.

ℹ : The connector guid can be obtained by consulting the $SYS/Coreflux/Assets topic.

Run connector

Run connector:

-R <asset_guid>

Stop connector

Stop connector:

-S <asset_guid>

⚠ Warning: To update the connector configuration, ensure you stop it first to avoid issues. After making the changes, restart the connector to apply the new configuration.

Logs

Logs are essential for monitoring and debugging your system. They provide insight into the operation of your connectors and can help identify and resolve issues promptly.

With Coreflux HUB

On Coreflux HUB, the logs are displayed in the "Log" section of the connector configuration.

With MQTT Explorer

To display logs in MQTT Explorer, follow these steps:

Publish the following command to the $SYS/Coreflux/Command topic:

-addTraceLog topic=topic/to/show/log level=Error/Information/Warning messageContains=(assetID)

2. The logs will be shown on the $SYS/Coreflux/Log/Traces/topic/to/show/log topic.

Example1:

To display informational logs, use:

-addTraceLog topic=log/inf level=Information

Note : This will display the Logs "Information" of all the connectors

Example2:

To display error logs, from a specific asset, use:

-addTraceLog topic=log/modbus/err level=Error messageContains=assetID

Note : This will display the Logs "Error" of a specific connector

Note: To display all three types of logs (Error, Information, and Warning), you will need to repeat this process three times, one for each log level.

Parameter	Description	Required	Example	Default Value
Name	Unique Tag identifier	Yes	`outputExample`	`"TagName"`
Route	Origin and destination of data. The options are: 'ToSubscribers' (0), 'ToOther' (1)	Yes	`1`	`0`
Publish	Chose how data is sent. The options are: 'Update' (0), 'Cyclic' (1), 'Once' (2)	Yes	`0`	`1`
PublishCycle	Specifies the interval for publishing messages when 'publish' is set to 'Cyclic'. Must be a value between 1 and 86,400 seconds (24 hours).	No	`500`	`1`
MqttTopic	Unique topic connecting with the specified Register	Yes	`machine/motorStart`	`"mqtt/topic"`
MqttRetain	Defines if the message should be retained	Yes	`true or false`	`false`
QualityOfService	Quality of service for the MQTT topic. Options are: 'AtMostOnce' (0), 'AtLeastOnce' (1), 'ExactlyOnce' (2)	Yes	`2`	`2`
ModbusMemoryArea	Defines the register, coil, or input to access. See the ModbusMemoryArea Table.	Yes	`0`	`2`
ModbusMemoryAddress	Defines the Modbus memory address to read/write. The address is defined by the OEM and can range from 0 to 655535.	Yes	`5`	`0`
ModbusDataType	Defines data type to read/write. See the Tag Data Types	Yes	`0` (Boolean)	`0`
RegisterByte	Defines the register byte to read/write when using ASCII	Conditional	`0`	`0`
ModbusRegisterBit	Define the Modbus memory address bit to read/write. From bit 0 to bit 16, when using BOOL	Conditional	`2`	`0`
SwapByte	Changes the order of bytes within a Register (e.g., from AB to BA)	No	`true`	`false`
SwapWord	Changes the order of words in a double Register (e.g., from ABCD to CDAB)	No	`true`	`false`