# What Is MQTT? See a Live Feed in Minutes

> How MQTT works: brokers, topics, wildcards and publish/subscribe, shown with Helsinki's public transit feed so you can watch a live feed with no hardware.
>
> MQTT · June 16, 2026 · by Alex Spataru · https://serial-studio.com/blog/what-is-mqtt

MQTT is the messaging protocol that quietly runs a large part of the connected world, from home-automation sensors to industrial telemetry. If you have seen it mentioned in IoT tutorials and never quite pinned down what it does, this is the short version, followed by a way to watch a real MQTT feed in a couple of minutes without buying anything.

## The idea: publish and subscribe

Most networking you have met is request/response. A client asks a server for something and the server answers. MQTT works differently. It is a *publish/subscribe* protocol, and the key move is that publishers and subscribers never talk to each other directly.

There are three roles:

- **Publishers** send messages.
- **Subscribers** receive messages they have expressed interest in.
- A **broker** sits in the middle. Every message goes to the broker, and the broker forwards each one to whoever is subscribed.

This decoupling is the whole point. A temperature sensor can publish a reading without knowing or caring who is listening. A dashboard, a database, and an alerting service can all subscribe to that same reading independently. You can add or remove either side without touching the other.

MQTT was designed in 1999 for constrained, low-bandwidth, unreliable links, and that heritage shows: the protocol is small, the message overhead is tiny, and it runs happily over a flaky cellular connection.

## Topics: how messages are addressed

Publishers do not send to a subscriber, they send to a **topic**: a hierarchical string with levels separated by slashes, such as `sensors/kitchen/temperature`. Subscribers ask the broker for the topics they want.

Two wildcards make subscriptions flexible:

- `+` matches exactly one level. `sensors/+/temperature` catches the kitchen and the bedroom, but not `sensors/kitchen/humidity`.
- `#` matches everything below a point. `sensors/#` catches every reading from every room.

A few other features round it out: quality-of-service levels (0, 1 and 2) trade delivery guarantees against overhead, *retained* messages let a new subscriber immediately get the last known value on a topic, and a *last will* message lets the broker announce that a client dropped off unexpectedly. You can go a long way knowing only topics and wildcards.

## Watch a real feed, no hardware needed

The clearest way to understand MQTT is to see one. Helsinki's public transport authority, HSL, publishes the live position of its entire fleet on an open MQTT broker. Around 1,500 buses, trams and trains report their position roughly once a second, and anyone can subscribe anonymously.

The connection details are public:

| Setting | Value |
|---|---|
| Host | `mqtt.hsl.fi` |
| Port | `1883` |
| Topic | `/hfp/v2/journey/ongoing/vp/#` |
| Auth | none (anonymous) |

Each message is a small JSON object describing one vehicle:

```json
{
  "VP": {
    "veh": "6314",
    "desi": "550",
    "lat": 60.21472,
    "long": 24.93021,
    "spd": 12.4,
    "hdg": 188
  }
}
```

The trailing `#` on the topic subscribes to every vehicle at once, which is that firehose of 1,500 messages a second in action.

## Seeing it on a map

To watch this you need an MQTT client subscribed to the broker. Serial Studio's MQTT subscriber connects to `mqtt.hsl.fi`, subscribes to the topic, and maps each `lat`/`long` onto a live map widget. Serial Studio ships a ready-made [HSL project](https://serial-studio.com/examples#MQTT%20Subscriber%20Example) for this: open it, press Connect, and after the next position update arrives the map zooms to a moving vehicle. MQTT is part of the Serial Studio Pro build.

There is one detail in that example worth calling out, because it teaches something true about MQTT. The broker delivers a continuous byte stream, not neatly separated JSON objects, so the project's small parser keeps a buffer, finds each complete `{ ... }` message, and emits one dashboard row per vehicle position. A single `TARGET_VEHICLE` constant then filters the 1,500-vehicle stream down to the one bus you want to follow:

```js
const TARGET_VEHICLE = "6314"; // change to track a different vehicle
```

That is MQTT in miniature: a broker fanning a high-rate stream out to anyone who asks, and a subscriber taking exactly the slice it cares about. Once you have watched a bus move across the map, the protocol stops being abstract.

## Frequently asked questions

### What port does MQTT use?

The standard port is 1883 for plain MQTT and 8883 for MQTT over TLS. Brokers that accept MQTT over WebSockets (so a web page can subscribe) usually listen on a separate port that varies by broker. The HSL feed above uses plain 1883.

### How is MQTT different from HTTP?

HTTP is request/response: a client asks, a server answers, and the connection's work is done. MQTT keeps one long-lived connection open and pushes messages as they happen, so nothing polls. The overhead is also far smaller; an MQTT packet header starts at 2 bytes, which matters on battery-powered or metered links.

### Do I need to run my own broker?

Not to learn. Public test brokers such as `test.mosquitto.org` and `broker.hivemq.com` accept anonymous connections, and open data feeds like HSL's give you real traffic to watch. For a real project you would run your own (Mosquitto is the usual choice and runs on a Raspberry Pi) or use a managed cloud broker, because public brokers offer no privacy and no uptime promises.

### Does MQTT guarantee delivery?

Only as much as you ask for. Each message has a quality-of-service level: QoS 0 is fire-and-forget, QoS 1 retries until acknowledged but can deliver duplicates, and QoS 2 delivers exactly once at the cost of extra round trips. Telemetry that updates every second is usually fine at QoS 0, since the next reading supersedes the lost one anyway.