The client modules communicate with the bridge module using the ESP-Now protocol. ESP-Now allows devices to communicate wirelessly with each other using Wi-Fi without the help of a router. This is an energy-efficient way of communication and will help the modules to perform for a longer period of time. When the push button is engaged, the data is sent to the bridge module. The bridge module is connected with both the clients as well as the gateway. The serial communication between the bridge and the gateway ensures data communication. The gateway handles the message between the MQTT broker and the bridge module. It also handles the encryption and decryption of the messages, which increases the security of the network. The gateway communicates with the broker over MQTT protocol based on the sender-receiver topics. The public MQTT broker used in this application is Mosquitto test server. A Node-Red platform is connected to the broker as well to handle data and send new settings.
The Node-Red platform receives the data from the MQTT broker and will perform data handling and associated functionalities. It is also associated with a dynamic dashboard, through which data can be visualized using various tools. The docker tool helped us to host the Node-Red platform locally, for faster development and access to data. The dashboard can also be used the sent the commands from the cloud platforms to the MQTT broker and from there to the microcontrollers via the gateway. The IoT applications can access the cloud-hosted Node-Red to present the data to the user and for robust control of the network.
The MQTT protocol is suitable for communication over constrained networks, which may face low bandwidth and frequent connection drops. It works on the principle of message and events. Messages from the controller are published by the gateway into the event topic, it will be accessed by the cloud application which subscribed to the event topic. If the topic in which the message is published matches semantics, data is analyzed and displayed. The cloud application can also publish into an order topic. The gateway is subscribed to the order topic and will apply settings sent if they are recognized like activation or deactivation of the system as well as setting the refresh rate. Then the gateway handles its settings and potentially transmits data to connected network members. However in real-life applications a private and secured MQTT broker should be used, as a public broker is accessible by everyone.
Clients
Bridge
Gateway
MQTT broker
NodeRed
Tools
Every client nodes have their own ID that should be unique and set up per board in the code before building and flashing the software on the board.
Clients have connected to the bridge thanks to ESP-NOW communication.
Even if the client does not use the serial port to communicate data, the serial port is used for debugging, notably in the ESP-NOW callback function.
The GPIO pin corresponding to D1 is set up for the program to be able to read it and every time the pin is sensed and detect the button is pressed, we try to send the board's ID 10 times until just give up.
Finally, the board goes to sleep, and thanks to the D0 to RST cable the board is able to wake up thanks to the real-time clock after the deep sleep function is called with a 5 seconds delay.
The bridge node is configured to be the "one" node in a "many" to "one" ESP-NOW communication.
The main loop is empty, just containing a delay to avoid some CPU usage.
This is because everything is handled in the ESP-NOW callback which is run concurrently.
The callback just transmits the ESP-NOW data through the serial cable.
Some special values are also be sent but this will be explained in the gateway part
Contrary to the two previous parts written in C++, the gateway is a simple python program reading its configuration from a configuration file in the ini format.
It is connected to the MQTT broker using TLS for encryption to improve the security of the communications.
The python eclipse paho library allowed us to handle MQTT communication easily
Refresh and enable/disable settings are given to the gateway through a special MQTT topic the gateway is subscribed for.
The gateway reads bridges transmitted data from every serial cable in the configuration, this gateway can handle multiple bridges.
Special values exist for the gateway to know if the bridge is ready or if an error occurred.
When the gateway received the board value the gateway serializes a JSON object containing a board ID and the current time-stamp and sends it to a specific MQTT topic, different from the one used for settings.
The official mosquito broker, test.mosquitto.org was used.
It is perfect for this experimental work but the sent data is public and so this should not be used in real life.
The data sent by the board is only using the MQTT QoS 0 as it is not dramatic if detection fails if another is done in a short amount of time later on.
For the settings sent to the gateway, however, the QoS is set to 1 as it does not matter if the same setting comes multiple times, but we want to ensure it has been received.
NodeRed allowed us to read and send data easily from the MQTT broker topics used by the gateway.
The dashboard module allowed us to control settings and to visualize data in an easy way.
To develop and flash the board, the platformIO VSCode extension allowed us to efficiently develop the board software with the Arduino libraries
Our NodeRed Instance was also hosted locally in a Docker container, to allow fast and flexible development.
A full setup can be made for a production-ready system