
Hands-On MQTT Programming with Python
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
Key Features
Make your connected devices less prone to attackers by understanding security mechanisms
Take advantage of MQTT features for IoT and Machine-to-Machine communications
The only book that covers MQTT with a single language, Python
Book DescriptionMQTT is a lightweight messaging protocol for small sensors and mobile devices. This book explores the features of the latest versions of MQTT for IoT and M2M communications, how to use them with Python 3, and allow you to interact with sensors and actuators using Python.
The book begins with the specific vocabulary of MQTT and its working modes, followed by installing a Mosquitto MQTT broker. You will use different utilities and diagrams to understand the most important concepts related to MQTT. You will learn to make all the necessary configuration to work with digital certificates for encrypting all data sent between the MQTT clients and the server. You will also work with the different Quality of Service levels and later analyze and compare their overheads.
You will write Python 3.x code to control a vehicle with MQTT messages delivered through encrypted connections (TLS 1.2), and learn how leverage your knowledge of the MQTT protocol to build a solution based on requirements. Towards the end, you will write Python code to use the PubNub cloud-based real-time MQTT provider to monitor a surfing competition.
In the end, you will have a solution that was built from scratch by analyzing the requirements and then write Python code that will run on water-proof IoT boards connected to multiple sensors in surfboards.
What you will learn
Learn how MQTT and its lightweight messaging system work
Understand the MQTT puzzle: clients, servers (formerly known as brokers), and connections
Explore the features included in the latest versions of MQTT for IoT and M2M communications
Publish and receive MQTT messages with Python
Learn the difference between blocking and threaded network loops
Take advantage of the last will and testament feature
Work with cloud-based MQTT interfaces in Python
Who this book is for
This book is for developers who want to learn about the MQTT protocol for their IoT projects. Prior knowledge of working with IoT and Python will be helpful.
More details
Other editions
Additional editions

