Presentation for the IOT Dublin meetup in September 2017

1. MQTT
Overview
Brian O’Donovan
Sept 2017

2. Who am I
2
• Over 30 years of experience in the IT
Industry
• Last 20 years working with Lotus/IBM
• Most of experience on ‘big’ software
• Sideline interest in IOT devices (particularly
weather related)
• More details on my Blog
http://brianodonovan.ie

3. Outline of Talk
3
• Message passing architecture
• MQTT v REST/SOAP
• Protocol Details (with thanks to Peter R. Egli)
• https://www.slideshare.net/PeterREgli/mq-telemetry-transport

4. Messaging Architecture
4
• Let each component be independently developed
• When data to share it sends out a message
• It sends the message to a broker and the broker passes it on to the
components which have declared an interest
• The publisher does not need to know what the consumer does
with the data
• Producers and consumers can be developed and tested
independent of each other
• Message logs can be replayed
• Easy to switch implementation

5. Example of a home Alarm
5
• A door sensor simply broadcasts a message saying is the door is
opened (1) or closed (0)
• Payload is only 1 byte long
• Doesn’t need to know/care if this represents a problem
• a separate module worries about whether the alarm is set or not
• A fire detector is different from a door sensor, but it can
broadcast “no fire” (0) or “fire” (1) so very similar handling

6. Alarm Controller
6
• Listens to events from the door and fire sensors.
• Also listens to the messages from the keypad to arm/disarm that
system
• This allows it to decide if the alarm is active when door opens
• In a simple system it might control the alarm bell directly
• A more flexible system would send out a MQTT message to say that the alarm
system and another module would look after deciding what to do about it e.g.
send a text to the owner, sound the bell and/or notify the police
• If alarm is monitored by a security company with their own MQTT
broker we might pass it on.

7. Analysis of priority
7
• Sensors send data
• They have limited battery so minimize load on them
• Sometimes we have low power devices listening for
messages and reacting to them (e.g. opeing a door lock)
• So these are considered next priority
• Brokers typically run on “real computers” so make them
do most of the work,

8. What is MQTT
8
• Message Queing for Telemetry Transport (MQTT) is
• A publish/subscribe messaging transport protocol
• It is light weight, open, simple, and designed to be easy to
implement.
• These characteristics make it ideal for use in many situations,
including constrained environments such as for communication
in Machine to Machine (M2M) and Internet of Things (IoT)
contexts where a small code footprint is required and/or
network bandwidth is at a premium.

9. MQTT History
9
• Invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom,
now Cirrus Link) back in 1999
• Initially only used inside IBM, but version 3.1 was released royalty
free in 2010
• In 2014 MQTT was officially approved as OASIS Standard and in 2016
it became an ISO Standard
• Several implementations available
• Eclipse Paho is an open source broker implemented in Java.
• IBM released a free broker which consumes 300Kb of memory

10. MQTT Highlights
10
• All communication is via a hub
• Hierarchical topics e.g.
• /building6/alarm/windows/front5
• /building6/alarm/doors/rear1
• Publish to a specific topic, but subscribe using wildcards
• + is single level wildcard while # matches multiple levels
• e.g. /building6/# or /+/alarm/doors/+
• Detailed connection attributes in the connect/subscribe
• Assured delivery, Last will & testament

11. MQTT v HTTP
11
• Different design goals
• HTTP is designed for browsers interacting with web servers
• Although now used for other things
• Power consumption is not a big issue for HTTP but is core to MQTT
• Web pages are typically large so overhead is not a big %
• HTTP is Stateless
• Modern architecture is to have a large cloud of servers and you don’t know in
advance which is going to serve each request
• MQTT is statefull so information can be sent at connect time (which is
sent once rather than with each request)

12. HTTP sample
12
TCP Header
78 bytes
11.1%
Payload
53 bytes
7.8%
HTTP header
553 bytes
80.1%

13. MQTT Protocol Details
13

14. MQTT Protocol Details
14

15. Retain Publishing
15

16. MQTT Connect Message
16

17. MQTT Publish
17