00:03
The Internet of Things or IOT is all
about interconnecting devices and one
00:09
lightweight, secure way for online
devices to communicate is using MQTT.
00:13
MQTT is a publish/subscribe based
messaging protocol that avoids direct
00:18
connections between devices by relaying
data through a central server called the
00:22
broker. This is really desirable in IOT
because it's easy to add new devices
00:27
without touching the existing
infrastructure and since new devices
00:31
only need to communicate with the broker
they don't actually need to be
00:34
compatible with the other clients. In
this video I'll explain how the MQTT
00:39
model works, go over some advantages and
disadvantages, and finally use it to
00:44
toggle a digital output.
00:50
To get an idea of how the
publish/subscribe or pub/sub messaging
00:54
model works let's start with a real-life
example. Let's say I have a switch
00:59
connected to one device and I want to
use it to toggle the state of a light
01:02
attached to another separate device.
Traditionally I would just connect them
01:07
directly but then if I added new devices
with more lights and wanted them to be
01:12
triggered by the same source I would
need more connections and the same goes
01:15
for adding more triggers. This gets very
messy and difficult to maintain.
01:19
Especially with IOT you could have a
whole building full of lights and
01:23
switches where each is a separate device.
So instead of doing it this way I can
01:28
use the publish/subscribe system. This
way I can have the device with the
01:32
switch publish the switch state under
some topic say switch for example. Then I
01:38
just subscribe to that topic from
another device and any time a message is
01:42
published with a matching topic the Broker
will relay the new information over, and
01:46
this device can use that to toggle a
light. Now if I go to add more lights or
01:51
more switches I just have one new
connection for each client to the server
01:55
creating a nice hub-and-spoke model that
is easy to maintain rather than the
02:00
spider web that we traditionally
needed. What's more is that this only
02:04
demonstrates how one topic can work
between devices. You can have as many
02:08
topics as you want for your application
with each one having different clients
02:11
on either end. Being one to one, many to
many, or any combination. The pub/sub
02:17
architecture is very flexible and
scalable making it great for IOT
02:21
applications. Now let's make this a
reality. Here I have a groov EPIC, Edge
02:27
Programmable Industrial Controller that
has a light hooked up to it. I can use
02:30
this screen to toggle the light but I'm
not always going to be standing right
02:36
next to the device so I'm going to set
up the groov EPIC to be an MQTT client
02:41
that is subscribed to a specific control
topic. To toggle the light based on the
02:45
messages that come in on that topic.Then
all I need to do is publish to that
02:49
topic from my laptop which is a separate
client and I'll be able to control the
02:53
light from anywhere in the world. To
control the light I'll be using Node-RED
02:57
since it has a basic MQTT client
built-in and it's running on the groov EPIC
03:01
right
out of the box. To find out more about
03:03
either groov EPIC or Node-RED check
out opto22.com. Now, let's get that client
03:08
set up.To get to Node-RED I just go to
my host name slash Node-RED. Then I just
03:16
proceed through security,
03:23
I can drag a subscription node in right
away.
03:28
Double-click it to edit its settings.
03:32
For this example I'll be using the
public broker. And in my case MQTT.groov.com
03:40
Here you could use a broker running
on a local device like your Mac, Linux, or
03:45
Windows PC, a Raspberry Pi, or cloud
service like Amazon Web Services.
03:50
The default secure port for MQTT is
8883 but I'll just be using the
03:55
insecure broker 1883. Many brokers
are encrypted or password protected but
04:03
this one is open to the public so we'll
leave username and password blank. The
04:07
final setting screen shows three
additional optional messages birth, death
04:11
and will. I'll come back and set these
up later once we know everything else is
04:16
working. So now with the broker setup
we're almost ready to subscribe. The next
04:21
thing to look at is the topic. The topic
namespace is an unmanaged way to
04:25
identify your messages. I say unmanaged
because there is no enforced format or
04:30
standard to follow. Each client
determines the topic of that devices
04:34
messages which means you as the
programmer have to be consistent and
04:39
specific with your topics. And you'll
need to share it with anyone else that
04:43
interacts with your broker since they'll
need to know what to subscribe to and
04:46
what to publish to. This is a lot of
freedom but I'll keep things simple for
04:52
this example and just use workshop slash
switch. Where switch is called a sub
04:57
topic of workshop. I could have
workshop itself be a sub topic of
05:01
something larger or I could just publish
directly to the topic switch but that's
05:06
going to depend on your application.
05:13
Next I can choose the quality of service
which is a big part of MQTT. In short it
05:19
determines how much of a guarantee of
delivery you want for your message.
05:23
0 quality of service means that the broker
received the message at most once. But
05:28
might miss it since there is no
confirmation made. Quality of service 1
05:32
means that the broker will receive the
message at least once but may get
05:36
duplicates while it's waiting for
confirmation. And finally Quality of
05:40
Service 2 means that the broker will
receive the message exactly once. The
05:45
highest quality of
service sounds the most attractive and
05:48
for control purposes it is really the
only option worth considering but it
05:52
does come at the cost of extra network
traffic since the broker and client must
05:57
exchange confirmation packets.
Particularly for quality level 2 since
06:01
both sides have to acknowledge the
publication. Now with my subscribed
06:05
client all set up I'll need to use this
switch message to toggle a light.
06:12
To do that I'll use the SNAP PAC write
Node. These are used to interface with
06:20
the i/o modules installed on the groov EPIC chassis. This will just connect to
06:26
the local host device since Node-RED
itself is running on the groov EPIC. And I'm
06:30
going to be writing to the digital
output I have setup on the system
06:33
strategy called panel red LED. And that's
all there is to setup.
06:42
If I wanted, just for testing, I could
also add a debug node to double-check
06:48
the output here as well. Now with my Node-RED flow all set up
06:55
I'll hit deploy. And, now I just need to
publish to this topic to test it out. To
07:01
do that I'll be using a separate client
running on this laptop called MQTT FX.
07:08
Once it's loaded I just bring up my
server list and I can go ahead and add
07:12
the broker. In this case it'll be the
same public broker that I added to Node-RED
07:20
it's at MQTT.groov.com and I am
using the insecure broker port 1883. And,
07:28
I'll not be putting in a user name or
password since it's open to the public.
07:32
Now I'll just hit apply, close this
window, and connect to the broker. Now all
07:41
I need to do is publish to that same
workshop / switch topic and give it a
07:47
message. And, in this case I want to turn
the switch on so I'll send the message
07:51
true. Now all I have to do is publish and
the light comes on. Fantastic!
08:00
The connection is both sound and very
fast and if I were to use my own broker
08:05
I can encrypt the data and securely
password protect it - in this case the
08:10
publishing client is my laptop.This
represents the switch. It publishes the
08:15
switch state up to the broker and then
the broker relays that message down to
08:18
Node-RED on the groov EPIC where it
makes the control decision to turn on
08:21
the light. So now that we know everything
is working let's take a quick look at
08:26
some of the more advanced features that
I skipped. Birth, death, and will messages,
08:30
retain topics, and finally wildcards. So
if I go back to Node-RED
08:37
and bring open the broker properties
I can see those three messages birth,
08:43
death and will. Like the node info tab
says these messages are sent whenever
08:50
this device connects, disconnects and is
forcibly disconnected from the broker.
08:57
For example I can have the birth message
publish under the topic workshop slash
09:02
status and give it the payload: Online.
Since that will be the status once this
09:09
message is sent. Because I want this to
arrive at least once I'll give it the
09:14
quality of service level 1 and I'll turn
the retain flag to true you'll see what
09:19
this does in just a moment. Similarly
with the closed message or a death
09:24
message I can say "offline". Since when I
successfully disconnect the workshop
09:29
status will be offline I'll give it the
same quality of service and retain flag
09:36
now with these two messages setup I can
just listen to this one workshop status
09:41
topic and I'll be able to track the
state of this device as it comes on and
09:44
offline. But if it drops unexpectedly
without sending a disconnect message I
09:49
want to know that this is handled by
the will or last will and testament
09:53
message. This message gets sent by the
broker if this client ever unexpectedly
09:59
disconnects. So, in this case I'm going to
use that same workshop status tag and
10:06
give it the payload "disconnected". Since
it is an abrupt disconnection that
10:12
causes this message to be sent. Now I'll
save these new settings, deploy,
10:22
and head over to MQTT FX to subscribe
to this message. What's great about the
10:31
retain flag for MQTT topics is that I
can now subscribe to this status and
10:36
I'll get the message right away when I
connect because it was set to retain it.
10:40
Now the broker will keep track of the
latest copy of this tag to come in,
10:45
retain that data, and send it out to
anyone that comes and subscribes to this
10:49
topic. While I can't use this feature to
request the state of the device at any
10:54
time it does mean that new devices to
join the system are aware of the health
10:58
of all the other clients that are
already connected. So, now to test this
11:03
out. If I go and make a change to my Node-RED flow and deploy that should mean
11:08
that this client disconnected and
reconnected. And if I go back to MQTT I
11:13
can see that the disconnect message went
through and let me know that my device
11:16
was offline and then it came back up and
I got another message. Finally I want to
11:22
see the last will and testament. So, to
test that one out I'm going to try and
11:26
use a wild card. A wild card is
essentially a way to select any matching
11:32
topic. For example if I wanted the
status of every device, not just the
11:36
workshop, I could replace workshop with
the single level of wild card "plus". And
11:41
what this does is plus will replace
anything that matches a subtopic status.
11:47
So if I subscribe to that I'll be
getting both a copy of the workshop
11:53
status and a copy of the developer
status, which is another machine running
12:00
The other thing I can do is subscribe to
a workshop slash hashtag or the pound
12:08
character. This is a multi-leveled
wildcard that will match all sub topics
12:13
of workshop including both switch and
status. And if status had any sub topics
12:19
it would get those as well. It's also
possible to get everything matching
12:26
every single topic by just using a
single multi-level wildcard on its own.
12:30
But this gets a little bit loud so it's
usually not recommended.
12:38
I'll unsubscribe from these topics and
just use that single level wildcard plus
12:43
slash status. To test the last will and
testament when I subscribe
12:49
I see the retained messages come in. Then
when I unplug the ethernet cable on my
12:53
groov EPIC it disconnects from the
internet and the broker lets all the
12:58
subscribed clients know that this device
has dropped. This "disconnected" here is
13:03
that last will and testament message.
Using this it's possible to monitor the
13:08
health of your various devices and even
have a system in place to alert you when
13:12
something is down, attempt to reboot it,
or shift that devices responsibilities
13:16
over to another system. And there you
have it, there's a quick run through of
13:21
MQTT and its place in the Internet of
Things. To learn more check out
13:25
opto22.com Thanks for watching.