- MQTT (Message Queuing Telemetry Transport) is a publish/subscribe messaging protocol used for IoT applications. - Topics are hierarchical strings separated by '/' that allow efficient filtering of messages. Wildcards '#' and '+' can be used. - Nodes publish messages to topics without needing to know each other. Other nodes subscribe to topics to receive messages.

1. Message Queuing Telemetry Transport (MQTT)
Topic parameters
Khamdamboy Urunov, a Ph.D. student.
Special Communication Research
Center.,
Graduate School of Financial
Information Security., Kookmin

2. Contents and comments
• Topic instructions
• Message type and examples
2

3. MQTT Topic
3
Publish / Subscribe
The publish / subscribe model lets you build a network of nodes that don’t need to know each other to
function.
Instead, nodes only know of topics to publish or subscribe to.
For example, you might have a topic structure like this:
o inside/bedroom/temperature
o inside/kitchen/temperature
o inside/bathroom/temperature
The various temperature sensors in your house would publish to their own topic, while a display showing
temperatures in the house might subscribe to something like:
inside/+/temperature
The “+” acts as a wildcard, allowing a system to subscribe to a group of similar topics.
publisher subscribertopic
senso
r
senso
r Temperature
Message B = light (On/Off)
Temperature
Message A = 270

4. MQTT Topic and Wildcards
4
Topics and wildcards
Messages are addressed through the use of topics.
Topics are separated by a “/“ allowing topics to be grouped in a tree structure.
Messages Address
topics
https://hackaday.io/project/1183/logs
How you design your topics is important to allow efficient use of wildcard
matching.
There are two wildcard characters “#” and “+” , level spared “/”
 “#” is the multi-level wildcard and matches zero or more levels.
 “+ ” is single – level wildcard
 “/” spared level
How you design your topics?
Name: identifying the topic within the domain

5. MQTT Topic Name
5http://www.slideshare.net/InduSoft/indusoft-web-studio-and-mqtt-for-internet-of-things-applications
 The MQTT Topic Name is included in every PUBLISH message
 In general Topic name have the format:
• site/line/machine/data
 Notice that the device or appliance ID is useful to include to be able to subscribe to
the flow coming from a specific device, the refrigerator, as opposed to all instance of a
given device
 As such the length of the topic name, in real application is on the order of tens of
bytes.
site/line/machine/data
How to make Topic Name:
inside/bedroom/temperature/value ?
value
How size of Topic Name?
Topic Name = 10 byte
appliance ID is usefully to include to be
able to subscribe to the flow
• Refrigerator
• Smart door

6. MQTT Topic Name
6
Topic is a UTF-8 string, which is used by the broker to filter messages for each connected
client.
A topic consists of one or more topic levels.
Each topic level is separated by a forward slash (topic level separator).
For example a subscription to myhome/groundfloor/+/temperature would match or not match the
following topics:
Multi Level: #
While the single level wildcard only covers one topic level, the multi level wildcard covers an
arbitrary number of topic levels.
In order to determine the matching topics it is required that the multi level wildcard is always the last
character in the topic and it is preceded by a forward slash.
http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices

