Smart home automation with MQTT
Andrei Cornel – Cristian, Tudor Gabriel, Madalina Arhip-Calin, Alexandru Zamfirescu
Department of Power Engineering Systems
Polyethnic University of Bucharest – Faculty of Power Engineering
Bucharest, Romania
Abstract – This paper aims to investigate the main
advantages brought by Message Queuing Telemetry
Transport (MQTT) protocol which is used by Internet of
Things (IoT) devices. In addition to the advantages
brought by the MQTT protocol in the smart grid
environment we will also analyze the challenges and
limitations that are introduced by it and were it should
be adopted in the current smart grid. As a study case for
this paper the practical implementation of MQTT in a
smart home automation system will be presented.
Index terms – IoT, MQTT, smart grid, smart home
I. INTRODUCTION
MQTT is lightweight protocol designed for power
constrained and low bandwidth devices used for
machine-to-machine (M2M) connectivity through IoT
environments that work over TCP/IP. MQTT was
developed by Andy Stanford-Clark and Arlen Nipper
at IBM in 1999 and used as a proprietary protocol by
IBM until 2010 when MQTT version 3.1 was released
with royalty free license. This event was followed
closely by the standardization and inclusion of MQTT
in OASIS, Organization for the Advancement of
Structured Information Standards, and its release by
OASIS as version 3.1.1. Shortly after it was accepted
by OASIS, MQTT became also an ISO standard in
2016, ISO/IEC 20922:2016 [1,2].
For IoT devices embedded throughout a smart
grid MQTT offers the ability to send and receive data
in near real time with a small footprint on the
communication network and on the device itself.
Being a lightweight protocol, MQTT it is not only
useful for power or bandwidth constrained devices,
but it means that can be also deployed on the current
intelligent electronic devices (IED) without affecting
their functionality. Moreover, because MQTT works
over TCP/IP protocol, that is used by every system or
equipment connected to the internet, it means that
MQTT can be implemented without any
supplementary cost over a system with an internet
connection.
978-1-7281-3349-2/19/$31.00 ©2019 IEEE
II. MQTT STRUCTURE
What makes MQTT a lightweight protocol is the
use of publish – subscribe (pub/sub) architecture. In
the pub/sub architecture messages are sent (published)
by a client to a server who forwards the message to
another client. In order to assure that the message is
correctly forwarded by the server, the client that
receives the message is required to be subscribed to
the topic where the message was published [3].
In short, a message is published by client to a
certain topic in a server and the message is forwarded
to one or more clients that are subscribed to the same
topic. The topic is represented by the place were data
is sent and retrieved by clients and its structured the
same way that folders are structured in an operating
system. For reading data, a client needs to subscribe to
the exact topic of published message, or it can use the
characters “#, +” to multiple topics at one. These
characters are named wild cards and are used for single
or multilevel topics. In MQTT servers are known as
brokers and handles the data transmission between the
clients. The pub/sub provides one to many data
distribution and assures that the messages are not
mixed by decoupling messages transmitted and
received by the clients [2,3].
In order to assure that the message is sent to the
broker MQTT assures three quality of service (QoS)
levels [3]:
• QoS 0 - at most once delivery, the message it
is just delivered without a notification that it
was received. Used only in wired connection
or by severely restricted devices;
• QoS 1 - at least once delivery, for every
message delivered a publish
acknowledgement notification is sent back the
sender, if the notification it is not received in a
specified time the message will be sent again
with a duplicate tag.
• QoS 2 - exactly once delivery, it used above
QoS 1 and it ensures that duplicate message is
 not delivered to the receiving client. Used only
