IoT Core MQTT Client

available on the bsc pro from version 3 7 0 introduction the "iot core mqtt client" export module establishes the connection to an mqtt broker and publishes status messages under various topics several export instances can be created, but only one instance per broker url messages are always transmitted as strings and are usually formatted as json objects configuration the export connection can be created and the parameters configured in the iot export area of the web configuration or the bsc remote tcp/ssl and web socket (http/https) connections are supported authentication is possible via user name and password or client certificate the corresponding certificates or access data can be stored during configuration it is possible to customize the basic topics for publishing news parameter default value possible values description user available user accounts the user account to be used when accessing the data it is thus possible to restrict the export of devices or access to commands connection mode socket socket websocket selection whether a tcp or web socket connection is used broker ip or dns name of the broker without protocol or port example test mosquitto org the broker to which the connection should be established port 1883 1 65535 the port to use when establishing a connection auth user user name for authentication at the broker auth password password for authentication at the broker ssl off on trust all off option whether an encrypted connection should be established with the option "trust all" it is possible to trust all certificates ssl server crt in ssl mode, the server certificate is used to validate the connection to the broker ssl client crt in ssl mode, the client certificate is used to validate the client ssl client key in ssl mode, the private client key is used to authenticate to the broker ssl client key password in ssl mode this password is used to unlock the client key https hostname verification on on off in ssl mode, the hostname used is explicitly checked in the broker's certificate qos 0 0 1 2 the qos value determines how messages are delivered the higher the qos value, the greater the latency of message delivery qos 0 means that the messages are sent without confirmation of receipt a classic "fire & forget" qos 1 , on the other hand, sends the message until a confirmation of receipt is received by the broker the client can be sure that the broker has received the message it is possible that a message is sent or delivered multiple times qos 2 uses a double confirmation to ensure that a message is delivered only once for this purpose, the broker confirms receipt to the client, and the client in turn confirms receipt of the confirmation to the broker thus client and broker both know that the message was delivered correctly and only once by using event ids and timestamps in the message containers used by this implementation, it is possible to deal with duplicate messages and thus avoid the high latencies of qos 2 and implement similar security with qos 1 in principle, qos 0 can also be used in environments with stable connections retain messages on on off specifies whether the last messages for a topic should be cached on the broker other clients will then receive these messages directly after their login this way the last known state can be effectively cached on the broker timeout (s) 90 0 10 15 30 60 90 120 150 180 300 600 1200 1800 3600 time in seconds which is waited to establish a successful connection otherwise this is interpreted as an error the value 0 deactivates the timeout, it will be waited until the connection could be established successfully keep alive interval (s) 60 0 10 15 30 60 90 120 150 180 300 600 1200 1800 3600 maximum time in seconds that may elapse before a data packet must be sent if there is no regular data traffic within this time, a ping is automatically sent the value 0 deactivates this monitoring max inflight 10000 1 65000 in qos modes 1 and 2, this value determines the maximum number of messages that can be sent without an acknowledgement of receipt being received this value may have to be increased in very large operating environments topic structure the topics are implemented on the basis of the "resource path" of the object types from the iot core data model docid\ uv3 mck6dtxwysimop4mz the "base topic" is always placed in front if the "object topics" option is activated, object messages are each sent in a subtopic the topic is then made up of "base topic", "resource path" and the object id this option is ignored for dto objects without id support