Blog 2 - MQTT - Igor Kapusniak
Blog 2 - MQTT
What is MQTT?MQTT is a publish-subscribe messaging protocol. It was designed primarily for use in situations where network bandwidth is limited, unreliable or has high latency, such as Internet of Things (IOT) devices.
It operates over TCP/IP and has very little overhead which makes it ideal for running on edge devices with little processing power and memory, like sensors and embedded systems.
Devices communicate by publishing messages to topics and subscribing to topics of interest on a central server known as a MQTT Broker.
Usecases
MQTT has many real world practical uses cases the most common areas where MQTT would be applied would be Smart Home Systems, and Industrial, Agricultural, Environmental Monitoring.
In smart home systems devices such as thermostats, light sensors use MQTT to publish their values to the cloud from which devices like heat pumps or lights can subscribe to and behaviour accordingly.
For monitoring MQTT is used accross many industries to collect and publish data from factory equipment, soil moisture sensors and weather stations.
Constraints
Although MQTT has many advantages over other methods of data transfer over the internet, it does lack in some areas such as security, broker is a single point of failure, Reliability, and Low throughput.
MQTT has no built in encryption by default, this means that if the message is intercepted by an unwanted party it can be read by them as the message is sent in plain text.
The MQTT Broker is a centralised server that all messages sent to and read from. This makes setup of a broker easy however since all subscribers and publishers are reliant on a single server it makes it a single point of failure. This means that the whole MQTT network stops functioning if the broker goes down.
Reliability and Throughput are not very compatible with MQTT. With higher levels of reliability the protocol introduces significant overhead in terms of message persistence, acknowledgements and broker memory usage. This is because multiple round trips are required between client and broker (publish -> store -> send -> ack -> deliver). This significantly slows down throughput and increases latency. As the number of messages or the size of payloads grows, the broker becomes a bottleneck, and throughput drops sharply.
With lower levels of reliability there is a risk of data loss as the client does not know whether their sent message has arrived or not.
Lab
For this week's lab we set up a MQTT demo using microbits, a microbit board for cloud and the IOT MQTT Panel mobile application. The goal of the lab was to use MQTT to transfer data between the microbits and the IOT MQTT Panel application.
Lab setup
The first step was to download the IOT MQTT Panel mobile application and set up a dashboard using the provided broker address, port, username, and password. This allowed us to publish and subscribe to the MQTT broker.
Next we flashed the following program onto our microbits. The program sent data using radio with the master microbit connected to the board for cloud. Both reception and transmission from the microbit was possible.
The microbits sent JSON payloads to the master microbit which then published the message to a topic on the MQTT broker. When the microbits received a message that is was a number, the number would be display using their LED matrix.
Lastly we added widgets to the IOT MQTT Panel app which allowed for both subscribing and publishing to the MQTT broker. Using the Dial widget we were able to track the tilt angle of the microbits. The slider allowed us to publish number values that the microbit would subscribe to and displayed on the led matrix. The graph widget displayed the same information as the dial but provided a history of past values. The text widget allowed us to see all the data being published to the broker under a specific topic.
In conclusion this lab demonstrated full end to end communication from a IOT device (microbit) to a mobile application and back. It allowed for data to be published to the MQTT broker either through adjusting the tilt angle of the microbit or adjusting the slider value on the app, and subscribing to data was demonstrated through the graph, dial, and text widgets on the app and through the led matrix on the microbit.
Code Explanation
Client
The clients code can be divided into 3 sections
1. on start
This code is run only once at the start when the microbit boots, the purpose of this is to the the correct radio channel so that both the master and slave microbits are communicating on the same channel.
2. Forever
This is a loop that runs infinity until the program is stopped. The purpose of this code is to flash a LED in the centre of the LED matrix, this lets the user know if the program has loaded successfully and whether the code is still running.
3. on radio received
This piece of code waits for data to come in on the radio channel, once data from the radio is received there is a check performed to make sure the message sent is meant for this specificc microbit (in this case output3). If the message is meant this microbit the value is extracted and displayed on the LED Matrix. A led in the bottom right corner is flashed. Upon reception of the message the rotation angle of the microbit is sent to the master microbit. This data is then published to the mqtt broker throught the use of the cloud board.
Master
The master microbits code can be divided into 4 section: setup, MQTT Subscriber, radio message parsing, and message sending.
Setup:
Using on startup we can define constants and set up connections to an internet access point, MQTT broker, and the radio group to listen on.
MQTT Subscribing
Using the MQTT library and by subscribing to a topic data is pulled from the broker. Upon reception of a message a debug LED is triggered indicating a received message. Next the message is parsed for the number that was sent and for the id the message was meant for. Finally the id and number is broadcast via radio to the client microbits.
Radio Message Parsing
This section is responsible for receiving radio messages broadcast from the client microbits and publishing the message on the MQTT broker.
When data is received via radio 1000 is added to the received number (This was a fix to a bug which caused the final character to be duplicated if a message was shorter than a specific length).
Next using the name of the client device which sent the message and the patch_value a JSON string is created and published to the MQTT broker.
Finally based on the id of the device that sent the message a corresponding LED is flashed.
Python and paho library
To further expand upon the functionality from the lab I wrote a python script that used a library called paho to enable communication with MQTT brokers. The script was able to both publish data to the broker as well as subscribe to specific topics.
Having a python script communicating with a MQTT broker is extremely powerful especially compared to the IOT MQTT app as it allows for almost limitless possibilities for project ideas. For example using a library called smtplib emails could be sent to someone when the microbits detect a specific action, or the data could be logged in a database either on device or in the cloud.
Identified Issues
While developing the python script I found 2 errors in the code for microbit connected to the cloud board. If a microbit was used to send a letter or a word instead of a number the cloud board seems to freeze up not allowing any more data to be published from the microbits. Secondly there is a syntax error on the JSON object sent from the IOT MQTT Panel which work now because the data is sent as a string and not an actual JSON package but if an actual JSON package is sent then the cloud board is unable to parse it and the data is not published leading to the board freezing up again.
Comments
Post a Comment