for critical applications.
Fig. 1 MQTT pub/sub architecture [4]
MQTT has the option to retain a message on the
broker for an unlimited period. This way new clients
that subscribe to that specific topic receive instantly a
message with the last known good data published
without waiting for new massages to be sent from the
publisher [2].
In order to prevent partial running status in MQTT
is implemented a keep alive system that checks if the
connection between broker and clients it is still active
or if one of them is offline. This system is triggered by
long transmission times or lack of transmission for a
certain time. A message is request status message is
sent by the client or broker, which in return responds
with an acknowledgement of the request sent. If a
response it is not received in an allocated time the
connection with the broker or client in question is
terminated and a last will and testament (LWT)
message is sent [2,3].
LWT is a message used to notify the reason why
a connection between a broker and client, who was
actively subscribing or publishing to a topic, was
terminated. The notification message is sent to all
clients subscribed to that topic. LWT is not only
generated by the lack of a keep alive response but also
in case a client ends a connection without a proper
disconnect from the broker.
A variation of MQTT is used for wireless sensor
networks under the name MQTT-SN (Sensor
Network) or MQTT-S. MQTT-SN is based on the
same pub/sub architecture used by the original version
with difference that unlike MQTT, MQTT-SN was
created for communication protocols used in wireless
sensor networks (WSN) like Zigbee [5].
Fig. 2 MQTT-SN architecture [5]
TCP/IP is too complicated to work with sensor
networks that are constrained both by bandwidth and
computational power. As an alternative MQTT-SN
can be used over UDP (User Datagram Protocol), that
like TCP (Transmission Control Protocol) is used over
IP (Internet Protocol) but with a much smaller
footprint over the used network and device.
Another difference between MQTT and MQTT-SN is
the use of gateway and forwarders in addition to a
client and a broker. Gateways are used to interconnect
the two protocols and forwarders are used to re-
encapsulate data on the way between a client and a
gateway. Forwarders are used due the large number of
communication nodes present in WSN to assure that
the date arrives at destination in the same form that
was generated [5].
In MQTT, unlike traditional client-server
architecture, a client does not need to be aware of
physical identifiers in order to connect to a server. A
big advantage of MQTT is that the message used in it
can have any format. This means that the publisher and
subscriber need to establish beforehand the data
format.
III. MQTT USE CASE
As presented above MQTT is fast and lightweight
communication protocol, so one obvious use case is its
implementation in a smart home automation
management system. This is an obvious choice
because most of the devices used in a smart home are
optimized for low power consumption and have
limited computational ability. Therefore, MQTT
pub/sub architecture allows smart devices, or the user
directly, to retrieve from sensors data and sent
command in accordance with the received data in real
or near real time.
The next step for a smart home is the use of an
automated demand response (ADR), implemented by
the power distribution system operator (DSO). A
system like ADR allows the DSO to request an end
user to use certain appliances when surplus power is
generated. This can become a real scenario soon due
to the increase use of distributed energy resources
(DER) like photovoltaic and wind power station by
residential users, that will cause imbalance in the
distribution power grid due to the extra power
generated locally. As an example, this system can be
used for switching between fossil-fuel heating system
and an electrical heating system, when surplus power
is present in the distribution power grid [6]. This can
be achieved only by allowing communication between
a smart meter and a smart appliance, in this case an
electrical heater.
The MQTT is perfect for this kind of operation
because it is offering a fast, robust and secure way of
communication between the smart meter and the smart
appliance, and between the smart meter and the DSO.
MQTT provides DSO a reliable way to exchange data
with the end user and the DER by using the local
communication infrastructure [6].
Furthermore, the DSO can use MQTT for the
integration of smart meter in cloud-based
infrastructure. By using cloud and cloud computing
environments together with IoT technologies like
MQTT advanced services like state estimation,
demand response and user awareness can be enabled
for smart grids. For function like state estimation to
work a constant flux of data needs to be retrieved from
field devices as fast as possible. MQTT pub/sub model
allows data to be gathered in real or near-real time
from IED like smart meters and enables fast
bidirectional communication which is needed to
send/retrieve data from/to field devices [7].
Results obtained from a state estimation system
can be used as feed in data for a network
reconfiguration system. A network reconfiguration
system can be used to balance power generation and
consumption in part of distribution power grid by
reconfiguring portions/branches of distribution grid
using the switch devices installed throughout the grid
[7].
Network reconfiguration can be employed with
fault detection, isolation and restauration (FDIR)
system. Using the two system together the outage
duration in a power distribution system can be reduced
considerably [8].
As in the examples above MQTT in smart grid
environment is used only to send/retrieve data to/from
different devices and systems due to its fast-two-way
communication architecture.
IV. MQTT LIMITATION AND CHALLENGES
As perfect as it sound MQTT protocol has some
limitation and disadvantages. One of the main
disadvantages is MQTT dependency to the broker. In
MQTT the broker affects the scalability of the overall
system, meaning that the network can expand as much
as the broker can support it. Also, the broker can be a
point of failure in an automation system because the
broker usually is plugged directly in a wall socket
while the devices that sent/retrieve data from it are
most of the time battery operated. So, in case of a
power outage the broker will offline while the devices
will try to publish data to it [9].
V. STUDY CASE - MQTT USE IN SMART
HOME AUTOMATION SYSTEM
MQTT will be used in a simple smart home
automation system as a transmission protocol. The
setup used is composed of two raspberry pi 3B+
boards, two wemos d1 mini development boards
equipped with DHT11 temperature and humidity
sensor and one wemos d1 mini equipped with a one
channel relay switch.
The raspberry pi and wemos d1 mini are both low
cost development boards that can be used in small
automation project with the big difference that
raspberry pi is much closer to computer in terms of raw
power and can use as operating systems Linux
distributions or even stripped-down versions of
windows 10 as operating systems (OS). Wemos d1
mini is a board based on the ESP8266 wireless
microcontroller, it does not support an operating
system nor those have the required raw power to do so.
In order to use a wemos it is necessary to program it in
an environment like Arduino IDE. Wemos can be used
as a standalone device if it is programed as a webserver
to display data various sensors like DHT11 or to
control a relay via a webpage. But the most likely
scenario is use of wemos boards together with a
raspberry pi or something similar, where the raspberry
will be the master control device.
In the center of this configuration will be one of
the raspberry pi board which will act as the MQTT
broker. The other devices will act as clients for MQTT,
which will either publish or subscribe messages to a
topic in the broker or will do both. For example the
wemos board with the DHT11 sensor will only publish
data, the measured humidity and temperature, while
the wemos board with the one channel relay switch
will publish data, the open or closed relay state, and
will also subscribe to another client, that will issue
control commands for the relay.
First, we need to install and configure the broker.
For this purpose, we used Mosquitto as MQTT broker.
Mosquito is open source lightweight messaging
protocol for MQTT, suitable for large range of
devices, varying from power constrained devices up to
state-of-the-art servers. After the Mosquitto
installation on the raspberry pi we need to setup a
username and a password, used by the clients that will
subscribe or publish to the broker to authenticate.
 Next the MQTT clients will be configured with present programs like this for android or iOS
