What MQTT is, and how does it work for automation... 
A very popular standard for generic and home automation and for WiFi / Net communication
MQTT stands for Message Queue Telemetry Transport and is a "protocol" originally designed for telemetry, that is, measuring things at a distance (what TXtemp, TXdata, TXsoil etc. do). It was invented in 1999 by two researchers, Andy Stanford-Clark of IBM and Arlen Nipper of Arcom, and its specifications are public. 
The system has simple rules that lend themselves well to the exchange of messages between devices and is therefore widely used in personal home automation and IoT (Internet Of Things). 
The operation of MQTT is based on an MQTT broker (which is a "server" program that can "run" on a PC, a local network device, a HUB such as ControlHUB, or on a remote server on the Internet or in the "cloud" as it is so common to say today) which is the "dispatcher" of messages, and then some MQTT clients, that send and receive such messages by passing them to the Broker or receiving them through the Broker (and never directly between them). 
Examples of MQTT brokers are the most diverse: one of the best known and used is Eclipse Mosquitto (download here), which is also available as an add-on for Home Assistant (HASSIO); a smaller but very useful one for simple automations is the one pre-installed inside  ControlHUB
Examples of MQTT clients are: 
- components / devices enabled for the use of MQTT (for example of temperature humidity meters or other things like TXtemp TXdata and TXsoil, or a switch like DoorSwitch or garage gate opener like DoorOpen, or a display like 8888-Display or SuperClock
- any personal HUB (Home Assistant, Homebridge, openHAB etc.); 
- a computer, a smartphone, a tablet that use any MQTT client software (for example the Mosquitto program can also act as a client) 
The mechanism is this: each client can "register" with the broker as Publisher and / or as Subscriber, giving the name of one or more Topics on which he wants to publish messages as Publisher and one or more Topics he wants to listen as a Subscriber (for example to receive commands or notifications). 
For example, if we had a TXtemp temperature sensor configured to automatically publish (e.g. every 10 minutes) an MQTT message containing the telemetry of the temperature detected by it, and two subscribers registered to listen on that given topic at the broker, these subscribers would receive (say every X minutes) the temperature through an MQTT message sent to him by the broker (a message containing the temperature). 
For TXtemp the name of the "telemetry" Topic is standard and is obtained from the name given to the TXtemp in the Settings, for a TXtemp named "Kitchen" it will be for example: 
and its message / payload (in JSON notation) something like: 
{"B":21,"C":0,"Temperature":18.25,"Time":"2020-05-30 20:49.05","H":"0721"} 
(as you can see, it contains the temperature as well as other information relating to date, time, etc.; other sensors will send other data, and perhaps in a different format). 
By subscribing to the Topic tx-o-kitchen, at each publication all the Subscriber will receive the message with the temperature. 
The subscriber can be here an Assistant or multifunction Hub, a display, or other. 
In summary: TXtemp publishes, the message goes to the Broker, the Broker distributes it to all Subscriber. 
Similarly, the control/command messages (eg switching on/off of an MQTT smart switch) consist of a Topic (containing the "name" of the recipient) and a payload (containing the action to be performed). Any MQTT client that has subscribed to that Topic will receive it, but it will be "executed" ie it will involve an action only by those devices designed to execute that particular command. 
For example the DoorOpen device is designed to listen on a standard command topic which name is derived from the name given to the DoorOpen in the Settings, for example a DoorOpen named "Garage" the command Topic will be 
and the related payload (or message) in JSON notation that triggers the opening is: 
Whoever subscribes to a command topic with the Broker is usually the device itself to be controlled, while whoever publishes the command messages in this case is usually a personal Assistant or Hub. 
The personal hub/assistant publishes (for example after your voice instruction, or a click on a icon), the message goes to the Broker, the Broker distributes it to the subscribers, including for example DoorOpen, which reads it and acts accordingly (e.g. by opening the gate). 
The Hub can also be a hardware (such as ControlHUB; which can also act as a Broker) and can in turn be controlled by an Assistant via MQTT. 
The subscribers listening on a given topic can be multiple; moreover, publishers can without limitations publish on the broker how many and which messages they want. There is no control over the source of the message: the broker simply receives them and then passes them on to anyone who subscribes to that given topic. 
The MQTT broker is usually unique, as it acts as a collector for the exchange of all MQTT messages related to the automation and usually resides on a specific computer, whether it is Windows-based, macOS or a Raspberry. Some systems and automation hubs have the broker already inside and ... we know at least one system that has this useful feature: our ControlHUB! For small systems you can take advantage of the already included Internal Broker without having to configure ANYTHING (for large systems you will have to use another broker). 
Alternatively, even if it is not a very safe solution, you can use an external Broker residing on the Internet (which can also be called "Cloud" to make figs). 
More on the MQTT broker and also on ControlHUB... 
There would be a lot of other things to say about MQTT, but this should be enough to make things work. 
Comments in the user's forum are welcome as usual ... 
Home page - WFeasy Hardware Solutions Home - Hardware by VisualVision 
VV Automazione Domotica MQTT 
(C) 2020 VisualVision