Servers
MQTT
MQTT is the preferred protocol standard for communication between components of an IoT solution. It is an asynchronous messaging protocol that uses servers known as brokers. It follows a publish-subscribe (pub-sub) model and uses what are known as topics as the channel for communication.
To use MQTT, boards must have WiFi capability and be connected to a WiFi network. Sensors connected to the board will publish their data to a topic on an MQTT broker and the app will subscribe to the topic. Whenever the sensor captures any data it is displayed on the app through this pub-sub approach. In the other direction, the app will publish a control signal to a topic on an MQTT broker and the microcontroller that has subscribed to the topic will receive the signal and change the device state as required.
Manage Servers
There are multiple public MQTT brokers on the cloud that are free to use, we will use the one from HiveMQ.
Note that public MQTT brokers do not guarantee persistence or security of data. Do not ever post any confidential data on such brokers. Many of these brokers offer an alternative to set up a private and secure broker, generally at a cost but with some free trial options. Private and secure MQTT brokers that work with a user id and password for authentication are easier to set up and are supported by the mobile app. Brokers that require certificates for authentication are currently not supported by the mobile app.
Servers in this context are the MQTT Brokers. There are several public MQTT brokers on the cloud you can use for free, or you can have a private broker on the cloud at a cost, or you can run your own MQTT broker on your local computer.
MQTT Brokers use two main protocols:
- MQTT over TCP (for native apps) and
- MQTT over Websocket (for browser and mobile apps).
Both protocols further support secure (TLS) and unsecure communication. Brokers listen on specific ports for each protocol. While there are some standard ports, brokers may use any port of their choice (which they will specify in their documentation). Private brokers also require authentication credentials, either a user id and password, or certificates.
We will be using the following public MQTT brokers to test the app:
| Broker FQDN | Port | Protocol | User Id/Password |
|---|---|---|---|
| test.mosquitto.org | 8080 | Websocket Unsecure | Not required |
| broker.hivemq.com | 8000 | Websocket Unsecure | Not required |
| broker.hivemq.com | 8884 | Websocket TLS | Not required |
| broker.emqx.io | 8084 | Websocket TLS | Not required |
When configuring MQTT servers in Node-RED use the TCP protocol (and corresponding port) since the connection is being made through Node.js code.
To create a server enter the following details in the form:
- Name
A short name to identify the server. - Description
A short description of the server. - Protocol
Select from the list of supported protocols. - IP Address
Optional, can be used if you are running a local server. - Broker FQDN
Fully Qualified Domain Name similar to those in the list above. - Port
A standard port is pre-entered based on the selected protocol but can be edited. - MQTT URL
This is the complete url with the protocol, FQDN, port, and required suffixes. It is pre-generated based on the values entered but can be edited as specified in the broker documentation. - User Id
Optional, generally required for private brokers. - Password
Optional, generally required for private brokers along with user id. - Enabled
The server is enabled by default but can be disabled if you don't want to use it for a while.
See the screenshot of the Manage Server page below:
Server List View
The server list view shows all the servers with their details and status. You can connect and diconnect from servers as required. See the screenshot of the Server List below.