Communication by the MQTT communication protocol

The MQTT (MQ Telemetry Transport) is a simple "Internet of Things" communication protocol, based on publishing and subscribing of messages. The central Broker component manages the receipt, storage, and transmission of of messages between clients.
A client can be of the type Publisher (publisher), of the type Subscriber (subscriber) or even a Publisher and Subscriber simultaneously.
The client of the Publisher type sends messages of a specific topic to the Broker server, which acts as an intermediary between publishers and subscribers.
A topic is similar to a delivery address or, more precisely, a folder on a computer. These are organized hierarchically and form a flexible data structure separated by slashes (e.g. device/sensor1/status).
They allow you to dynamically subscribe to both individual topics and entire groups at once. This can be achieved using a so-called wildcard(*) (e.g. device/*/status). The Publisher can be for example a sensor or meter.
The opposite is a Subscriber that subscribes to receive a specific topic. When the Publisher sends new data for the same topic, the Broker immediately forwards it to all Subscribers who are subscribed to it. A Subscriber can subscribe to any number of topics or unsubscribe from them.
Thanks to the fact that the clients communicate only with the intermediary (with the server - with the Broker), the clients do not have to know the network topology and each others existence - they only need to know how to connect with the Broker.

Client logs in using a unique "ClientID" and an optional "Username" and "Password".

The MQTT protocol defines three levels of message confirmation QoS (Quality of Service)

The client of the Publisher type can send messages with the Retain and DUP flags.

Support for TLS 1.3 has been implemented since version Pm9.0.35.
Secure communication is enabled via the "Secure connection (TLS)" configurator. Next, you need to change the value of in the "TCP/UDP remote port number" configurator to 8883 for TLS or 8884 for mTLS (mutual TLS).

According to the communication encryption level, the MQTT protocol defines usage of 3 network ports: See: Wikipedia: A list of TCP and UDP port numbers used by protocols to run network applications.

If secure connections are enabled, you must import the certificates into the Windows Certificate Storage. You can verify the presence of a certificate by running certmgr.msc, which opens the Windows Certificate Manager. The client must have the Broker server certificate in the Trusted Root Certification Authorities folder or, if applicable, all certificates in the chain of trust. No further requirements are used for the server for communication via TLS.
However, if mTLS is required, the client must also have its own certificate and its certificate authority, including keys, imported into the Personal folder. On the other hand, the server must have the client’s certificate imported into the Trusted Persons folder and, in the Trusted Root Certification Authorities folder, the client’s root CA certificate (the certificate used to sign the client’s certificate).
Important: Private keys must never leave the device to which they belong. Certificates stored in the Personal folder are accompanied by a private key (indicated by a small key icon next to the certificate). In other folders, they are imported without a private key.

Limitation: If the certificates for both parties are issued by a publicly trusted certificate authority (e.g. Let's Encrypt, GlobalSign, Certum), it is not necessary to import the certificates of other side at all. These certificates are usually preconfigured. If necessary, you must update the Windows Certificate Storage to include the latest versions.
If this is not the case and everything relies on so-called self-signed certificates, the client must have the Broker server certificate installed. For mTLS, mutual identity verification is required; therefore, the Broker server must also have the client certificate installed.

Links and directions