Fazley RabbiMQTT is a lightweight messaging protocol that lets IoT devices send and receive small messages through a central server called a broker. A sensor "publishes" a reading to a named topic, such as farm/shed1/temperature, and anything that has "subscribed" to that topic, such as a dashboard, an alert service or a fan controller, receives it almost at once. It was designed for weak, unreliable connections and small devices, which is why it is so common in IoT.
The post office analogy
Think of MQTT as a post office with labelled pigeonholes.
- Publishers drop letters into a pigeonhole. A temperature sensor publishes its reading.
- The broker is the post office. It receives every letter and knows who wants which pigeonhole.
- Subscribers have asked for copies of everything in certain pigeonholes. A dashboard subscribes to temperature; an alert service subscribes to the same topic and checks the value.
The important point is that the sensor does not need to know who is listening. Add a second dashboard or a new alert next month and the sensor's code stays the same. That separation keeps small systems simple and lets them grow without rewiring everything.
Following one reading from sensor to phone
Take a hypothetical poultry shed near Natore with a temperature sensor and an exhaust fan.
- An ESP32 board reads the sensor every minute.
- It publishes the value to the topic
farm/shed1/temperatureon the broker, over Wi-Fi or mobile data. - The broker passes the message to every subscriber of that topic.
- The dashboard updates the chart. The alert service compares the value with the limits the farm owner set.
- If the reading is outside those limits, the alert service sends a message to the manager's phone.
- Commands can travel the other way too. The controller subscribes to
farm/shed1/fan/command, so an "on" message from the dashboard reaches it quickly.
Control like this always needs a safe fallback and local switches. Monitoring adds to proper ventilation equipment and good husbandry; it never replaces them. The poultry shed climate monitoring page describes a full set-up.
Words you will hear
Topic
A text label with levels separated by slashes, like a folder path. Good topic names follow a plan (site, area, device, measurement) so that everyone can read them. Subscribers can use wildcards to receive whole groups of topics at once, for example every reading from one shed.
QoS (quality of service)
Each message can be sent at one of three levels: at most once (fast, may be lost), at least once (repeated until confirmed, may arrive twice) or exactly once (slowest, most careful). Routine readings often use the lowest level; alarms and commands usually deserve more care.
Retained message
The broker can keep the latest message on a topic and hand it to anyone who subscribes later. A dashboard opened in the morning then shows the last known value straight away instead of a blank screen.
Last will
When a device connects, it can leave a "last will" message with the broker. If the device drops off without saying goodbye, because of a power cut or lost signal, the broker publishes that message. This is a simple way to learn that a device has gone offline.
Keep-alive
Devices send small signals at regular intervals so the broker knows they are still connected.
MQTT or ordinary web requests?
Many devices could instead send readings to a web address, the way a browser loads a page. Both work; they suit different jobs.
| MQTT | Web requests (HTTP) | |
|---|---|---|
| Connection | Stays open | Opens and closes each time |
| Sending commands to a device | Arrives quickly | Device must keep asking |
| Message overhead | Very small | Larger |
| Best fit | Many devices, frequent small readings, two-way control | Occasional uploads, simple one-way reporting |
MQTT needs an internet-style connection such as Wi-Fi or mobile data. Very low-power radios like LoRa usually send to a gateway first, which then often forwards the data using MQTT. The article on IoT connectivity options explains those links.
Keeping MQTT secure
An open broker on the internet is an invitation to trouble. At minimum:
- Encrypt the connection with TLS, the same technology that protects websites.
- Give each device its own username and password or certificate, never one shared login.
- Limit what each device may publish and subscribe to. A sensor should not be able to send fan commands.
- Keep the broker software updated, and do not leave test settings switched on.
More on this in IoT security basics.
Questions to ask your developer
- Where will the broker run: a cloud service, a server we control, or a device on site?
- What is the topic plan, and is it written down?
- Which messages use which QoS level, and why?
- How will we know when a device goes offline?
- How are devices authenticated, and what happens if one is lost or stolen?
- What happens to readings while the internet is down?
If the answers are clear, the foundation is sound. If you are planning a monitoring or control project and want a second opinion on the design, my IoT device development service can help.