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!