Porovnávané verzie

Kľúč

  • Tento riadok sa pridal
  • Riadok je odstránený.
  • Formátovanie sa zmenilo.

...

The protocol is an implementation of the MQTT 3.1.1 standard (October 2014). MQTT protocol is a client/server protocol of subscribe/publish type. It is simple, has little overhead and is easy to implement. It is used for M2M communication (Machine to Machine) and in the IoT context (Internet of Things).
D2000 KOM implements the client part of the protocol. The protocol je implemented on a TCP/IP line. 
For transfer of LoRaWAN data encapsulated within the MQTT protocol, see LoRaWan protocol description.

Each PUBLISH message contains a topic (Topic), data (Payload) and level of confirmation (QoS). PUBLISH messages can be sent both by the client and the server. The clients at the beginning of the communication will use the SUBSCRIBE message to indicate what topics (parameter of Topic Filter protocol) they are interested in. 

Kotva
qos
qos
The protocol defines the following levels of confirmation of PUBLISH messages - QoS (Quality of Service):

...

The MQTT communication starts with the CONNECT message sent by client (D2000 KOM). Message contains User Name, Password and other parameters, from which only Clean Session Flag and Client ID can be modified (parameter Will Flag is not used, as  well as Will QoS and WillRetain Will Retain, parameter Keep Alive is set to 0). Server replies with CONNACK message with a return code that contains information about the success of connect operation.

...

Then follows a phase of communication, during which both the client and the server send PUBLISH messages (the client with any topic, the server with topics relating to the filter of topics of the received SUBSCRIBE message) and confirm them according to the value of the QoS parameter of the received PUBLISH messages.

...

  • Communication protocol "MQTT Client Protocol".
  • Station address: station address is a particular topic (Topic) or a # character representing # representing all topics. If there is a station with address # on the line, all messages are directed to its I/O tags. Otherwise, the searched KOM looks for a station with the address corresponding to the Topic field in the PUBLISH message is received from the MQTT server.
    Note: in the station address, there are not yet supported characters of mask "+" in sense of Topic Filter parameter station address doesn't support wildcard characters "+" corresponding to mask of Topic Filter parameter (yet).
  • Polling parameters on the Time parameters tab - recommended value is Delay=0.

...

Type of  I/O tagAddressDescription
I/O tags for reading data sent by MQTT server through PUBLISH message.
Note: values of I/O tags are set by D2000 KOM process in the order IN_TOPIC, IN_DATA and IN_ID. It is not necessary for configuration to contain all three I/O tags.
TxtI
Kotva
in_topic
in_topic
IN_TOPIC
Topic (Topic) of received PUBLISH message.
TxtI
Kotva
in_data
in_data
IN_DATA
Data (Payload) of received PUBLISH message.
Ci
Kotva
in_id
in_id
IN_ID
Identifier of 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 MQTT server sends also messages with the QoS_0 level of validation and the ACK_ID I/O tag is configured, then we recommend to activate activate the option New value when changing time option in the Filter tab, so that repeated writing of the value 0 will cause a generation of new value that differs only with time stamp to be generated with a different time stamp.
I/O tag to confirm a receiving of received data of to MQTT server.
Co
Kotva
ack_id
ack_id
ACK_ID
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 value of the IN_ID tag. Not until Only after then 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) to the IN_TOPIC, IN_DATA, and IN_ID (if it has been received in the meantime)
In case of the QoS_0 level of validationconfirmation, it is therefore necessary to re-enter repeatedly set the value of 0 into 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_IDare set I/O tags immediately after the PUBLISH message is publishedreceived and processed.
Note: for the messages received with the QoS_0 level of validation, no confirmation of is sent to MQTT server is sent, only the values of the next received PUBLISH message received will be published. 
I/O tags for sending values to the MQTT server through PUBLISH message.
Note: in order for the D2000 KOM process to send the PUBLISH message messages to the MQTT server, both I/O tags must be defined within one station.
TxtO
Kotva
out_topic
out_topic
OUT_TOPIC
Topic within of the PUBLISH message being sent.
TxtO
Kotva
out_data
out_data
OUT_DATA
Data (Payload) within of the PUBLISH message being sent.
Note: sending the message is carried performed out as a response result of writing to the entry into the OUT_DATA point 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).

...