MQTT Instructions
What’s MQTT
MQTT is an open-source pub/sub communication protocol. It is efficient in its utilization of bandwidth and system resources. As a result, it is popular in use cases ranging from low-powered embedded systems to cloud-native micro services.
The pub/sub model is at the core of MQTT communication. Information is organized by topics. Client devices can publish data to a topic to send messages to any subscribers. Similarly, clients can subscribe to a topic to be notified when a message is published.
MQTT Use-cases
MQTT is popular in IoT and IIoT (Industrial Internet of Things) because it can be used across platforms while consuming minimal bandwidth. IoT devices usually have limited resources. Because MQTT implementations are more lightweight and efficient than other communication architectures (for example, an HTTP-based RESTful API), MQTT is often a wise choice for IoT.
MQTT Broker
In MQTT protocol there are two major entities: a broker and clients.
MQTT Broker vs MQTT Clients
An MQTT broker is a central software entity in the MQTT architecture. It acts just like a real estate broker which first does background checks on the parties involved and then after making sure that the relevant rules are enforced, the broker initiates a transaction.
Here’s how MQTT brokers facilitate transactions between MQTT clients:
1. Allow clients to make a connection request
2. Authenticate the clients
3. Stores messages within the server
Clients can be almost any “smart” device including smartphones, web apps, sensor nodes, actuators, or even smartwatches. Clients can:
1. Connect to a broker with a username and password
2. Subscribe to a topic (listen for messages published to that topic)
3. Publish to a topic (send a message(s) to that topic)
Configurations On 4G Solar Camera
Here I use the MQTTX to show how to use MQTT on 4G Solar Camera.
MQTTX Installation
1. Download the installation file: https://github.com/emqx/MQTTX/releases/
2. Install and run MQTTX program.
Implement on 4G Solar Camera
1. Create a new connection to subscribe messages. You can use the default host for free. More hosts can be found from List of Popular MQTT Brokers.
Name: Enter name as you want.
Client ID: Customize the Client ID which is not occupied on the server, or use random one by clicking the button on the right. It’s suggested to use a random client ID.
Host: Use the built-in hosts of MQTTX or hosts from List of Popular MQTT Brokers.
Username & Password: Define the Username and Password, which are the authentication of the connection to the server and used by the subscriber to receive MQTT message from the publisher using the same account.
Click “Connect” in the upper right corner and connect to the server.
2. Create a new subscription to receive messages from 4G Solar Camera. To test the connection, here I set the topic as below: 4GSolarCam/Status (More topics please refer to the appendix).
3. Enable Post in 4G Camera, set up configurations, and ensure that the host, username and password of the connection are the same as those in step 1.
4. Set the Encoding format as “JSON” and the topic as “4GSolarCam/Status/$MAC address$”. Input anything in the input box and click send. And then, information will appear on the dialog. It means the configurations on both MQTTX and 4G Solar Camera are correct.
Snapshot Decoding
1. Program used:"transfer.exe" (A kind of XXD software which can also be gotten in Mac OS).
2. Add a new subscription with “4GSolarCam/Snapshot” topic. And set the decoding format of received playload to Hex.
3. MQTTX will receive image data in Hex format from the 4G Solar Camera after snapshots have been uploaded.
4. Copy the data and save it as a textual file in “.txt” format.
5. Press button “Ctrl+F”, search “ffd8” or “ff d8”. Then delete the data before it and save the file.
6. Press button “Win+R” and run “cmd”.
Change directory to the program and text file, input command: “transfer.exe -r -p snapshot1.txt snapshot1.jpg”.
Then a file named “snapshot1.jpg” will be generated in the folder.
7. Command for PowerShell: “.\transfer.exe -r -p snapshot1.txt snapshot1.jpg”
8. Double-click on “snapshot1.jpg” to view the snapshot captured.
Appendix
4G Solar Camera MQTT Topics
* The following description “SC” stands for 4G solar device (SC211-NA/EU/AU);
* “Client” stands for Client device.
The topic is divided into 5 parts:
* Snapshot
* Alarm
* Wake
* Status
* Configuration
1. Snapshot
* Client needs to pre-sbuscribe to the 4GSolarCam/Snapshot
* "SC->Client",SC actively pushes the picture to the topic
* After the client receives it,it needs to parse the data and save the image data as "JPG"
eg: The content of the push map is as follows
2. Alarm
* Client needs to pre-subscribe to the topic 4GSolarCam/Alarm
* "SC -> Client", SC sends active alarms to this topic
* Client parses the content after receiving it
eg: The content of the alarm is as follows
3. Wake
* SC subscription topic 4GSolarCam/Wake/5CC5638AE24C where "5CC5638AE24C", is the SC's own MAC address
* "Client -> SC", in sleep state, Client sends any content to the topic to wake up the corresponding SC, such as ",wake",
* After the SC wakes up, it will automatically turn on "WiFi", and "4G", and you can log in to the web page
4. Status
* Client needs to pre-subscribe topic 4GSolarCam/Status
* "SC -> Client", after SC wakes up, it will actively send status information to the topic
eg: The status information is as follows.
* SC subscription topic 4GSolarCam/Status/5CC5638AE24C, where "5CC5638AE24C" is the MAC address of SC itself
* "Client -> SC", in 4G working state, Client sends "status" to this topic to get the status information of corresponding SC
* After SC receives the message, it will send the status information to the topic 4GSolarCam/Status
5. Config
* SC subscription topic 4GSolarCam/Config/5CC5638AE24C, where "5CC5638AE24C" is the MAC address of SC itself
* " Client -> SC", in 4G working state, Client sends different customized information to the topic to configure SC, as follows
* -"shutdown": close the application
* -"reboot": restart the application
* -"upgrade": Online upgrade
* After SC receives the message, it performs corresponding operations according to the content
More about MQTT
Types of MQTT Brokers
Generally, there are two types of brokers:
1. Managed Brokers
2. Self-Hosted Brokers
1. Managed Brokers
Managed brokers don’t require you to set up anything on your server to enable MQTT communication. Managed broker services let you use their hosted brokers for your system.
2. Self-Hosted Brokers
As the name implies, self-hosted MQTT brokers require you to install the broker on your own VPS or server with a static IP. The installation process is not difficult but managing, securing, and scaling the brokers requires in-depth knowledge of the system.
3. List of Popular MQTT Brokers
There are plenty of viable managed and self-hosted MQTT brokers available. Here is an overview of some of the most popular options.
Type | Address and Port | WebSocket Support | SSL Support | Scalability | |
Managed | Dynamically assigned | Yes, port=443 | Yes, port=8883 | Auto Scale | |
Self-hosted and Managed | test.mosquitto.org | Yes, port=8081,8080 | Yes, port=8883,8884 | Scale horizontally making bridges | |
Self-hosted and Managed | test.mosca.io | Yes, port=3000 | Yes, port=8883 | Horizontally and vertically | |
Self-hosted and Managed | broker.hivemq.com | Yes, port=8000,443 | Yes, port=8883 | Yes, Broker-Clustering | |
Self-hosted and Managed | self-assigned | Yes, port=9001,9002 | Yes, port=8883 | Both horizontal and vertical | |
Managed | Dynamically assigned | Yes, port=443 | Yes, port=8883 | Auto Scale | |
Self-hosted | Self-assigned | Yes, port=8083, 8084 | Yes, port=8883 | Clustering | |
Self-hosted and managed | Self-assigned and dynamically allocated | Yes | Yes | Clustering |
MQTT Message Types
Regardless of the type of broker, MQTT message types are similar. Here, we’ll take a look at the most common MQTT message types: connect messages, disconnect messages, and publish messages.
When a client initiates a connection with a broker a connect message is used. The connect message will include the following data:
clientID, cleanSession, username, password, lastWillTopic, lastWillQOS, lastWillMessage, lastWillRetain and keepAlive.
The first two variables, clientID and cleanSession, are required for all connection requests while all other variables are optional. The clientID should be a unique ID for each client.
A disconnect message is used when the client tries to disconnect a TCP/IP Session. If a disconnect message is set, a predefined message is sent before the complete disconnection.
Lastly, we have the generic publish message. Any client can publish a message to a topic so that the subscribed clients can be notified.
MQTT Broker Security
MQTT broker security depends on the implementation. MQTT brokers generally provide TLS encryption for secure communication between clients and brokers. The default secure MQTT broker ports are 8883 for MQTT and 443 for MQTT over WebSockets.
If you need any help, please feel free to contact Milesight support (support@milesight.com).