How to Get Started with MQTT - YouTube

The Internet of Things or IOT is all about interconnecting devices and one

lightweight, secure way for online devices to communicate is using MQTT.

MQTT is a publish/subscribe based messaging protocol that avoids direct

connections between devices by relaying data through a central server called the

broker. This is really desirable in IOT because it's easy to add new devices

without touching the existing infrastructure and since new devices

only need to communicate with the broker they don't actually need to be

compatible with the other clients. In this video I'll explain how the MQTT

model works, go over some advantages and disadvantages, and finally use it to

toggle a digital output.

To get an idea of how the publish/subscribe or pub/sub messaging

model works let's start with a real-life example. Let's say I have a switch

connected to one device and I want to use it to toggle the state of a light

attached to another separate device. Traditionally I would just connect them

directly but then if I added new devices with more lights and wanted them to be

triggered by the same source I would need more connections and the same goes

for adding more triggers. This gets very messy and difficult to maintain.

Especially with IOT you could have a whole building full of lights and

switches where each is a separate device. So instead of doing it this way I can

use the publish/subscribe system. This way I can have the device with the

switch publish the switch state under some topic say switch for example. Then I

just subscribe to that topic from another device and any time a message is

published with a matching topic the Broker will relay the new information over, and

this device can use that to toggle a light. Now if I go to add more lights or

more switches I just have one new connection for each client to the server

creating a nice hub-and-spoke model that is easy to maintain rather than the

spider web that we traditionally needed. What's more is that this only

demonstrates how one topic can work between devices. You can have as many

topics as you want for your application with each one having different clients

on either end. Being one to one, many to many, or any combination. The pub/sub

architecture is very flexible and scalable making it great for IOT

applications. Now let's make this a reality. Here I have a groov EPIC, Edge

Programmable Industrial Controller that has a light hooked up to it. I can use

this screen to toggle the light but I'm not always going to be standing right

next to the device so I'm going to set up the groov EPIC to be an MQTT client

that is subscribed to a specific control topic. To toggle the light based on the

messages that come in on that topic.Then all I need to do is publish to that

topic from my laptop which is a separate client and I'll be able to control the

light from anywhere in the world. To control the light I'll be using Node-RED

since it has a basic MQTT client built-in and it's running on the groov EPIC

right out of the box. To find out more about

either groov EPIC or Node-RED check out opto22.com. Now, let's get that client

set up.To get to Node-RED I just go to my host name slash Node-RED. Then I just

proceed through security,

login.

I can drag a subscription node in right away.

Double-click it to edit its settings.

For this example I'll be using the public broker. And in my case MQTT.groov.com

Here you could use a broker running on a local device like your Mac, Linux, or

Windows PC, a Raspberry Pi, or cloud service like Amazon Web Services.

The default secure port for MQTT is 8883 but I'll just be using the

insecure broker 1883. Many brokers are encrypted or password protected but

this one is open to the public so we'll leave username and password blank. The

final setting screen shows three additional optional messages birth, death

and will. I'll come back and set these up later once we know everything else is

working. So now with the broker setup we're almost ready to subscribe. The next

thing to look at is the topic. The topic namespace is an unmanaged way to

identify your messages. I say unmanaged because there is no enforced format or

standard to follow. Each client determines the topic of that devices

messages which means you as the programmer have to be consistent and

specific with your topics. And you'll need to share it with anyone else that

interacts with your broker since they'll need to know what to subscribe to and

what to publish to. This is a lot of freedom but I'll keep things simple for

this example and just use workshop slash switch. Where switch is called a sub

topic of workshop. I could have workshop itself be a sub topic of

something larger or I could just publish directly to the topic switch but that's

going to depend on your application.

Next I can choose the quality of service which is a big part of MQTT. In short it

determines how much of a guarantee of delivery you want for your message.

0 quality of service means that the broker received the message at most once. But

might miss it since there is no confirmation made. Quality of service 1

means that the broker will receive the message at least once but may get

duplicates while it's waiting for confirmation. And finally Quality of

Service 2 means that the broker will receive the message exactly once. The

highest quality of service sounds the most attractive and

for control purposes it is really the only option worth considering but it

does come at the cost of extra network traffic since the broker and client must

exchange confirmation packets. Particularly for quality level 2 since

both sides have to acknowledge the publication. Now with my subscribed

client all set up I'll need to use this switch message to toggle a light.

To do that I'll use the SNAP PAC write Node. These are used to interface with

the i/o modules installed on the groov EPIC chassis. This will just connect to

