Blog 2 | MQTT | George Lipceanu

February 13th, 2026.

This week's sprint focused primarily on MQTT and using it to get a master-slave setup between a set of Microbits to communicate with a Beebotte MQTT broker. 

MQTT - What is it, Where it used, Pros and Cons

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe network protocol designed for peer to peer and IOT communication. It is an OASIS standard protocol, which is a list of standard protocols used across the computing industry. It is lightweight and efficient, allows for bi-directional communications and reliable message delivery through it's pub/sub architecture. It is primarily used in Smart devices and in IoT systems due to it's lightweight nature. 

    According to this article published on TencentCloud, some of the biggest flaws in MQTT include messages getting lost between broker and client and the broker not being able to handle a large amount of devices (which is where one might consider adding more brokers and balancing load across these). MQTT also does not inherently provide encryption for data in transit, but it is SSL/TLS compliant and can be configured to use this (although this adds extra complexity and overhead, adding weight to the system).

MQTT in the Lab

As this week was focused on MQTT, the aim of the lab was on connecting a master-slave system of Microbits to an MQTT broker, which then relays the data being passed through to a client device for use in logistics and observability. The slave nodes were connected to the master node using the radio field within the Microbit JavaScript/Python package, allowing the system to communicate wirelessly. 

The master node would then connect to the Beebotte server in order to send and receive MQTT inputs and outputs.

The IoT MQTT Panel app was used to connect our phones the Beebotte MQTT broker and be able to read the inputs and outputs coming in from the master and also allowing our phones to send inputs back to be used in the system.

The first figure above shows the tilt of input 1, a debug panel with all inputs being printed, the tilt of my own Microbit that I was using (input 2) and a line graph showing the tilts for input 2 and 3, which was information that was acquired through subscribing to the schools/inputs topic. The second figure shows an output slider for my Microbit, a debug screen for all of the outputs being sent from slave to master and another output slider for input 6. Putting a value into this slider would cause the corresponding Microbit to flash the number that has been inputted.

Independent Lab Work

Our group was then split off to find other services that could connect to the MQTT server, with the ultimate goal of being able to send an email if a Microbit were to tilt more than a certain amount. Although I went down a few rabbit holes looking into services like IQTTT, AWS SES and Firebase's email service, I found a simpler way to connect to the server using Node-RED. Node-RED provides users with a graphical way of creating connections and linking them to functions, including MQTT. I managed to run a container running Node-RED and got it connected to the Beebotte server, where I was able to filter through each input in schools/inputs using the switch block, which, combined with the bug fixes for JSON parsing (covered in the next section), will allow for the parsing of specific tilt values of each Microbit, which can then be linked to a function that sends emails depending on the tilt. 

NOTE: This is a very rough flow at the moment, all that is working is the input filtering as of right now but I plan to implement the rest of the flow to trigger an email send. Another thing to look into within Node-RED is to be able to use some type of trigger or input to send inputs from the Node-RED container to the MQTT broker to display something on the Microbit itself, similar to how it was done using the IoT MQTT Panel app.

Debugging and Bug-Fixing

When doing this independent learning, the team found an issue with how the server was sending and receiving JSON inputs and outputs, which we planned to handle in the next lab. Regarding schools/inputs, it was noted that there were extra closing braces in some of the JSON messages, making these invalid JSON objects. We believe that the reason for this is because when an input with a tilt with 2 digits is received by broker, the extra brace will begin to appear for inputs with 1 digit. So each time there is an extra input is received, the n-1th digit inputs will receive an extra brace relative to the input that has had the most amount of digits/characters, with the highest being 4 digits (-xxx). Since we knew that 180 or -180 would be the highest and lowest possible values, we simply only sent the absolute value of the tilt plus 1000 within the master microbit code, to ensure no extra characters are added into the JSON messages. This seems to have fixed the issue.

    There was also an issue with the sending of outputs, since the master code seemed to only respond to it's own string format (without a comma between the fields within the object), which was an invalid format of JSON. This was fixed within the master code by changing the amount of characters that are parsed to account for an extra character (the comma itself). Now with this, the Beebotte system can read these messages and use them as JSON outputs to be displayed on the slave nodes.

Proposed plan for next sprint..