Current master broker

Output

The name of the current master broker is output as text.

Publish all topics

Input

This input can be used to force the publishing of the MQTT client. All cached network contents are published via the Topics. For example, if the broker was unreachable, the last states could be sent to the broker on reconnect.

Diagnosis [Text]

Output

Error texts are output here. These can be displayed e.g. with the component "Protocol window" .Attention: Diagnostic or debug outputs are only intended for error cases. Please use only with consultation of the support team! If used, these can considerably impair the performance of the service.

Advanced Diagnostics

Input

(De)Activates the extended debug output. The extended diagnostics can be controlled here over different levels output-technically (e.g. at a protocol window to the output). Values of 0, 1 and 2 can be sent to this input via 8Bit and thus the outputs can be made clearer.

0 = Deactivates the extended diagnostic output

1 = Activates the output of relevant events (e.g. connect, disconnect, limit outputs) without further details.

2 = Activates the complete log output incl. publish/subscribe messages of all users/clients/$SYS, provided that the subscription/publish messages have not been switched off in the component settings.

KNX Gateway - Number of objects in send queue

Output

Outputs the number of objects in the send queue.

KNX Gateway - Delete send queue

Input

Deletes the entire send queue.

Dynamic

Folder

In this folder the dynamic data points are created from the channels (Topics).

Driver Gateway - KNX

Bidirectional

Bidirectional communication interface between KNX and MQTT Client. See Driver Gateway.

Driver Gateway - BACnet Server

Bidirectional

Bidirectional communication interface between BACnet Server and MQTT Client. See Driver Gateway.

Driver Gateway - BACnet Client

Bidirectional

Bidirectional communication interface between BACnet Client and MQTT Client. See Driver Gateway.

Driver Gateway - Modbus Master

Bidirectional

Bidirectional communication interface between Modbus Master and MQTT Client. See Driver Gateway.

Driver Gateway - General

Bidirectional

Unidirectional communication interface between this driver and the serial driver.

Primary Broker is Master Broker

Output

Output status, if the primary broker is the current master broker or not.

Statistics

Folder

Via the data points, messages received and sent in real time, as well as data amounts per minute/hour/day and since start can be output and analyzed. A reset at runtime is also possible.

Driver On/Off

Bidirectional

(De)Activate the component

Uptime

Output

Runtime of the MQTT client from start.

Uptime [s]

Output

Runtime of the MQTT client from start in seconds.

Connection status

Output

Outputs the current connection status as "On/Off/Undefined" signal. On=Connection OK, Off=Connection disturbed/not registered, Undefined=Client is off.

Payload [bytes]

Bidirectional

Payload is the actual transported raw data (without MQTT header) in the form of a byte array.

Payload Profile

Folder

If payload profiles have been created and assigned to a topic (data type: string), an additional subfolder is created in which the inputs/outputs of the payload profile fields can be found. See below for an example of the payload profiles.

Payload Profile (Publish JSON)

Output

Output of the data to be published for the set profile.

Payload Profile (Publish Trigger)

Input

Triggers the publishing of the data for the set profile. Note: The port is only available if a profile has also been assigned in the Topic Channel Editor.

QoS

Output

The Quality of Service (QoS) level is an agreement between the sender of a message and the receiver of a message that defines the delivery guarantee for a particular message.

 
There are 3 QoS levels in MQTT:

•0: "Fire-and-forget" - the packet is sent exactly once. Arrives, maybe not sometimes, analogous to the UDP protocol. Delivery: enormously fast.

•1: "Acknowledgement" - the receiver confirms to the sender that the packet has been received. It is possible for a packet to arrive more than once. Delivery: very fast.

•2: "Synchronised" - the parcel is guaranteed to reach the destination, and only once, but this variant generates slightly more "traffic". Delivery: somewhat slower.

Value

Bidirectional

Value of the topic taking into account the defined factor in the corresponding channel editor. Please note the Publish/Subscribe setting in the channel editor for each topic.

