Hey everyone, it’s Frenoy. This is going
to be a video on home automation and we are
going to look at something very important
which is communication, in particular MQTT.
By the end of this video, you will learn how
to communicate between devices and control
them over your home network.
If this is the first time you are learning
about home automation, then all of this may
sound very complicated. I am going to try
to do my best to break it down to a level
where it is easy to understand. So let’s
dive in.
The first thing we need to do is understand
what sort of communication we are looking
for. We’ve decided to use home assistant
as the home automation platform and this allows
us to control our devices using a computer,
smartphone or even remotely through the cloud.
All our devices will interact with home assistant
and they will be automated using it. We are
mainly interested in the communication that
goes on between all these devices.
One way to communicate between devices is
to use the client/server model which is very
similar to TCP/IP and how we access websites
in general. When you decide to visit Google
for instance, you would need to type in the
address Google.com which is known as a URL.
This URL represents an IP address belonging
to a server. Think of it as being similar
to your home address. Your computer will then
send the requests to this server and the server
will respond with the correct information.
Here is an example of this. As you can see
there are a number of requests being sent
out and if you select one of them, then you
will see an IP address to a particular server.
This sort of communication takes place for
pretty much all the websites and all this
happens very quickly. Let’s apply this model
to home automation.
Say you have a smart fan, which can be switched
ON remotely using a computer, and which can
also give you information like the fan speed,
temperature and so on. Under this model, we
would have to send requests to the fan to
ask for its speed, temperature and it would
respond with the correct values. In order
for this to work, we would need to know the
IP address of the fan so that we know where
we can send the requests to. For security
purposes, the fan will also need to know which
devices are allowed to communicate with it.
This is because you would want to control
who has access to your devices. This form
of communication is acceptable when you have
very few devices but it starts to get messy
as soon as you add more devices or enable
control from several other locations. Each
of these smart devices need to know who can
control them and similarly, each of the control
devices need to know which smart devices can
be controlled. You’ve probably guessed that
this gets complicated pretty fast and that
is why this communication model is not very
suitable.
The MQTT protocol tries to solve all these
issues for us and it does this brilliantly.
MQTT stands for Message Queuing Telemetry
Transport, and it needs a central hub or server
to take care of communication. This hub is
also called a broker. In simple terms, an
MQTT broker acts like a post office and all
communication has to pass through it. In this
protocol, devices communicate using the publish
and subscribe system. Let’s go back to the
smart fan example. We have the fan, a computer
to control it and we now add a third device
called the MQTT broker which will take care
of the communication for us.
When a device has some information it wants
to share, or broadcast, then it can publish
this to the broker. The broker will then have
a copy of this information. In our example,
the fan can send it’s the temperature and
its speed.
Similarly, when a device wants to obtain some
information, it can notify the broker that
it is interested in that information, and
so it subscribes to it. Our computer for instance,
will subscribe to the temperature and fan
speed so that it can track their values. In
this model, whenever the fan publishes its
temperature and speed, the broker will forward
these messages to the computer.
These strings which are used to identify the
published and subscribed messages are called
topics. A device can publish multiple topics
and it can also subscribe to multiple topics.
If multiple devices have subscribed to the
same topic, then the broker will send the
message corresponding to the topic, to all
of them. This is also called pub/sub messaging
where pub is short for publish and sub is
short for subscribe.
In this model, the end devices only care about
the pub/sub topics and they do not need to
know the IP addresses of each other. The broker
takes care of all communication and it even
has special messages that can be sent out
when devices are added or deleted. These are
called birth and last will messages but they
are optional so we will not talk about them
right now.
As a quick example, let’s define the pub/sub
structure which will allow the computer to
control the fan. Since the computer will be
sending the control message, it will need
to publish a topic, for example: fan/control.
Since the fan needs to receive a control message,
it will subscribe to the same topic. The broker
will take care of receiving and delivering
the messages for us.
Here are somethings to note, before we move
on:
The pub/sub topics are case sensitive. Which
means that these two topics are different.Messages
can also contain additional information which
is called a payload. If you have a display
connected using MQTT, then you can send the
text that needs to be displayed and so on.If
the broker fails, then the entire system will
fail. However, you can configure a backup
broker to handle messages in case the first
one fails. The broker can be run on private
devices like a raspberry pi, or you can even
use public services but these are not as secure.
A third option is to use the cloud. You can
even use a combination of private and cloud
devices depending on your needs. We will run
our broker on the same raspberry pi that we
are using to run home assistant.You can also
authenticate the communication between the
broker and devices to improve security.
Let’s start installing the MQTT broker.
Log into home assistant by typing in the IP
address along with the port 8123 and then
entering the username and password that we
set in the previous video. You can watch part
1 where we learn about and install home assistant.
Once in, navigate to hassio, then the addon
store, click Mosquito broker and install it.
This is one example of a broker and we will
be using it as it is very popular. Installation
might take some time, but when it has completed,
scroll down to the config section, add the
login details like so and hit the save button.
This is just an example, but please use something
a bit more secure.
Once done, scroll back to the top, make sure
that ‘start on boot’ is enabled and then
start the add-on. We will then need to create
a new user for MQTT and to do that, navigate
to configuration -> Users and click the add
button to create a new user. Add the details
like so but make sure the username and password
match the ones we listed in the config section
of the add-on.
Once done, navigate to configuration->integrations
and select configure next to MQTT. I would
recommend enabling discovery for now and then
click submit. Reboot the system by navigating
to hassio, system and hitting the reboot button.
Give the board about a minute or two to reboot
and then log back into home assistant.
Navigate to the developer tools section and
you should be able to see a new tab called
MQTT. We can quickly test the setup by subscribing
to a new topic say mqtt/test and then publishing
a message to the same topic. You should receive
something like this which indicates that the
broker has been setup correctly. You can also
test out the payload section like so. The
payload can be used to do things like control
LEDs or report errors, text and so on.
Now that this is setup, we need to try and
interface external devices. You would need
a WIFi enabled board and I will be using the
Arduino Nano 33 IoT board along with a WeMos
D1 mini. Let’s start with the Nano 33 IoT
board. First, we need to use the board manager
and install the board support package. We
then need to use the library manager to install
the WiFiNiNA library so that we can use the
WiFI module. We also need to install the pubsubclient
library for MQTT communication.
The library contains examples for different
scenarios, which are well documented. I would
recommend you open and view them to get a
better understanding of how they work. For
this video, I have created two sketches that
you can download and use.
Open up the sketch for the Arduino nano using
the IDE. You will have to enter your WiFi
name, password along with the mqtt broker
details. The server is the IP address of the
raspberry pi that is running home assistant.
The username and password are the same as
what we setup while installing the add-on.
The sketch already defines the pub sub topics.
I would recommend testing it out using these
first and then changing it later. The first
byte of the sub topic will control the LED,
while the first byte of the pub topic will
report it’s state.
The sketch itself is not very complicated.
We simply set up the wifi connection, set
the mqtt server connection and callback function.
The call back function will be automatically
called when a new message for the subscribed
topic has been received. It first prints out
the message along with the payload to the
serial terminal. It then takes the necessary
action which is controlling an LED in this
case. We publish the led state to the pubtopic
when its state changes. This way, another
device can obtain the LED state information.
In the while loop, we simply maintain a connection
to the mqtt broker and we send the led state
every 5 seconds. This is optional but I wanted
to include this as it will help you while
debugging any issues.
Before you upload the sketch, make sure you
have connected an LED to pin 2 using a current
limiting resistor as shown here. You can use
this wiring diagram if needed. We then simply
select the correct board, COM port and hit
the upload button. You can open up the serial
monitor to view the board status and make
sure the baud rate is set to 115.2 kbps. The
board should connect to your WiFI network
and the MQTT broker.
Now, go back to home assistant, navigate to
the developer tools section and the MQTT tab.
Subscribe to the pubtopic contained in the
sketch, which is arduino/ledState in our case.
You should be able to see a message from the
board, like this every 5 seconds. Now, if
you publish a message with 1 as the payload
to the pub topic which is arduino/ledControl,
then the LED should switch ON and the ledstate
message we receive should reflect this. Similarly,
we can send a message with the payload as
0, to switch OFF the LED. The board will also
print out the messages received to the serial
terminal. And that is how simple MQTT communication
is.
We will now control this LED remotely, using
the WeMos D1 mini board. Open up the sketch
for the board and start by entering your credentials
like before. The sketch is identical to the
first one and we only have a pubtopic since
we will only be sending the switch state.
The process is very similar to the previous
one. We start by setting up the WiFi connection,
and connecting to the server. The switch is
connected to pin D7 and it has a pull up resistor.
Whenever the switch is pressed, pin D7 will
go LOW and this can be detected in the sketch.
When this happens, we print out a message
to the serial terminal, and toggle the switch
state. This is then sent to the pubtopic.
Similar to the previous sketch, we keep sending
the switch state every 5 seconds. Again, this
is optional but it is useful for debugging
purposes.
Use this wiring diagram to connect the switch
to the board. You will end up with something
like this. If this is the first time that
you are using the WeMos D1 mini, then you
need to add the following URL using the preferences
window. You then need to install the board
support package for it and make sure you select
the right board along with the COM port. Once
everything is done, simply upload the sketch
and open the serial terminal to make sure
it has connected properly. The baud rate needs
to be set to 115.2kbps like before.
Pressing the switch should switch ON the LED
and you can then use the switch to toggle
its state. All the messages will also be displayed
on home assistant. If you enter the pound
or hash symbol as a topic then you will be
able to view all the messages. This is very
useful for debugging.
Here’s one thing to keep in mind. The MQTT
broker can be used by itself, without home
assistant. The reason we are using home assistant
is so that we can integrate everything to
a dashboard, automate the devices and also
be able to control them remotely. We will
cover all of this in future videos so do subscribe
to stay updated. I hope this video has given
you a better understanding of MQTT. Thank
you for watching and I will see you in the
next one!
