About MQTT and IoT Industries

One of the most commonly used TCP based protocols in IoT is the MQTT protocol. This protocol is easy to use. Its strengths are in machine to machine communication (with low data complexity and minimal response). The MQTT protocol recognizes two network entities.

Topics

Information channel that the client subscribes or publishes to. Topics are most often tied to specific data that the client collects e.g. temperature and humidity. As the topic is hierachical, it is possible to customize the topic to a specific location. For example:

• flat / temperature
• flat / thermostat status
• flat / humidity.

Deep Topic hierarchies are possible e.g.

• apartment / living_room / window_server_temperature.

Topics are case, but also character sensitive (watch out for spaces, backslashes). Another (or even the same) device can subscribe to the topic and perform an action based on the information (values) read.

Topics can be used for a number of scenarios from data recording (temperature, humidity) it can also be used to record and distribute current states (light status, thermostat status [ON / OFF]). Subscribed clients always have the up-to-date information on the topic when changes are published.

Brokers

A service that obtains messages from clients and distributes them to other clients (who subscribed to the relevant topic). Brokers enable communication, ensuring reliable delivery of the latest messages. Clients never communicate directly with each other.

The most common MQTT Broker for personal use (in a LAN network, in a smart home) is Mosquitto. This Broker is one of the most popular, used mainly in home automation systems - Hass.io or Domoticz.

Last Good Message

After messages are delivered to all known clients, nothing is retained by the broker. However, if a client publishes a message to a topic with a retain flag set to True, then the message is stored. New clients receive this Last Good Message upon subscription.

Cloud MQTT Brokers

The disadvantage of the Broker is that it is a physical device (or software emulated) and so most developers and IoT Engineers reach for a cloud solution, at least for testing purposes. The most famous are Google IoT Cloud, IBM Watson, Azure IoT and IoT Guru Live. These cloud MQTT servers are platform-specific, often require a login, an account link, and are limited to a fixed number of devices, and fixed number of topics.

Client

Often a microcontroller with a simple network stack that allows the device to connect to the Broker. The device sends (publishes) data to the network on the relevant topic. The device can also obtain data from the Broker - by subscribing to the relevant Topic. Hobbyist and Professional Programming of microcontrollers can be done in the Arduino IDE environment. Board support is installed in the environment by importing a package in the board manager. Support can be extended to Espressif based platforms such as the ESP8266 on the development board NodeMCU v3 Lolin and ESP32

Connecting to the server

IoT device specific client software connects to the MQTT server using a socket connection through WiFi. Libraries are available to connect to the WiFi network and establish HTTP connections.

• Using the PubSubClient library, it is possible to connect to MQTT Broker on port 1883 - unsecured port
• Using WiFiClientSecure library, it is possible to connect to secure MQTT port 8883 and then send a topic to the Broker or subscribe to one.

The client can also be another user device, such as a computer, which can subscribe using a web based or desktop application. Such a device can also send status updates, and other data to the network e.g. notify that a computer is turned on or the status of connectivity to the Internet.

Anonymous MQTT Brokers

There are freely available MQTT Brokers that are anonymously usable. After signing up to such a service, a user can send (Publish) the topics they want and also subscribe to topics.

Since free brokers generally do not require authentication, the Broker is shared by all users, it is possible to subscribe to any available topic from another device (with another user's data). Therefore, these broker are not suitable for secure implementations. They are suitable for testing and development purposes and mastering the functionality of communication with MQTT Brokers, and the related message types.

Example for Espressif boards on Anonymous Broker

The first step is to find information about the connection settings for connection with the MQTT Broker. With unencrypted connections, use the standard MQTT protocol 1883 and the MQTT Broker address. Add directives for the compiler (respectively for the preprocessor) to the codes, which, depending on the selected development board, dynamically assigns a linked library, which is used by the given microcontroller.

The source codes for ESP8266 and ESP32 are thus identical and fully transferable between these platforms. The program contains a counter that is incremented (so that the sent value is visibly changed). Data is sent to the topic: esp32 / counter every 10 seconds. The microcontroller also subscribes (but does not have to) subscribe to the same topic. This way you can check if the value in a given topic is changing.

This topic is then accessed by any device that is connected to the Broker and subscribes to esp32 / counter. If the client wants to subscribe to all topics that are available on MQTT Broker, it chooses topic #. The # grid character is similar to that used * in query languages (all).

As this MQTT Broker is public, you can see and modify data in all topics. This poses a safety risk, as temperature-based control systems can be dependent on the MQTT. For this reason, this MQTT Broker is mainly used for testing and development purposes. It is not suitable for use with a household connection to this MQTT Broker, as anyone can read your data or modify it in individual topics.

For testing, confirm that the Broker is fast, the response time is small, at the level of 30 to 50 ms with the processing of received data from the subscribed topic (time measured before the call and after the end of the function).