broker address, network connection method and the devices, we used myMQTT for android.
password and username previously set for Unlike other programs MQTT Explorer connect
authentication. The devices configured as MQTT to the broke and display all the topics used for
client will publish messages with data to the broker publishing or subscribing. This can be a useful
and will subscribe for control commands. So, the two function in the case where you have many devices and
you don’t remember all the used topics. Also, MQTT
wemos boards equipped with the DHT11 sensor will
Explorer can keep a history with all the messages sent
be used to measure temperature and humidity from
and it will show you when value is updated.
two rooms, bedroom and living room, and will publish
data under the topic” d1/home/rooms/living
room/temperature” for temperature and“d1/ home/
rooms/ living room/ humidity” for humidity. The same
structure is used for bedroom measurements topic, we
only need to replace living room with bedroom.
For reading data from multiple topics
simultaneously, we will need to use wild cards. For
example, if we want to read the temperature from the
bedroom and the living room at the same time we will
subscribe under the topic ”d1/ home/ rooms/ +/
temperature” or if we want to read both measurements
for the two rooms together we will use the following
topic path “d1/ home/ rooms/#”. For the relay switch
wemos will publish first to the broker the open or close
Fig. 6 – MQTT Explore program
status by sending 0 or 1 values using the topic ”
confirm/relay/switchConfirm1” and will receive
control commands by subscribing to the topic
”comand/relay/switch1”. The relay is configured
through wemos to be initially opened, so it will publish
0 and will receive 1 for closing the relay switch.
In order to check if everything is working
properly, we will need to create a subscribing client to
the created topics. This can be done in several ways as
follow:
• Using directly the comand line terminal in the
raspberry pi OS and writing mosquitto_sub -
d -u ‘username’ -P ‘password’ -t ‘topic’ for
subscribing to a topic and for publishing to a
topic mosquitto_pub -d -u ‘username’ -P
‘password’ -t ‘topic’ -m "Message", where -
d if for debug mode, so all messages
published or subscribed are outputted on the
screen. Another way to do this is by enabling
SSH on the raspberry and connecting to it via
SSH, this will open directly the comand line
terminal in raspberry pi OS and typing one of
the commands;
• Using a windows or MacOS program like
MQTT.fx or MQTT Explorer. MQTT.fx
needs to be configured with the broker
address and login credentials for publishing
or subscribing to topics. Also, there are Fig. 7 – myMQTT android phone scree capture
 Fig. 8 – openHAB control panel