Person
Gaston C. Hillar is Italian and has been working with computers since he was 8 years old. Gaston has a Bachelor's degree in computer science (graduated with honors) and an MBA. Currently, Gaston is an independent IT consultant and a freelance author who is always looking for new adventures anywhere in the world. He was a senior contributing editor at Dr. Dobb's, and has written more than a hundred articles on software development topics. He has received the prestigious Intel Black Belt Software Developer award eight times. He has written many articles about Java for Oracle Java Magazine. Gaston was also a former Microsoft MVP in technical computing. He lives with his wife, Vanesa, and his two sons, Kevin and Brandon.
Content
Installing an MQTT 3.1.1 Mosquitto server
Using command-line and GUI tools to learn how MQTT works
Securing an MQTT 3.1.1 Mosquitto Server
Writing code to control a vehicle with Python and MQTT messages
Testing and improving our vehicle control solution in Python
Monitoring a surfing competition with cloudbased real-time MQTT providers and Python
Understanding the MQTT puzzle - clients, servers, and connections
In versions of the MQTT protocol lower than 3.1.1, the MQTT server was known as an MQTT broker. Starting in MQTT 3.1.1, the MQTT broker was renamed the MQTT server, and therefore we will refer to it as the server. However, we must take into account that the documentation for MQTT servers, tools, and client libraries can use the old MQTT broker name to refer to the server. MQTT servers are also known as message brokers.
The MQTT server uses the previously explained topic-based filtering to filter and distribute messages to the appropriate subscribers. There are many MQTT server implementations that provide additional message filtering features by providing custom plugins. However, we will focus on the features that are part of the MQTT protocol requirements.
As previously explained, in MQTT publishers and subscribers are completely decoupled. Publishers and subscribers are MQTT clients that only establish a connection with the MQTT server. An MQTT client can be both a publisher and a subscriber at the same time, that is, the client can publish messages to specific topics and also receive messages that belong to topics to which the client has subscribed.
There are MQTT client libraries available for the most popular programming languages and platforms. One of the most important things that we must consider when we select the MQTT client library is the list of MQTT features that they support and the ones that we need for our solution. Sometimes, we can choose between many libraries for a specific programming language and platform, and some of them might not implement all the features. We will use the most complete libraries for modern Python versions that support a wide range of platforms throughout the book.
Any device that has a TCP/IP stack and is capable of using an MQTT library can become an MQTT client, that is, a publisher, a subscriber, or both a publisher and a subscriber. The MQTT library makes it possible for the device to talk to MQTT on top of TCP/IP and to interact with specific types of MQTT server. For example, any of the following can become an MQTT client, among other devices:
- An Arduino board
- A Raspberry Pi 3 Model B+ board
- A BeagleBone Black board
- A Udoo Neo board
- An iPhone
- An iPad
- An Android tablet
- An Android smartphone
- A laptop running Windows
- A server running Linux
- A MacBook running macOS
There are many MQTT servers available for the most popular platforms, including Linux, Windows, and macOS. Many of them are servers that can work as MQTT servers and they also provide additional futures. An MQTT server might implement only a subset of the MQTT capabilities and might have specific limitations. Hence, it is very important to check all the capabilities we will require in our solution before selecting an MQTT server. As happens with other middleware, we have open source versions, free versions, and paid versions. Thus, we also have to make sure we select the appropriate MQTT server based on our budget and our specific needs.
Throughout this book, we will work with the Eclipse Mosquitto MQTT server (http://www.mosquitto.org). Mosquitto is an open source MQTT server with an EPL/EDL license that is compatible with MQTT versions 3.1.1 and 3.1. We can take advantage of everything we learn with any other MQTT server, such as Erlang MQTT Broker (EMQ), also known as Emqttd (http://www.emqtt.io), and HiveMQ (http://hivemq.com), among others. In addition, we might use our knowledge to work with a cloud-based MQTT server such as CloudMQTT (http://www.cloudmqtt.com) or the PubNub MQTT bridge (http://pubnub.com). We will specifically work with cloud-based MQTT providers too.
The MQTT server is the central hub of the publish-subscribe model we previously analyzed. The MQTT server is responsible for the authentication and authorization of the MQTT clients that will be able to become publishers and/or subscribers after they are authenticated and authorized. So, the first thing that an MQTT client must do is to establish a connection with the MQTT server.
In order to establish a connection, the MQTT client must send a CONNECT control packet to the MQTT server with a payload that must include all the necessary information to initiate the connection and proceed with the authentication and authorization. The MQTT server will check the CONNECT packet, perform authentication and authorization, and send a response to the client with a CONNACK control packet that we will analyze in detail after understanding the CONNECT control packet. If the MQTT client sends an invalid CONNECT control packet, the server will automatically close the connection.
The following diagram shows the interaction between an MQTT client and an MQTT server to establish a connection:
After a successful connection has been established between an MQTT client and an MQTT server, the server will keep the connection open until the client loses the connection or sends a DISCONNECT control packet to the server to close the connection.
The CONNECT control packet must include values for the following fields in the payload, and bits for a special flags byte that is included in the control packet. We want to understand the meaning of these fields and flags because we will be able to specify their values when we work with MQTT tools and MQTT client libraries in Python:
- ClientId: The client identifier, also known as client ID, is a string that identifies each MQTT client that connects to an MQTT server. Each client that connects to the MQTT server must have a unique ClientId, and the server uses it to identify the state that it holds related to the MQTT session between the client and the server. If a client specifies an empty value as the ClientId, the MQTT server must generate a unique ClientId to identify the client. However, this behavior depends on the value specified for the CleanSession field.
-
CleanSession: The clean session flag is a Boolean value that specifies what happens after an MQTT client disconnects from the MQTT server and then reconnects. If CleanSession is set to 1 or True, the client indicates to the MQTT server that the session will only last as long as the network connection is alive. After the MQTT client disconnects from the MQTT server, any information related to the session is discarded. A new connection from the same MQTT client to the MQTT server will not use the data from the previous session and will be a new clean session. If CleanSession is set to 0 or False, we will work with a persistent session. In this case, the MQTT server stores all the subscriptions for the MQTT client and when the MQTT client disconnects, the MQTT server stores all the messages that arrive with specific quality of service levels that match the subscriptions that the MQTT client had at the time the disconnection occurred. This way, when the same MQTT client establishes a new connection with the MQTT server, the MQTT client will have the same subscriptions and will receive all the messages that it couldn't receive when it lost the connection. We will dive deep into quality of service levels for messages and their relationship with the clean session flag or the persistent session option later in Chapter 2, Using Command-Line and GUI Tools to Learn How MQTT Works.
When the clean session flag is set to 0 or False, the client indicates to the server that it wants a persistent session. We just have to remember a clean session is the opposite of a persistent session.
- UserName: If the client wants to specify a username to request authentication and authorization from the MQTT server, it must set the UserName flag to 1 or True and specify a value for the UserName field
- Password: If the client wants to specify a password to request authentication and authorization from the MQTT server, it must set the Password flag to 1 or True and specify a value for the Password field
We will dedicate an entire chapter to MQTT security, and therefore we just mention the fields and the flags that are included in the CONNECT control packet.
- ProtocolLevel: The protocol level value indicates the MQTT protocol version that the MQTT client requests the MQTT server to use. Remember, we will always work with MQTT version 3.1.1.
- KeepAlive: KeepAlive is a time interval expressed in seconds. If the value for KeepAlive is not equal to 0, the MQTT client commits to send control packets to the server within the time specified for KeepAlive. If the MQTT client doesn't have to send any control packets, it must send a PINGREQ control packet to the MQTT server, a ping request to tell the MQTT server that the client connection is alive. The MQTT server responds to the PINGREQ control packet with a PINGRESP response to the MQTT client, a ping response to tell the MQTT client that the connection with the MQTT server is alive. The connection is closed when there is an absence of any of these control packets. If the value for KeepAlive is 0, the keep-alive mechanism is turned off.
- Will, WillQoS, WillRetain, WillTopic, and WillMessage: These flags and fields allow the MQTT client to take advantage of the last will and testament feature of MQTT. If the MQTT client sets the Will flag to 1 or True, it specifies that it wants the MQTT server to store a last will message associated with the session. The WillQoS flag specifies the desired quality of service...
System requirements
File format: ePUB
Copy protection: Adobe-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Install the free reader Adobe Digital Editions prior to download (see eBook Help).
- Tablet/smartphone (Android; iOS): Install the free app Adobe Digital Editions or the app PocketBook before downloading (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (not Kindle).
The file format ePub works well for novels and non-fiction books – i.e., „flowing” text without complex layout. On an e-reader or smartphone, line and page breaks automatically adjust to fit the small displays.
This eBook uses Adobe-DRM, a „hard” copy protection. If the necessary requirements are not met, unfortunately you will not be able to open the eBook. You will therefore need to prepare your reading hardware before downloading.
Please note: We strongly recommend that you authorise using your personal Adobe ID after installation of any reading software.
For more information, see our ebook Help page.