7. 7
MQTT Topic Name (cont….)
Multi Level: #
Client subscribing to a topic with a multi level wildcard is receiving all messages, which start with the
pattern before the wildcard character, no matter how long or deep the topics will get.
 If you only specify the multilevel wildcard as a topic (#), it means that you will get every message
sent over the MQTT broker.
 If you expect high throughput this is an anti pattern.

8. 8
Topics beginning with $
o in general you are totally free in naming your topics, but there is one exception.
o each topic, which starts with a $-symbol will be treated specially
o for example not part of the subscription when subscribing to #
o these topics are reserved for internal statistics of the MQTT broker.
o Therefore it is not possible for clients to publish messages to these topics.
o At the moment there is no clear official standardization of topics that must be published by the broker.
o It is common practice to use $SYS/ for all these information and a lot of brokers implement these, but in
different formats.
o One suggestion on $SYS-topics is in the MQTT GitHub wiki and here are some examples:
$SYS/broker/clients/connected
$SYS/broker/clients/disconnected
$SYS/broker/clients/total
$SYS/broker/messages/sent
$SYS/broker/uptime
MQTT Topic Name (cont….)

9. MQTT Topic UTF-8
9
The third column of the following table shows the appearance of the space character, in the sense that the
cell contains the words “foo” and “bar” in bordered boxes separated by that character. It is possible that
your browser does not present all the space characters properly. This depends on the font used, on the
browser, and on the fonts available in the system.
http://www.cs.tut.fi/~jkorpela/chars/spaces.html

10. 10
MQTT Topic and Wildcards
http://www.slideshare.net/InfoQ/embedded-java-and-mqtt

11. 1. One topic for each device
For each device a topic is defined. Its state can be controlled by publishing a message with payload
“ON” or “OFF”.
Pro:
• the user must not know about the address code of the Intertechno device
• changes of the address must not be published
• the message is simply “ON” or “OFF to control the device
Contra:
• the user must know the topic for each device
• the user can only control configured devices
2. One topic for a JSON message
Pro:
• very flexible to control the devices
Contra:
• the user must know about the syntax of the JSON and the coding of devices
Solution:
Provide both options
11
http://www.jensd.de/wordpress/?p=1833
Home Control with Raspberry Pi and MQTT
This MQTT client basically follows two design patterns:

12. 12
My configuration is very simple
On start-up the Client is searching for sweethomehub-config.xml in the users home directory which is then unmarshalled from
JAXB.
This configuration contains the codes and the topic for each device and the MQTT settings for the broker connection:
Home Control with Raspberry Pi and MQTT (cont…)
And there is one additional topic awaiting the JSON commands:
sweethome/devices/jsoncommand
http://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices

13. MQTT Topic Architecture
13
A Topic is a hierarchical structured string, which is used for message filtering and
routing and determines which message gets to which client.
http://www.slideshare.net/InduSoft/indusoft-web-studio-and-mqtt-for-internet-of-things-applications

14. 14
MQTT QoS value

15. 15
MQTT QoS value (cont…)

16. MQTT TOPIC Summary (1/2)
16
 Don’t use spaces in a topic
A space is the natural enemy of each programmer, they often make it much harder to read and debug topics, when
things are not going the way, they should be. So similar to the first one, only because something is allowed doesn’t
mean it should be used. UTF-8 knows many different white space types
Each topic will be included in every message it is used in, so you should think about making them short and
concise. When it comes to small devices, each byte counts and makes really a difference.
 Keep the topic short and concise
Using non-ASCII UTF-8 character makes it really hard to find typos or issues related to the character set,
because often they can not be displayed correctly. Unless it is really necessary we recommend avoid using non
ASCII character in a topic.
 Use only ASCII characters, avoid non printable characters
http://www.slideshare.net/alexmorenocano/mqtt-slides

17. 17
In some cases it is very helpful, when the topic contains a unique identifier of the client the publish is coming from.
This helps identifying, who send the message. Another advantage is the enforcement of authorization, so that only a
client with the same Client Id as contained in the topic is allowed to publish to that topic. So a client with the
idclient1 is allowed to publish to client1/status, but not permitted to publish to client2/status.
Topics are a flexible concept and there is no need to preallocate them in any kind of way, regardless both the
publisher and subscriber need to be aware of the topic. So it is important to think about how they can be extended in
case you are adding new features to your product.
For example when your smart home solution is extended by some new sensors, it should be possible to add
these to your topic tree without changing the whole topic hierarchy.
 Don’t forget extensibility
 Embed a unique identifier or the Client Id into the topic
MQTT TOPIC Summary (2/2)
http://www.slideshare.net/alexmorenocano/mqtt-slides

18. Reference
18
1. https://github.com/aoabook/WroxAccessories/blob/master/src/com/wiley/wroxaccessories/MQTT.java
2. https://www.crossdart.info/p/mqtt/1.1.0/mqtt_message_publish.dart.html
3. http://iicb.org/viewpaper/1
4. http://www.javased.com/?source_dir=Racenet-for-
Android/src/com/albin/mqtt/message/RetryableMessage.java
5. http://www.programcreek.com/java-api-
examples/index.php?api=org.dna.mqtt.moquette.proto.messages.AbstractMessage.QOSType
6. http://indigoo.com/
Link of the source code and useful data:

19. Thank you!
hamdamboy.urunov@gmail.com
19