All this data retrieved from the wemos devices
needs to centralized. It can be used with programs like
MQTT Explorer, but it is not a practical way to do this.
In this scope on the second raspberry pi board will be
installed openHAB, short for open automation bus.
OpenHAB is opensource home automation platform
with the ability to integrate devices from different
developers and vendors like LG, Philips or Samsung
and it also support the MQTT protocol, although this
was made available with version 2 of openHAB [10].
OpenHAB work by linking things that are represented
by physical objects with items that represents the
functionality of the thing. In our case the thing is
represented by the wemos devices that are linked to
items represented by the temperature or humidity
readings or the relay status.
In our case openHAB is used to display
temperature and humidity, in Celsius degrees and
percentages, from the two rooms, bedroom and living
room and to control a power switch from the living
room with a toggle button, represented in fig. 8.
VI. VI. CONCLUSION AND FUTURE WORK
In our setup we presented a simple MQTT
implementation example in a smart home environment
using ESP8266 based development boards, wemos d1
mini, and openHAB platform. The ESP8266 offers the
ability to control devices like sensors or relay shields
via wireless internet network. This means that devices
can be used anywhere on our premises as long they are
in the Wi-Fi router coverage area. The configuration
used can be extended by adding sensor for AC voltage
and current measurements for all the power sockets
where the daily used appliances are plugged in. In
addition, there can be added automation controls for
powering on the air conditioning system when the
temperature exceeds a certain setpoint value or to
automate lighting control in house based on the
ambient light. Furthermore, implementing a cloud
solution will allow you to access data from
everywhere, not only your personal network
A system like this will evolve with the further
development of technologies like ESP8266, openHAB
platform and MQTT. For openHAB there is already a
version 3 in development.
VII. REFERENCES
[1] MQTT protocol [Online]: http://mqtt.org/faq
[2] Perry Lea, "Internet of Things for Architects", Packt
Publishing, 2018
[3] MQTT v3.1.1 Oasis standard [Online]:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-
v3.1.1.html
[4] MQTT pub/sub architecture [Online]:
https://1sheeld.com/mqtt-protocol/
[5] Andy Stanford-Clark and Hong Linh Truong,
"MQTT For Sensor Networks (MQTT-SN) Protocol
Specification", IBM, November 14, 2013
[6] John C. Hastings, David M. Laverty, "Modernizing
wide-area grid communications for distributed
energy resource applications using MQTT publish-
subscribe protocol", IEEE Power & Energy Society
General Meeting, 16-20 July 2017
[7] Marco Pau et al., "A cloud-based smart metering
infrastructure for distribution grid services and
automation", Sustainable Energy, Grids and
Networks, Volume 15, September 2018, Pages 14-
25
[8] Abouzar Estebsari, Edoardo Patti, Luca Barbierato,
"Fault Detection, Isolation and Restoration Test
Platform Based on Smart Grid Architecture Model
Using Internet-of-Things Approaches", 18th IEEE
International Conference on Environment and
Electrical Engineering (EEEIC), June 2018
[9] Andrew Minteer, "Analytics for the Internet of
Things (IoT)", Packt Publishing, 2017
[10] OpenHAB documentation [Online]:
https://www.openhab.org/docs/