MQTT Clients
MQTT Clients
The MQTT Client is your SCADA project’s gateway to the world of IoT (Internet of Things). Through this interface, your SCADA system can communicate with thousands of devices via an MQTT Broker (e.g., Mosquitto, HiveMQ, AWS IoT).
MQTT Parameter Reference Table
The following table details the functions and usage of all settings available in the MQTT Client interface.
| Parameter | Description and Usage Tips |
| No | Sequence number assigned by the system. |
| Symbol | A mnemonic name given to the connection or topic operation (e.g., “Factory_Broker” or “Temp_Data”). |
| Client ID | The unique identity of the device on the Broker. Warning: If two devices try to connect with the same ID, the Broker will continuously disconnect the old connection, causing communication interruptions |
| Host Address | The IP address or domain name of the MQTT server (e.g., test.mosquitto.org:1883). |
| User Name | The username used if the Broker requires authentication. |
| Password | The password used if the Broker requires authentication. |
| Type | Determines whether the connection will be encrypted (Secure Socket Layer) or not. |
| Rule | Publisher: Sends data from SCADA to the Broker (Event Recorder does not work). Subscriber: Pulls data from the Broker to SCADA (Retain setting is critical) |
| Retain | In Publisher Mode: Ensures the last sent data is kept in the Broker’s memory. In Subscriber Mode: If Disconnect mode is used, the other party must send the data with Retain enabled |
| QOS | Quality of Service. Determines the guarantee of data delivery. As the level increases, reliability increases but speed decreases. 0: At most once (Not guaranteed). 1: At least once (Guaranteed). 2: Exactly once (Double confirmed, safest but slowest). |
| Topic | The path address where the message will be published or subscribed to (e.g., Factory/Machine1/Data). |
| Payload | The packaging format of the data (JSON, XML, Plain Text, Custom). |
| Tag List | (Advanced Synchronization): Opens the window that maps fields within incoming/outgoing packets to project tags for structured formats like JSON/XML. |
| Enable | Determines if the server is active. Clicking opens the Compare Dialog. Here, you can define a condition. Pressing OK opens the Conditions Dialog, where multiple Enable conditions can be added. If any of these conditions are valid, the server becomes active. Tip: Leave this field empty if you want the group to be always active. |
| Trigger | Used to link the operation to a Tag status instead of a time Period. The operation is performed when the tag is triggered. Multiple Triggers can be defined. |
| Keep Alive (sec) | The interval for sending the “I am still here” signal to the Broker (Seconds). |
| Period (ms) | The repetition cycle of the operation. |
| Timeout (ms) | The duration to wait before switching to a Fault state if no response is received from the server. |
| Retry Count | Determines how many times the server will retry before switching to “Fault” status if the connection is lost or an error occurs. |
| Disconnect | Selected (Intermittent Mode): Connects only when data needs to be sent/received, then disconnects. Ideal for infrequent data. Not Selected (Continuous Mode): The connection remains open continuously. Ideal for frequent data flow. |
| Event Recording | Works only in Subscriber mode. Enables recording of data coming from the Broker to the SCADA event log. |
| Activate | Start Connection (Trigger): Used to activate the MQTT operation (Connecting or Sending Data) in the relevant row. |
| Success | This tag becomes True if the operation started with Activate completes without issues. |
| Fault | This tag becomes True if an error occurs during the operation (e.g., Server missing, authorization error). |
| Comment | Explanatory note regarding the row. |
Detailed Parameter Explanations
Working Modes
- Publisher (Data Sender)
- Function: Sends a tag value from SCADA to the Broker.
- Triggering: Sending frequency is determined by Period or a Trigger tag.
- Event Recorder: Non-functional in Publisher mode because there is no external data being written to SCADA.
- Subscriber (Data Receiver/Listener)
- Function: Receives data from the Broker and writes it to a SCADA tag.
- Working Logic:
- In Continuous Connection: SCADA listens to the line continuously. The moment a Publisher sends data, the Subscriber captures it.
- In Disconnect Mode: SCADA connects to the server only when the Period expires or a Trigger arrives, checks “Is there a message for me?”, and then disconnects.
- Importance of Retain: If you are in Disconnect mode, the sender (Publisher) must send the data as Retain. If there is no Retain, SCADA will miss messages sent while it was disconnected. If Retain is active, SCADA receives the “last updated value” the moment it connects.
Retain (Persistent Message)
- For Publisher: If checked, the Broker keeps the last message sent in memory. Even if a new device joins the network later, it receives this “last value” immediately upon subscribing to that Topic.
- For Subscriber: Vital if intermittent (Disconnect) connection is used.
Connection Strategy (Disconnect and Keep Alive)
Correct configuration of the Disconnect box and Keep Alive time is essential for system stability. There are two main scenarios:
1. Continuous Connection (Disconnect NOT Selected)
Preferred when data traffic is heavy (e.g., every second). SCADA connects to the server once and keeps the line open continuously.
- Rule: Period (ms) time must be less than Keep Alive (sec) time.
- Why? SCADA says “I am here” (Ping) to the Broker during the Period. If no signal is received until the Keep Alive time expires, the Broker cuts the connection.
2. Intermittent Connection (Disconnect SELECTED)
Preferred to avoid burdening the server when data traffic is sparse (e.g., every 15 minutes).
- Behavior: When the time comes (Period/Trigger), SCADA wakes up -> Connects -> Sends/Receives Data -> Disconnects.
- Important: If you are a Subscriber in this mode, the other party must send the data as Retain. Otherwise, messages arriving while SCADA is sleeping will be lost.
Custom JSON Protocol and C# Integration Example
Custom: JSON is a high-performance communication method that runs directly over a TCP socket, stripped of the header overheads of the standard HTTP protocol.
The biggest advantage of this protocol is that both data reading (Read) and data writing (Write) commands can be sent simultaneously within a single data packet.
Protocol Structure (Payload)
Communication takes place in the form of a JSON object sent to the server and a JSON response returned from the server.
Request Format
The Client sends a JSON to the server in the following structure:
JSON
{
"read": [ "Tag_Name_1", "Tag_Name_2" ],
"write": [
{ "tag": "Tag_Name_3", "value": false },
{ "tag": "Tag_Name_4", "value": 100 }
]
}
- read: An array containing the names of the tags to be read.
- write: An array of objects containing the names and values of the tags to be written.
Response Format
The server returns the operation result as a JSON containing Key-Value pairs:
JSON
{
"Tag_Name_1": true,
"Tag_Name_2": 45.5,
"Tag_Name_3": "success",
"Tag_Name_4": "success"
}C# Client Code Analysis
The logic for a C# application connecting to the Wise SCADA server via TCP port 5000 and exchanging data using the Custom: JSON protocol is as follows:
- Connection Setup (TcpClient): The client opens a raw TCP connection to the SCADA server over the specified IP and Port (e.g., 127.0.0.1:5000).
- Request Creation: The tags to be read (read) and written (write) are defined within a request object. In the example above, Tag_Name_1 and 2 are read, while values are written to Tag_Name_3 and 4.
- Serialization: The C# object is converted into a JSON format String using the JsonConvert.SerializeObject command.
- Data Transmission: The created JSON text is converted to a byte array using Encoding.UTF8.GetBytes and sent to the server over the network (stream.Write).
- Data Reception and Processing: The response from the server is read with stream.EndRead, converted back to text, and parsed as a JObject (Deserialize). Results are typically displayed or processed.
Developer Note: This method is much faster than the HTTP REST API because, instead of opening a new connection (handshake) for every request, continuous data flow can be maintained over the established socket.