the local host device since Node-RED itself is running on the groov EPIC. And I'm

going to be writing to the digital output I have setup on the system

strategy called panel red LED. And that's all there is to setup.

If I wanted, just for testing, I could also add a debug node to double-check

the output here as well. Now with my Node-RED flow all set up

I'll hit deploy. And, now I just need to publish to this topic to test it out. To

do that I'll be using a separate client running on this laptop called MQTT FX.

Once it's loaded I just bring up my server list and I can go ahead and add

the broker. In this case it'll be the same public broker that I added to Node-RED

it's at MQTT.groov.com and I am using the insecure broker port 1883. And,

I'll not be putting in a user name or password since it's open to the public.

Now I'll just hit apply, close this window, and connect to the broker. Now all

I need to do is publish to that same workshop / switch topic and give it a

message. And, in this case I want to turn the switch on so I'll send the message

true. Now all I have to do is publish and the light comes on. Fantastic!

The connection is both sound and very fast and if I were to use my own broker

I can encrypt the data and securely password protect it - in this case the

publishing client is my laptop.This represents the switch. It publishes the

switch state up to the broker and then the broker relays that message down to

Node-RED on the groov EPIC where it makes the control decision to turn on

the light. So now that we know everything is working let's take a quick look at

some of the more advanced features that I skipped. Birth, death, and will messages,

retain topics, and finally wildcards. So if I go back to Node-RED

and bring open the broker properties I can see those three messages birth,

death and will. Like the node info tab says these messages are sent whenever

this device connects, disconnects and is forcibly disconnected from the broker.

For example I can have the birth message publish under the topic workshop slash

status and give it the payload: Online. Since that will be the status once this

message is sent. Because I want this to arrive at least once I'll give it the

quality of service level 1 and I'll turn the retain flag to true you'll see what

this does in just a moment. Similarly with the closed message or a death

message I can say "offline". Since when I successfully disconnect the workshop

status will be offline I'll give it the same quality of service and retain flag

now with these two messages setup I can just listen to this one workshop status

topic and I'll be able to track the state of this device as it comes on and

offline. But if it drops unexpectedly without sending a disconnect message I

want to know that this is handled by the will or last will and testament

message. This message gets sent by the broker if this client ever unexpectedly

disconnects. So, in this case I'm going to use that same workshop status tag and

give it the payload "disconnected". Since it is an abrupt disconnection that

causes this message to be sent. Now I'll save these new settings, deploy,

and head over to MQTT FX to subscribe to this message. What's great about the

retain flag for MQTT topics is that I can now subscribe to this status and

I'll get the message right away when I connect because it was set to retain it.

Now the broker will keep track of the latest copy of this tag to come in,

retain that data, and send it out to anyone that comes and subscribes to this

topic. While I can't use this feature to request the state of the device at any

time it does mean that new devices to join the system are aware of the health

of all the other clients that are already connected. So, now to test this

out. If I go and make a change to my Node-RED flow and deploy that should mean

that this client disconnected and reconnected. And if I go back to MQTT I

can see that the disconnect message went through and let me know that my device

was offline and then it came back up and I got another message. Finally I want to

see the last will and testament. So, to test that one out I'm going to try and

use a wild card. A wild card is essentially a way to select any matching

topic. For example if I wanted the status of every device, not just the

workshop, I could replace workshop with the single level of wild card "plus". And

what this does is plus will replace anything that matches a subtopic status.

So if I subscribe to that I'll be getting both a copy of the workshop

status and a copy of the developer status, which is another machine running

in the building.

The other thing I can do is subscribe to a workshop slash hashtag or the pound

character. This is a multi-leveled wildcard that will match all sub topics

of workshop including both switch and status. And if status had any sub topics

it would get those as well. It's also possible to get everything matching

every single topic by just using a single multi-level wildcard on its own.

But this gets a little bit loud so it's usually not recommended.

I'll unsubscribe from these topics and just use that single level wildcard plus

slash status. To test the last will and testament when I subscribe

I see the retained messages come in. Then when I unplug the ethernet cable on my

groov EPIC it disconnects from the internet and the broker lets all the

subscribed clients know that this device has dropped. This "disconnected" here is

that last will and testament message. Using this it's possible to monitor the

health of your various devices and even have a system in place to alert you when

something is down, attempt to reboot it, or shift that devices responsibilities

over to another system. And there you have it, there's a quick run through of

MQTT and its place in the Internet of Things. To learn more check out

opto22.com Thanks for watching.

you