“Using an RPi as the MQTT broker. We’ll explore 2-node communication as well as LWT messages (last will)
Story
In any IoT project we have a number of unique requirements and restrictions. The communication strategy to connect devices and send data between them is critically important.
In this guide we will explore a powerful, simple and lightweight messaging protocol over the wire: MQTT
Originally published on my blog.
What’s The MQTT Protocol?
In the embedded world, we assume by default that the end-devices are going to work under a variety of processing capacity, energy or communicationconstraints. And specifically on the subject that concerns us in this post, how we are going to implement the communications of our system is going to have a direct implication on the consumption of resources and energy of the devices.
In this guide we are going to explore MQTT, a lightweight communication protocol over TCP invented in 1999 by Andy Stanford-Clark from IBM and Arlen Nipper from Arcom, initially designed for battery-operated devices to supervise oil pipelines. Later in 2010, IBM released it as a royalty-free protocol. In 2014, OASIS announced that the MQTT v.3.1.1 had become an OASIS standard and a lot of MQTT clients were developed for all programming languages.
The most commonly used broker is the Eclipse’s Mosquitto library: an open-source implementation of the MQTT v3.1 and v.3.1.1 standards providing a lightweight method to transport messages, enabling the pub/sub pattern for low power sensors, mobile devices, embedded computers, and microcontrollers. You can install the Mosquitto broker on your PC as well as on any embedded system with Linux support, such as the Raspberry Pi.
Main Features
Data agnostic: you can use it to send sensor data, images or even OTA (over the air) updates
Lightweight and bandwidth efficient: smallest frame is only 2 bytes long
Per-queue QoS levels
Runs on top of the TCP/IP stack, so you can use it to encrypt the data with TLS/SSL and to have a secure connection between clients
Simple to develop: clients exist for all operating systems and programming languages
Central broker: different devices can communicate with each other without having to worry about compatibility
Session awareness: provides an identity-based approach for subscriptions
Flexible subscription topics using single-level and multi-level wildcards
Basic Terminology
Broker: the software application that receives messages from publishing clients and routes the messages to the appropriate subscribed clients
Client: a device that can publish messages to a topic or subscribe to messages from a topic
Topic: an identifier (a string) used by the broker to filter messages for each connected clients. It is sent by clients to the broker in a subscribe request to express the desire in receiving messages published by other clients. It is sent by the clients when publishing messages to any other client that subscribed on the same topic
Publish: the action of sending a message from a client to the broker
Subscribe: the action of informing the broker about an interest in receiving future messages published by other clients on that topic. A client can subscribe to multiple topics
Unsubscribe: the action of informing the broker that a client doesn’t want to receive messages of the specified topic
And now, before jumping into the real thing, let’s make sure first that we are on the same page with our development tools.”