...
- Communication protocol "MQTT Client Protocol".
- Station address: the station address corresponds to the Topic field in the PUBLISH message received from the MQTT server. The address can be a specific Topic, a regular expression, a # character representing all Topics, or a topic .* representing all Topics that are not suitable for other stations. The processing priority is as follows
:Kotva prio_processing prio_processing - If there is a station with address # on the line, all messages are directed to its I/O tags and no further search is performed.
- Otherwise, all other stations on the line are searched (except the .* address). If the Topic matches the address of a station, the message is directed to that station and no further search is performed.
- Otherwise, all other stations on the line are searched (except the .* address), and their address is evaluated as a regular expression. If the Topic matches the station address, the message is directed to that station and no further search is performed.
Stations are searched in descending order (by station address), so more specific terms go first (e.g., status/battery before status/batt.*) - Finally, if there is a station with a .* address, the message is addressed to it.
- Polling parameters on the Time parameters tab - recommended value is Delay=0.
...
Note: If the station address is in abbreviated form, commands (DCMD, NCMD) are not processed for it. If it is in the form of a regular expression ('namespace/group_id/.*/edge_node_id/[device_id]'), the station also processes commands (including the command sent by the D2000 KOM process if Send Node Control/Rebirth=YES). Therefore, we recommend the station address in abbreviated form. If it is also necessary to process commands (from other Host Applications), then create another station with an address in the form of a regular expression (e.g. spBv1.0/Sparkplug Devices/DCMD/MyDevice).Kotva komunikacna_stanica_pozn komunikacna_stanica_pozn
The Browse button opens a browse dialog for the station address. As long as the communication is functional, a dialogue with the Topics received so far will be displayed. The list of received topics can be cleared with the Refresh button.
Note: the Station column shows the station to which the Topic has been assigned (based on the abovementioned processing priorities). For Sparkplug addresses, the abbreviated form of the address is displayed.
Station protocol parameters
...
| Type of I/O tag | Address | Description | ||||||
|---|---|---|---|---|---|---|---|---|
| I/O tags for reading data sent by the MQTT server through a PUBLISH message. Note: values of I/O tags are set by the D2000 KOM process in the order IN_TOPIC, IN_DATA, and IN_ID. It is not necessary for the configuration to contain all three I/O tags. | ||||||||
| TxtI |
| Topic (Topic) of received PUBLISH message. | ||||||
| TxtI |
| Data (Payload) of received PUBLISH message. | ||||||
| Ci |
| Identifier of a packet (Packet Identifier) of PUBLISH message that depends on the level of validation (QoS). For messages sent with QoS_0, the identifier is zero, for QoS_1 and QoS_2, it is a positive 16-bit number. Note: if the MQTT server sends also messages with the QoS_0 level of validation and the ACK_ID I/O tag is configured, then we recommend activating the option New value when changing time in the Filter tab, so that repeated writing of the value 0 will cause a new value that differs only in a timestamp to be generated. | ||||||
| I/O tag to confirm the received data to the MQTT server. | ||||||||
| Co |
| If an output I/O tag with ACK_ID address is defined, the D2000 KOM expects confirmation of the processing of each message by writing a copy of the value of the IN_ID tag. Only after, it sets values from the next received PUBLISH message (if it was received in the meantime) into the IN_TOPIC, IN_DATA, and IN_ID I/O tags (in this order). In the case of the QoS_0 level of confirmation, it is, therefore, necessary to repeatedly set the value of the I/O tag ACK_ID to 0. If the I/O tag ACK_ID does not exist, the values are written into the IN_TOPIC, IN_DATA, and IN_ID I/O tags immediately after the PUBLISH message is received and processed. Note: for the messages received with the QoS_0 level of validation, no confirmation is sent to the MQTT server, only the values of the received PUBLISH message will be published. | ||||||
| I/O tags for sending values to the MQTT server through a PUBLISH message. Note: in order for the D2000 KOM process to send the PUBLISH messages to the MQTT server, both I/O tags must be defined within one station. | ||||||||
| TxtO |
| The topic of the PUBLISH message being sent. | ||||||
| TxtO |
| Data (Payload) of the PUBLISH message being sent. Note: sending the message is performed out as a result of writing to the OUT_VALUE I/O tag (i.e. if the Topic does not change then it is sufficient to set the OUT_TOPIC point once - e.g. by using default value). | ||||||
| I/O tags for parsing JSON messages | ||||||||
TxtI, TxtO, Qi, |
| If Payload Type=JSON, the message is parsed as JSON data. The json_address value specifies the name of the JSON field whose value is to be assigned to the I/O tag. For other examples, see the description of the LoRaWAN protocol's Envelope type I/O tags. | ||||||
| I/O tags for parsing Sparkplug messages | ||||||||
TxtI, TxtO, Qi, |
SA=sparkplug_address Output I/O tags: | If Payload Type=Sparkplug, the message is parsed as Sparkplug data (a binary format built on Google Protocol Buffers). Sparkplug data contains metrics that have text identifiers (sparkplug_address). The value type must be specified for output I/O tags. Simple types are supported:
The PUBLISH message created during writing contains a Topic derived from the station address. The message type depends on the station address - whether it is Edge Node (NCMD) or Device/Sensor (DCMD). The Payload contains a timestamp, a value type (type), a written value (encoded according to the specified value type), and a metric name (sparkplug_address). | ||||||
Browse
For the I/O tags, it is possible to discover the list of objects, as long as the KOM process is running and communication with a station is established.
Clicking the Browse button opens the MQTT Item Browser window and displays a list of received metrics. The object list is created dynamically as a result of received messages.
The list of objects is dynamic, i.e. when a new value arrives in the KOM process, it is updated. Filtering in individual columns (with the exception of Time column) is also supported, asterisks can be used in the mask (e.g. *Short*).
Double-clicking on a particular line will insert the value from the Address column into the configuration of the I/O tag from which the MQTT Item Browser window was opened.
The Refresh button clears the list of values in both the CNF and the KOM process and optionally sends the Rebirth command (if Send Node Control/Rebirth=YES).
The Value column contains the received value.
| Kotva | ||||
|---|---|---|---|---|
|
...
- Ver. 1.0 - August 8th, 2017 - document creation.
- Ver. 1.1 - October 15th, 2021 - support LastWill and Retain parameters
- Ver. 1.2 - October 27th, 2021 - support for parsing of JSON messages
- Ver. 1.3 - February 1st, 2022 - support for timestamps in JSON messages
- Ver. 1.4 - October 4th, 2024 - support for MQTT Sparkplug, support for browsing
| Info | ||
|---|---|---|
| ||
...