A brief crash course on the basics of MQTT and why it’s a great option for building 'location aware' systems.
MQTT - or Message Queueing Telemetry Transport - is a lightweight messaging protocol that has gained massive popularity in recent years, especially in the context of IoT (Internet of Things) systems. Its adoption by the IoT community is largely due to MQTTs incredibly modest throughput requirements, making it ideal for low bandwidth, high latency environments where system load and battery life are crucial for the ongoing operation of low power sensors connecting with the cloud and to one another.
MQTT uses a publish/subscribe model where messages are communicated over different channels, called “topics”. Your basic MQTT system consists of multiple clients and a single MQTT broker. If some of that sounded like nonsense, let’s go right ahead and deconstruct a few of those concepts.
A client could be anything from a simple IoT device such as a temperature sensor or our Spotto B1 Reader, a mobile device viewing live updates on-screen, or a backend application listening to updates to kick off a workflow. Clients don’t connect directly with one another, at least not via MQTT, instead they connect via a broker.
The MQTT broker can be thought of as a server responsible for connecting clients together. The broker receives messages from clients that publish to a given topic, then forwards them on to any client subscribed to the same topic.
A topic is a communication channel in which data can be sent (by a client publishing), and received (by a client subscribing). Topics are identified by a string, kind of like URL endpoints in the context of HTTP. If we want to hook up a temperature sensor, perhaps we’d have the device publish a message like { temperature: 32 } to a topic named my_temperature_sensor, with which a client could subscribe to receive temperature updates. Subscribers only have access to the last message published to a topic. When a new message gets published to the same topic, it overwrites the prior message, and so on.
Since topics are really at the core of communication over MQTT, let’s dig a little deeper.
MQTT topics can be split into levels using the / character. There is a limit of 128 topic levels in the MQTT spec, which should be more than enough to satisfy any use case. Use topic levels to get granular control over where messages are routed, which becomes particularly important at scale, or to help better represent the natural hierarchy of how publishers/subscribers relate to one another. Using our above example, imagine you had a number of temperature sensors, perhaps installed at different locations in your home. You could have your fleet of sensors each publishing to their own topic:
ground_floor/living_room/sensor1
ground_floor/kitchen/sensor2
first_floor/bedroom1/sensor3
first_floor/bedroom2/sensor4
Special wildcard characters can be used when subscribing to topics, enabling messages across multiple topics to be received by a single connection. You cannot publish to multiple topics using a wildcard.
The # character can be used to subscribe to all topics underneath a level of the hierarchy. Using the above example, a subscription to ground_floor/# will receive all messages published to topics that start with ground_floor, ignoring any of the first_floor sensors.
ground_floor/living_room/sensor1 ✅
ground_floor/kitchen/sensor2 ✅
first_floor/bedroom1/sensor3 ❌
first_floor/bedroom2/sensor4 ❌
You can also subscribe to the very top level i.e. all messages published to the broker. The topic name for this would simply be #. Note that the hash wildcard must be the final character in a topic subscription and cannot be followed by a topic suffix i.e. ground_floor/#/sensor1 is invalid!
The + character can be used to substitute a particular level of the hierarchy. For example, ground_floor/+/sensor1 will match any room on the ground floor with sensor1, which would yield only ground_floor/living_room/sensor1, from the above list.
ground_floor/living_room/sensor1 ✅
ground_floor/kitchen/sensor2 ❌
ground_floor/kitchen/sensor1 ✅
ground_floor/study/desk/sensor1 ❌
first_floor/bedroom2/sensor1 ❌
Notice here that ground_floor/study/desk/sensor1 does NOT match, this is because the + wildcard covers only a single level of the topic hierarchy.
MQTT is designed to be used at scale and can be trusted to support massive workloads simply because of how lightweight the protocol is. The compute demands of an MQTT server would be orders of magnitude lower than an HTTP server facing the same amount of traffic. MQTT also has a number of built in optimisations that further reduce the load on the system. For example, the broker discards messages that are published to a topic that has no subscribers, reducing unnecessary traffic.
In many cases, only a single MQTT broker is required, that can be scaled up with additional compute as the traffic demands, however in more complex implementations, or where high availability is a must, multiple brokers can share the load. Brokers can communicate with one another and share topics via a connection known as a bridge.
So now we know a little about MQTT, why does it matter in the context of Spotto?
Spotto actually has it’s own MQTT broker that you can connect to as a subscriber and receive updates from Spotto in real time! We publish all significant updates that occur within Spotto to a secure topic that only your account can access, with read-only permissions. This has a major advantage over HTTP as you don't have to keep polling an endpoint to receive updates, instead when a change happens, your application gets notified, all with minimal overhead.
Hooking into the Spotto MQTT stream could make your applications location aware. Take for example, a high value asset moving outside of a security zone, this could trigger a workflow that sounds an alarm or notifies someone. The possibilities are truly endless. To get set up with the Spotto MQTT broker, read this guide.