Timestamp

Output

Timestamp of the last received value.

Connection

...

Enter the connection data to the MQTT broker - see below.

Further Broker Connections

0

Additional brokers can be created here, which should also receive the data simultaneously. With this function it is possible to publish topics to several brokers and/or to subscribe to them - a redundancy solution can be built up here.

Payload Profile

...

Using self-defined payload profiles, it is possible to split JSON strings that are transmitted in a topic into individual sub-data points of the respective topic according to the hierarchy (see example below).

Channels

0

For each channel, the MQTT topic to be subscribed to must be specified, as well as the associated data type. Optionally, a descriptive name can be specified, which is also taken into account when creating the data points and is displayed there. Additionally, the QoS level, whether the message should be retained and whether the topic should be published and/or subscribed can be set.

Last Will

...

Often referred to as a will. The purpose of this special function is mainly to tell the connected MQTT broker when the client is unexpectedly offline (e.g. connection lost). The corresponding content for this state is stored in the payload and defined with its own topic.

Publish all topics on Reconnect

Disabled

This property can be used to force the MQTT client to publish on reconnect of the broker. All cached network contents are published via the Topics. If the broker was unreachable, for example, the last states could be sent to the broker on reconnect.

Basetopic

empty

The BaseTopic is prepended to all Topics in the channel list. BaseTopic 1234 would automatically convert an existing Topic "sensor/humidity/value" into "1234/sensor/humidity/value". It is therefore possible, if many clients of buildings, plants or devices have to be mapped uniquely in the broker, to solve this automatically via the BaseTopic and also to create copies much faster and easier, which then only differ via the BaseTopic.

Append name to topic

Disabled

Here you can select whether the name (label) of the topic is additionally appended to the topic as defined in the channel editor. Accordingly, there is a new additional export mechanism (Channel Editor - Export Details) to output the topics including all settings and data type definitions as a list.

Disable cyclic heartbeat

Deactivates

The cyclic heartbeat message is no longer published to the broker if the option is set to active.

Ignore messages at start (duration [s])

0

Ignores incoming messages such as retained topics for the specified duration when starting the client. Default value: 0

Do not display subscription messages

Disabled

Subscription messages are not output in LogLevel 2 of the extended diagnosis, if activated.

Do not output publish messages

Disabled

Publish messages are not output in LogLevel 2 of the extended diagnosis, if enabled.

Do not output messages received

Disabled

Messages received are not output in LogLevel 2 of the extended diagnostics, if enabled.

Driver On/Off

Disabled

(De)activate the component

Server URL/IP:

IP address or hostname of the server to be queried.

Port:

Specification of the communication port to the MQTT broker (default: 1883 or 8883 (TLS)). This port must be entered in the firewall as soon as bidirectional communication is to take place.

User / Password:

If authentication is required to access the broker, user name and password can be stored (leave blank for anonymous access).

Timeout [s]:

Communication timeout in seconds (default: 5 seconds).

Client ID:

Unique name for this client, which may only be used once. If the component is copied, a new ID must be generated or a new unique name selected.
The ID for the client, if it is to connect to an EisBaer MQTT broker, must be at least 10 characters long for security reasons. Otherwise the connection will be denied.

Websocket:

Optionally, it can be specified whether the telegram traffic should take place via websockets.

TLS:

Depending on the server, the connection can also be encrypted via TLS. This makes the fields for "Accept all certificates" and "Server certificate" active.

Server certificate:

Path specification to the server certificate that is to be used for communication. By default, you will find a self-signed certificate in your EisBaer installation directory.
The default path incl. certificate for a protected TLS connection between EisBaer MQTT client and EisBaer MQTT server with this certificate is: C:\Program Files (x86)\Alexander Maier GmbH\EisBaer SCADA 3.0\mqttbroker.cer

For the EisBaer MQTT broker, the certificate to be used is located as a pfx file in the same path, which does not have to be transferred specifically for the broker.