Payload Types and Custom Formatting
Payload Types and Custom Formatting
In MQTT communication, the “Payload” is the body of the transported data packet. The MQTT Broker (Server) is not concerned with the content of the data it carries; it simply delivers it to the receiver like a box. Therefore, the sender (Publisher) and the receiver (Subscriber) must agree on the same format.
Wise SCADA supports the following Payload types:
1. Standard Formats
In these options, the data format is automatically managed by Wise SCADA. It is recommended to use these options if you are communicating between two Wise SCADA projects.
- JSON (Default): Data is sent in a readable structure complying with modern web standards.
- Example Output: {“TagName”: “Motor_Speed”, “Value”: 1450, “Quality”: true, “Timestamp”: “…”}
- XML: Data is sent in a tag-based XML tree structure. This is mostly used for integration with legacy ERP systems.
- Plaintext: Only the raw value is sent (e.g., 1450). Since the data does not contain tag information, the identity of the data must be understood via the Topic header.
2. Custom Payload (Special Formatting)
If you are going to communicate Wise SCADA with a custom electronic circuit or a different brand’s IoT device, you should use the Custom option. This mode allows you to design the data packet character by character.
Configuration: The Custom format is defined using the 2nd column in the Tag List window.
$$$ Syntax: The “magic character” is the $$$ sign. SCADA places data where it sees this sign or reads data from there.
- In Publisher (Sender) Role: The $$$ in the template is deleted, replaced by the current value of the Tag, and sent.
- In Subscriber (Receiver) Role: The incoming message is scanned according to the template. Data corresponding to the $$$ position is extracted and written to the SCADA Tag.
3. Custom Format Scenarios and Examples
The table below shows the templates you will write in the 2nd column of the Tag List window and the resulting data packets.
| Purpose | Tag List 2nd Column | Generated/Read Data Packet | Description |
| Numeric JSON | {“Temp”:$$$} | {“Temp”:24.5} | If the other side expects data as a Number, quotation marks are not used. |
| String JSON | {“Status”:”$$$”} | {“Status”:”Active”} | If the other side expects data as a String, $$$ must be enclosed in quotes. |
| Simple Equals | Val=$$$ | Val=100 | Used for some simple serial port/TCP device protocols. |
| Raw Data | $$$ | 45.2 | Behaves the same as Plaintext. Only sends the value. |
| Multi JSON | {“Heat”:$$$,”Hum”:$$$} | {“Heat”:22,”Hum”:60} | Note: Used for sending/receiving multiple data points in a single line (Advanced). |
Critical Warnings:
- Format Compatibility: The template you design (quotes, commas, brackets) must match exactly the format expected by the remote device. Even an extra space can cause a “Parse” error.
- Data Types: Sending {“A”:$$$} transmits a number (25), while sending {“A”:”$$$”} transmits text (“25”). The remote device’s software might be sensitive to this distinction.
4. Working Logic and Limitations
- Broker Does Not Analyze: The Broker (Mosquitto, etc.) never reads or changes the Payload content. It only transports it. Creating and decoding the format is the responsibility of the end devices (SCADA and Device).
- Batch Sending: In the Publisher role, when the values of the tags in the Tag List change, data can be packaged and sent collectively. The packet logic is more efficient than sending data one by one.
- No Dynamic Method: Due to the nature of MQTT, it does not work with the “Give me the current value” (Get) command. You either subscribe (Subscribe) and data flows to you, or you publish (Publish) and data goes out.