Blog 2 - MQTT - Davin Barron
Blog 2 - MQTT
About MQTT:
What the heck is it?
MQTT stands for Message Queuing Telemetry Transport. It is a lightweight messaging protocol which is used for machine-to-machine communication.
The idea is that there is a broker to handle the communication that receives messages and filters them.
Publishers are devices that send data, think temperature 🌡 and location 🌍
Subscribers are devices that want to receive that data such as a dashboard or a mobile app like IoT MQTT Panel.
Between them is a topic which is like the subject line used to route messages.
Publishers send data to the topic and subscribers subscribe to the topic to receive it :)
Where did it come from?
In 1999, Andy Stanford-Clark from IBM and Arlen Nipper from Arcom Control Systems put together the first version of the MQTT. The original idea was to monitor some oil pipelines with sensors.
Their goal was to have a protocol that is bandwidth-efficient, lightweight and uses little battery power, because the devices were connected via satellite link, which was extremely expensive at that time.
How is it used today?
Today, MQTT is used practically everywhere from smart homes, automotive devices, manufacturing machinery and social media apps like Facebooks Messenger.
This is thanks to how efficient and lightweight MQTT is!
That sounds awesome! But.. what is the catch?
One of the major concerns regarding MQTT is the fancy word we probably all heard a million times at this point is "Scalability".
The reason for this is that MQTT relies on a centralised broker which can become a bottleneck if network traffic becomes heavy.
MQTT Lab Work
During this week's sprint, we learned about how MQTT can be used in IoT applications using Micro:bit. During our lab sessions, we set up a Master-Slave architecture using Micro:bits connected to an MQTT broker hosted on a BeeBotte server.
To interface with the hardware, we used a mobile application called IoT MQTT Panel, which allowed us to communicate data from the app directly to the Micro:bits in real-time.
Setup
We began by installing the IoT MQTT Panel app and configuring the connection settings to point to our BeeBotte server.
Then we hooked up the Micro:Bits to a computer and downloaded the following slave program to them.
This program is designed to send sensor data via Radio to a Master Micro:bit, which acts as a gateway. The Master then packages this data into JSON payloads and publishes them to a specific topic on the MQTT broker.
We added some widgets to the IoT MQTT Panel app and tried some additional panels to allow for subscribing and publishing to the MQTT server.
The dials showed the tilt of the Micro:bit and the slider allowed us to send a number to be displayed on the Micro:bit LEDs. We also included a debug panel to monitor the raw JSON payload information.
What was cool was that we can actually connect to the other Micro:bits that were also connected to the server as seen from the multiple lines on the graph. These lines display the tilt information on each of the Micro:bits that I connected to, pretty awesome if you ask me! 😎
Alternative ways to connect to an MQTT Broker
For one of the workshops, we were tasked to investigate alternative ways to interact with an MQTT broker. Something I tried was creating a python script to send JSON information to the MQTT broker using a module called paho.mqtt. I tried to retrieve JSON information and save it to a CSV file which we can use for debugging issues.
I also tried my hand at publishing temperature and humidity data using another script which may or may not have crashed the server haha but it did work 😅
Debugging
During our class time, we had the opportunity to play around and tinker with MQTT and we encounter an issue with the schools/input topic. The JSON strings that we got had extra braces 😱
We tried different approaches such as changing the buffer time between messages and adding in a J for debugging to see if it would have any extra braces. The J had no issues so it shows us that there was an issue with the actual JSON string. Hurray for J! 🙌
We discovered that the string slicing logic (length - 21) didn't account for the exact structure of the incoming JSON message. By changing the slicing to (length - 22), this removed the extra brace.
An earlier patch we made was to make the input an absolute value and add 1000 which worked! The reason for this is the numbers are now consistent in length.
We also experienced a similar issue for the output/schools JSON string. The problem we found was how we hardcoded the index (message.index_of(":") + 1) and a fixed length of 9 to find the value.
proposal for next sprint...????
Comments
Post a Comment