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:20
login.
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
11:57
in the building.
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.
13:30
you